How coding agents actually work, stage by stage

A coding assistant suggests the next line. A coding agent is handed a ticket and comes back with a branch. The gap between those two is mostly engineering that happens outside the model.

Here is what actually runs when you give one a task, and where each stage tends to break.

How coding agents work: the shape of a run

Four stages, in order: understand the request, find the relevant code, make changes, verify them. The model is involved in all four and in charge of none.

Meta’s Muse Code describes exactly this shape, planning changes, writing code and validating results across large repositories.

The model never touches your repository. It names a tool and supplies arguments, and your code decides whether to run it.

That separation is the security boundary, and it means the quality of an agent is largely the quality of the tools it was given rather than the model behind it.

Finding the code is the hard part

A large repository does not fit in a context window and would not help if it did. So the agent has to locate a few relevant files before it can reason about anything.

Most systems combine keyword search with embedding search, because each fails where the other works. Semantic search misses exact identifiers; keyword search misses the function that does the thing without using the word.

The underlying idea is the one from the original RAG paper, combining “pre-trained parametric and non-parametric memory”, and our guide to vector search covers the storage side.

Retrieval quality sets the ceiling on everything downstream. An agent given the wrong three files will write a confident, coherent, wrong change.

Which is why repository structure matters more than people expect. Clear module boundaries and descriptive names help an agent for the same reason they help a new hire, and a codebase organised by accident is hard for both.

Why the good ones plan first

Asking for a plan before any edit is not a stylistic preference. It measurably improves the outcome.

Google Research showed in Chain-of-Thought Prompting that working through steps before answering beat a fine-tuned model on a maths benchmark, and a code change is a chain of dependent decisions.

Newer work pushes further, having agents simulate a course of action before committing to it. A simulated dead end costs one generation; a real one costs a tool call, its output, and permanent space in the transcript.

A plan is also the artefact you can review. It’s far cheaper to reject a wrong approach in three lines than a wrong implementation in three hundred.

Sub-agents and worktrees

The newest design choice is to stop running one long agent and run several short ones instead.

Muse Code fans work out to sub-agents running in parallel in isolated worktrees, which CNBC noted as the mechanism for handling large projects.

	One long agent	Parallel sub-agents
Context per unit	Grows all run	Stays short
A failure	Contaminates everything after	Ruins one worktree
Token cost	Quadratic in steps	Higher total, lower per unit
Conflicting edits	Impossible	Now your problem to merge

The motivation comes straight from the failure data. Long agent runs degrade on context rather than capability, which our piece on the 2026 research covers, and short chains are the reliable fix.

Tool design decides quality more than the model does

Give an agent a tool called run_command and it’ll do something surprising eventually. Give it read_file, run_tests and apply_patch and it stays inside a space you defined.

Error messages matter as much as the tools. The model reads them, so an error saying which argument was wrong and what values are valid gets corrected next iteration, while a stack trace gets the same mistake retried.

Output size matters too, and it’s the one people miss. A tool that dumps an entire file into the transcript has spent context that the agent needed later, which is why summarising tools outperform raw ones.

Permissions are the last piece. An agent that can commit to a branch is a different risk from one that can push to main, and that distinction is enforced in your code rather than in the prompt.

Verification is what makes this work at all

Code is one of the few domains where a model can check its own output mechanically. Tests either pass, the build either succeeds, the type checker either complains.

That is why coding agents work better than agents for most other jobs. DeepSeek’s R1 work found “self-reflection, verification, and dynamic strategy adaptation” emerging specifically where answers could be checked.

It also sets the limit. An agent working in a repository with no tests has no feedback signal, and its output is a guess formatted as a diff.

Which produces an awkward result: these tools help most where the codebase is already disciplined, and least where the mess is worst.

The bottleneck moved downstream

Generation got cheap. Reading the result did not, and it is still done by people who did not write it.

The market noticed before most engineering teams did, with CodeRabbit raising $143 million to help companies govern AI-generated code.

So the practical advice is to size the review capacity alongside the tool. Ten parallel agents produce ten changes for a team that was already the constraint.

Evaluating how coding agents work, honestly

Ignore the benchmark score. Coding benchmarks saturated to near 100%, and a well-specified benchmark issue is nothing like the ticket your team actually files.

Take ten real tickets from your own backlog, run them, and count how many produced a change you would merge without rewriting it. That number is the only one that transfers.

Then count the tokens it took to get there, because the economics of an agent that needs four attempts are very different from one that needs one.

Whether to use a framework for all this or write the loop yourself is the next decision, and our comparison of what a framework actually buys you works through the trade.

Review capacity is the constraint this creates downstream, which is why CodeRabbit raised $143 million to help companies govern the output.

And check how it behaves on a task it can’t complete. An agent that stops and says so is deployable; one that keeps going and produces something plausible is a liability, and you’ll only find out by giving it an impossible ticket.