The Coding Agent Is Becoming the Cheap Part

I used to judge a coding agent by the first edit it produced. Did it understand the bug? Did it touch the right file? Did it make a mess? That is still a useful test, but it misses where the real engineering work has moved.

The same agent can fix the same issue in ten minutes or burn an afternoon wandering through a repository. It can return a tidy summary that sounds convincing after it stopped two edits before the test suite. It can make a decent change with a small model and a clean task boundary, then make an expensive mess with a larger model and a bloated conversation.

The model matters, but the harness around it determines whether agentic coding feels like a tool or a liability.

The harness is the unglamorous machinery: how the agent gets repository context, when a task starts fresh, which commands are allowed to fill the conversation, how much effort the job deserves, and what counts as proof when the agent says it is done. None of that makes for a flashy demo. It decides whether the next hundred runs are cheap, legible, and safe to review.

Context is now a budget with a memory problem

Anthropic's recent guide to Claude Code sessions puts the mechanics in plain terms. A coding session carries the files the agent read and the output from the commands it ran into later turns. A task that starts by reading the relevant test and implementation can stay small. A task that begins with broad search, noisy test output, and yesterday's unrelated work makes every later turn carry baggage.

That detail changes how a team should think about an agent. Context directly affects the bill, the model's attention, and the failure surface.

Anthropic recommends clearing a session between unrelated tasks, checking what is already loaded, and moving noisy commands into a subagent or a quieter command form. It also warns that changing a model or effort setting mid-session can invalidate the prompt cache. These are practical operating moves, but they point to a larger rule: an agent needs a deliberate working set, much like a service needs bounded memory.

The common response is to write a longer project instruction file. That can work for a while. Then it turns into a graveyard of old constraints, copied commands, and rules nobody can safely remove because nobody remembers why they were added.

A project called Graft takes a more interesting route. It builds a local code graph from the repository and refreshes that graph when code changes. Its structural pass uses deterministic parsing, while its deeper summaries are cached by content hash. The goal is to give an agent a map of the repository that follows the code instead of a huge pile of prose that follows team anxiety.

Graft reports its own 162-run comparison found 42% lower token use, 60% lower elapsed time, and a 66% versus 54% result on the SWE-bench Verified tasks it tested. Treat those as project-reported figures, not a promise for every codebase. The useful lesson sits beneath the chart: context should be generated from the current repository and fetched in pieces. It should not become a permanent, expanding attachment to every request.

Effort needs a job description

Once the working set is under control, the next question is effort. Teams often treat this as a slider for making an answer smarter. In practice, effort changes the work pattern. It affects how many files an agent reads, how often it uses tools, whether it runs tests, and how far it pushes through a multi-step task before asking for help.

That distinction matters because a request to rename a field and a request to untangle an authentication flow do not need the same operating mode. One needs a narrow edit and a targeted check. The other needs exploration, a plan, several changes, and a test run that proves the pieces still fit.

Anthropic's model and effort guide makes the same split: choose a more capable model when the agent had the right context and still could not solve the problem; raise effort when it skipped files, failed to run checks, or stopped partway through a refactor. That is a better diagnostic than reflexively choosing the biggest model for everything.

A good harness makes the choice visible. Give routine, reversible work a small context and a low-cost path. Give ambiguous or high-impact work a named plan, a larger budget, and a defined verification stage. The aim is to match the spend to the job, instead of paying premium prices for an agent that was never told what kind of work it had.

Agentic coding now resembles production engineering. The useful interface is a workflow with limits, checkpoints, and a record of why a particular run had permission to spend more time and read more code.

A completed task needs evidence tied to the code

The last part is the one teams avoid because it exposes a gap between a fluent summary and a completed change. “Tests pass” has no value if the code changed after the tests ran. A green result from an earlier state is a historical fact, not evidence about the pull request in front of you.

ProofRun is a small recent project built around that gap. It records a real command result against the current git commit plus hashes of staged, unstaged, and untracked changes. Change one byte after a test passes and the recorded state becomes STALE. Its language is deliberately narrow: PASS, FAIL, STALE, or NOT RUN.

That is a far better contract for an agent than asking it to sound confident. It replaces a vague claim with a status that a reviewer can inspect. The tool does not decide whether code is good. It proves whether a declared check ran against the code that exists now.

The same principle appears in self-bench, which turns completed work from a repository into private evaluation tasks. It reconstructs a task from the commit before the change, creates hidden tests and a reference solution, then checks that the task fails without the solution and passes with it. That is a useful direction for teams that have outgrown public benchmarks but still need a way to compare agent workflows.

The model race will keep producing better coding agents. Good. As agents become cheaper and more capable, the scarce skill is building a harness that gives them clean context, assigns effort on purpose, and refuses to confuse a polished summary with a verified result.

Start with one change this week: make every agent run leave behind the exact commands it ran, the code state those commands covered, and the checks that are now stale. Once that record exists, you can improve the model, the prompt, and the workflow without losing the only thing that matters in a codebase: what actually happened.