AI Agents · entry 07/08 · 3 min read
Coding agents
Software is where agents work best — because the environment is scriptable, the feedback is mechanical, and being wrong is cheap. What that buys, and what it quietly costs.
Why this application worked first
Coding is the environment the agent loop was waiting for. The world is fully scriptable — files, shells, tests, linters, type checkers — so tools are cheap and unambiguous. Feedback is mechanical: the tests pass or they don't, which is a verifiable reward in exactly the sense that made reasoning models work — with one difference worth holding onto: this verifier lives in the agent's working directory and can be edited. And errors are usually recoverable, because version control makes edits to tracked files undoable, though the shell commands and network calls around them are not. Compare that to a robot arm or an email agent, where the environment is partly unobservable and mistakes stick.
What the loop looks like
Read the relevant code, form a plan, edit, run the tests, read the failure, edit again — until green or until stuck. The interesting engineering is not the model call; it is context and verification. Context: real repositories don't fit in a window, so the agent must find the right files (search, symbol lookup, retrieval over the codebase) rather than being handed them. Verification: an agent with a test suite it did not write behaves measurably better than one without, because it can check itself against something it cannot edit — which means the highest-leverage thing a team can do for its coding agents is have good tests, an insight that predates agents by thirty years.
Honest strengths and limits
Strong: well-specified, well-tested, local changes — a bug with a reproduction, a mechanical refactor, a migration across many files, test-writing, unfamiliar-language translation, first drafts. Weak: work whose difficulty is deciding what to build; changes whose correctness isn't checkable by running something; and large diffs nobody reviews carefully, which is where the real cost lands. Benchmark numbers on curated issue sets run well ahead of what teams observe on their own repositories, for the usual reasons: the benchmark is not your distribution, its issues arrive with a reproduction and an oracle test that yours don't, and a benchmark that becomes a target stops tracking ability.
Failure mode
Review capacity as the silent bottleneck. Generation gets cheap, so volume rises; reviewing does not get cheaper, so the queue fills with plausible diffs that compile, pass, and are subtly wrong — plausibility being exactly what a model optimizes. Teams then merge on green tests alone, and the tests were often written by the same agent. The discipline that holds: keep changes small enough to read, require the agent to show its verification, and treat "the tests pass" as evidence rather than proof — the junior-operator posture, applied to a colleague who types faster than you can read.