Two years of agentic coding: what stuck
The workflows that survived contact with real work, the ones that did not, and what the whole thing actually changed.
Terminal coding agents went from research preview to standard tooling in about two years. Enough time has passed to separate what stuck from what was a phase.
what stuck#
Mechanical refactors at scale. The clearest win, by a wide margin. Renaming a concept across four hundred files, migrating a deprecated API, converting a pattern used everywhere. Verifiable, tedious, and exactly what the tools are good at.
The important second-order effect: refactors that were too expensive to do now happen. A codebase where cross-cutting cleanup is affordable is a meaningfully better codebase, and that is a permanent improvement rather than a productivity number.
Working in unfamiliar territory. A language you do not know, a framework you have not used, an API you have never touched. The median output in an unfamiliar domain is better than your first attempt, and reading it teaches you the idioms.
This is the use case I would defend most strongly and it is discussed least.
Test generation from a specification. Not "write tests for this function" — that produces tests that assert the implementation. But "here is the behavior, write tests that verify it" works well and it inverts the effort in the right direction.
Investigation. Reading logs, bisecting history, tracing a call path, summarizing a large diff. Parallelizable, cheap, and it saves the expensive resource, which is your attention.
Repository-level instruction files. AGENTS.md and its equivalents became standard practice, and the discipline of writing down how your project actually works improved documentation for humans as a side effect.
what did not stick#
Fully autonomous feature development. The demo works. The real version produces a plausible implementation of a subtly different feature, because the requirements that live in someone's head were never written down.
Agent fleets at high concurrency. The generation scales; the review does not. Two to three concurrent agents with one reviewer turned out to be the practical limit, and the constraint is entirely on the human side.
Orchestration frameworks. Absorbed into the models, as function-calling libraries and JSON-repair libraries were before them. The durable layer was never orchestration.
"Just describe it and it builds." For anything with design decisions, the description that is precise enough to produce the right result is approximately as long as the code, and writing it is the same work.
what actually changed about the job#
Review is the bottleneck, permanently. Generation got roughly two orders of magnitude cheaper. Verification got no cheaper at all. Everything downstream follows from that asymmetry and nothing in two years has changed it.
Tests became the primary artifact. If the implementation is cheap and verification is expensive, effort moves to specification. The teams getting the most out of these tools are the ones with strong test suites, and the correlation is not subtle.
Type systems got a promotion. Every constraint the compiler checks is verification you do not perform by reading. Teams that were ambivalent about strict typing became evangelists, and the reason is always the same: it catches the class of error generated code produces most.
Small diffs became non-negotiable. A machine can produce two thousand lines effortlessly. Accepting it is not a favor to anyone.
The skill that separates people is judgment, not speed. It always was. It is now the only thing, and the gap between engineers who can tell when output is wrong and engineers who cannot is much more visible than it was.
the thing still unresolved#
The apprenticeship problem.
The judgment that makes a senior engineer valuable was acquired by writing a lot of code badly and then debugging it. That work is being automated. Nobody has a replacement for how the next generation acquires it, and junior hiring contracted sharply during exactly the period when the training mechanism was being removed.
I have written about this several times and I still do not have an answer beyond: deliberately do the hard part yourself sometimes, review generated code carefully as a learning exercise, and hire juniors anyway.
That is a partial answer to a structural problem and I am not satisfied with it.
the honest summary, two years in#
These tools are genuinely useful and the useful envelope is narrower and more specific than either the enthusiasts or the skeptics claimed.
They are excellent at bounded, verifiable, tedious work. They are unreliable at anything requiring judgment about what should be built. They multiply output and do not multiply throughput, because throughput is limited by review.
The engineers getting the most from them are the ones who were already good at specifying problems precisely and at telling when something is wrong. That is not a new skill and it was never evenly distributed.
Which is roughly what every previous tooling revolution did: raised the floor, moved the bottleneck, and made expertise more valuable rather than less.
— Dom, July 31, 2026