AI writes code, not products: what was left for me once agents took over the typing

I no longer write most of the code in my own apps. Agents write it; I specify, decide and verify. It sped me up several times over — just not the way people usually talk about. The time it takes for a feature to be finished did not shrink. The time I have to spend on it did. And the interesting thing about what was left is that it is exactly the work I used to think of as secondary.

Where the speedup actually hides

The study everyone quotes in this debate measures something different from what I do.

METR in 2025 put 16 experienced developers on 246 real issues in open-source repositories they knew well. With AI tools they were 19% slower — while believing they had been 20% faster. That number went around the world. What gets quoted far less is that the February 2026 update, across 57 developers, 143 repositories and over 800 tasks, reversed it: returning developers came out around 18% faster, newcomers around 4%. The authors themselves add that this is only very weak evidence for the size of the speedup, and that participant selection likely makes it a lower bound.

But both studies still measure the same thing: how long a task takes a developer who is sitting at it. That is the mode where you have the model next to you and wait for it to finish typing.

My mode is different. I hand over a batch of work, put the laptop down and go do something else. A week can pass before a piece of the program is done — but my time inside it is a matter of hours: writing the brief, deciding two or three things along the way, reading the diff, going through the review.

Time-to-done did not shrink dramatically, and occasionally it stretched. My hours did, several times over. Writing Najeto by hand would have been months of evenings. This way it is weeks of calendar and days of my work — and those weeks are not empty, I am just doing something else in them. A stopwatch over a single task cannot measure that.

For the mode to work, three things have to hold: the work can be cut into pieces that do not wait on each other; you have something else to do meanwhile; and you have something that can verify the output. Miss any one and you fall back to sitting next to an agent — and there the speedup really is debatable.

On the other side of the ledger sits the 2025 Stack Overflow Developer Survey: over 84% of developers use or plan to use AI, but only 29% trust it — down 11 points year on year. And the single biggest frustration, reported by 66% of them, is not "it writes nonsense". It is "solutions that are almost right, but not quite".

That is the verification tax — and it is paid in exactly the resource delegation freed up, namely my time. The code I get back is nearly always syntactically fine, passes type checking, and looks like something I would have written, just a little less tidy. It also contains decisions I never had to make.

Conventions are an executable spec

The one thing that meaningfully raised the quality of the output was not a better model. It was rules written down concretely enough that they cannot be worked around.

I keep them outside the repository, as a set of conventions the agent loads depending on what it is doing. Not "write clean code", but:

• Every helper is its own file inside a helpers/ folder, file name equals function name, unit test next to it.
• No barrel index.ts; import directly.
• Shared constants go into constants.ts at the nearest common ancestor.
• Never any. as only with a JSDoc note explaining why.
• Branching over an enum is always a switch with an exhaustiveness check in default, never a chain of ifs — otherwise a new variant silently falls into whichever branch happened to be last.
• Screen variants (petrol, EV, plug-in hybrid, hour-metered) split at the top, at screen level, and share only the subcomponents underneath.

These are not style preferences. They are rules that shrink the space in which an agent can get it wrong. An exhaustive switch means a new variant is a compile error at every site that forgot about it — a safety net I do not have to police myself.

The more concrete the rule, the less room there is for "almost right".

Orchestration, not prompting

I do not talk to one agent. There are five, each with a different role and different limits:

The most useful rule of the whole set is the most boring one: review checks first whether the change belongs to the task at all, not whether it is correct. An unsupervised agent does not add a bug — it adds a feature you did not want, a refactor you did not ask for, and an "improvement" that breaks something three screens away. Scope is the thing that escapes first.

And the second rule: the manager must not write. The moment a planner can touch code, it stops delegating and starts "just quickly fixing it myself" — and the control loop disappears with it.

Where the bottleneck moved

Two years ago the limit was "how much can I type". Today the limit is "how much can I decide and verify" — typing could be delegated entirely, deciding and reading diffs cannot be delegated at all. That is exactly why my hours shrank while the calendar stayed much the same.

In practice that means:

• The spec became the expensive part. An hour with the spec-writer saves three hours of fixing something finished and wrong.
• Decisions must not hide inside the implementation. "Should I store the place name or the full address?" is a product question dressed as a technical one. When the agent does not ask, it decides on its own — and you find out a month later.
• The competitive edge moved. When anyone can produce a prototype in an hour, the value stops being the ability to build it. What is left is judgement about what to build, and getting it in front of people.

I am not claiming I would do this better without agents. Four apps alongside a full-time job would not have happened. I am only saying "AI built my app" is a bad description of what happened. AI wrote the code. The app still had to be decided by me — and that part did not shrink, it just stopped being hidden underneath the typing.

Sources

• Randomised trial on the impact of AI on experienced open-source developer productivity — METR, July 2025 (16 developers, 246 tasks).
• Updated results on a larger cohort and a change to the experiment design — METR, February 2026 (57 developers, 143 repositories, 800+ tasks).
• The academic paper for that study on arXiv — METR, 2025.
• The AI chapter of the 2025 developer survey — Stack Overflow, December 2025.