Coding Agent

How a coding agent differs from code completion

A completion tool proposes text at a particular editing point. A coding agent can take responsibility for a sequence of actions: locate a defect, inspect related files, produce a patch, and check the result. Products can offer both experiences, so the interface alone does not establish whether a workflow is agentic.

The practical distinction is feedback. After a tool runs, its result becomes input to the next decision. A failed test may lead to another investigation rather than simply another paragraph of advice. The ReAct research formalized a broader pattern of interleaving model reasoning with actions in an external environment. It is a conceptual foundation, not evidence that any particular coding product succeeds on production work. ReAct paper.

An agent can still be closely supervised. Autonomy is a property of the permissions and workflow, not a binary consequence of using an AI model. A system that pauses before every write can remain an agent, while an unattended script with a fixed sequence does not become one merely because it calls a model once.

Model, harness, and environment

The model interprets the task and proposes the next action. The harness manages messages, exposes tools, processes tool results, and decides when execution may continue. The environment supplies the repository, dependencies, credentials, network access, and test infrastructure.

These layers affect one another. A strong model cannot inspect a dependency that its search tool cannot reach. A useful patch may fail verification because the test environment is incomplete. Conversely, an unrestricted shell can execute a harmful command even when the model was given a polite instruction to be careful.

Claude Code's architecture documentation describes its model-and-tools loop and identifies the surrounding application as the agentic harness. That distinction is useful when comparing products: changing a harness can change results even when the underlying model remains the same. How Claude Code works.

A hypothetical bug-fix run

Consider a request to fix an API endpoint that returns duplicate results when two records have the same timestamp. A well-scoped task states the expected ordering, the files the agent may change, and the checks needed for acceptance.

The agent searches for the endpoint, reads its query builder, and discovers that pagination sorts only by timestamp. It proposes adding a stable secondary key. Before editing, it inspects callers to check whether the cursor format is part of a public interface.

The first patch updates the query but leaves an incompatible cursor parser. A focused test fails. The agent uses that result to revise the parser and adds coverage for tied timestamps. It then runs the relevant checks and produces a diff with a summary of the change and the remaining uncertainty.

This sequence illustrates why the final patch matters more than the confidence of the opening explanation. The agent did not know the entire solution at the start. It learned from the repository and from a failed check. A reviewer still needs to examine migration compatibility and decide whether the acceptance evidence is sufficient.

Define completion before execution

A task needs an observable outcome. "Improve pagination" leaves too much room for interpretation. "Return each matching record exactly once across consecutive pages, including timestamp ties" gives the agent and reviewer a shared target.

Record intermediate statuses separately: started, patch produced, checks passed, accepted, and merged. An agent that reports success after editing a file may not have completed the engineering task. Likewise, a pull request can merge and later require a revert. These events answer different questions about the agent task outcome.

Acceptance criteria should include important negative conditions. For the pagination example, preserving authorization checks and avoiding a full-table scan may matter as much as eliminating duplicates. Test coverage will rarely capture every requirement, which is why code review remains part of the evaluation rather than a redundant step.

Permissions and resource boundaries

Give the agent the access needed for the task and make consequential permissions explicit. Reading a production log is different from modifying production data. Permission to edit a workspace is different from permission to publish its contents.

Untrusted repository text, issue comments, or tool output can contain instructions. The system should treat that material as task data, not as authority to expand its permissions. OWASP's agent guidance discusses least privilege, tool controls, isolation, and limits on resource consumption. OWASP agent security guidance.

Set an agent budget for time, model usage, or repeated attempts. When that budget expires, preserve the partial result and state what remains incomplete. If several agents work concurrently, include their combined activity in the parent task's accounting and define who resolves overlapping edits.

Evaluate the whole system

Use a representative set of tasks with stable starting revisions and repeatable environments. Keep track of the model version, harness configuration, tool access, instructions, and time or cost limits. A comparison that changes all of those at once cannot isolate which change produced the result.

SWE-bench illustrates issue-based evaluation: the system receives a repository and an issue and produces a candidate patch, evaluated in a reproducible harness. Public benchmarks provide useful evidence about the tested setting. Their scores do not directly measure business value or review burden in your repositories. SWE-bench overview.

For a team pilot, report accepted tasks, total cost including failed attempts, human review time, and subsequent repairs. Separate task categories such as documentation, migrations, and unfamiliar debugging. Include failures rather than showcasing only the most successful run.

Finally, distinguish adoption from impact. More agent sessions show that people are using the system. Establishing a productivity improvement requires a credible baseline and comparable work, with attention to quality and human effort. That is the measurement problem covered by agent developer productivity, not a conclusion that follows from tool usage alone.