When people ask what I use AI for, the picture behind the question is usually a robot writing the whole program while I watch. The real thing is smaller and stranger than that, and after about a year of running an AI assistant as the main way I write code, I can finally describe it without exaggerating in either direction.
The short version, before the details:
- I have no honest number for how much faster it made me, and neither does anyone else selling you one. The most careful study run so far found experienced developers going slower with these tools while feeling faster.
- What genuinely sped up is the boring, fully specified work: the tenth variant of a config, a component ported from one framework to another, the first draft of code I was going to rewrite anyway.
- What got worse is the reading. I write less and review more, and reviewing is the harder job. Code that compiles, runs, and is quietly wrong is now something I generate several times a week.
- I stopped letting it near a few things on purpose, and the test is how much damage a wrong move could do rather than whether it could do the task.
What the one careful study found
The pitch for every AI coding tool is a percentage. Forty percent faster, two times the output, that sort of thing. When someone actually measured it properly, the percentage came out negative.
In mid-2025 a research group called METR ran a randomized controlled trial with experienced open-source developers working in their own large repositories. Half the tasks allowed AI tools, half did not. The developers expected the AI tasks to go about 24% faster. They came out about 19% slower. And after finishing, having lived through the slowdown, the same developers still estimated that the tools had sped them up by around 20%.[1]
The estimate-after-the-fact is the part I recognise. The feeling of speed is real: you are typing less, the screen is filling up, momentum feels high. Whether the pull request actually landed sooner is a separate question, and it is not the one your gut is answering.
METR were careful about the limits of what they found: experienced people, their own codebases, a specific set of tools at a specific moment. It is not a verdict on every situation. But it is the closest thing to a real measurement I have seen, and it points the opposite way from the marketing. So I stopped trying to claim a speedup and started paying attention to what the work turned into instead.
What actually got faster
The honest list is unglamorous.
Renaming a concept across a codebase, where the change is mechanical but touches forty files and three of them have a subtle variation. Writing the config for the fifth deploy target that is almost like the fourth. Porting a component from Vue to a React equivalent when the logic is settled and only the syntax changes. Generating the first version of something I already know I will rewrite, because a bad draft is easier to react to than a blank file.
This website is the clearest case I have. The chart below is its commit history by year: it sat almost untouched through 2024 and 2025, then in 2026 I rebuilt it from scratch on a different framework, and the count for this year so far is close to four times every prior year put together.
The tool did not create the two-year gap and it did not create the decision to close it. What it changed was the cost of each individual step in the rebuild. A framework migration on a solo side project is the kind of work that normally dies in the messy middle, where every remaining task is fiddly and none of them is interesting. Dropping the cost of the fiddly step is enough to keep going past that point. The AI is not especially good at websites. The count went up because “I will do that later” stopped being the automatic answer to every small task.
None of that is a two-times multiplier. It removes one kind of friction from one kind of work, and that work is the part of the job I was glad to hand off anyway.
What got worse
I now spend more of my day reading code than writing it, and reading code you did not write, to a standard where you would sign your name under it, is genuinely hard. It is the part of code review that senior people find tiring even when a colleague wrote the code and can explain it. Doing it several times an hour, against output that has no author to ask, is a different daily experience from typing.
The failure mode that costs the most is not the code that breaks, because that announces itself. It is the code that compiles, runs, passes the obvious check, and is subtly wrong in a way you only catch if you already knew the answer.
I have shipped that failure onto this very site. Earlier this year I went back through the blog and found that four articles contained figures and code blocks presented as coming from this repository that did not match the actual files. A schema described with the wrong field count and the wrong base path. A configuration snippet introduced as “the real config from this blog” that contained two options the file has never had. An opening anecdote about a session recording of a real client visit, when no session recorder had ever been installed. Every one of those read as more authoritative than careful writing would have, because confident prose with a specific detail attached is exactly what a language model is good at producing. I had reviewed all of it. It all looked right. It took a deliberate line-by-line pass against the source files to catch, and the corrections are in the page histories now.
METR’s explanation for their slowdown matches this. Their developers lost time cleaning AI output up to the standard their projects required: style, tests, documentation, the implicit conventions of a codebase the model has never worked in. The generation is fast. The bringing-it-up-to-standard is not, and it is work that did not exist before in the same shape.
What I stopped handing it
Two things, for two different reasons.
The first is editor autocomplete, the kind that suggests the rest of the line as you type. I used it for a while and turned it off. For me it interrupted the part of programming where you are still deciding what the code should be, by constantly proposing an answer before I had the question straight. Other people love it. I found it was pulling my attention toward evaluating a suggestion instead of toward the problem, and the constant small yes-or-no decisions were more tiring than just writing the line. I never moved to an editor built around it either.
The second is anything where a wrong tool call has a large blast radius. The tool I use runs in a terminal, not an editor,[2] and it connects to a handful of outside systems through a small protocol called MCP:[3] my task tracker, a secrets store, the analytics for this site. The rule I hold those to is not “read only”, because that is not what I granted and I should not claim it. It is reversibility. It creates and edits tasks in my own tracker freely, hundreds of times over, because a wrong task is a thing I delete in one click. It does not get near a customer database or a production console, because “the model will probably not do the bad thing” is not a strong enough guarantee when the bad thing cannot be undone. I wrote up the full set of connections I kept and the much longer list I cut separately; the short rule is that a connection earns its place only if I can name the weekly friction it removes, and only if the worst thing it could do is something I could undo.
The grant is wider than it feels day to day, which is easy to forget until you count. When I went through the session logs for this site I found 743 task-creation calls and, less comfortably, two dozen reads and writes against the secrets store. Every one of those was something I asked for. None of them was something I would have listed if you had asked me to describe the setup from memory.
The shape, not the size
A year in, here is the change I can actually name. The work is front-loaded onto review instead of writing. A solo project is more likely to survive its boring middle. And I have a new recurring way to be wrong that I have to guard against on purpose.
That is a real change and I would not go back. It is just not the change on the box. If you are deciding whether to adopt one of these tools, the question worth asking is not speed, because you will feel faster whatever happens and the measured answer might still be slower. Ask instead whether you would rather spend your day producing code or vouching for it. That is the trade.
It is the same exercise as keeping an honest list of what you check on a portfolio rather than what you assume people look at. The version you can defend is shorter, and less flattering, than the one you would like to be true.