Claude Code on My Own Blog: 47 Commits in 2 Days, 14 Rewritten by Hand — and METR's Gap Between −19% Reality and +20% Feeling
I handed Claude Code a draft of my own blog and got 47 commits in two days. I rewrote 14 by hand. I unpack why the sense of speed lies (METR: -19% in fact, +20% by feel), why "almost correct" code is the most expensive kind, and how the aviation rule of "children of the magenta line" sets the levels of delegating to AI. Exact prompts, a tool table, verified numbers.
Aviation, April 1997, the American Airlines training academy in Dallas. Captain Warren Vandenburgh stands before a class of pilots — twenty-seven years in the Air Force, Top Gun fourteen times, thirty-two years with the airline. He clicks a slide. On the slide, one number: 68%. That's the share of accidents, incidents and violations his group studied that were caused not by hardware failure but by poor management of automation. Pilots had forgotten how to switch the autopilot off. They had become, in his phrasing, "children of the magenta line" — dumbly steering the machine along a colored route on the display while the aircraft did the wrong thing. Vandenburgh gives one rule, precise as a torque spec on a bolt: "If at low altitude you catch yourself asking what is it doing now? — disconnect the automation and fly the airplane yourself."
Twelve years later, on the night of 1 June 2009, over the Atlantic, Air France flight 447 loses its airspeed data. The autopilot disengages on its own and hands the controls to two pilots who for years had barely flown by hand at altitude. They pull the stick toward themselves — exactly the opposite of correct — and within minutes the A330 falls from thirty-five thousand feet into the water. The skill they had delegated to the automation turned out to be missing in the one moment it became critical. Two hundred and twenty-eight people died not because the machine broke, but because the humans had forgotten how to do the thing they were sitting in the cockpit for in the first place.
I'm not a pilot. I run a kitchen — and the kitchen is an honester metaphor here than the cockpit, because in a kitchen the bill is brought straight to the table. A good restaurant is built simply: the chef doesn't slice every onion himself, he hands out stations to the sous-chefs and holds the mise en place in his head — the exact knowledge of what's made of what and where it's going. Claude Code is a brigade of sous-chefs that cooks faster than any human and never tires. I handed it a draft of my own blog. By morning I was staring at 47 commits in two days and caught myself on exactly Vandenburgh's question: what has it done here? What are these dishes sitting on the pass under my name? And 14 times I had to pull a plate off the pass — switch off the autopilot and rewrite by hand — because the sous-chef had cooked, technically flawlessly, something I hadn't ordered.
And this is no longer a marginal story about one oddball with a blog. Per the Stack Overflow Developer Survey 2025, nearly half of all respondents and over half of professional developers specifically use AI tools daily (47% and ~51% respectively). The automation paradox — an effect described for decades in aviation and nuclear power — is being reproduced at scale for the first time inside live production codebases right now: not in research labs, but on the daily deadlines of real teams. When the tool goes from seasoning to the main course on the menu, the hidden effects stop being statistical noise. They become operational reality — and the debt each person racks up at their own station gets eaten by the shared dining room.
My antagonist isn't the machine
Let's name the antagonist right away, because without a face this is a lecture, not a mirror. The antagonist of this text is not Claude. Claude is excellent. The antagonist is the Automation-Dependent Pilot. The same one from Vandenburgh's slide: the human who stopped choosing the level of automation to fit the task, lost situational awareness, and catches "what is it doing now?" only once it's too late to pull the stick.
In my case this pilot wears my face. It's me at two in the morning, staring at the green commit counter and feeling the pure dopamine pleasure of speed: look how much it did while I drank my coffee. Except the counter doesn't measure how much I did. It measures how much I didn't do — and it glows brighter the longer I haven't touched the stick. That's the magenta line in its purest form: it moves forward, it says "everything's under control", and it leads exactly where you yourself aren't looking.
METR — a research organization that evaluates the capabilities of AI models — ran, in mid-2025, not a survey but a randomized controlled experiment. Sixteen experienced open-source developers. 246 real tasks in their own mature repositories (on average 22 thousand stars, over a million lines of code). Half the tasks they were allowed to do with AI (Cursor Pro plus Claude 3.5/3.7 Sonnet, the frontier at the time), half without. And here's the result that still aches in the tooth of everyone who read it: with AI, the developers worked 19% slower. Not faster. Slower.
The cruelest part isn't even that. Before the experiment these people predicted AI would speed them up by 24%. After the experiment, having physically sat through the slowdown in their own bodies, they still believed AI had sped them up by about 20%. That is — even caught red-handed, the brain rewrote the protocol in favor of the pleasanter version — like a witness who lies not to the investigator but to himself.
Here is where the load-bearing structure of the whole text lives. Not "AI is bad" — that's boring and untrue. But that your internal speedometer is broken in a specific, predictable direction. It shows arrival while you're stalling. This is the automation paradox in its purest form: the automation runs so smoothly that you stop noticing how you yourself are degrading — until the bill comes, all of it, at once. The best self-assessment system evolution ever devised turns out to be a free lawyer for the opposing side.
47 commits, two days, and why 14 isn't a bug
Now the specifics, because I promised an honest case study, not a parable. I gave Claude Code access to my blog repository and for three days straight set tasks of varying caliber. Over the two hottest days, 47 commits ran up. Of those I rewrote 14 by hand — not patched a comma, but tore out and rewrote the logic or the text from scratch.
The temptation is to say "14 rewrites is a failure of automation". So: no. It's not a failure. It's structure. In the METR work, reviewing and fixing the AI output was a separate line item of time: people didn't just get something finished — they sat over the generated material, read it, and reworked it by hand, and that editing ate the time the speed was supposed to save. Rewriting isn't an exception to the delegation process. Rewriting is the process. It's the kitchen arithmetic of any chef: the sous-chef sliced, marinated, seared — but the decision of what goes out to the dining room under your name and what goes in the bin, you delegate to no one, because that's exactly what you're paid for. Whoever thinks he delegated the writing has actually delegated only the prep, and kept the most expensive part for himself — the taste test. This isn't an assistant who took the work off you. It's an assistant who took the slicing off you and left you the tasting, and you rejoice as if you'd been let off the kitchen.
And here's where the most insidious thing lurks. Not the code that's obviously broken — that's visible, easy to throw away. The most expensive is the code that's "almost correct". The Stack Overflow Developer Survey 2025 (84% of developers already use or plan to use AI) names the top frustration of the year outright: solutions that are almost right, but not quite — so answered 66%. The second-largest pain point: debugging AI-generated code taking longer — 45.2%.
"Almost right" is more expensive than "wrong" for a simple reason. An obviously spoiled dish the waiter turns back at the kitchen — it's visible, easy to pull. But "almost right" goes out to the dining room: it's plated beautifully, it smells the way it should, it passes your taste test, because you're ten hours into service and it's "almost". And the customer takes a bite — in front of others, a week later, in prod. Exactly like that A330 that flew flawlessly for years until one icy night showed what the pilots actually couldn't do. "Almost right" is the alternate law of your code: everything works until it stops, and that's exactly when you discover there's no one to carry the weight. The most dangerous dish isn't the one burned black, but the one raw inside under a perfect crust — the defect is caught on the smooth detail where they simply forgot to cut the thread.
On the subject of trust. In that same Stack Overflow survey, more developers actively distrust the accuracy of AI (46%) than trust it (33%). And only 3.1% trust it "highly". That is, the industry has already felt out what I was feeling out by hand at night: use it — en masse; believe it — carefully. This isn't Luddism. It's a grown-up attitude toward a tool that takes off beautifully and can't land — and the landing is always left to you.
The machine writes forward and doesn't clean up after itself
There's one more thing the commit counter fundamentally can't show. It counts what's added. It doesn't count what should have been removed.
GitClear analyzed 211 million changed lines of code — the repositories of Google, Microsoft, Meta and others, 2020–2024. Look at two curves. The share of copied, duplicated code rose from 8.3% in 2021 to 12.3% in 2024 — roughly four times more clones. And refactoring — the lines that move, that is, cleaning up after yourself — fell from 25% to under 10%. 2024 became the first year in their data's history when copy-paste overtook refactoring. One important caveat in fine print: the sample isn't random — it's mostly large corporate repositories, so read the figure as a direction, not a verdict on the whole industry. The direction, though, is unambiguous. In kitchen language this has a simple name: a new prep flies into the pot while no one washes the dirty dishes — they just get shoved deeper into the sink. A kitchen where the orders grow every day and the dishwasher's been let go still smells fresh. The smell changes precisely when the next plate stops fitting in the sink.
The metaphor here isn't even a metaphor — it's mechanics. Picture an intern who, for every task, brings not a solution but three more files "just in case", copies a chunk from here, another chunk from there, throws nothing away. In a week you don't have a codebase, you have a junkyard, where every duplicate will one day have to be fixed in three places at once — and you'll even thank him for the productivity, because look at all the commits. The speed of writing is real. The debt under it is also real, just with deferred payment and brutal interest.
The Google DORA 2024 report adds something colder: despite the rise in individual productivity and satisfaction, adopting AI correlates with worse software delivery. By the report's estimate, +25% adoption is associated with −7.2% delivery stability and −1.5% throughput. An important caveat in fine print, which an honest chef doesn't paint over: it's a correlation, not causation — the researchers themselves say the finding needs further study. But the mechanism is entirely down-to-earth. AI makes it easier to write more code — so the change size grows, and large changes are always riskier. Generating faster ≠ delivering faster. The dining room fills with plates twice as fast — but whether they arrive intact, the statistics no longer promise.
Productivity measured in commits isn't an asset. It's debt taken on interest, which at first feels like income — and sends the statement precisely when you've got nothing left to pay it with.
WALL-E, or the physical model of what's coming for you
So far we've been counting what gets ruined in the codebase. The nastiest part is left: what gets ruined in you. And the most precise picture came not from a McKinsey report but from a children's cartoon.
In Pixar's "WALL-E" there's a frame that still makes me uneasy. The starship Axiom, people who for seven hundred years haven't risen from their hovering chairs, staring at a screen half a meter from their faces. Their bodies have gone round and boneless — bone and muscle dissolved from disuse. The captain physically can't stand on his own legs without a robot's help. Pixar, incidentally, consulted a physiologist and leaned on space data: astronauts in weightlessness lose on average 1–2% of bone density per month. This isn't satire on laziness. It's a physical model of what delegation does to any unexercised muscle — atrophy doesn't hurt, and that's the trick.
Competence doesn't vanish dramatically. No one sends a notice: "your writing skill has been discontinued." It just quietly stops carrying weight. And you find out not when you've stopped walking, but when you suddenly needed to stand up — and the floor turned out to be farther than you thought.
That's why I now consider those 14 manual rewrites not a tax but training. They were my squats. The only part of the process where my own writing skill didn't atrophy but worked against resistance. Had I accepted all 47 commits without looking — the counter would show 47, and the muscle I think text with would have withered by exactly that difference. And at some point, when I'd need to write something the machine can't — something alive, with its own stake — I'd pull the stick toward myself and find my hands had forgotten the motion.
Writing isn't the production of an artifact. Writing is a way of thinking. Delegate the draft — you share the work. Delegate the decision of what to keep from the draft — you delegate the thinking. And that is no longer optimization, but the same magenta line, along which you obediently fly the airplane into the ground, admiring how evenly it goes.
Three dishes whose recipe I lost
I put off the most uncomfortable part of the title for a long time. 14 rewritten, 30 kept — that's a normal kitchen. But three commits I still don't understand. The deploy holds, tests are green, prod doesn't fall — but how exactly it works, I honestly can't say. Let's take these three apart, because this is exactly where the mechanism hides that the green counter doesn't show.
The first — a regular expression for parsing a date edge case. Claude produced a line of seven groups with lookaheads, gave it three tests, the tests pass. I read it three times. I know what it does — it catches a format my old code was missing. I don't know why exactly this way and not something simpler. It's a dish the sous-chef cooked to a recipe he didn't show me: tastes perfect, but if tomorrow a guest asks for it gluten-free, I don't know which ingredient to pull out without collapsing the whole thing.
The second — a change in the build config that removed a hydration error. Claude reordered two plugins and added a flag I hadn't seen before. The error vanished. Why plugin order cures hydration — I don't know and I'm afraid to touch it, the way a cook is afraid to touch an oven that finally stopped throwing off the temperature: it works — step away.
The third — the worst, because the quietest. A utility Claude wrote on the first day and wove into four places. It works. I stopped asking how. This is exactly the moment a dish moves from "I cook it" to "I order it": the recipe now lives not in my head but in someone else's hands, hands that aren't physically in the kitchen. As long as the orders come in — nobody cares. Right up until the evening the sous-chef doesn't show for his shift, the guest sends the plate back, and I'm standing over the stove with three dishes I serve every day and don't know how to make.
And here it's worth naming the thing for what it is, because the parallel is too precise to skip. Cursor, Copilot and this whole brigade monetize the feeling of motion — exactly as crypto in 2021 monetized the feeling that you're getting rich while the chart is green. There's one difference, and it's not in our favor. Crypto had volatility — an honest, visible acknowledgment of risk: the chart could turn red any second, and you saw it. Here the chart is always green. The risk is yours, the feeling of productivity is yours, and the bill for three recipe-less dishes comes to them in the form of one more monthly subscription. The green counter is HODL with no red day until the liquidation itself.
But there's a strong objection here that deserves full force, not deflation. The advocate of full agent autonomy will say: METR measured mature legacy repos with a million lines of code, where every change drags dozens of dependencies behind it — of course it dragged there. In a greenfield project built from the start for an AI workflow, the lines don't carry that load: the agent knows the whole codebase from zero, there are no unpredictable dependencies, no eternal context of prior decisions. And the atrophy problem is solved simply: you carve out two hours a week for hand-coding outside the AI workflow — and the muscle stays alive. No need to sacrifice speed for exercises you can do separately. This is an honest position, and in specific conditions it has real force.
But here's what it doesn't explain: greenfield projects stay greenfield exactly until they become a product. A year later — legacy. Three years later — legacy with a team that doesn't remember why it was done this way. And "separate exercises for atrophy" demand a discipline that in 99% of teams doesn't survive deadline pressure. What's effective for one disciplined senior with his own training schedule dissolves in organizational reality — and the debt the agent accumulated remains, even if the author himself exercises well.
The tool: levels of delegation, per Vandenburgh
Vandenburgh didn't say "turn off the autopilot forever" — that would be idiotic, the autopilot saves lives at cruise altitude. He said something else: know the altitude at which you take the controls back. Consciously choose the level of automation to fit the task. Here is that same idea, translated to delegating to Claude. Not "use it or not", but "at what level, for what, and where is my hand on the stick".
But before the table — a question the draft version of this text dodged: who, exactly, has an interest in you not asking this question? The layout here is three stories tall, and on each floor someone else gets the bill. The vendor collects the subscription regardless of how many commits survive. The company books the speed gain as profit and externalizes the technical debt onto future teams not yet on the payroll. And the skill atrophy is borne by the individual developer — not the vendor, not the company, but the one standing alone at the stove. Benefit socialized, risk privatized — the classic scheme where someone cooks the banquet and someone else washes the dishes. The table below is a tool not against AI, but against this specific distribution, where your endless trust in the autopilot is most profitable for everyone except you.
| Level | Aviation analog | What I hand to Claude | Where my hand is on the stick | Stall risk |
|---|---|---|---|---|
| 0. Manual | Hand-flying | Nothing. I think and write myself | The whole time | Low / slow |
| 1. Hint | Flight Director | Phrasing options, paragraph rewrite | I accept every sentence consciously | Low |
| 2. Draft | Autopilot, manual throttle | First draft of a section on my frame | I rewrite the thesis and the ending | Medium — "almost right" |
| 3. Agent | Full autopilot + autothrottle | Multi-file changes, series of commits | Review of every commit before merge | High — debt and clones |
| 4. Autonomy | Child of the magenta line | "Do it and ship it yourself" | None. You watch the counter | Spin |
The rule for using the table is one, Vandenburgh's. The moment you catch yourself asking "what is it doing here?" — you've fallen a level lower than you thought. Switch off the autopilot immediately and take the stick. Don't finish reading a commit thinking "well, seems okay". "Seems okay" at low altitude is exactly the 66% "almost right" that then gets debugged twice as long. The difference between level 3 and level 4 isn't a function in the code. It's the second in which you decided that looking was no longer required.
And, since the theme is exact prompts, here honestly is what worked and what didn't. A prompt-constitution at the start of the session worked: "Here is my voice (three examples). Here is what I do NOT write (a list of clichés). Always show the scene before the conclusion. Don't flatter." Narrow level-2–3 tasks with an explicit boundary worked: "rewrite only this section, don't touch the rest, return a diff." Everything at level 4 failed: "write a post about X" returned smooth, competent, dead text with no stake — a technically flawless autopilot flying nowhere with perfect posture. The worst failure was the request "clean up the duplicates": the agent happily added code but couldn't clean up after itself — exactly the GitClear curve, reproduced live on my own desk.
The altitude at which I take the stick
Let's return to that cockpit over the Atlantic. The scariest thing in the AF447 story isn't that the autopilot disengaged. It was supposed to disengage, it honestly said "you've got it from here". The scariest thing is that over years of smooth flight the human had forgotten how to do the thing she was in the cockpit for in the first place. The machine didn't kill the crew. The crew was killed by the unaccustomed hand that, in the one moment it was needed, did the opposite of correct — and did it confidently, because it didn't know how to do otherwise.
Here is my conclusion after 47 commits and 14 rewrites, without a warm ending, because a warm one here would be a lie. Nearly half of professional developers already work with AI daily, and the curve only goes up — this isn't a marginal experiment, it's the dominant mode. So the question "take the stick or not" will stand before almost everyone who produces anything. And everyone's speedometer is broken in one direction: it'll show +20% when it's actually −19%.
The child of the magenta line doesn't live in Claude. It lives in the part of me that enjoys watching the green counter and not asking what's under it. Claude is a wonderful intern you can neither fire nor promote: he won't grow inside you, and you, if you hand him the thinking, will wither inside him — and he's the only employee whose degradation is debited from your account, not his. A tender for your blog, where you are both the sole author of the prompt and the sole reviewer of the result — is a tender where the winner already sits on the committee and shakes his own hand. The only honest post that remains yours in it — not author, not reviewer, but the one who knows the altitude at which he switches off the autopilot.
I know mine. It's at the level of the final paragraph and the load-bearing thesis — there, where the text either has a stake or it's a corpse. This paragraph I wrote myself. Not because Claude couldn't have assembled similar words — he could have, and possibly smoother. But because this is the last dish in the kitchen I refuse to hand to other hands: the recipe must stay in my head, because that's exactly what tomorrow's guest, not yet in the room, will ask for. Otherwise one day a text gets served that I didn't actually think — smooth, competent, with 47 commits under it, like a perfectly plated dish that's cold inside. And no one, myself included, will pull it off the pass. I'll just stand over the stove, watching the green counter of orders — and not notice that I've already forgotten how to cook.
Frequently asked
What is the "automation paradox" and how does it show up in AI coding?
It's the effect, described for decades in aviation and nuclear power, where automation runs so smoothly you stop noticing your own skills decaying — until the bill arrives all at once. In AI coding the METR experiment caught it live: developers worked 19% slower with AI yet still felt 20% faster afterward. Your internal speedometer is broken in one predictable direction: it reads arrival while you're stalling.
Why is "almost correct" code more expensive than broken code?
Broken code is visible — you see it and throw it out cheaply. "Almost correct" passes your review, looks right, smells right, and ships — then breaks a week later in prod, like the A330 that flew flawlessly until one icy night exposed what the pilots couldn't actually do. In the 2025 Stack Overflow survey, 66% named "almost right but not quite" their top frustration, and 45.2% said debugging AI code takes longer. It's the alternate law of your codebase: everything works until it doesn't.
What does it mean that the machine "writes forward and doesn't clean up after itself"?
A commit counter measures what's added, never what should have been removed. GitClear's analysis of 211 million changed lines (2020–2024) found copy-pasted code rose from 8.3% to 12.3% while refactoring — the lines that move, that tidy up — fell from 25% to under 10%, with 2024 the first year copy-paste overtook refactoring. The sample skews to large corporate repos, so read it as direction, not a verdict — but the direction is one way: debt piles up silently, like water in the hold.
What is the steelman for full AI autonomy, and why doesn't it fully hold?
The strongest counter: METR measured mature legacy repos with a million lines and dozens of dependencies, so of course it dragged; a greenfield project built for AI workflow carries none of that weight, and atrophy is solved by two hours of hand-coding a week. It's an honest position with real force in specific conditions. But greenfield stays greenfield only until it becomes a product — a year later it's legacy — and the "separate exercises" demand a discipline that doesn't survive deadline pressure in 99% of teams. Benefit socialized, risk privatized.
What is the Vandenburgh rule for delegating to Claude?
Captain Warren Vandenburgh's rule was: know the altitude at which you take the controls back. Translated to AI: the moment you catch yourself asking "what is it doing now?", you've dropped a level lower than you thought — kill the autopilot and grab the stick. Don't finish reading a commit thinking "seems okay"; "seems okay" at low altitude is the 66% "almost correct" that gets debugged twice as long. The difference between level 3 and level 4 isn't a function in the code — it's the second you decided looking was no longer required.
Comments
Signed-in readers only — to keep it human, not a bot swamp.