The first change went in fine, and that where this begins. You moved a button, added a field, or fixed the “thing” that had been bothering you since Saturday. You asked for it in plain English, the machine did it, and the screen looked right. It went so smoothly that it seemed to say something reassuring about the software you had built, when what it was actually reporting was how small that software still was.

The second change is the one that breaks something you were nowhere near. A field you never touched stops saving. A page you haven’t opened in a week starts throwing an error. The strange part isn’t the breakage, because software breaks and always has. The strange part is that you have no idea why, and no way to find out that doesn’t involve asking the same machine that wrote the thing in the first place. That moment isn’t a bug. It’s a bill arriving, and nobody mentioned the meter was running.

First, the part I’m not taking back

You described something you wanted, in ordinary words, and working software came out the other end.

Ten years ago that took a team, a budget, and about four months of everybody’s life. I used to run a group with 100s of developers writing code, day in and day out. You did it on a Saturday, in between other things, then you showed somebody, they were impressed, and you were a little bit proud of it. You should have been.

That’s not a trick and it isn’t cheating. It’s the newest thing to happen to software in my working life. There’s a lot of sneering about it and none of that is coming from me.

So nothing below is an argument that you shouldn’t have built it. Keep hold of that, because the rest only makes sense if we agree on it.

You described something you wanted, in ordinary words, and working software came out the other end. Ten years ago that took a team, a budget, and about four months of everybody’s life. You did it on a Saturday, in between other things, and then you showed somebody and they were impressed, and you were a little bit proud of it. You should have been. That is not a trick and it isn’t cheating, it’s the newest thing to happen to software in my working life, and there is a great deal of sneering about it at the moment, none of which is coming from me.

Nothing below is an argument that you shouldn’t have built it. Hold onto that, because the rest only makes sense if we agree on it first.

The Four-Second Decision

Everything turns on a moment so small you have never once noticed making it. The model hands you thirty lines of code and the screen does the right thing, and you have two options. You can read those thirty lines, work out what each one does, decide whether you agree with it, and notice the bit that is going to bite you in two weeks; call it twenty minutes, and it is real work, the kind that leaves you tired. Or you can accept it and ask for the next thing, which takes four seconds.

Run that forty times in an afternoon, which is an ordinary afternoon, and the arithmetic stops being close. Reading costs you north of thirteen hours, and simply accepting costs about three minutes. Nobody picks thirteen hours over three minutes, especially forty times in a row. This isn’t a character flaw: you didn’t take a shortcut, you responded to the prices in front of you, and so would I, and so does every professional who does this for a living.

But the two choices leave behind entirely different things, and that asymmetry is the whole story. Accepting adds working software and contributes nothing whatsoever to your picture of how the software works. Do it forty times and you own a system that does forty things and a mental model that covers almost none of them. The gap opens quietly, a few lines at a time, and for a long while it costs you absolutely nothing.

What Cheap Generation Leaves In the Code

There’s a company called GitClear that measures this sort of thing at scale. They sell code analysis tools, so they potentially have some interest in the outcome, but they have the largest dataset anyone has published on it: 211 million changed lines of code across five years. Over that window, the share of work that was reorganizing existing code fell from about 24 percent to under 10, the share that was copied and pasted rose from around 8 percent to over 12, and in 2024, for the first time they had ever recorded, copying overtook reorganizing.

That is a very dry way of describing something quite human. Reorganizing code means going back into something you already built and making it simpler, collapsing four things that do almost the same job into one thing that does it properly. Nobody sees it, it adds no features, and it is the only reason a system stays small enough to hold in your head. It is also the one job that requires you to understand what is already there, which makes it the first thing to go the moment understanding becomes the expensive part. Copying is its exact opposite: fast, effective, and quietly capable of putting the same idea in four places. Now change that idea. You have to find all four, and you don’t know there are four, because you never read them.

None of this began with AI, and researchers were picking at it long before any of us were typing prompts. Mondal, Roy and Schneider went through four open source projects across thousands of revisions and found that of the duplicated code which ever needed a bug fix, up to a third was carrying a bug that had been copied in from somewhere else. Duplication repeats more than the code. It carries the mistakes along with it, quietly, into places nobody is looking.

Here’s where the Saturday left you: with a system whose behavior is now larger than your picture of it, and a gap between those two things that widened a little every time you said yes. While you were only ever adding, that gap cost nothing, because adding doesn’t need the picture.

Changing does.

A change is a prediction. You are saying that if you alter this, that will happen and nothing else will, and the second half of that sentence is the entire sentence. Anyone can predict the thing they are aiming at; the skill is predicting what else moves. That prediction can only be made from the picture you never built, and predictions are cheap to make and expensive to be wrong about, which is as true of a bridge or a business plan as it is of four hundred lines of something you didn’t read. Your first change was safe because the app was still small enough that guessing worked. That’s not a skill you had. That’s a size you had.

Not a Beginner Problem

Filing all of this under inexperience would be convenient, and one number makes that difficult. Google runs a study every year called the State of DevOps report, the closest thing this industry has to a census, and Google does not sell you a coding assistant. In 2024 they looked at what happens to professional teams as they adopt AI and found two things at once. Individual productivity went up, along with flow and job satisfaction, and those people were measurably faster and measurably happier. 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 the boring word for 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, which I appreciated, because nobody went looking for it.

