There is a shift happening…
There is a shift happening in how engineering leaders describe the people they want on their teams, and it is showing up in the language before it shows up anywhere else. Job descriptions are starting to read differently. The conversations we have been having with CTOs and VPs of Engineering are starting to sound different too. The role is changing, and the people closest to it can feel it.
This piece pulls together what those leaders have been telling us. It is not a prediction. It is a description of a change that is already underway, drawn from the interviews behind our wider research into AI in software engineering.
Code stopped being the expensive part
For most of the history of the industry, writing code was the constraint. Custom software development was slow, it was costly, and the people who could do it well were rare. A great deal of how engineering teams are structured, how they plan, and how they hire was built around that single fact. You did a lot of work upfront precisely because the act of building was expensive enough to be worth protecting from mistakes.
That assumption is now under real pressure. One leader described pushing eleven pull requests in a week after barely touching code for the previous six months, the difference being that he could now prompt a change between meetings and come back to working code. Another talked about a single application going from seven thousand tests to eleven thousand in three months, after it had taken eight years to reach that first number. The leaders we spoke to were careful, and several were sceptical of the louder claims in the market, but the direction was consistent. The cost of producing code is falling, and it is falling fast enough to change what the job is.
“When the expensive part of a job gets cheaper, the value does not disappear. It moves. And the leaders we interviewed were remarkably aligned on where it is moving to.”
The new bottleneck is everything around the code
Several leaders made a version of the same point: their problem is no longer how fast their teams can write software. One put it plainly, saying his biggest challenge was not having more people to produce code, it was that his teams were now producing too much of it for the rest of the system to absorb. Reviewing, building, testing, deploying, deciding what to build in the first place. Those are the constraints now.
This matches something our wider research kept surfacing. Development time is rarely the real blocker to product velocity. The bottlenecks tend to sit upstream, in unclear requirements, weak product decisions, and friction between engineering and the rest of the business. AI that makes code cheaper does not fix any of that. If anything it exposes it, because the part of the process that used to absorb the slack is now moving faster than everything around it.
So the engineer who is most valuable in this environment is not the one who can produce the most code. It is the one who can operate well across the whole path from a business problem to a shipped, working change. That is a different person, and the leaders we spoke to are starting to hire and organise around that difference.
What leaders are actually describing
When you collect the descriptions together, a fairly clear picture emerges of the engineer that leaders now say they want.
They want someone with high agency. More than one leader used almost that exact phrase. The distinction they drew was between an engineer who reads a ticket and executes it precisely as written, and an engineer you can hand a problem to and trust to go and solve it, including working out what the problem actually is. One leader estimated that the first type made up the large majority of the engineers he had encountered through traditional outsourcing, and that the rare exceptions, the ones who thought beyond the ticket, were the ones his company found a way to hire permanently.
They want strong communication, and they mean it more literally than the phrase usually implies. One leader pointed out that when you prompt an AI agent, you are communicating in plain language, so written communication is now part of the technical craft itself, not a soft skill bolted onto it. The same leader noted that as the work shifts away from constructing code, the engineer ends up closer to the business, dealing more directly with what the requirement actually is rather than just the functional spec handed down to them. Clear writing and clear thinking about requirements have become core competencies.
They want people who can work in vertical slices. One leader described moving away from allocating several engineers to a project and towards putting a single engineer on it, expected to work across the whole thing end to end rather than staying inside a backend or frontend lane, pulling in specialists for advice rather than handing off. The dedicated development team of four or five becomes a much smaller group, sometimes one engineer alongside a product person and a designer, sometimes less than that. The compressed role is the unit of work now.
This has consequences for how teams are resourced. The leaders we spoke to who used third parties were clear that the model that works is team augmentation rather than arms-length outsourcing, engineers who integrate fully into the team and own a real part of the mission, not a vendor you brief and wait on. As the role gets broader and more judgement-led, IT staff augmentation that drops in ticket-takers looks less and less viable. What these leaders want from outside help is the same product-minded engineer they are trying to hire directly.
And they want people who can let go of their code. Several leaders touched on this, and it was one of the more human observations in the interviews. A lot of engineers, particularly experienced ones, have their identity tied up in writing code and in the code they have written. One leader described the future model as engineers producing a high volume of work knowing that most of it will be rejected, with people who have judgement and taste doing the choosing. He pointed out that this is hard for engineers who get attached to their work and sensitive about review. The engineer who thrives treats the code as more disposable, and treats the judgement about what is worth keeping as the real contribution.
Taken together, that is a recognisable role. It is an engineer whose value sits in judgement, communication, breadth, and the ability to take an idea from wherever it comes from and turn it into product. Some leaders would call this a product engineer. Whatever the label, the leaders describing it are describing the same person.
Want to talk product engineers?
30-minute intro call. No commitment or cost.
Why this is a real shift and not just new vocabulary
It would be easy to read this as the industry rebranding. Good engineers have always cared about the product, the argument goes, and the best ones have always thought beyond the ticket. There is something to that. One leader was clear that the rediscovery of older, sound engineering practices is part of what is happening here, not the invention of something entirely new.
But the leaders we spoke to were describing structural change, not a change of emphasis. Hiring is the clearest example. Several said the traditional technical assessment has stopped working, because there is no reliable way to tell whether a take-home test was done by the candidate or by an AI. That is not a tweak. It forces interviews to shift towards judgement, debugging, critique of AI-generated output, problem decomposition, and how a candidate actually collaborates with the tools. The thing being assessed is changing because the thing being valued is changing.
Team structure is changing too. A flat headcount with an AI budget instead of new hires, projects staffed with one engineer instead of four, the open question of whether you even need the product layer in its old form. One leader described finally bringing in an experienced product leader to mature the old way of doing product, only to find that AI was making that old way itself questionable. Another pointed out that getting real value from AI agents often means a serious investment in legacy software modernization first, simplifying and unifying a codebase so an agent can work in it safely. These are not cosmetic adjustments. They change who gets hired, how they are organised, and what their day looks like.
And the leaders were honest about the discomfort in it. The same change that elevates the judgement-led engineer is unsettling for engineers whose sense of their own value is built on output. One leader framed it as a genuine change management problem, not a tooling problem. People associate their worth with how well they execute their craft, and this shift takes some of that execution away. That is a real cost, and the leaders who seemed most clear-eyed were the ones treating it as such rather than pretending it away.
What this does not mean
It does not mean fewer engineers. The leaders most credible on this were sceptical of the boardroom assumption that AI simply means you can stop hiring. One described that view as a finance-led mentality, and argued the companies that win will be the ones that realise they need more engineers, not fewer, because each engineer can now carry far more. The roles change. The headcount logic is not as simple as it looks from the outside.
It does not mean code knowledge stops mattering. Quite the opposite. Leaders were consistent that the engineers who get the most from these tools are the senior ones who can look at generated code and immediately see where it is wrong, because they hold the design patterns and the architecture in their heads. The same leaders worried openly about junior engineers, who can now commit plausible-looking code they do not understand, and about the skill erosion that follows. The judgement that makes a product engineer valuable is built on exactly the deep technical grounding that the role is sometimes assumed to move away from. It does not replace that grounding. It sits on top of it.
And it does not mean AI is a finished story. Several leaders pointed out how recently the tooling crossed the line into genuine reliability, and how much is still unresolved, from technical debt to testing to what agentic delivery does to a team over a longer period. The shape of the product engineer role is becoming clear. The environment it operates in is still moving.
Where this leaves engineering leaders
If the role is changing, the practical questions follow from there. How do you assess for judgement and communication when the old technical filters no longer hold. How do you help your senior engineers move towards orchestration and review without losing what made them good in the first place. How do you bring junior engineers along so they build real depth rather than a dependence on the tools. How do you structure teams when the unit of delivery is getting smaller. And how do you manage the genuine human cost for engineers whose sense of their value is tied to the part of the job that is changing fastest.
None of those have settled answers yet. But the leaders who seemed best positioned were not the ones with the most aggressive AI adoption or the most tooling. They were the ones who had noticed the role itself was changing, and had started to think clearly about what that meant for how they hire, organise, and lead. The language in the job descriptions is shifting because the job is shifting. The leaders worth listening to are the ones treating that as the real story.
Working through what this means for your team
If the shape of the engineering role is changing, the way you hire, structure and support your team has to change with it. This is the kind of problem we work on with engineering leaders: how to build a dedicated development team around judgement and product thinking rather than raw output, how to bring AI into custom software development without accumulating hidden technical debt, and how to resource through team augmentation that genuinely integrates rather than outsourcing that holds you at arm’s length. If any of that is live for you right now, we are happy to talk it through.
Want to chat product engineers?
We’ve seen first hand how the world of software is changing and we’ve fully embraced it. If you want to learn more about what we’re doing in this space, give us a call.
