I Trusted Claude Code and Shipped 40% Slower: 3 Places the Speed Actually Died
Monday morning I estimated an HTTP retry tweak at 45 minutes. I closed the laptop at 8
PM. Fine, one bad estimate. Except when I added up the last five sprints and compared them to the five before I bolted Claude Code onto everything, the shape was ugly: my “quick” tasks were finishing about 40% slower on average, and I had walked around for two months telling anyone who would listen that the AI had turned me into a shipping machine.The AI is not the villain here. I still use Claude Code every day. What died is the story I told myself about where the time was going. This is the log of the three specific places I lost it, and the one harness rule I added on Monday to stop lying to myself.
The illusion I was defending
I had a “feeling” I was faster. That feeling is the same one described in the METR randomized study from July 2025 (arXiv
.09089): 16 experienced open source developers with an average of 5 years on their own repositories, given AI tools, took 19% longer to complete tasks. Before starting, they predicted a 24% speedup. After finishing, slower, they still believed the AI had sped them up by 20%. The gap between what you feel and what the clock records is about 39 percentage points, and it does not close after you live through the slowdown.So my private “40%” is just my number, on a smaller sample, in a codebase I know cold. METR gets 19% and I get 40% for roughly the same reason: the harder I know the codebase, the more expensive it is to route the decision through someone else who does not.
Fine. Where did the time actually go?
Place 1: The 3-second response that hid a 40-minute read
Claude Code returns a diff in three seconds. My brain reads that as “the task took three seconds.”
The task did not take three seconds. The task took three seconds of generation plus the twelve minutes I spent reading the diff, plus the twenty-eight minutes I spent chasing an off-by-one in an exponential backoff that only fired under load, plus the fifteen minutes of writing a test that would have caught it if I had written the test first the way I do without AI. That’s fifty-five minutes, and I logged it in my head as “quick fix, Claude did it.”
The generation speed contaminates the estimate for the entire ticket. If you asked me on Monday morning “how long?” I would have said 45 minutes because the AI part is 3 seconds and the “read and verify” part felt free. It is not free. It is the whole job.
The Anthropic official docs recommend Plan Mode explicitly for this reason — it is read-only, Claude proposes changes without touching files, and you’re supposed to review the plan before it runs (Claude Code permission modes). I did use plan mode. I just skimmed the plans the same way I skim CI output: looking for red, not looking for wrong.
Place 2: Auto-accept mode as a slow leak
Anthropic rolled out an official “Auto” permission mode in March 2026 that makes permission decisions on your behalf, with a separate safety classifier vetting each shell command before it runs (Anthropic engineering: auto mode). The classifier is genuinely good at blocking the obviously catastrophic stuff, like pushing to main or exfiltrating secrets. That is not where the time died.
The time died in the acceptable-but-wrong lane. Auto-accepting file edits (“Accept edits” mode, which auto-approves file edits and safe filesystem operations inside your working directory) let a whole category of “yes, this compiles, but it is not what I wanted” changes ship into my working tree without me looking at them until I ran the code. Then I read the change on a compile failure or a test failure, which is a much more expensive place to read it. Cognitive context switches are pricey and I was buying them wholesale.
The trap is not the mode. The trap is treating “safe” (the classifier blocked the disaster) as “correct” (this actually matches my intent). Those are different words. The auto-classifier does not know my intent. My intent lives in my head, and I was outsourcing that head to a very fast typist.
Place 3: The “one more prompt” verification loop
This one is the deepest cut. Every time Claude Code returned a solution that was 90% right, I sent it back with “close, but also handle X.” Twenty seconds to type the follow-up. Two minutes to re-read the new diff. Six minutes to run tests. Eight minutes to notice that the fix to X regressed the thing that was already right. Sixteen minutes per loop, and the loop feels fast because each turn is short.
Three loops is 48 minutes, which is longer than it would take me to write the whole thing myself in a codebase I know. But I never budget for three loops on Monday morning. I budget for one, feel great about the first response, and by the third loop I have talked myself into “I’m almost done” and I stay another hour past the point where sunk cost should have told me to close the loop and finish it by hand.
Simon Willison has been putting this fairly plainly in his writing for a while: LLMs are a productivity amplifier for tasks you know how to do and a mirage for tasks you don’t, and the trap is that they feel the same from the inside. He’s right, and my log agrees.
What actually broke: the estimate, not the AI
Notice a pattern. In each of the three places, the AI performed roughly as advertised. It generated code fast. Its Auto mode blocked genuinely dangerous shell calls. Its plan mode showed me plans. None of that is the problem.
The problem is that “generation” and “task” are different sizes and my estimate collapsed them. When I say “this will take 45 minutes,” I am estimating the total ticket: generate + read + verify + fix + verify + commit. The AI compresses only the first component. It leaves the rest untouched or, worse, expands it because now I am reading someone else’s code instead of writing my own. If you shrink 5 minutes of a 45-minute task, you save 5 minutes. If you shrink 5 minutes and then blow up the other 40 into 60 because verification is now more expensive, you lost 15 minutes and told yourself you saved 5.
That is not a Claude Code bug. That is an arithmetic bug in my planning, and it took me sixty days and one 8 PM Monday to notice.
The harness rule I added on Monday
I didn’t quit Claude Code. I added one rule to my per-repo CLAUDE.md, and it took me under a minute to write.
## Estimate policy
When I estimate any task involving AI code generation, I separate the
estimate into two lines:
- Generation budget: how long the AI will take to produce first-draft code.
- Verification budget: how long I will take to read, run, and correct it.
The commit only happens when both budgets close. If the verification
budget runs out and the code is not shipping, I stop and rewrite by hand
rather than opening another prompt loop.Three effects since I added it:
- My estimates got more honest. “Quick” tickets get 90 minutes now instead of 45, because 45 was fiction all along.
- I catch the “one more prompt” loop earlier because verification has a real budget instead of an infinite string.
- I stopped using auto-accept for anything I could not describe out loud before generating it. If I can’t describe the intended change in a sentence, the AI doesn’t have my intent either, and any speed it gives me is going to be given back with interest inside 20 minutes.
None of this is anti-AI. Every one of these rules boils down to giving verification the same respect I give generation. The rest of my harness is still Claude Code, plan mode when I don’t know a subsystem, auto-accept when I do, and a memory file per project so the AI doesn’t relitigate decisions I already made yesterday.
What I now believe
I believe two things I didn’t believe on Monday morning.
First, the feeling of speed is not evidence of speed. It is evidence of how fast the last visible unit of work happened. If the visible unit is “AI returns code” and the invisible unit is “I read and verify code,” the feeling is going to lie in a very consistent direction. METR measured 39 percentage points of lie. My personal number is uglier because I estimate more aggressively than the median dev. Yours will differ. Timing yourself once, on real work, will tell you which side of the line you’re on faster than any think piece.
Second, I got slower not because of AI, but because I let AI speed rewrite my estimation model in the background. The estimation model is the thing that keeps me honest. Once it goes, the tool that gets blamed is the loudest tool in the room, and Claude Code has been by a wide margin the loudest tool in mine. The tool didn’t lie. My clock did, and I trusted the clock more than the ticket. That is the mistake, and the mistake is fixable with sixty seconds and a CLAUDE.md edit.
The irony that lands hardest: the study that most helped me use AI well is a study about AI making experienced developers slower. I did not get slower from using AI. I got slower from believing the AI without timing myself. Different failure mode, same repair.
The harness rules I use across all my Claude Code projects — memory files, permission mode discipline, verification budgets, session cost accounting — are collected in Harness Engineering: A Field Guide. It is written for engineers who want to run Claude Code past the “open three terminals and hope” stage.
Related posts on this blog:
Was this article helpful?