Posted on July 9, 2026
A few weeks ago I watched an AI agent build a working prototype of an internal tool in one evening. Work that would have taken a good developer two weeks. So when people tell me that code quality stopped mattering — that everyone can code now, that craft is nostalgia — I get where it comes from. I have seen the demo too.
And they are partially right. For prototypes, quality genuinely does not matter. A prototype exists to answer one question as cheaply as possible, and the correct fate of most prototypes is the trash bin. Polishing one is like ironing a napkin.
The mistake is extrapolating from the demo to the decade.
The most expensive part of software was never writing it. We have known this for longer than most of today's developers have been alive. Lientz and Swanson measured it around 1980: more than half of all staff effort went into maintenance, and later estimates put maintenance at 60–80 % of the total cost of ownership. Robert Glass collected the same numbers in Facts and Fallacies of Software Engineering and added the detail everyone misses: most of that maintenance is not bug fixing. Roughly 60 % of it is enhancements — pushing new features into old code.
Maintenance is not the boring epilogue of a project. It is the project.
The word sounds like oiling a machine. In reality it is almost everything a software organization does after the first release:
Notice what these have in common. None of them is typing. All of them are understanding. A large field study by Xia et al. tracked 78 professional developers over 3,148 working hours and found they spend about 58 % of their time on program comprehension. The single largest line item in software development is not writing code. It is reading it.
When producing something gets cheap, you produce more of it — and the bottleneck moves to whatever comes next. Writing code got dramatically cheaper. So we write dramatically more of it. And every cheap line still bills the full price to be read, debugged, secured and migrated.
The early data says exactly that. GitClear analyzed 211 million changed lines and found an eightfold rise in duplicated code blocks; 2024 was the first year copy/paste outnumbered refactoring, and the share of freshly written code revised within two weeks nearly doubled since 2020. The 2024 DORA report measured that a 25 % increase in AI adoption came with a 7.2 % drop in delivery stability: teams ship more and break more. And my favourite, because it is a proper randomized controlled trial: METR let 16 experienced maintainers work on mature repositories averaging a million lines. With AI they were 19 % slower — while estimating they had been 20 % faster. On exactly the kind of codebase where the money lives, the demo effect flipped its sign.
These numbers will age; models improve fast and some of them may look silly in two years. The direction of the incentive will not. Cheap writing means more code, and more code means comprehension gets more expensive, not less.
Which leads me to a claim that sounds contrarian and is actually just arithmetic: code that is well prepared for operation and change will win because of AI, not despite it. Such code is easy for a human to understand. It is easy to reason about — you can predict what a change does without running the whole system in your head. And changes to it stay local, so they do not spray regressions across the codebase.
Here is the twist: every one of those properties helps the model too. Clear seams, small units, honest types, decisions documented next to the code — that is precisely the context in which AI agents stop hallucinating architecture and start being fast. Well-factored code is not a tax on AI velocity. It is the fuel. (And the METR slowdown is, I suspect, largely the price of AI wading through code that was never prepared for anyone to understand it — human or machine.)
If you are validating an idea, exploring an API or building a throwaway script — go fast, let the AI write everything, delete it with pride. This argument targets code that survives contact with production. The only real danger in prototype-land is the oldest one in our industry: the "temporary" prototype that meets its first paying customer and is suddenly load-bearing. That code just joined the maintenance economy, whether you planned it or not.
So how do you write code that wins this era? I want to spend the next series of posts showing exactly that, on real production code, pattern by pattern. And I will spoil the punchline now: there is nothing new in it. It is recycled patterns and practices that have been with us since the seventies — Parnas wrote the information hiding paper in 1972 — and they held true every year since. What changed is the speed. When everything accelerates, the practices that quietly paid for themselves over a decade suddenly pay for themselves in a quarter. Modern problems require traditional solutions.
First installment is already out: fifteen design lessons extracted from the most boring endpoint we own. It starts with a password reset.
Sources: Lientz & Swanson, Software Maintenance Management (1980); Robert L. Glass, Facts and Fallacies of Software Engineering (Addison-Wesley, 2002); Xia et al., Measuring Program Comprehension: A Large-Scale Field Study with Professionals (IEEE TSE, 2018); GitClear, AI Copilot Code Quality (2025); Google, 2024 DORA Report; Becker et al. (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025); Parnas, On the Criteria To Be Used in Decomposing Systems into Modules (CACM, 1972).