Programming with agents: what to learn, and in what order

Back to school. If this week you have finally resolved to learn to program with agents and gone looking for a path, you will have got back a list of twenty-odd items with a product name on each one. This editor, that CLI, this protocol, that orchestrator, this extension that shipped last month. Ordered top to bottom, with the implicit promise that whoever walks it comes out the other side having become something.

The problem with those lists is not that they are wrong. It is that they expire before you finish walking them.

The tools in this field have a half-life of under eighteen months: half the proper nouns in any roadmap published in 2024 no longer exist, go by another name, or belong to another company. What has not expired in seven years is something else, much duller and considerably more useful: the list of controls you have to rebuild by hand. Because every new name for the craft announced a task we were going to stop doing, and behind each one was a control that vanished along with it and that somebody had to put back together.

That list can be studied in order. Eight levels, each with three parts: what you stop doing, what you start doing and —the part that actually matters— how you know you have cleared it.

That third part is what separates a study guide from a syllabus, and it is not a formatting whim. In February 2026, METR abandoned the redesign of its productivity experiment because it can no longer get a control group: developers refuse to take part if it means working without an agent, even for money, and many admitted they were not submitting the tasks they feared having to solve by hand. If a lab with funding and method cannot measure whether this is faster, your feeling of getting better is worth nothing. Hence every level ending in something that can be checked from outside.

One warning before starting, and this one is measured: productivity dips before it rises. DORA calls it the J-curve —learning curve plus review overhead— and it explains why so many people quit at exactly the low point, when they have already paid and not yet collected.

Level 0. Reading code you did not write

You stop typing code. You start assessing somebody else’s prose in a formal language, which is a different skill from writing it and one almost nobody has trained seriously.

It sounds elementary and it is the level where most people get stuck, because it is invisible: nobody tells you that you passed. It is also the only level that cannot be skipped. Everything that follows consists of delegating the writing, and delegating without knowing how to judge the result is not delegating, it is signing a blank check.

Exit criterion: in a generated change that passes the tests, you find something that still needs fixing, and you can say why in one sentence. If the only things you find are matters of style, you are not reading yet.

Further reading: Spinellis treats reading other people’s code as a technique with exercises in Code Reading (2003). It predates all of this and deals only with the part that has not changed, which is exactly the part that matters here.

Level 1. Vibe coding with a perimeter

You stop reading the code. You start deciding in advance where not reading it is allowed.

Vibe coding is a legitimate tool with a narrow domain of application: prototypes, explorations, scripts that run once, things whose failure costs nothing. The level is not about learning to do it —there is nothing to learn— but about learning to bound it. The dangerous thing is not Saturday’s prototype; it is Monday, when the prototype walks into a repository that does matter without anybody having decided it was going in.

Bounding sounds abstract until you write it down. In a single-use script, or in an exploration branch that will never be merged, not reading the code is fine. In anything that touches billing, authentication or migrations it is not, because there a plausible error breaks none of the tests you have and gets paid in money or in data.

Exit criterion: you can write in one line, for a specific repository, where not reading the generated code is allowed and where it is not, and that line survives a colleague arguing with it.

Further reading: “Not all AI-assisted programming is vibe coding”, by Simon Willison, is useful above all for arguing the boundary with a team without the conversation turning into a fight between camps.

Level 2. The loop and the safety net

You stop driving. You start building the place where the agent can be wrong for free.

What you study here is not the agent, it is git. Short-lived branches, small commits, worktrees, containers, sandboxes, explicit permissions, cheap undo. A developer with version control hygiene can let an agent work for hours and lose, at most, compute time. Without it, every run is a bet placed on a working tree they cannot reconstruct.

It is by some distance the level with the best return in the whole itinerary, and almost no public roadmap includes it, because it contains no new technology. And it weighs more the worse the repository is: DORA measures effectiveness on complex legacy systems at under a third of what it is on new work, so on an old and tangled codebase this level is not preparatory, it is the condition for anything else to be worth doing.

Exit criterion: you can throw a full hour of an agent’s work in the bin without losing anything of your own and without thinking twice.

Further reading: the worktrees chapter of Pro Git reads in an afternoon and is free. It mentions agents on no page whatsoever; that is exactly why it still works.

Level 3. Context as a budget

You stop writing prompts. You start administering a window with limited resources.

This is where the techniques the industry formalized in 2025 come in, plus a discipline: a short instructions file —a pilot’s checklist, not a style guide—, compaction when it is due, notes kept outside the window, subagents for whatever makes a lot of mess and returns little, and just-in-time retrieval —pulling content in by its path when it is needed— instead of preemptive dumps. Along with one counterintuitive idea that takes a while to acquire: adding more context makes the result worse past a certain point, and that point arrives sooner than the size of the window suggests.

Exit criterion: faced with a run that went wrong, your first hypothesis is what was in the context at that step, not which model you were using.

Further reading: Anthropic’s engineering post on context, read with the reservation any interested party’s writing deserves, is where these techniques are described in most detail.

Level 4. Executable verification

You stop checking by hand. You start turning acceptance criteria into checks that run on their own.

This is the level that absorbs the verification tax, and that is why it is the center of gravity of the whole itinerary. It has two faces. Before: a written specification, however short, and even if it dies with the feature —the spec-first level of Böckeler’s taxonomy is enough for the overwhelming majority of teams—. After: tests, types, linters, hooks and, when the check cannot be automated, an evaluator that is not the same instance that did the work, because agents approve themselves with remarkable generosity.

And one metric to internalize here rather than later: what matters is not that it gets it right once, but that it gets it right every time.

