Cheap code is a reason to build fewer things, not more

Cheaper code generation is an argument for building fewer surfaces, not more of them. AI collapsed the cost of producing a codebase, a service, or a second platform implementation, and it did nothing to the cost of reviewing one. Every architecture decision that traded build effort against surface count was priced against an input that is no longer scarce, which means most of those decisions need re-arguing and a good number of them now come out the other way.

The industry is drawing the opposite conclusion. The common read on cheap generation is that you can now afford to build things you previously could not justify: the second native codebase, the extra service, the bespoke internal tool. That follows only if production was the constraint. The data from the last two years says it was not.

The queue is the finding, not the speedup

LinearB's 2026 benchmarks report analyzed 8.1 million pull requests from more than 4,800 organizations across 42 countries, covering work submitted through 2025. The headline number is not about how fast anyone writes code. AI-generated pull requests wait more than sixteen hours on average before a reviewer picks them up, against roughly 200 minutes for unassisted work. Those two figures are the finding. The multiples circulating from this dataset, commonly 4.6x overall and around 5.3x for agentic pull requests against about 2.47x where a human guided each decision, are summary statistics computed on different slices, so the pattern to hold onto is the gap in hours rather than any single ratio.

The rest of that dataset explains why reviewers hesitate. AI-generated pull requests are substantially larger. They merge at 32.7 percent against 84.5 percent for unassisted work. Teams generating 25 to 35 percent more code with AI saw review times increase by 91 percent.

Worth stating what this data is: observational telemetry from real teams, not a controlled experiment. It shows a strong association between AI-generated work and review behavior. It does not prove that AI generation alone caused the difference, and the argument here does not need it to.

One counterintuitive detail is worth sitting with: once a reviewer actually starts, AI pull requests get reviewed roughly twice as fast. There are two readings. The generous one is that AI-generated code is often more uniform and easier to scan. The uncomfortable one is that a reviewer facing a 400-line change they did not write, on a queue that is already backed up, is skimming. Given a 32.7 percent merge rate, we do not think the generous reading is the whole story.

So the shape of the problem is a queue, and queues do not care how fast the upstream stage runs. They care about arrival rate and service rate. AI raised arrival rate substantially and left service rate alone.

Two research programs point at the same broader constraint

DORA's measurements over two years describe the same thing from a different angle, and the arc matters more than any single year.

In 2024, every 25 percent increase in AI adoption was associated with an estimated 1.5 percent decrease in delivery throughput and a 7.2 percent decrease in delivery stability. That finding traveled widely and is still being quoted. It is also out of date. In 2025, throughput flipped positive as teams and tools matured. The stability finding did not flip. AI adoption remained associated with rising delivery instability, covering both how often a change fails on deploy and how often an unplanned fix follows. Those stability measures are self-reported, which is worth stating rather than burying.

DORA's 2026 research on generative AI in software development makes the operational point from another direction: the benefits depend on fast, high-quality feedback loops, which includes automated testing and code review.

Atlassian's Teamwork Lab described a related gap in its own 2026 work, an efficiency paradox in which individual output rises without a matching gain at team level, because coordination does not scale automatically with individual productivity.

These are not the same measurement. DORA is looking at software delivery, Atlassian at team coordination, and LinearB at review queues specifically. What they have in common is the shape of the problem: more local output does not convert into proportional system-level throughput, and the losses show up wherever human judgment is required.

There is a fairness point to make here too, and it needs handling carefully because the numbers are easy to misread. METR's early 2025 study found AI caused tasks to take 19 percent longer. In its February 2026 update, the ten developers from that study who returned were estimated at an 18 percent speedup, and newly recruited developers at 4 percent. METR reports those as negative numbers in a convention where negative means faster, and describes the result as some evidence for speedup.

The caveats are larger than the finding. The confidence interval on that 18 percent runs from a 38 percent speedup to a 9 percent slowdown, so it crosses zero. METR judged the data an unreliable signal and is redesigning the experiment, because developers who did not want to work without AI increasingly declined to take part. That biases the estimate downward, meaning the real effect is probably better than measured rather than worse. The honest summary is that the 2025 slowdown headline is no longer the current state, and nobody has a clean number for what replaced it.

Everyone stops at the process conclusion

The observation that code got cheap while judgment did not is not ours. It has been made repeatedly this year, sometimes well.

What is striking is that almost every version of it lands in the same place: improve your review process. Smaller pull requests. AI-assisted first-pass review. Better risk signals. Keep humans accountable for the parts that carry consequences. All sensible, and all of it treats review capacity as a throughput problem to be optimized.

That is the weaker conclusion. Where review capacity is already constrained, and the LinearB data suggests that covers a lot of teams, you have two levers rather than one. You can raise review capacity, which is hard, bounded by the number of senior people you have, and subject to the same fatigue that produced a 32.7 percent merge rate in the first place. Or you can lower the amount of surface that needs reviewing, which is an architecture decision you control completely and can make once.

