You can also watch this on Youtube.
If I had a tech company today and I had to choose between hiring a junior engineer or a senior engineer with 10 years of experience who has only ever focused on writing code like a code monkey and completely ignoring the product side of things, I would definitely hire the junior. Hands down, no hesitation.
I know that sounds crazy, especially right now when everyone is panicking about junior developers being replaced by AI. But I think junior engineers now have a really unfair advantage that most people in our industry are completely ignoring.
Everyone is asking the wrong question
There’s one question that you see over and over on social media nowadays, since AI came into our world. What about the junior developers? How are people going to grow into senior developers when AI can do their job? How are juniors going to practice? How are they going to make mistakes if they don’t touch the code and grow into the profession?
I get it. It’s a legitimate concern. But I think that people asking these questions are thinking about it completely wrong.
They’re assuming the only way to grow as an engineer is through writing code, through mastering a tech stack, through years of repetition. And that’s exactly the kind of thinking that’s going to get people replaced. Not juniors, but the seniors who think like that.
Junior engineers coming into the industry right now are still learning how everything works. They have not been polluted by the “always.” They’re still malleable. Their tech brain is still evolving, and that’s the best time to create the engineers of the future.
Writing code is the easiest part
Everyone is focused on the fact that AI is getting very good at writing code, and really, it is. That’s undeniable. But writing code is the easiest part of software engineering.
Think about what actually makes a product successful. It’s not the code. It’s understanding what to build. It’s clarifying messy requirements. It’s talking to users and figuring out their real problems, not the problems they tell you they have, but the ones you discover by watching them struggle. It’s making architectural trade-offs. It’s dealing with production accidents at 3:00 AM when something breaks in a way nobody anticipated. It’s understanding how your changes affect the system as a whole. System thinking.
AI cannot do any of this. And this is exactly where product engineers live. This is the work that matters.
So when people say AI is going to replace junior developers, what they really mean is that AI is going to replace the grunt work. The boilerplate, the simple bug fixes, the repetitive coding tasks. And you know what, that’s amazing, because that was never the valuable part of the job anyway. And plus it sounds more like exploitation than actually teaching anything to junior developers, really.
Start from the problem, not the tech stack
I’m going to say that the best way for junior engineers to get into the industry right now is to stop thinking about tech, at least as the first thing. Stop thinking about what tech stack you should learn. Start thinking about whether it even makes sense to learn coding or not. Instead, start working from a product problem.
Let me give you an example. Let’s say you have this onboarding that is not working well, and people are churning after the first step. Let’s see why. You don’t need to be an expert in product or a UX designer or any of that to start doing this. Otherwise, what’s really the point of being a junior developer who is learning?
You start from there, from the problem. Let’s go look at the session replays. Let’s maybe go talk to some users. Let’s do some usability tests and watch people using the onboarding and see where things break. These are really simple instructions, some guidelines that junior developers can follow. And of course, that means they’re probably not going to do a great job initially. That’s expected, which is perfectly fine.
The best thing is that they will start understanding and seeing how things work. They will start thinking not in terms of solutions, but in terms of problems to solve.
Once they identify the problem, they can start doing some research. They go online to look for best practices. They ask AI. They go ask their senior engineers or other people in the company who understand what they’re doing. How can I do this? What’s a good approach? What do you recommend? And it’s perfectly fine for them to also just try something, anything, and see what happens.
For this to work, you need to work in a company that makes failure a first-class citizen of the system. You must fail to learn. That’s inevitable. And most of the time, that’s the best way to learn, together with working from a problem and not from a solution. That’s also the best way to develop problem-solving skills.
Once the problem is found, the junior product engineer can also suggest how to improve the experience and eventually change it in the code. I expect a junior engineer to have a basic understanding of programming. If they’ve done any courses or university degrees, I am pretty sure they have a good foundation to become dangerous with code. You don’t need 10 years of experience. It is completely feasible to do it from day one. They will need to interact with the code and understand what effect the changes have on the codebase. But I would say it’ll be better to work in an AI-assisted way, using AI to talk with the code, try to understand what’s going on, and implement the changes.
How I accidentally became a product engineer
All of this makes me think about my first job back in 2016 as a software engineer. I just came out of university, but I had already started programming when I was 15 years old. So I had developed some experience, but not really production experience. Mainly some side projects, playing with it. The university really helped me get some better knowledge about databases, software engineering principles, and the stuff there.
In this company, my first job was very challenging. The company was called ViriCiti, a startup in Amsterdam that was building a monitoring system for electric buses all around the Netherlands and in other countries. I was tasked with building the system to update the software on the devices on the buses. We had these small devices running, reading data from the buses, and the system needed to update both the operating system and the applications running on it.
I’ve always been kind of a curious person, really entrepreneurial and proactive. So I thought, let’s just get on with this. Let’s see what I have to do. I just followed my gut.
That instinct to start from the problem is what really made a difference. I didn’t just sit down and code. I went to my colleagues and asked them: what’s the problem that we’re trying to solve here? What does the current process look like? What’s breaking? And I built prototypes and put them in front of people before building the real thing. I watched how they used it and iterated based on their feedback.
That’s the product engineering way of working, in my opinion. Even though back then, I really didn’t know I was doing that.
Did I write the best code? I think not. I probably over-engineered it a lot because I was following design patterns and everything, and I wanted to impress my colleagues. But I already knew a bit of test-driven development, which was very helpful in writing some good code. And while developing, I was also learning at the same time: React, Redux, how to write better CSS, and I was studying how to use Node.js, streaming and APIs.
Eventually, I did it, of course, with help from the CTO and my colleagues. But it was one of the most successful projects of my career, and I still remember it. Back then, I didn’t realise that I was accidentally doing product engineering. I was just trying to solve a problem the best way I could.
Hyper-specialisation is the real risk
I think new engineers really have the opportunity to start with a fresh perspective about how products are built. They can easily overcome senior engineers who have been stuck in their ways for ages, who have only been focusing on the tech part.
Those engineers are the ones who risk more to be replaced by AI. Because AI is getting very good at writing code. Anything that is hyper-specialised is something that AI will do very well eventually, because hyper-specialisation means you have seen the same pattern over and over and over, and you want to apply it. That’s exactly what LLMs are good at. Pattern recognition and applying a solution to a specific problem that’s been seen before.
If anything, the learning process for juniors will be sped up way more thanks to AI. You have a personalised coach that can help you along the way. In the beginning, you are not an expert in product discovery, you’re not an expert in experience design, you’re not an expert in software architecture. But junior engineers can now use a mix of working with mentors together with an AI coach that can give them feedback.
For this to work, it’s very important that these new product engineers work in a company that enables them to do this, that accepts failure as the only way to grow. The best way to grow as an engineer, as always, is by testing something, seeing how it works out in the wild, and getting feedback. Nowadays, with AI, you can do this very quickly. You can build stuff very fast, and you can get feedback more often.
Junior engineers have an unfair advantage of having a very fresh pair of eyes, a very fresh brain that they can use to learn new ways of thinking. They will do way better than engineers who are stuck in their ways.
A playbook for getting started
Now you may say, this is great, but how does it work in practice? How can I get experience if I’m not hired by someone?
Back before AI, what you would do was work on a side project, maybe, or do an internship. You’d try building a Twitter clone or a parking system. Whatever your imagination is, your only limit. You were trying to reproduce a solution, something that already exists.
I think it’s pretty much the same now, but better. You don’t need to be an entrepreneur or a founder to start building a product. You can look at your life and see what problems you have. You can ask friends, ask your family. Ask your communities locally or online. Go out there and look for a problem to solve with your skills. A real problem, not a technical problem, something that is really human.
Then you start talking to people. This is the problem I have, and I have an idea on how to solve it with a tech product. I have a set of hypotheses that I need to validate. You start talking to people, doing interviews, gathering insights about how they behave and what their needs are. Maybe you can do this while reading Continuous Discovery Habits by Teresa Torres, which is one of the best books on the topic.
Once you do this, you can start prototyping. You can do this with Lovable, v0 or Replit. Nowadays, it’s so easy to build a prototype. The same people you interviewed before, you can run some usability tests to see how they use the software, if it makes sense, if there’s any friction. Maybe you can create a landing page and show it to the people you’re talking to, and ask what they think about what the product is going to solve and how it’s going to help them.
Once you have a good understanding of the direction, you start building it properly with Cursor or whatever you like, in an AI-assisted way. You build your first version, your minimal viable product. You ask people to become beta testers so they can use it. You set up monitoring and analytics so you can see what’s working and what’s not. You set up weekly calls with these early customers or users to get their feedback.
In the worst-case scenario, you have learned a lot about how to run a product. You have learned about the end-to-end process of developing a product. In the best case scenario, you may have actually found something that people need, something that they will pay for, and then you can become an entrepreneur. That’s also an option. And really, it is not a coincidence that at PostHog, the pioneering company that made the product engineer role famous, they mainly hire people who were working as entrepreneurs before. That tells you something about it.
Once you’ve done this, you can start looking for companies. I would say the best way is to look for early-stage startups where they would love to have people who understand what it takes to build a product and are not scared to get out there and talk to customers. People who are entrepreneurial and are generalists with a broad skillset.
Portfolios have also completely changed. It doesn’t make any sense to have these websites where you list all the technologies you know, and that you worked as a front-end developer and back-end developer, developing this or that feature. Really, no one cares anymore. It’ll be much better to have a website where you describe how you tackle product problems. Maybe like a case study. You write about it, and if you want, you can even talk about this on social media, on X or LinkedIn. It’s always a good thing to position yourself in your niche, to write about this stuff, so other people know what you’re doing, and recruiters come to your profile and see you have this kind of thinking.
A lot of companies are not hiring junior developers because it’s difficult to train them, and there’s a high supply of senior software engineers. But not all senior developers can be product engineers. They’re stuck in their ways and only focused on their tech side. There is an opening for junior product engineers who can work with the startups being built right now in the AI space.
I’m pretty much convinced that once you prove you can work like this, a lot of opportunities will start to open up for you.
A message for engineering leaders
If you are a manager or a leader, this part is specifically for you. Charity Majors said something that should keep every engineering leader up at night: “By not hiring and training up junior engineers, we are cannibalising our own future.” AWS CEO Matt Garman called replacing junior developers with AI “one of the dumbest things I’ve ever heard.”
So what should you do instead?
Redefine what a junior role looks like. Stop hiring juniors to write boilerplate. Hire them to solve problems. Put them in front of customers. Let them own the full loop from understanding the problem to shipping a solution and measuring if it worked.
Make failure safe. If juniors can’t fail, they can’t learn. Create an environment where trying something and being wrong is not just acceptable but expected.
Pair them with AI, not against it. AI is a force multiplier for juniors. They can learn faster, prototype faster, and get feedback faster. They still need mentorship from humans to develop the judgment that AI doesn’t have. The product thinking, the system thinking, the understanding of what to build and what not to build, and also understanding why. But AI can really help them get better feedback and speed up the learning.
The companies that do this will have a huge advantage in the next five years. The companies that don’t will be fighting to get a good product engineer.
Where to start
If you want to start this journey, let me give you three books that I think are essential for the path I’ve described.
Continuous Discovery Habits by Teresa Torres. This is the book for learning how to talk to customers, validate hypotheses, and make product decisions based on evidence instead of assumptions. It’s the foundation of the discovery part.
Extreme Programming Explained by Kent Beck. This is about the development process itself. How to work in small increments, test-driven development, and shipping continuously. It’ll teach you how to build things the right way.
Don’t Make Me Think by Steve Krug. It’s all about understanding how users actually interact with what you build. It’s short, it’s practical, and it will change how you think about design, even if you’re not a designer.
Whether you are a developer wanting to get started or a manager thinking about your hiring strategy, I hope this made you see the opportunity here. There is a lot of talent out there right now. People with fresh eyes and fresh brains who can be shaped into the product engineers of the future. Some companies are making the mistake of ignoring this. Don’t be one of those companies.
And if you are a junior developer, don’t wait for permission. Start building. Start from the problem. The tools have never been more accessible, and the opportunity has never been bigger.
