What AI Can't Compress

The numbers are no longer in dispute. AI tools write roughly 41% of new code, GitHub Copilot accounts for nearly half of what its users commit, and developers report spending 30–60% less time on the coding, testing, and documentation that used to make up most of their day. Take whichever survey you prefer – Stack Overflow, GitHub’s internal data, the State of AI Design 2026 – and the trend line is the same. The act of producing functional code has been compressed to a fraction of what it cost three years ago.

This is the starting point. Not a debate, not a forecast. The baseline.

What got commoditised is narrower than the hype suggests. It is not engineering. It is not architecture. It is not the judgment that decides whether a feature belongs in the system at all. What got commoditised is typing – the act of producing syntactically correct code that does what the prompt asked for. That has collapsed in price, and it will keep collapsing. Everything that sits above it – the decisions about what to build, how it fits the rest of the system, and whether it will still make sense in eighteen months – has not moved at all. If anything, it has become more valuable, because the cost of getting it wrong now compounds faster than it ever did.

The market has not caught up to this yet, but the evidence is starting to arrive at speed.

Gartner now projects that prompt-to-app approaches will increase software defects by 2,500% by 2028 – a number that sounds sensational until you read what’s underneath it. The defect class they describe is the dangerous one: code that is syntactically correct but lacks awareness of the broader system, code that introduces subtle but severe flaws because the generator had no model of the architecture it was operating inside. Forrester puts a different lens on the same problem: 75% of technology leaders are expected to face moderate-to-severe technical debt by 2026, with AI-accelerated coding cited as a primary driver.

The numbers from inside engineering organisations are more concrete still. An independent analysis of 470 real-world pull requests found that AI-generated PRs contained 1.7 times more issues than human-written ones – 10.83 versus 6.45 on average – with logic errors 1.75 times more frequent and readability problems three times worse. A peer-reviewed paper by Baltes, Cheong and Treude, published this March, names the phenomenon directly: AI slop. Their analysis of 1,154 developer discussions frames AI-generated code as a tragedy of the commons, where individual productivity gains externalise costs onto reviewers, maintainers, and the codebase itself. One quote from their data captures the dynamic precisely: “They’re literally just using you to do their job – critically evaluate and understand their AI slop and give it the next prompt.”

The Pragmatic Engineer’s 2026 reporting splits the workforce into archetypes, and the pattern is striking. Shippers are thriving on AI velocity. Builders – engineers who care about how things age – are increasingly overwhelmed by what they’re being asked to review. The asymmetry is structural. Generating code is cheap. Reviewing it well is expensive. The review layer was already thin. Now it is being asked to scale against a generator that has no incentive to stop.

This is the moment where the economic argument flips.

When production is commoditised, the differentiator moves to what production can’t produce. That’s not a slogan. It’s how markets have always worked. When fabric became cheap, tailoring became valuable. When stock photography became free, art direction became the brand. When code generation hits 41% and climbs, the scarce resource is no longer the code. It’s the judgment about which code should exist.

Models generate the statistically common solution. That is what they are designed to do. The statistically common solution is sometimes the architecturally appropriate one and often is not. Knowing the difference – being able to look at a prompt-shaped response and say this works but it will rot in production, here’s why, and here’s what we ship instead – is what separates the engineers worth hiring in 2026 from the engineers who are now competing directly with a free tool. The work has moved up the stack.

The demand signal is already visible at the companies that are taking AI most seriously. The State of AI Design 2026, drawing on case studies from Anthropic, Stripe, Linear, Notion, Shopify, Framer and Sierra, makes the point explicitly: hiring managers want AI fluency alongside a high bar for craft, taste, and vision. Both, not either.

The companies setting the standard in AI are not lowering their craft bar. They are raising it.

Speed is real. The 41%, the 30–60% time savings, the productivity dashboards – none of that is hype, and none of it is going to reverse. But the cost of bad code hasn’t disappeared along with the time it took to write it. It has moved. It has moved out of the production phase, where AI made it cheap, and into the review, debugging, and maintenance phases, where it has become more expensive than it has ever been.

The evidence for that move is already in the data. An independent analysis of 470 real-world pull requests found that AI-generated PRs contain 1.7 times more issues than human-written ones – 10.83 versus 6.45 on average – with logic errors 1.75 times more frequent and readability problems three times worse. The Stack Overflow 2025 Developer Survey, covering 49,000 developers, reports that 66% cite “almost right, but not quite” as their top frustration with AI output, and 46% no longer trust the accuracy of what it produces – up from 31% the year before. The Baltes, Cheong and Treude paper published in March names the dynamic directly: AI generation is cheap; review is not; the review layer was already thin; the cost is being externalised onto the humans downstream of the generator.

This is what buried debt looks like in motion. It does not show up on the velocity chart. It shows up six months later, in the engineer who can’t ship a feature without first untangling three months of accumulated assumptions nobody wrote down. It shows up in the Forrester forecast that 75% of technology decision-makers will face moderate-to-severe technical debt by 2026, with AI-accelerated coding cited as a primary driver. The speed is there. The debt is there too. They are the same story.

The question worth asking of any engineering partner now is not how fast can you ship. It is what does the system look like in eighteen months when the speed has compounded and nobody on the team remembers why these decisions were made. The engineers who can answer that question are the engineers worth paying for. The ones who can’t are competing with a tool that will keep getting cheaper.

If you are evaluating engineering partners or senior hires in 2026, the criteria that mattered in 2022 are not the criteria that matter now. Velocity tells you almost nothing – most teams can hit high velocity for a quarter by accepting whatever the model suggests. What you want to know is what they choose not to ship. How they think about the seam between AI-generated code and the parts of the system that need to survive five years of product evolution. Whether they can articulate, out loud and without bullet points, why a particular architectural decision matters now and what breaks if it’s deferred. Whether their definition of done still includes anyone reading the code again.

The engineers worth hiring are the ones who can use AI ruthlessly for the parts of the job that have genuinely become cheap, and who refuse to use it for the parts that have not. The clients worth working with are the ones who understand the difference, and pay for the second category accordingly.

Craft was never a luxury. It was the part of engineering that the market kept underpaying for because cheaper substitutes seemed close enough. The substitutes are now everywhere, free, and accelerating. Whatever sits above them is now the entire business. The teams that have spent the last decade building real architectural judgment didn’t pick the wrong skill. They picked the only one that holds its value.

The strategy isn’t going faster. The strategy is going deeper – into the decisions that happen before a prompt is written, into the architecture that determines whether AI output is useful or corrosive. I’ve written about what that looks like in practice in I Built a Portfolio With AI. Here’s What Actually Worked. The guardrails you set before the agent touches the code are the work now. That’s where the craft went. Not away – upstream.