Deleting work you already paid for feels like losing. Keeping it is what costs you, and I paid that bill for weeks before somebody showed me.
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. That 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. That 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 learns that the bug is in your code. Thousands of people use the tool, you use your code, 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. The argument was satisfying to win, and the delivery was my 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 serious 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. I think that feeling is the most expensive instinct in software right now, and it’s eating the very gains teams bought the tools to get.
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 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, and that happens because it’s the rule, whether or not anyone failed.
What should a manager do when someone is stuck?
Steve Davis never chewed me out, and I still think about that. 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. That 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, and both feel like retreat to the people who need them most. I’d rather lose three days to the delete key than three weeks to pride, and I learned that the expensive way.
