Two facts about AI and software engineering sit awkwardly next to each other.
The first: adoption is close to universal. Most professional developers now use AI assistants daily, and a growing share say they wouldn’t want to work without them.
The second: the most methodologically rigorous attempt to measure what those tools do to productivity found a slowdown.
Both are true, and the space between them is where most engineering leaders are currently making staffing decisions — usually on the basis of a vendor slide rather than either fact.
The study that complicated everything
In July 2025, the research nonprofit METR published a randomized controlled trial. Sixteen experienced open-source developers completed 246 real tasks — bug fixes, features, refactors — in mature repositories they had contributed to for years. Each task was randomly assigned to allow or disallow AI tools.
The developers predicted AI would make them roughly a quarter faster. After finishing, they estimated it had. The measured result was the opposite: tasks took about 19% longer when AI was allowed.
The gap between perception and measurement is the finding that should concern anyone running an engineering organisation. It isn’t that the developers were bad at their jobs or bad at prompting. It’s that self-assessed productivity turned out to be badly unreliable — and self-assessment is precisely what most companies are using to justify their AI strategy.
The mechanism is intuitive once you see it. Writing code got faster. Everything around writing code got slower: prompting, reading output you didn’t write, verifying it against constraints the model couldn’t see, and repairing the misses. The visibly fast part felt like acceleration. The slow part felt like ordinary engineering.
METR was unusually careful about what the result does not show. It studied experienced engineers in large, familiar, high-standard codebases during a specific model window. It doesn’t describe juniors, greenfield projects, prototypes, or later tool generations — and the researchers said so explicitly.
There’s a postscript worth knowing. When METR tried to repeat the experiment with a larger group and newer tools, they reported in early 2026 that the data wasn’t giving a reliable signal, partly because too many developers now decline to participate in any study that requires working without AI. That’s a failed measurement and, at the same time, a genuine observation about how entrenched these tools have become.
The hiring data is clearer than the productivity data
While the productivity question stayed contested, something more measurable was happening in the labour market.
Researchers at the Stanford Digital Economy Lab, working with payroll data covering millions of US workers, have tracked employment by age and by how exposed an occupation is to AI. Their headline finding, first published in 2025 and updated through mid-2026, is that workers aged 22 to 25 in the most AI-exposed occupations — software development prominent among them — now sit roughly 19% below where their employment would be had it kept pace with similarly aged workers in less-exposed jobs. Experienced workers show no comparable gap.
Three details matter more than the headline number:
It’s a hiring effect, not a firing effect. The gap comes primarily from roles that were never opened, not from people being let go. Nobody announced this. It happened through job requisitions quietly not being posted.
It splits on automation versus augmentation. Where AI substitutes for tasks, entry-level employment fell. Where it complements the work, employment held steady or grew. Same technology, opposite outcomes, depending on how it was deployed.
The proposed mechanism is codified versus tacit knowledge. AI is strongest at the formal, documented, teachable knowledge that a graduate arrives with. It is weakest at the judgement acquired through years of doing the work — knowing which edge case will bite, which abstraction will rot, which reviewer to ask.
This is contested, and honestly so. Economists at Stanford’s own policy institute have noted that the decline began around the time of aggressive interest-rate rises and post-pandemic tech over-hiring, both of which independently depress junior hiring; at least one study in Denmark found no difference between AI-adopting and non-adopting firms. The researchers’ response is that the divergence persists after controlling for those factors and has continued widening well after rates peaked. It’s suggestive rather than settled — but it is the best data available, and it points somewhere.
What this actually does to team shape
Put the two findings together and a picture emerges that is neither the optimistic nor the apocalyptic version.
Code review became the bottleneck. When generation is cheap and verification is expensive, the constraint moves to whoever can competently evaluate output. Teams that added AI without adding review capacity produced more pull requests and shipped no faster.
The valuable skill shifted from writing to judging. Reading unfamiliar code and deciding whether it’s correct is cognitively harder than writing code you already understand. That skill correlates strongly with experience — which is exactly the profile the hiring data says is holding up.
Teams got flatter and more senior. Fewer people, each doing work that used to be split across levels, with the routine tasks that once trained juniors now absorbed by tooling.
And that creates the obvious problem nobody has solved: if the on-ramp closes, where do the seniors of 2032 come from? The tacit knowledge that makes experienced engineers valuable is acquired by doing the routine work first. A company that stops hiring juniors is optimising its current quarter against its own future supply — and if the whole industry does it simultaneously, the scarcity that follows will be entirely self-inflicted.
The hiring consequence most companies underestimate
If your team is getting smaller and more senior, every individual hire matters more, and the pool you’re hiring from is thinner.
This is compounded by where demand has concentrated. ML engineering, model evaluation, data infrastructure, and AI-adjacent security are scarce specialisms that price at or near international rates almost everywhere — the geographic arbitrage that made offshore hiring attractive largely disappears at the top of the market. What you’re competing for is a small number of people who are experienced enough to be trusted with judgement, and they are not conveniently distributed across your existing offices.
Which turns a talent problem into a logistics one. When the right person is in a country where your company has no legal presence, the sourcing was the easy part. You then choose between incorporating a local entity — reasonable for a team, disproportionate for one hire — engaging them as a contractor, which is fast but carries reclassification risk once the arrangement is full-time and indefinite, or hiring through an Employer of Record that employs the person locally on your behalf and handles payroll, contracts, and statutory obligations while they work entirely for your team.
The reason this belongs in an article about AI is straightforward: the tooling made your team smaller and more senior, seniority is scarce, and scarcity means you no longer get to filter candidates by geography. The employment mechanics stopped being a back-office detail the moment your shortlist went global.
What to do with all this
Stop measuring AI impact by asking people how it feels. That’s the one thing the research establishes firmly. Measure cycle time, review throughput, change failure rate, and whether things actually ship sooner.
Fund review capacity alongside generation capacity. More code with the same review bandwidth produces a queue, not velocity.
Deploy AI where it augments rather than substitutes. The employment data suggests this distinction predicts outcomes better than adoption rate does — and it’s a choice about how you set the tools up, not a property of the tools.
Keep a junior pipeline deliberately, and restructure what juniors do. If the traditional training tasks are automated, the training has to come from somewhere else: structured review apprenticeship, pairing on verification, ownership of small systems end to end. This is a cost, and it’s cheaper than the alternative.
Hire for verification skill. The ability to read unfamiliar code and find what’s wrong with it is now closer to the core of the job than the ability to produce code quickly. Most interview processes still test the second one.
The companies that will look smart in five years aren’t the ones that cut hardest or adopted fastest. They’re the ones that noticed which parts of the work actually got cheaper, which parts got more expensive, and staffed accordingly.
