AI Did Not Make Me Faster. It Changed What I Am Slow At.
I design products and I write the code. Three of the apps on the App Store are mine end to end: my idea, my design, my code, my name on the listing. So people assume I am going to tell them AI made me fast.
It did not, exactly. It changed what I am slow at, which is a different claim and a more useful one.
There is a study I keep coming back to because it embarrassed everybody, including the people who ran it. In July 2025, METR published a randomized controlled trial on experienced open source developers working in repositories they already knew well. Sixteen developers, 246 real tasks, an average of five years on the codebase. Before starting, they predicted AI would cut their completion time by 24%. Afterwards, they estimated it had cut it by 20%.
It increased their completion time by 19%.
They were slower and they were certain they were faster. That gap between the felt speed and the measured speed is the most honest thing anyone has published about this technology.
I should say immediately that METR has since walked back how much weight the number can carry. Their follow up work hit serious selection problems, and one of their own researchers now thinks developers are more sped up in early 2026 than the early 2025 estimate suggested. Fair. The tools got better and the study was a snapshot. I am not citing it as a verdict on AI. I am citing it because it proves the measurement problem exists, and I have never seen a company measure this at all.
What actually got cheaper
Production got cheaper. That is the whole change and it is enormous.
A screen used to be an afternoon. Now it is a few minutes, and if I do not like it I throw it away without the sunk cost feeling that used to keep bad work alive. The same is true of a first pass on a data layer, a migration script, a set of icons, or the fourth variation of an onboarding flow that I only wanted to see in order to rule it out.
What that buys is not time. It is a larger number of options considered before committing. I now routinely look at five approaches where I would previously have looked at one, and the one I ship is better because the other four existed.
That is a real gain and it does not show up as speed. It shows up much later, as the redesign I did not have to do.
What did not get cheaper
Almost everything that decides whether the product works.
Knowing what to build has not moved at all. A model will happily produce whatever I describe, at length, with confidence, which means a bad decision now gets built faster and further before anyone notices. Being wrong is more expensive than it used to be, not less, because I get to the fully realized version of the wrong idea in a day instead of a fortnight.
The last 10% has not moved much either. The state nobody thought about. The permission dialog that fires at the wrong moment. What happens when the network drops halfway through. Models are good at the shape of a solution and unreliable at the specific case, and the specific case is what users actually hit.
Review, privacy declarations, entitlements, store listings, screenshots at every size, the crash that only appears on a device you own and not in any simulator. None of that is faster.
And taste has not moved at all. When five options take ten minutes to produce, the scarce act is knowing which one is good and being able to say why. That skill was always valuable and it was previously hidden behind the cost of production, because when you could only afford one option, nobody found out whether you could choose.
The thing that surprised me
My bottleneck stopped being the work and started being my own review capacity.
I can generate more than I can properly read. That is a genuinely new failure mode. It is very easy to accept something that looks right, because it does look right, and to find out three weeks later that it was subtly wrong in a way that has now spread into four other places.
The habit that fixed it was boring: I read everything I ship, and if I am too tired to read it, I do not ship it. Not a rule about AI. A rule about me.
This is where the METR result stops being an amusing statistic and starts being a warning. If experienced engineers in code they know well can be 19% slower while feeling 20% faster, then a company rolling this out across hundreds of people and measuring nothing is not managing a productivity programme. It is running an uncontrolled experiment and reporting the vibes.
What this means if you are not a solo developer
Most companies I talk to are asking whether AI lets them hire fewer people. That is the wrong question and it is also, structurally, the defensive question.
The better question is what your team could attempt now that was previously not worth attempting. The small internal tool nobody could justify. The second language version. The accessibility work that kept losing to the roadmap. The prototype that settles an argument in two days instead of being debated for two quarters.
Those are the things that were killed by production cost, and production cost is exactly what fell. Meanwhile the things that were killed by lack of clarity are all still there, untouched, because no model has ever told a company what its product should be.
If I had to give one piece of advice to a team starting this, it would be to measure something before you begin. Anything. Time to first working version, number of open bugs at ship, how long a decision takes to get made. Pick two numbers and write them down. Otherwise in a year you will have spent real money and your only evidence will be that everybody feels faster, and we already know from a controlled trial exactly how much that feeling is worth.
The part I will defend
Building alone with these tools is genuinely different from what was possible five years ago. I do not think that is hype. One person can now hold design, code and release in their head at the same time, and the handoff losses that eat most product teams simply do not occur, because there is no handoff.
But the reason it works is not that AI is doing the job. It is that the job is now mostly deciding, and deciding was always the part I was being paid for.
References
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 July 2025. 16 developers, 246 tasks, forecast 24% speed up, self reported 20% speed up, measured 19% slow down. Preprint at arXiv:2507.09089.
- METR, We are Changing our Developer Productivity Experiment Design, 24 February 2026. Documents the selection problems in the follow up work and METR's current view that developers are likely more sped up in 2026 than the 2025 estimate implies.