Code generation, solution exploration, faster execution on repetitive tasks, these are no longer experimental uses. They’re how teams work now. The conversation around it tends to focus on how much of a developer’s work AI will eventually handle, but from where I sit as a product manager, that’s not the most pressing question. The more relevant one is how this changes the way we build products.
Good products have never come from code alone. They come from understanding users, making good calls consistently over time, and solving real problems. AI supports a lot of that process, and those responsibilities still sit with the people behind it.
Building software goes beyond writing code
Progress in software is easy to measure by features delivered or lines of code written, but product development works differently. Delivering code means implementing a brief. Building a product means understanding the problem behind that brief and having a stake in whether it actually gets solved.
The teams that stand out are the ones asking better questions before they start: why is this being built, for whom, and what happens if we get it wrong. Those questions used to live in product meetings, and now they belong to everyone on the team, developers included. I’ve seen this happen gradually over the years, and AI is making it more visible.
When something looks finished quickly, it’s easy to mistake velocity for correctness. A prototype that used to take three weeks gets built in three days, and an AI-generated solution can be structurally sound and still be the wrong answer to the problem. Whether it solved the right problem is still a call that sits with the people on the team.
AI is changing where developers add value
Many development tasks that once required significant time can now be completed much faster. Generating boilerplate code, suggesting implementations, explaining unfamiliar code, helping investigate bugs, these are things many developers already rely on daily.
What AI doesn’t change is the need for engineering judgment. Someone still has to assess whether a solution fits the architecture, whether it introduces complexity that will be painful to maintain, and whether it actually serves the product’s goals. In my experience, understanding the context behind a feature is becoming just as important as implementing it correctly, sometimes more so.
Junior developers and the value of experience
Junior developers and their place in an AI-assisted workflow comes up in almost every conversation I have on this topic. The role will look different in the coming years, less about writing large volumes of code, more about understanding the problem, learning fast, and knowing how to get the most out of the tools available.
Practical experience stays essential for a reason that’s easy to overlook. AI can produce working code in seconds, but understanding why that code works, recognising potential issues, and knowing when a different approach is needed takes time. Those skills develop through real projects, code reviews, and a lot of trial and error. A junior developer who builds real understanding alongside the tools will be in a much stronger position than one who uses them to skip that process entirely.
The risk that's easy to overlook
When companies move fast with AI, the most common problem I see is that people stop questioning what the tools produce. Something that arrives quickly and looks polished is easy to trust, and that’s exactly where quality and security issues creep in. They don’t always show up right away, which makes them harder to deal with when they eventually do.
That problem looks different from a product perspective, but it’s the same underlying issue. A feature that gets built fast and looks complete can still miss the point entirely. Speed of delivery and quality of direction are two different things, and confusing them is one of the more expensive mistakes a product team can make. I’ve seen it happen, and it’s always harder to course correct than it looks upfront.
What changes when AI is part of the team
As a product manager, one of the most visible changes is how quickly an idea can go from conversation to something you can actually put in front of a user. Weeks instead of months. That changes how you plan, how you prioritize, and how much you can afford to test before committing to a direction.
When building becomes easier, choosing what to build becomes harder. That question carries more weight when the team can execute so fast, and I spend more time on it now than I did a few years ago. It’s where product thinking earns its place in an AI-assisted workflow, and honestly, it’s one of the more interesting parts of the job right now.
The skills that will matter in the next few years
Critical thinking and the ability to evaluate solutions will count for more than the ability to produce them. A solid grasp of architecture and how complex systems fit together becomes more relevant as the scope of what teams can build expands. Being able to articulate a problem clearly enough that AI can actually be useful on it is a skill that’s easy to underestimate, and one I find myself paying more attention to in conversations with developers.
The same goes for adaptability, the tools are changing fast enough that staying current is part of the job, for developers and product managers alike. And as roles grow more interconnected, being able to communicate across technical, product, and business areas becomes less of a soft skill and more of a core one.
Five years from now
My expectation is that teams will work differently, not that there will be fewer people in them. AI is already part of most workflows, and what I see so far is more efficiency and a sharper focus on impact. Roles are getting more flexible, and the line between technical, product, and business work is becoming less defined.
Technology amplifies what people bring to their work. That’s been true of every tool this industry has adopted.
Insights provided by Andrei Popescu, Senior Product Manager at DevHub.
