Deleting work you already paid for feels like losing. Keeping it’s what costs you.
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 metrics stayed flat. A controlled trial found experienced developers working on mature codebases were slower with AI assistance, not faster, 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.
Why do developers keep debugging code they should rewrite?
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’s the sunk cost trap, and knowing the name of it doesn’t stop anyone at hour forty, when you’re close, when the next idea is going to be the one.
The next idea is never the one. If it were, you wouldn’t be at hour forty.
Generating a fresh version now costs almost nothing. The economics that once justified grinding on existing code are gone, and the instinct that grew out of those economics is still here.
What happens when a bug is not in your code?
Early in my career I was the lead developer on a system for a rivet company. Rivets were the entire business. One product, made very well, and they were among the biggest in the country doing it.
We built their accounting and merchandising systems. Payables, receivables, general ledger, all of it, developed from nothing and delivered. I wrote software every night for months and I was good at it by then, which turns out to be part of the story.
Then I hit a bug I couldn’t find.
The program crashed hard and dumped a full screen of garbage. Not diagnostics. Garbage. Nothing on that screen told me anything about what had gone wrong or where.
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.
Can a bug be in the compiler instead of your code?
The bug was in the compiler.
I proved it, which took a good part of those weeks. Then I opened a ticket with the vendor, a large computer manufacturer at the time, and that ticket was never resolved. As far as I know it’s still open somewhere.
Every developer is taught that the bug is in your code. The tool is used by thousands of people, your code is used by you, so the odds are overwhelming. That rule is correct almost every time.
Almost every time isn’t every time. When you land on the exception, following the correct rule costs you weeks, and there’s no way to know in advance which case you’re in.
The part under your control is how long anyone stays in the hole before getting help.
How do you know when to stop debugging and start over?
Steve Davis came in and fixed the project. He didn’t 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 didn’t 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’d confused winning the argument with the vendor for delivering the work. Those are separate projects. The first one is satisfying and the second one is the job.
The rule I took out of it: when something has resisted you for a while, stop asking what’s wrong with it and start asking what it would cost to delete it. Usually the answer is less than you think, because you understand the problem far better now than you did when you first wrote the thing.
Is it faster to rewrite AI-generated code than to fix it?
Often, and the reason is the same reason as forty years ago.
When you debug code you wrote, you’re working with a model of it in your head. When you debug code a machine wrote, that model doesn’t exist. You’re reverse engineering a stranger’s work to repair it, and reverse engineering is slower than writing.
The research supports this. Independent analysis of code quality has found rising churn, meaning more lines written and then quickly changed again. One review reported a substantial increase in security defects in AI-assisted code. That’s the shape of work that was accepted before it was understood.
The alternative takes a minute. Throw it out, change what you asked for, generate again. The cost of the second attempt is close to zero and the cost of the third hour of debugging is an hour.
Almost nobody does it, because it feels like giving up.
How long should a developer work alone before asking for help?
Less time than they do, and the reason isn’t stubbornness.
Competent people don’t ask for help because they’re competent. I’d become a good programmer, so I believed I should be able to solve a programming problem. That belief is what kept me in the hole.
The weaker developer asks on day two. The strong one is still there on day twelve, making excellent progress on the wrong question.
A rule fixes this and it doesn’t require anyone to admit anything. 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’s the rule.
What should a manager do when someone is stuck?
Steve Davis never chewed me out. That’s the part I still think about.
He explained what had gone wrong and how to fix it, and then we moved on. No lecture about how I should have come to him sooner. No comment on the weeks. He treated it as a technical situation with a technical answer.
I was a young developer who had just burned real time on a client project. He could have made a lesson out of it and I would have remembered the lesson. Instead I remember him.
Forty years later I’m writing about it, which tells you which approach lasts.
A manager who blames gets a team that hides problems until the problems are large. A manager who explains gets told about problems while they’re still small. Every operations leader knows this and a good number of them do the other thing anyway, because blame is faster in the moment.
What did the rivet project teach about shipping?
The systems went in and they worked. Payables, receivables, general ledger, merchandising. That company ran on them.
What I carried forward wasn’t a debugging technique. Nobody needs my method for isolating a compiler defect on hardware that no longer exists.
I carried forward two habits. Set a limit on how long anyone works alone on something that’s not moving. And when work has resisted you long enough, delete it and build it again with what you now know.
Both habits cost nothing. Both feel like retreat. Neither one is.