Monday morning I estimated an HTTP retry tweak at 45 minutes. I closed the laptop at 8:07 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" tickets 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. I still use Claude Code every day, and Opus 4.7 is a real jump from Opus 4.6. Anthropic reports SWE-Bench Pro moving from 53.4% to 64.3% in the April 2026 release notes. 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.
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:2507.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 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 who does not.
Fine. Where did the time actually go?
Sink 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. It took three seconds of generation plus twelve minutes reading the diff, plus twenty-eight minutes chasing an off-by-one in an exponential backoff that only fired under load, plus fifteen minutes writing the test that would have caught it if I had written the test first the way I do without AI. That is 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.
Anthropic's docs point to Plan Mode for exactly this reason — read-only, Claude proposes changes without touching files, and you are supposed to review the plan before it runs (permission modes). I did use plan mode. I skimmed the plans the same way I skim CI output: looking for red, not looking for wrong.
Sink 2: Auto-accept mode as a slow leak
Anthropic shipped an official Auto mode through spring 2026, opening it to Team, Enterprise, and API between March 24 and April 16, and then to Max and Pro users, with Sonnet 4.6 support added alongside Opus 4.7 (Auto mode announcement). The safety classifier runs on Sonnet 4.6 no matter which model your main session uses, and it is genuinely good at blocking the obviously catastrophic stuff: pushing to main, 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 classifier does not know my intent. My intent lives in my head, and I was outsourcing that head to a very fast typist.
Sink 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 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 is right, and my log agrees.
What actually broke: the estimate, not the AI
In each of the three sinks, 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 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 rule I added to CLAUDE.md on Monday
I did not 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 split 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 cannot describe the intended change in one sentence, the AI does not have my intent either, and any speed it gives me is going to be given back with interest inside 20 minutes.
One more piece if your team ships services: pair the verification budget with a CI perf gate. CodSpeed hardened its AI-agent integration in March 2026 with an MCP server that can hunt regressions on every PR (changelog). Auto mode plus a perf-gate CI catches the "compiles green, ships slow" class of AI-generated code that would otherwise blow up the verification budget after merge.
What I now believe
Two things I did not 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 are 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 did not 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 full set of harness rules I use across all Claude Code projects — memory files, permission mode discipline, verification budgets, session cost accounting — is 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.
Top comments (0)