A Coding Agent Is a Loop Around a Compiler
The model writes the code; the harness makes it correct by running it.
A coding agent that only writes code is a fancy autocomplete. The thing that turns a plausible diff into a change you can merge is the code harness: the sandbox, the tools, and the loop that runs the code and reads the real errors.
Watch a developer at work and it is a tight loop: write a few lines, run them, read the error, fix it, run again. They are not smarter than the compiler; they just use its feedback relentlessly until the thing works. A coding agent is that same loop, automated, and its quality comes almost entirely from how well the loop around the model is built.
A coding agent that only writes code is a fancy autocomplete. What separates that from an agent that actually ships a working change is not a better model. It is the machinery around the model that applies the change, runs it, reads what happened, and tries again. That machinery is the code harness.
By "code harness" I mean everything a coding agent needs beyond writing text: a sandboxed workspace to make changes safely, tools to edit files and apply diffs, a way to build and run tests, a way to read the real output when something breaks, and a loop that feeds that output back so the next attempt is informed. The model proposes a change in words. The harness turns those words into an edit, runs it against reality, and decides whether it worked.
Here is the part that matters most: plausible code and correct code look identical until you run them. A model can produce a diff that reads perfectly, imports the right names, and still fails to compile or quietly breaks a test. The only thing that tells them apart is execution. The compiler and the test suite are ground truth, and they live in the harness, not the model.
Step through one such loop and watch the errors drive it toward working code:
That is why the loop is the whole game. Without it, an agent confidently announces that it fixed the bug, but nothing ran, so you get well-written nonsense. With it, the agent gets the exact error back, the missing import, the failing assertion, the stack trace, and can respond to what actually happened instead of to what it imagined. Feeding back the real output, not a summary of it, is what makes the difference.
So a good code harness only accepts a change that survives real checks: it compiles, the tests pass, and the types and lints are clean. Anything less goes back. This is the same idea as any disciplined engineering process, except the author happens to be a model that is fast, tireless, and occasionally confidently wrong, which makes the checks matter more, not less.
A few things follow from treating the harness as the real work:
- Sandbox everything. Changes should be isolated and reversible, so a bad edit costs nothing and a destructive command cannot escape.
- Feed back exact output. The compiler error verbatim beats a paraphrase. The agent should react to the real signal.
- Keep changes small. Small diffs are easier to run, verify, and revert, and they keep the loop tight.
- Gate on tests, then review the diff. Passing tests is the floor, not the ceiling. A human still reads the change before it merges.
The model is the author. The harness is the editor, the compiler, and the test suite that turn a fast, fluent draft into a change you would actually merge. Get excited about the author if you like, but the reason the code works is that something ran it.
