Coding Agent — AI Glossary

Reference details

Related terms

• Code Generation
• Tool-Using Agent
• SWE-Bench

How it works

1. The agent is given a goal and a workspace rather than a prompt and a blank page: a checkout, a shell, file read and write, and usually a way to search the repository.
2. It reads before it writes — locating the relevant files and existing conventions — because a patch that ignores surrounding code fails review even when it is correct.
3. It edits, then runs something that can disagree with it: the test suite, a type checker, a linter, a build.
4. The failure output goes back into context and the loop repeats. This is the mechanism that separates a coding agent from code completion — an external verifier it cannot talk its way past.
5. It stops on a signal defined outside itself, usually a green suite, and emits a diff for human review rather than committing silently.

Example: The verifier is what makes the loop converge

An agent is asked to fix a failing test. It reads the test, edits the implementation, and re-runs: still failing, with a different error. Second edit, suite passes. Nothing about the model guaranteed that; the suite did. Remove it and the same agent produces a patch that looks plausible and is never contradicted, which is why coding agents are strongest in repositories that already have tests and weakest in the ones that most need help. The loop cannot converge on a signal the repository does not emit.

Commonly confused with

Blurred into coding assistants, and the difference is who holds the loop. An assistant suggests and a developer accepts or rejects each suggestion, keeping the human in the loop at every step. A coding agent is given a goal and runs its own edit-test-fix cycle for many steps before returning, so the human reviews an outcome rather than a sequence of suggestions. That changes what matters: an assistant is judged on suggestion quality and latency, an agent on whether it converges at all and whether its diff is reviewable when it does.

When to use it

Reach for it when:

• The task has a machine-checkable definition of done, such as a failing test or a type error.
• The repository has a test suite or type checker the agent can be held to.
• The work is mechanical but spread across files — a rename, a migration, a repeated refactor.

Reach for something else when:

• Nothing in the repository can contradict the agent, so a wrong patch looks exactly like a right one.
• The task is a design decision rather than an implementation, where the hard part is choosing, not typing.
• The change is small enough that reviewing a multi-step trace costs more than writing it.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Coding Agent — AI Glossary.

• Browse models
• Review providers
• Inspect benchmarks
• Explore workflows
• Learn AI concepts
• Read decision guides
• Review trust and methodology
• Start a decision path