Exit criterion: the agent cannot declare itself the winner on its own; something outside it has to agree.

Further reading: Specification by Example, by Gojko Adzic (2011), is the prehistory of all this, fifteen years before anyone needed it. It does not talk about agents, it talks about how an acceptance criterion becomes something that executes, which is the hard half of this level.

Level 5. Tools and their blast radius

You stop running the actions yourself. You start deciding which ones the agent may run without asking, and what the worst case is for each.

If level 2 protected your work, this one protects everything outside the worktree: the network, the databases, the credentials, the remotes, the money. The technical part is the easy part —MCP for the agent-tool axis, ACP for the agent-editor axis, and the empirical observation that ten well-bounded tools outperform fifty overlapping ones—. The hard part is the inventory of damage.

And nearly all real damage is accidental. A force-push onto a shared branch. A key committed. A migration run against the wrong database because the environment variable pointed somewhere else. Nobody attacked anything: you granted the capability and it got it wrong, which is what stochastic systems do.

On top of that sits a second case, less frequent and a good deal nastier, worth knowing about even if it has not happened to you yet. Simon Willison’s lethal trifecta —private data, untrusted content and an outbound channel— gets assembled by a coding agent with nobody planning it: your repository and your credentials, the README of a dependency or the text of an issue written by anyone at all, and a shell with network access. As long as the three coincide there is no patch, only separation. The 2026 CVEs against specific coding agents came from exactly there.

Exit criterion: you can say, for every capability your agent has been granted without asking, what is the worst it can cause by getting it wrong. If you have to open the configuration to answer, you did not decide it.

Further reading: Threat Modeling, by Adam Shostack, is from 2014 and is about systems under attack, not systems that get things wrong. It works anyway, because the question it teaches you to ask —what can go wrong here, and what does it cost— is the same in both cases.

Level 6. The environment as a product

You stop watching. You start building the thing that watches.

This is the harness level, and its method fits in one sentence: no rule enters the environment without a real failure behind it. The agent gets something wrong, you change the environment, you document which error the change answers. The rest is putting the controls in the right place —the deterministic before the commit, the arguable after integration— and keeping the trajectories, because without a record of what the agent did and why, you are not doing environment engineering, you are speculating about it.

Exit criterion: your failure rate drops measurably without your having changed model.

Further reading: there is no finished book, and the reason says more than any recommendation would. The only one taking the harness seriously, Agentic Engineering at Scale by Chris Ford, has been publishing chapter by chapter in early release for months and is still not whole. In the meantime, the most solid things out there are Hashimoto’s notes and Böckeler’s work, and they are articles.

Level 7. The fleet, the cost and the signature

You stop working with an agent. You start managing several, and you discover that the scarce resource is no longer generation.

When you can launch five agents in parallel, the limit stops being how many changes get produced and becomes how many you can review, integrate and stand behind. The work here is management and accounting: real parallelism with real isolation, a review queue that does not jam, and a metric still missing almost everywhere, cost per accepted change, which is the only thing that turns token consumption into an interpretable figure.

And one decision that is not technical and that nobody delegates on your behalf: what does not get automated. Which change does not ship without somebody looking at it. Who signs.

Exit criterion: you measure, you have a number, and that number matters to somebody other than you.

Further reading: Accelerate, by Forsgren, Humble and Kim, is about measuring software delivery with not a single agent involved. It has been cited to exhaustion and it is still a good place to argue about which number is worth having, which is this level’s question.

What no public roadmap includes

The lists from the opening have a second trap, worse than expiry and more expensive: most of them teach a syllabus of Python, asyncio, vector databases, RAG and orchestration frameworks. That is not this. That is building agents, which is a different craft, with a different market and a different hiring profile. What you have just read is developing software with agents.

On the second one there are books, though few and young. Kim and Yegge published Vibe Coding in 2025, more manifesto than manual and useful precisely for that when what you need is to convince somebody; Osmani put out Beyond Vibe Coding the same year, considerably more sober and with free companion material. Neither of them reaches the upper levels of this route, and that is not an oversight on their part: the book that takes those seriously is still being written. And it is worth not confusing that shelf with the one beside it, the one holding Chip Huyen’s AI Engineering, which is excellent and belongs to the other profession.

The confusion is not new: back in 2023 swyx already separated the software engineer amplified by AI from the engineer who builds products with models, and warned that the first would end up being the floor of the market rather than a differentiator. That is exactly what has happened. The “AI engineer” role is unbundling into specialties —agentic systems architecture, evaluation and governance, inference optimization, post-training— and none of them is the one you need to ship a feature on Thursday.

There are also four things that determine the outcome and appear in no syllabus because they do not sell well. Reading diffs at volume without your attention shutting down, which is a human factors problem documented since 1983 and not a question of personal discipline. Budgeting, because every control you add is paid for in compute and reliability has a price. Knowing what does not get delegated. And the most uncomfortable one: how you train whoever comes next, when the first layer of tasks —the one that used to teach you how to judge— is precisely the one that has disappeared.

You are going to write level eight yourself

These eight levels do not describe a career that ends. They describe a method, and the method is the only thing that survives the next word.

Because there will be another one. Before Christmas, probably, a new term will show up with its wave of threads, its corporate report and its roadmap of twenty-odd items, and it will announce —like every one before it— one more task the human stops doing. When it arrives, the question is not whether it has to be learned. It is the same question that orders this entire list: which control disappears with it, who rebuilds it, and how you check from outside that it has been rebuilt.

If you can answer those three, you write level eight yourself, and you get there ahead of the people waiting for somebody to publish the syllabus.