One caveat matters here and I would rather raise it than have you catch me at it. DORA surveys professional software teams, not somebody building an app from a prompt on a Saturday, and that is not your situation. I am using it the other way around. These are people who do this for a living, with tests, with code review, with a colleague down the hall who knows the system, and if they still measure that cost with all of that in place, then what you are running into isn’t a skill problem. It’s structural.

The part I find uncomfortable

Things break, and that’s ordinary. No matter how good you are, there will always be some test case that you missed, a usage situation that crept in and you never predicted. It is completely normal.

What happens next is the bit that bothers me. Something breaks, so you describe the breakage and you ask for a fix. You get one, and the screen looks right again.

Now answer me this. Was that a fix, or was it a second change that happens to hide the first one?

You can’t tell. Telling those two apart needs exactly the model you skipped. A fix removes the cause. A cover-up removes the symptom. On a screen, at eleven at night, they look identical.

That’s the bill: you can no longer tell whether you’ve fixed something or buried it.

This is where the knowledge deficit becomes more painful as it gets ahead of you. I’ve asked for a change before, the generated code came back working, but I went and looked behind the curtain anyway.

What I saw was weird. Imagine looking at some buggy code from a junior programmer, and you have 10 lines of code. They may be poorly written, but you can look at 1, 2, 3, 4, etc., and you can see how they relate to each other. There’s an obvious progression of logic, and it sort of makes sense, even though it doesn’t work. With generated code, you can end up with 10 consecutive lines of code that seemed to have no relationship to each other at all, and that makes manual tracing of defects even more difficult because the basis of the logic is difficult, if not impossible, to infer.

It would be easy to call this a beginner problem

It isn’t one, and there’s a number for that.

Google runs a study every year called the State of DevOps report. It’s the closest thing this industry has to a census, and Google doesn’t sell you a coding assistant. In 2024 they looked at what happens to professional teams as they adopt AI, and they found two things at once.

Individual productivity went up. So did flow, and job satisfaction. The people using it were faster and happier, and that’s measured, not claimed.

Delivery stability went down. For every 25 percent increase in AI adoption they estimated a 7.2 percent drop, with throughput off by about 1.5 percent as well.

Stability is the boring word for how often a change breaks something and has to be undone. More work, done faster, breaking more often. The researchers called their own result surprising, which I appreciated. Nobody went looking for it.

One caveat matters here, and I’d rather say it than have you catch me at it. DORA surveys professional software teams, not somebody building an app from a prompt on a Saturday. That isn’t your situation and I’m not going to pretend it is.

I’m using it the other way around. These are people who do this for a living, with tests, with code review, with a colleague down the hall who knows the system. If they still measure that cost, it isn’t a skill problem. It’s structural.

What you took on

Which raises the question of what the person you didn’t hire was for. Not typing: typing was never the expensive part, and anybody who has done the job will tell you the same. They were holding the model. They knew that this thing over here talks to that thing over there, so touching one means checking the other, and they carried a picture of the system around in their head, kept it current without being asked, and could tell you in about four seconds which parts of it your change was going to disturb. That is the bit you can’t buy in four seconds, and it’s the bit that got quietly left out of the deal, because nobody itemized it. It had no line on the invoice. It was simply what came along with the person.

To be fair, plenty of software people spent years being paid to type things a machine can now type in a second, and pretending otherwise helps nobody. But the ones who were worth their salary were never selling you the typing. They were selling you the answer to a single question: if we do this, what else moves? That question does not get cheaper when code gets cheaper. It gets more valuable, because now there is a great deal more code to move. I used to work with an engineer who typed faster than any person I’ve known, but that wasn’t what made him the highest-paid engineer in the department. It was the fact that he wrote amazing code that was beautifully structured, commented, and fully documented without anyone asking him to write. The funny thing is, especially given that person’s personality, I think he did all this just so no one would ever hassle him if they had to go in and make some changes to the code.

As I was watching videos on YouTube to get some insight on this article, it was clear some of the audience worked this out long ago. I went through a pile of the most popular tutorials on building apps with AI, millions of views between them and most of them useful, and almost every one ends in the same place: it works, here it is running, well done. Underneath one of them somebody had written, “I’ll spend 30 minutes prompting, 30 minutes testing it, then 5 hours going back and reverse engineering it trying to figure out why it works that way.” Thirty minutes to build, five hours to understand. That ratio is the entire subject of this piece and it is sitting in a comment rather than in any of the videos. Under another, a viewer noted that the most important lesson wasn’t in the video at all. Under a third: most of us already know about these tools, and what we are looking for is not how to make more apps. People have worked out that the missing skill is neither the coding nor the tooling.

So the job you took on was never writing the software. It was knowing why it works. That job didn’t disappear when the typing got cheap, it just stopped being handed to you along with the code; it used to arrive as writing and now it arrives as reading, and reading is the part all of us are skipping.

Which suggests something small enough to actually do. Next time you accept something and it works, before you ask for the next thing, ask one more question instead: have it explain what it just did, and where else in the app that same idea already appears. Thirty seconds. It will not give you a computer science degree and it will not make you an engineer. What it does is begin building the picture you are going to need in week three, at a cost of almost nothing today, and since the gap only gets expensive because it grows quietly, slowing the growth is most of the work.

I’d be interested to know where it first bit you, and whether you saw it coming. I don’t think most of us do.

If this was useful, my book Founders Who Finish is at davesaunders.net, along with my newsletter, The Build.