Developers using AI tools merge far more code than they used to and their organizations ship at about the same rate. One large study found pull requests nearly doubling while review time rose almost as much and delivery stayed flat. A controlled trial found experienced developers slower with AI assistance while believing they were faster.
Something is absorbing the gains. I think a large share of it is people fixing generated code instead of throwing it out and asking again.
Nobody deletes, and the reason is sunk cost
Because rewriting feels like admitting the last three days were wasted. They were already wasted. The only question left is whether you spend three more.
That is the sunk cost trap, and knowing the name of it does not stop anyone at hour forty, when you are close, when the next idea is going to be the one. The next idea is never the one. If it were, you would not be at hour forty.
Generating a fresh version now costs almost nothing. The economics that justified grinding on broken code are gone. The instinct that grew out of them is still here.
Weeks on a bug that was not mine
Early in my career I was the lead developer on a system for a rivet company. Rivets were the entire business, and they were among the biggest in the country doing it. We built their accounting and merchandising systems from nothing and delivered them.
Then I hit a bug I could not find. The program crashed hard and dumped a full screen of garbage. Not diagnostics. Garbage.
I spent weeks on it. I read my code, rewrote sections, tested pieces in isolation, and got nowhere. Every day I was sure I was close.
The bug was in the compiler.
I proved it, which took a good part of those weeks, then opened a ticket with the vendor. That ticket was never resolved. As far as I know it is still open somewhere.
Being right did not ship the system
Steve Davis came in and fixed the project. He did not find the bug.
He took the modules I had been fighting with, threw them away, and rewrote them. That was the entire intervention. The rewritten code did not hit the compiler defect, the system worked, and the project moved.
I was right about the cause. Steve shipped the system. Only the second one mattered to the client.
I had confused winning the argument with the vendor for delivering the work. Those are separate projects, and only one of them is the job.
The same trap with AI-generated code
When you debug code you wrote, you are working with a model of it in your head. When you debug code a machine wrote, that model does not exist. You are reverse engineering a stranger’s work in order to repair it, and reverse engineering is slower than writing.
Independent analysis has found rising code churn, meaning more lines written and then quickly changed again. One review reported a substantial increase in security defects in AI-assisted code. That is the shape of work accepted before it was understood.
The alternative takes a minute. Throw it out, change what you asked for, generate again.
Two habits that cost nothing
Set a limit before the work starts. Half a day, one day, whatever fits. When the limit is reached, somebody else looks at it. Not because you failed, because that is the rule. Competent people do not ask for help because they are competent, and that belief is what keeps them in the hole.
And when work has resisted you long enough, delete it and build it again with what you now know.
One more thing I still think about. Steve Davis never chewed me out. He explained what had gone wrong and we moved on. No lecture about the weeks. Forty years later I am writing about it, which tells you which approach lasts.
The full article is on my site: https://thewritingking.com/when-to-delete-instead-of-debug/. It runs longer, carries the diagrams, and answers the questions readers ask most.
These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.