Coding agents crossed the line from autocomplete to delegation

For three years the defining AI coding experience was the same shape: you typed, something guessed the rest of the line, you accepted or you didn't. It was useful. It was also bounded — the model never held more than the fragment in front of it, and you never stopped being the person doing the work.

That shape has changed. The tools people now describe as "coding agents" don't complete your line. They take a task, read the repository, run commands, read the failures, and come back some time later with a diff. The loop is no longer keystroke-sized. It's task-sized.

That sounds like a difference of degree. It isn't.

The unit of work is what changed

Autocomplete sits inside your attention. You are already in the file, already holding the problem, already going somewhere — the model just shortens the distance. Your understanding of the code never lapses, because you never left.

Delegation sits outside your attention. You describe an outcome, the work happens somewhere else, and you rejoin at the end to judge a result you didn't watch being produced.

This is why the experience of using a good coding agent feels less like using a faster editor and more like reviewing a junior engineer's pull request — including the part where reviewing carefully sometimes costs more than writing it yourself would have.

What gets better, concretely

Three categories of work changed materially:

• Mechanical, wide changes. Renaming a concept across ninety files, migrating a deprecated API, threading a new parameter through a call chain. These were always tedious rather than hard, and tedium is exactly what a long-running loop absorbs well.
• Work gated on a feedback signal. Anything where success is checkable — making a failing test pass, getting a build green, fixing a type error — because the agent can run the check itself and iterate without you.
• Unfamiliar-codebase reconnaissance. "Where does authentication actually get enforced?" is a question that used to cost an afternoon of grepping.

The common thread is not intelligence. It's the presence of a cheap, automatic verdict the loop can run against itself.

What doesn't get better

Work without a verdict stays hard. Naming a concept well, choosing which abstraction earns its keep, deciding that a feature shouldn't exist — none of these have a test that goes green. An agent will produce a confident answer for all of them, and the confidence is uncorrelated with the quality.

What this changes in practice

If you write software, the highest-leverage adjustment is not learning to prompt better. It is making your repository legible to a process that can only learn from what it can run.

An agent is only as good as the feedback loop you hand it. Tests, types, linting, and a build that fails loudly aren't hygiene any more — they are the interface.

Concretely, that means:

1. Invest in checkable signals. A test suite that runs in thirty seconds is worth more to an agent than a beautifully written contributing guide.
2. Keep diffs small enough to review honestly. The moment a change is too large to read, the safety property you were relying on is gone, regardless of who wrote it.
3. Decide explicitly where the approval gate sits. Not everything needs one. Things that touch production, credentials, or data absolutely do.

The larger question

The thing worth sitting with isn't whether agents write good code. On many well-specified tasks they already write acceptable code.

The question is what happens to an engineering organisation when producing code becomes much cheaper than reading it. Review is the only remaining place where human understanding of the system is renewed — and review is the step that does not get faster.

That's the tension the next few years of software engineering will be about.