The Verification Tax

Fast, cheap, good: pick two. The rule survived fifty-seven years because it described a real constraint. Half of it is now wrong, and the half that broke is not the half most teams think.

Where the triangle came from

Martin Barnes drew it in 1969 for a course called Time and Money in Contract Control. Three corners, time, cost and quality, each pulling against the other two. It held for so long because all three were funded from one account: skilled human attention. Money bought hours. Hours bought either speed or care, and Fred Brooks showed in 1975 that past a certain point buying more hours bought neither, because coordination ate the difference.

That single shared input is the whole mechanism. The triangle was never a law of physics. It was a description of what happens when one scarce resource feeds three goals. Change the resource and the rule changes with it.

AI changed the resource for exactly one of the three.

The triangle did not break. It split. Fast and cheap now describe generation, where the constraint collapsed. Good still describes verification, where nothing moved.

One corner collapsed, the other did not

The collapse is easy to document. Epoch AI tracks what it costs to buy a fixed level of model performance over time. The price of GPT-4 level results on PhD-level science questions fell roughly 40 times per year, and across the benchmarks they track the range runs from 9 times to 900 times per year. Producing a plausible first version of nearly anything is now close to instant and close to free.

Teams feel it. In the 2025 DORA report, drawn from nearly 5,000 technology professionals, 90 percent said they use AI at work and more than 80 percent said it raised their productivity. For the first time, AI adoption correlated positively with software delivery throughput. In the 2024 report that correlation ran the other way.

If the old rule still held, quality should now be cheap too. The same 2025 report says it is not. AI adoption still correlates negatively with software delivery stability. Throughput up and stability down, in one dataset, in one year. That is the split, measured.

Good was always a claim about checking

Quality is not a substance you put into an artifact. It is a claim you establish about one. Verification, the work of establishing that claim, used to be funded from the same account as construction, which is why the two moved together and why Barnes could treat quality as a corner you traded away. Cut construction cost to near zero and verification cost stays exactly where it was. The ratio between them shifts by orders of magnitude, and every process built on the old ratio quietly stops working.

One thing did change, and it made this worse. The link between how good something looks and how good it is has weakened. Every review instinct a professional has was calibrated on human authors, for whom clean structure and confident prose were weak but genuine evidence of underlying care. A model produces that surface independently of the care. The proxy broke and nothing replaced it.

METR ran the experiment that shows the cost. Sixteen experienced developers worked 246 real issues on open-source repositories they had contributed to for years, projects that average more than 22,000 stars and a million lines of code. Before starting, they forecast that AI would speed them up by 24 percent. Afterwards, they estimated it had sped them up by 20 percent. The clock said they were 19 percent slower.

The slowdown is not the interesting number. The 39-point gap is. These were not careless people, and they were not wrong that generation had got faster. What they could not perceive is that reading, checking and correcting had absorbed the gain, because verification effort arrives as a diffuse tax on attention rather than as an event you can point at. Nobody logs the twenty minutes spent deciding whether a plausible diff is also correct.

The bill that does not show up this quarter

GitClear studied 211 million changed lines from repositories owned by Google, Microsoft, Meta and enterprise C-corporations, from January 2020 through December 2024. Two numbers moved in opposite directions. The share of changed lines that were refactored, meaning moved rather than newly written, fell from about 25 percent in 2021 to under 10 percent in 2024. The share classified as copy-pasted rose from 8.3 percent to 12.3 percent over the same window, and duplicated blocks grew roughly fourfold.

Refactoring is what you do when you understand code well enough to not want a second copy of it. Copy-paste is what you do when producing a second copy costs less than understanding the first. The crossing lines read like a discipline problem. They are better read as a location readout: they tell you where the cheap resource now sits, and what people do when one corner of the triangle goes on sale.

None of it appears in a quarterly delivery number. It appears eighteen months later, as a change that should take a day and takes three weeks.

The rule that replaced pick two

The replacement was published before the models arrived. Accelerate, the 2018 book by Nicole Forsgren, Jez Humble and Gene Kim, found that speed and stability were not a tradeoff for teams that had the right delivery capabilities. Elite performers deployed far more often and had lower change failure rates at the same time. The tradeoff turned out to be conditional rather than fundamental, and the condition was whether the checking had been automated.

The 2025 DORA report says the same thing about AI, more loudly. It calls AI an amplifier: teams with strong automated testing, mature version control and fast feedback loops convert model output into throughput, while teams with tightly coupled systems and manual gates get very little from the same tools. The model is identical for everyone. The verification capability is not, and that is what decides the outcome.

So the useful question is no longer which two you pick. It is whether a cheap automatic oracle exists for the work in front of you: something that can tell you an output is correct without spending a person on it. A test suite, a compiler, a type system, a simulator, a replay of production traffic, a diff against a known good result.

Where an oracle exists, take all three. Generation is free and checking is free, so the 1969 rule genuinely does not apply, and a team still rationing against it is leaving output on the table. Where no oracle exists, and architecture decisions, security posture, a number you put in front of a customer and a claim in a regulatory filing all qualify, the triangle is fully intact. The only thing AI changed there is that weak work now arrives faster and looks better while it does.

This reframes what an AI strategy is. Most of them are procurement plans: which models, which seats, which vendor. That is the half of the problem that solved itself, and it keeps getting cheaper whether or not you have a plan for it. The half that did not solve itself is unglamorous and internal. It is test coverage on the paths that matter, environments that reproduce production, data you can replay, and a review process that assumes the author had no judgment.

Barnes's triangle lasted because it named a real scarcity, not because it was a law. The scarcity moved. The organizations that look lucky in three years will be the ones that spent this stretch building the machinery that decides whether a thing is right, rather than the ones that adopted the models earliest, because that machinery guards the only corner that still costs anything.

What leaders should do

1. Split cycle time into generation and verification and track the two separately. If generation gets five times faster and total cycle time improves by 10 percent, verification is your binding constraint and more model capacity will not move it. Both DORA and METR predict that exact shape, so measure it before you spend against it.
2. Fund the oracle before the model. List the work you want accelerated over the next two quarters and mark each item with the automatic check that would prove it correct. Put the next budget increment into building checks for the unmarked items rather than into more seats for work that has none.
3. Run GitClear's three measures against your own repositories: share of changed lines refactored, share copy-pasted, and count of duplicated blocks. All three are computable from git history you already have, and they move a year or more ahead of your delivery metrics.
4. Stop accepting self-reported productivity as evidence. METR's participants were off by 39 points about their own work, on code they knew well. Require one measured before-and-after comparison on real tasks before any rollout scales past a pilot.