You built the app on a Saturday. The first change worked. Then the second change broke something three screens away that you had never touched, and you had no way to diagnose it without asking the same model that wrote it. Dave Saunders calls that moment a bill arriving, and argues nobody mentioned the meter was running.
The four-second math problem
Every time the model hands you thirty lines of code, you have two options. Read them, understand them, spot the trap buried in line 22: roughly twenty minutes of real work. Or accept them and move on: four seconds. Run that choice forty times in an afternoon and reading costs you over thirteen hours while accepting costs about three minutes. Nobody picks thirteen hours over three minutes. That is not a character flaw. It is a rational response to the prices in front of you.
The problem is what the two paths leave behind. Accepting adds working software and contributes nothing to your picture of how the software works. Forty accepts and you own a system that does forty things with a mental model covering almost none of them. The gap opens quietly, a few lines at a time, and costs you nothing until you try to change something.
What the data says about duplication
GitClear, which sells code analysis tools and therefore has some interest in the outcome, published a dataset of 211 million changed lines of code across five years. Over that window, the share of work spent reorganizing existing code fell from about 24 percent to under 10. The share that was copy-paste rose from around 8 percent to over 12. In 2024, for the first time in their records, copying overtook reorganizing.

Reorganizing code means going back into something you built and making it simpler, collapsing four near-identical functions into one. Nobody sees it, it adds no features, and it is the only reason a system stays small enough to hold in your head. It also requires you to understand what is already there, which makes it the first thing to go when understanding becomes the expensive part.
Separate research by Mondal, Roy, and Schneider across four open source projects found that of duplicated code which ever needed a bug fix, up to a third was carrying a bug copied in from somewhere else. Duplication repeats the mistakes along with the logic, into places nobody is looking.
Even professionals are measuring the cost
Google’s 2024 State of DevOps report surveyed professional engineering teams, not solo builders working from prompts. The finding went in two directions at once. Individual productivity went up, along with flow and job satisfaction. Delivery stability went down: an estimated 7.2 percent drop for every 25 percent increase in AI adoption, with throughput off by about 1.5 percent as well. Stability is how often a change breaks something and has to be undone. More work, done faster, breaking more often. The researchers described their own result as surprising.
Saunders makes the caveat explicit: DORA surveys professionals with tests, code review, and colleagues who know the system. If those teams still measure that cost with all of that in place, it is not a skill problem. It is structural.
The fix versus the cover-up problem
Something breaks. You describe the breakage, you ask for a fix, the screen looks right again. Saunders asks: was that a fix, or was it a second change that happens to hide the first one? A fix removes the cause. A cover-up removes the symptom. On a screen at eleven at night they look identical, and telling them apart requires exactly the mental model you skipped building.
He also notes something specific about generated code’s structure: unlike buggy code from a junior developer, where ten lines have a visible logical progression even when broken, generated code can produce ten consecutive lines with no apparent relationship to each other. Manual defect tracing gets harder because the basis of the logic is difficult or impossible to infer.
The one small thing worth doing
The practical suggestion Saunders lands on is narrow enough to actually use. Next time you accept generated code and it works, before asking for the next thing, ask one more question: have the model explain what it just did, and where else in the app that same idea already appears. Thirty seconds. It does not make you an engineer. It begins building the picture you will need in week three, at nearly zero cost today.
The missing skill, as several commenters on popular AI coding tutorials had already worked out, is neither the coding nor the tooling. It is knowing why the thing works. That job did not disappear when typing got cheap. It just stopped being handed to you along with the code.
