On 24 February 2026, METR, a donation-funded nonprofit that runs third-party evaluations of frontier AI models, published the kind of note research organizations avoid writing. The team announced a redesign of its developer productivity study because too many participants refused to work without AI tools.
The original result had become an article of faith among skeptics. In a randomized controlled trial run between February and June 2025 and released as a preprint, METR found that sixteen experienced open-source maintainers took 19 percent longer to close issues in repositories they had contributed to for years when they were allowed to use AI. They had forecast a 24 percent speedup. After finishing, still convinced they had been helped, they estimated a 20 percent gain.
The follow-up, launched in August 2025 with 57 developers across 143 repositories and more than 800 tasks, reversed the sign. Returning participants showed an estimated 18 percent speedup, with a confidence interval running from 38 percent faster to 9 percent slower. Newly recruited developers showed 4 percent. METR headlined neither figure, because between 30 and 50 percent of participants admitted withholding tasks from randomization rather than risk being told to do them by hand.
An instrument built to test whether programmers deceive themselves about AI stopped working because programmers would not give the tools up for fifty dollars an hour. The live question is no longer whether machines write acceptable code. It is who pays to check it, and what that bill is doing to the profession.
A standard humans never met
The common objection (”I will write it myself because it is more secure and more precise”) assumes a baseline that the comparative literature does not support. In a peer-reviewed test of exactly that question, Asare, Nagappan and Asokan prompted Copilot with the exact scenarios in which human developers had historically introduced C and C++ vulnerabilities. The tool reproduced the original vulnerable code roughly a third of the time and reproduced the human fix a quarter of the time. Their conclusion in Empirical Software Engineering: Copilot is not as bad as human developers at introducing vulnerabilities.
This does not make generated code safe. It establishes that the comparison was never machine against a clean record, but against decades of buffer overflows shipped by qualified engineers under deadline.
The demand that machines write perfect code was never a technical specification. It was a description of who currently absorbs the blame when code fails.
Nor does the resistance look like job protection. If it were, the pattern would be refusal. Instead Stack Overflow's 2025 survey of more than 49,000 developers found adoption at a record 84 percent while trust in accuracy fell to 29 percent from 40 percent a year earlier, with only 2.6 percent of experienced respondents highly trusting the output. Nathen Harvey, who leads DORA at Google Cloud and co-authored its 2025 report, declined to read that gap as a defect, calling it "a healthy level of trust" and adding that code needs a feedback loop whoever wrote it. METR's own staff gave the lowest productivity-gain estimates of any subgroup it surveyed, which the authors attribute partly to knowing the perception gap they found.
Generation was never the expensive part
The case for handing the work over usually arrives as arithmetic: a model doing senior work at half the price is a win even when the output needs correcting. The arithmetic sounds unarguable. No authoritative source establishes the halving and the evidence suggests the saving is booked in the wrong column.
Google’s DORA program, surveying nearly 5000 technology professionals, found 90 percent adoption and more than 80 percent reporting productivity gains. It also found what that narrative cannot absorb: higher adoption correlates with rising delivery throughput and rising instability at once. DORA’s work with 1110 Google engineers named the mechanism the verification tax, the effort re-spent auditing what was saved in writing. Verification is a different cognitive task from creation, and it does not scale with the thing generating the work.
METR’s February to April 2026 survey of 349 technical workers, a convenience sample its authors caution against over-reading, puts a number on the wedge. Median self-reported speed gain: 3x. Median self-reported gain in the value of work delivered: between 1.4x and 2x.
Writing code was never the binding constraint on shipping software. Reading it was, and generation at machine speed has made that constraint tighter, not looser.
This is where the accounting goes wrong. Cost per line of code was always a vanity measure and cost per unit of generated output is the same error with a larger denominator. DORA’s ROI framework, released on 22 April 2026, models adoption as a J-curve with a budgeted productivity dip, and is explicit about where the return sits: reinvest reclaimed capacity rather than cut headcount, because the gains come from eliminating rework rather than removing people.
What the compiler settled and what it did not
The sociology here has a close precedent. When John Backus proposed a high-level language for the IBM 704 in the mid-1950s, users doubted that anything compiled could match hand-written assembly. Backus’s own account records that his team treated the translator, not the language, as the real challenge, on the belief that object code appreciably slower than hand-coded equivalents would have destroyed adoption. They built an optimizing compiler good enough to settle the argument, and the profession stopped hand-coding arithmetic.
The parallel holds where the objection is about status rather than engineering. It breaks on verification. A compiler is deterministic: its correctness is established once by its authors and then inherited by every program it touches. A language model is stochastic and its characteristic failure is not a crash but plausibility. The single largest frustration in the Stack Overflow data, cited by 66 percent of respondents, is output that is almost right, with 45 percent reporting that debugging generated code costs more than writing it would have.
A compiler had to be proven correct once. A model has to be checked every time, by someone qualified to notice what is subtly wrong.
The second break is more consequential. FORTRAN did not remove the bottom rung of the profession. It widened it.
The rung that disappeared
Something is being lost, and it is not precision. Using ADP payroll records covering millions of workers through June 2026, Brynjolfsson, Chandar and Chen find no economy-wide displacement from AI. They also find that employment of 22-to-25-year-olds in the most AI-exposed occupations now sits 19 percent below where it would be had it tracked their less-exposed peers, a shortfall that has widened from 15 percent in mid-2025. Experienced workers show no comparable gap. The adjustment runs through reduced hiring rather than layoffs and concentrates where AI substitutes for labor rather than complementing it.
The authors are careful in ways their popularizers are not. Controlling for occupational education levels attenuates the effect from 18 percentage points to roughly 9, the divergence runs stronger in the ADP panel than in national benchmarks and they present all of it as descriptive rather than causal. Their proposed mechanism is what matters here: generative AI substitutes best for codified knowledge, the formal content of a degree, while complementing the tacit knowledge that comes only from years of practice.
DORA reached the same place from the other direction, warning that AI lets developers bypass the productive struggle through which expertise is formed. Its supporting citation is an ACM study of 21 developers working at the frontier of AI-assisted practice, which inventories the judgment those developers still supply themselves.
The cheapest work to automate turned out to be the work that manufactured the next generation of people qualified to check the machine.
The strongest case for waiting this out
Every measurement here is a photograph of a moving object. METR’s experiment did not merely fail; it failed because capability rose fast enough to make the control condition intolerable. Its respondents place their own uplift at 1.3x in March 2025, 2x in March 2026 and 2.5x by March 2027. On that reading, the verification tax is a transitional cost of immature tooling, the entry-level gap is a hiring freeze that will thaw and today’s skeptics will read like the engineers who insisted no compiler could beat their assembly.
The sharpest version of that objection is that verification is exactly where investment is now concentrated, in automated review, generated test suites and agents auditing other agents. DORA’s own diagnosis leaves the door open, describing models as incapable of signaling uncertainty for now rather than in principle. A model that could flag which of its outputs deserve scrutiny would cut the tax at its root.
So the argument survives partly. The Bureau of Labor Statistics still projects 174,700 additional software developer positions by 2035, growth of 10 percent, with median pay at $135,980 as of May 2025 and attributes that demand partly to building AI systems.
Two things the transition story cannot recover. Projected growth for the occupation has been marked down across successive BLS vintages, from 17 percent for 2023 to 2033 to 10 percent for 2025 to 2035, which is expansion decelerating rather than collapse. And a cohort not hired between 2023 and 2026 does not get re-hired into the seniority it would have had. Tacit knowledge cannot be bought back at any token price.
Cost per accepted change
The metric now determines the outcome. In April 2026, DORA researchers documented tokenmaxxing, in which companies rank engineers on internal leaderboards by raw AI consumption. Their assessment records developers running agents on meaningless projects to hold position, teams reaching a marginal throughput improvement at ten times the cost and knowledge hoarding as engineers withhold effective prompts from colleagues. Their warning is compact: “Be careful what you incentivize, you just might get it.”
DORA reports that some firms have already abandoned consumption leaderboards for spend dashboards with circuit breakers on runaway agents. Its recommendation is to pair delivery metrics with cost per accepted change and code rework rates, then measure by team or application rather than by individual.
A shop that cannot state its cost per accepted change does not know whether it is buying capacity or buying rework. The difference will surface first in the seniority profile of whoever is left to review the output.


