Coding agents

This is probably the agent you already use every day: Claude Code, Cursor, Codex, Devin. Under the hood it is nothing exotic - a model in a loop, running tools over your repo. What makes coding the breakout application is not a special model. It is that code has a property most tasks lack: outcomes are verifiable. A test passes or it does not. That single fact turns a code generator into a self-correcting agent.

A coding agent is a model in a loop over a repo

Strip away the UI and a coding agent is, in Simon Willison's phrase, "an LLM + a system prompt + tools, run in a loop."^[1] The model emits a tool call; a harness executes it against the real world (the filesystem, the shell, git), captures the result, and calls the model again. The loop stops when the model returns no tool call (it thinks the task is done) or a step or cost safeguard trips. You have seen this machinery already: it is the agent loop, wired to real tools, with reflection baked into every turn. "A simple tool loop is a few dozen lines of code - a good loop (recovery, context management, permissions, caching) is where the engineering lives."^[1]

Claude Code's docs describe the loop as three blended phases that repeat until the work is verifiably done. A question about your codebase might only need the first; a bug fix cycles through all three, over and over.^[2]

Crucially, the human stays in the loop. You can interrupt (Esc), or type a correction that the model reads after the current action finishes: a live steering signal, not a fire-and-forget batch job.^[2]

The loop, as a cycle

Here is the beating heart of every coding agent. The branch at run tests is the whole point: green exits the loop, red routes to reflect / fix and the cycle continues.

Why coding is the breakout application: verification

Every other applied-agent domain - clicking around a GUI, drafting an email - struggles because success is fuzzy and expensive to check. Code is the exception. The generation-verification loop closes cheaply and automatically: generating a fix is hard, but checking it is a compiler pass, a type-checker, a test suite, each a fast, objective, machine-runnable verdict. That asymmetry is what lets the agent grade its own work and iterate without a human in the middle of every step.

This makes the single highest-leverage practice obvious: give the agent something to verify against. Provide the failing test, the expected output, the target screenshot. Anthropic's own harness guidance goes further: verify end-to-end (drive the real app), not just unit tests, because agents will otherwise mark a feature "done" that does not actually work for a user.^[3]

Context gathering: agentic search, not RAG

Before it can act, the agent has to find the relevant code in a repo it has never seen. There are two philosophies, and this is one of the most instructive design forks in the whole field.

This is not "good versus bad": both are shipping products. It is a real tradeoff - precision, freshness, and privacy versus conceptual recall on large repos. It is the same RAG-versus-tool-use tension from the retrieval module, now decided for code specifically.

The harness and the ACI: the interface drives performance

Here is the counter-intuitive lesson. The Princeton SWE-agent paper found that the interface you give the model matters as much as the model itself. A human-oriented UI (the raw Linux shell) is a bad fit for a language model. Wrap the same GPT-4 Turbo in a purpose-built Agent-Computer Interface (ACI) and SWE-bench performance jumped from ~3.8% to 12.5%, roughly 10.7 points over a plain-shell baseline.^[8] Same model. Better interface.

The harness is that interface plus the machinery around it - Claude Code is "the agentic harness around Claude: it provides the tools, context management, and execution environment."^[2] SWE-agent distilled four ACI design principles worth memorizing:

1. Actions should be simple and easy for a model to understand.
2. Actions should be compact, accomplishing a lot in few steps.
3. Feedback should be informative but concise, never flooding the context window.
4. Guardrails mitigate error propagation and speed up recovery.

Those are not slogans, they are concrete components. Compare what a human tool exposes versus what SWE-agent's ACI exposes:

The lint-guarded editor is the sharpest example of principle 4: it stops the agent from ever seeing a broken file, a whole class of downstream errors prevented at the interface. A real harness adds more on top: context management (auto-compact older tool outputs, then summarize, which is why durable rules belong in CLAUDE.md, not chat, since compaction can drop early messages), permissions (ask before edits or commands with irreversible side effects), checkpoints (snapshot each file before editing so you can rewind), and subagents with fresh isolated context that return only a summary.^[2] One more quiet economic driver: harnesses never mutate earlier turns, so the prompt prefix stays cache-hittable, cutting the token bill of a long session dramatically.^[1]

Watch it run: fixing a failing test

Prompt: "The checkout flow is broken for users with expired cards. Code is in src/payments/. Write a failing test, then fix it." Here is the trace, phases tagged. Notice that running the test again is the entire difference between an agent and a code generator.

$ pytest -k checkout                        # (1) gather - reproduce it
  FAILED test_checkout_expired_card
  AttributeError: 'NoneType' has no attribute 'refresh'

$ grep -rn "refresh" src/payments/          # (1) agentic search, no index
  token.py:42     def refresh(self): ...
  checkout.py:88  token = self.get_token(); token.refresh()

$ sed -n '60,120p' src/payments/checkout.py    # (1) read a 100-line window
  -> get_token() returns None when the card is expired

# (2) edit - guard the None  (harness snapshots the file + lints the patch first)
  checkout.py:88   if token is None: raise ExpiredCardError(...)

$ pytest -k checkout                        # (3) verify - run it again
  PASSED

# tests are green -> the model returns no tool call -> the loop stops.

Three phases, recurring: context (the reproduce, search, and read), action (the edit), verify (the re-run). Had the test still failed, the last output would feed reflect / fix and the cycle would spin again. Devin runs exactly this loop autonomously end-to-end - sandboxed shell plus editor plus browser, long-horizon planning, iterating until tests pass - then opens a pull request for human review.^[10]

SWE-bench, and a reality check

SWE-bench is why we can even talk about progress: it hands an agent a real GitHub issue and grades it by whether its patch makes the repo's hidden tests pass. SWE-agent posted 12.5% in mid-2024; Verified leaders now sit in the 70 to 90%-plus range.^[11] Genuinely fast progress, but do not read the headline number as "solved."

The frontier framing is telling: the discipline is shifting from prompting agents to designing the loops that run them - worktrees, skills, sub-agents, external state, and start-of-session verification that survives across many context windows. "Loop engineering," not prompt engineering, is where reliability now comes from.^[12]

Check yourself