In mid-2025, the research group METR ran a randomized controlled trial. Sixteen experienced open-source developers worked through 246 real tasks in repositories they already knew well. When they were allowed to use AI tools, they took 19% longer. Before starting, they predicted AI would make them about 24% faster. After finishing, they still believed it had made them about 20% faster. That gap, between how fast the code felt and how long it took to get it right, is the most useful number I know for anyone trying to hire or buy engineering talent right now.
Here is my position after eleven years running a software studio. Engineering talent is now measured at the code review. The engineer worth paying for can read a large diff, whether a colleague, a contractor or a model wrote it, and point to the few lines that will wake someone up at 3 a.m. In the last three years, typing speed, framework breadth and output volume got cheap. Judgment about what should not ship did not, and every serious dataset on AI-assisted development points to that same constraint.
The Consensus: AI Shrinks the Talent Problem
The common view goes like this. Assistants make every engineer more productive, so you need fewer of them. Juniors start performing like mid-levels, mid-levels like seniors, and the talent shortage eases. The adoption part is real. In Stack Overflow's 2025 developer survey, roughly 84% of respondents said they use or plan to use AI tools in their work.
The same survey also contains the detail the consensus skips. More developers said they distrust the accuracy of AI output (around 46%) than said they trust it (around a third). The people closest to the output are reporting that the work has moved rather than disappeared. It has moved from writing code to checking it. A tool that most of its users don't fully trust doesn't remove the need for judgment. It adds more things that need judging.
Where It Breaks: More Code, Less Stability
Google's DORA 2024 report gives the clearest team-level figure. Across its survey population, a 25% increase in AI adoption was associated with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. The mechanism is not mysterious. Generated code arrives in larger batches, pull requests get bigger, and review is the stage that has to absorb the extra volume. When a team produces code faster than it can evaluate it, the surplus becomes inventory: unreviewed, poorly understood, and waiting to fail in production.
The METR result fits the same picture. The developers in that study were not slow typists. Their time went into prompting, waiting, reading suggestions, and fixing output that was almost right. Generation was never the scarce step for an experienced engineer. Verification was, and AI tools make verification heavier.
What the Scarce Skill Actually Looks Like
Reading Well Matters More Than Writing Fast
A senior engineer's real output is the set of bad changes that never reach main: the missing index on a table that will hold ten million rows, the retry loop that double-charges a card through Stripe, the permission check that works in staging only because staging has one tenant. None of this appears in a lines-of-code metric, and all of it decides whether a platform survives its second year. When a model can produce the first draft in seconds, the person who can say why that draft is wrong is the whole value of the hire.
Scope Judgment Is Engineering Talent
The most valuable engineering decision I have watched in recent years involved deleting work rather than writing code. When we took over Meal4U, the previous team had failed to deliver. We spent a week taking the scope apart and re-estimated it about ten times, cutting 30 to 50% on each pass, until we found the smallest product that could actually ship. No assistant proposes that. A model will generate everything in the backlog if you ask it to. Deciding which 70% of the backlog should not exist yet takes someone who has watched over-scoped builds fail.
Specification Is Where Seniority Shows First
When HeyTutor's founders came to us, they had a one-page spec. Before building, we turned it into a 40-page one, because most of what makes a marketplace hard is invisible on page one: payouts, disputes, cancellations, what happens when a tutor no-shows. AI coding tools execute whatever intent you give them, very quickly. That makes it far more costly to get the intent wrong, and only experienced engineers reliably catch that before the sprint starts.
The Pipeline Number That Should Worry Every CTO
In 2025, Stanford's Digital Economy Lab analyzed payroll data and found that employment of software developers aged 22 to 25 had fallen by nearly 20% from its late-2022 peak. Employment of older, more experienced developers held up far better. The market has read the AI story and cut the entry level.
The consequence arrives on a delay. Reviewers come from years of shipping code, getting paged, and living with their own mistakes in production. A smaller cohort of juniors today means fewer people five to eight years from now who can read a diff and know where it will break. The engineering talent that AI makes more valuable is the same talent the current hiring market is producing less of. I expect senior review capacity to get scarcer and more expensive through the rest of the decade, and teams that already have it will be ahead of teams planning to hire for it later.
How We Price Review Into Delivery
At EltexSoft, one rule sits above sprint velocity. Every pull request is reviewed by at least one other senior engineer before it merges. Every engineer on our team of 35+ has at least five years of production experience, so the reviewer has shipped and supported systems like the one under review. Our engineers use Claude Code and Cursor every day. We treat them as reviewed accelerators: their output goes through the same review as a new contractor's code, with no exceptions for a clean-looking diff.
The rule has a cost, and we pay it on purpose. Some weeks, review is the slowest stage in the pipeline. We would rather a change wait a day in review than cost a client a week in incident response. It helps that our DevOps work is owned by the engineers who write the application code. The person approving a migration is often the person who gets paged if it goes wrong, so they have a direct stake in reviewing it properly.
What This Means for Hiring and Buying Engineering Talent
The most revealing interview we know gives the candidate a real pull request with three planted defects and one subtle design problem, then measures what they find and how they explain it. A candidate who finds the design problem is worth more than one who rewrites the function faster. The equivalent test for a vendor is to ask for anonymized review threads from a live project. Long, specific threads mean judgment is being applied. A history of one-word approvals means it isn't, however strong the résumés look.
The cost comparison changes too. A senior-heavy team at $50 to $99 an hour looks expensive next to cheaper hourly capacity paired with AI tools. But if the DORA figures hold, extra output without extra review capacity buys lower stability, and lower stability gets paid for in rework, incidents and rewrites. An hourly rate reflects how much code gets written. What matters to the business is how much code survives.
If this argument is right, the best way to judge a team is to watch its review process on your own code rather than read its pitch. That is why our engagements start with a free discovery week followed by a paid pilot with no lock-in. During the pilot you see the pull requests, the review threads and the decisions about what to cut, all in two-week sprints with daily standups. The next step is to book the discovery week and bring the part of your roadmap you're least sure about.
Last updated October 14, 2026