The second lever is barely being discussed, and it is the one with better economics.

Surface count is now the cost variable

Here is the re-pricing, stated plainly. When production was expensive, the cost of a design was roughly proportional to how much work it took to build. Surface count mattered, but it was entangled with build effort, so optimizing for build effort was a reasonable proxy.

Cheap generation broke the proxy. Build effort fell sharply. Everything downstream of build did not: review, dependency management, configuration, secret handling, permission models, release pipelines, monitoring, incident response, and the human cost of holding a mental model of the system. Those scale with how many distinct things exist, not with how long each took to produce.

Which means a design with two codebases carries something much closer to two full sets of downstream ownership cost than the build-time comparison suggests, even when it takes only slightly longer to produce. The research does not establish a precise multiplier and this post is not claiming one. What it establishes is the direction, and the direction used to be a rounding error. AI made it the main term.

The natural filter is also gone. When a thing took two days to build, the two days were doing quiet work: they forced a decision about whether the thing was worth having. That filter has been removed, and nothing replaced it. Teams are now capable of acting on far more decisions than they have capacity to evaluate.

What re-prices when you count surfaces instead of hours

Several arguments that were settled on build effort have to be re-argued on review surface, and they do not all survive.

Cross-platform versus two native codebases. The classic case for dual native was quality and platform fidelity, paid for with roughly double the build. If the build is no longer the expensive half, the case has to be made on review surface, where dual native is straightforwardly worse. We argued the specific version of this in our post on the web and mobile decision.

Service decomposition. Splitting a service used to trade coordination cost against build and deploy independence. Now each additional service is another dependency graph, another configuration surface, and another thing in the review queue. The threshold for justifying a split should be higher than it was, not lower.

Build versus buy. The build side of that comparison got cheaper and the own side did not. Owning is where review, patching, and dependency rot live.

Bespoke internal tooling. This is where cheap generation is most seductive and the arithmetic is worst, because internal tools get built quickly, reviewed lightly, and maintained by nobody in particular.

Polyglot stacks. Choosing the ideal language per component was always partly a build-effort argument. Every additional runtime is a separate review competency, and reviewers are the scarce resource.

None of this is an argument for one codebase at all costs. It is that every new boundary should have to justify its permanent verification and ownership cost, rather than only its build cost.

Three places this changed what we did

An iOS product built around live camera inference stayed single-platform rather than expanding to Android on the strength of how quickly a second implementation could be produced. The capability requirement justified native. Nothing justified two of them.

Our own web properties run on one boring stack: Next.js App Router, TypeScript, Postgres, Docker behind Cloudflare and Caddy. There have been several points where a separate service would have been quicker to generate than an addition to the existing one. We have consistently taken the slower option, because the faster one adds a surface we then own permanently.

And the reason we hold this position at all is that we keep finding the failure it predicts. A lint rule of ours ran on every commit, passed every time, and had stopped checking anything. Our analytics collected more than we would have chosen by default while nothing appeared to be wrong. Neither was bad code. Both were plausible configuration that runs without complaint, which is exactly the failure mode that scales with surface count and is invisible to the tests you would think to write. We have written before about why the failure mode is not bad code.

Where this argument stops

Taken too far, "build fewer things" becomes bad advice, and it is worth marking the boundary rather than letting the argument run.

Some surfaces exist for reasons that have nothing to do with build effort, and consolidating them is a mistake regardless of what review costs. Isolation boundaries that exist for security or blast radius should stay. Independent scaling requirements are real. Team ownership boundaries are load-bearing in organizations past a certain size, and a shared codebase across teams that do not talk is its own failure mode.

Consolidation also has a failure mode of its own. One large surface can be harder to review than three small ones if the coupling is bad. The argument is not that fewer is always better. It is that surface count now carries a much higher price than it did, so the burden of proof has moved. Adding a surface used to need a reason. It now needs a better one.

And none of this is an argument against using AI assistance. We use it heavily. The point is about what to do with the savings.

How to price a design decision under a review constraint

Three questions, in order.

First, how many distinct things will exist after this decision that did not exist before? Count codebases, services, runtimes, deployment targets, and configuration surfaces. Not files.

Second, who reviews each of them, and do those people already have capacity? If the answer involves the same two senior engineers who are already the bottleneck, the design is more expensive than it looks regardless of how fast it can be produced.

Third, what would make this surface disappear later? Surfaces are much easier to add than to remove, and a design with no removal path is a permanent commitment made on the strength of a temporary discount.

The savings from cheap generation are real. The mistake is spending them on more surface area. Spend them on verification, on the review capacity that is actually binding, and on building less.

Written by Synthetixis, an AI-native product studio. More on what most AI software gets wrong.