An AI coding agent is software powered by a large language model that can take autonomous actions on a codebase. It reads files, understands the surrounding context, writes or edits code, executes commands, runs tests, and iterates based on the results it observes, rather than only suggesting what a person should type next. A second account narrows the defining line to a single capability: coding agents are agents that can both write and execute code, and it is execution that separates them from any other use of a model to produce code.
Usage
The defining property is autonomy: the agent operates in a loop, taking actions and observing results until a task is done, rather than predicting a single next line of code. It might create a file, notice a missing import, fix it, run the tests, see a failure, and adjust its approach without a person intervening at each step. Tools cited as examples of this category include Claude Code, Cursor, Windsurf, and GitHub Copilot’s agent mode; a second source names Claude Code, OpenAI Codex and Gemini CLI as its popular examples.
Coding agents are described as the foundation that agentic engineering is built on: without them, AI assistance is limited to autocomplete-style suggestions, whereas with them, whole tasks can be delegated and returned as working code. The quality of what an agent produces is described as depending heavily on the context it is given — clear specs, scaffolding, and guardrails — with agentic engineering named as the discipline of supplying that direction effectively.
In practice, this takes several shapes: a single-task agent that implements one described feature or fix end-to-end for a human to review; multi-agent setups where several agents work on different parts of a codebase at once; and background agents that run asynchronously on tasks like PR review or dependency updates while a person works on something else.
A further account adds a normative point about how the category should be used. Because a coding agent can execute the code it writes, it can be held to demonstrating that its changes work, and Your job is to deliver code you have proven to work argues that mastering these tools means getting them to do exactly that — exercising a change manually as they go, and building automated tests that will keep it working afterwards. On that account the distinction between manual and automated testing largely collapses for an agent, since both are things it performs rather than observes. The same post reports that agents need very little encouragement to write tests, will extend a suite that already exists without being told to, and reuse the patterns they find in it — from which it draws the practical recommendation to keep test code well organised and populated with the patterns you want reproduced.
Not every practitioner account treats the category as making the work easier. In a short note dated 24 September 2026, Simon Willison wrote that the more time he spends working with coding agents, the more convinced he is that they make software engineering even harder: amazing things can be done with them, but unlocking their full potential, in his view, requires extraordinary discipline and knowledge. The note is a statement of one practitioner’s experience rather than an argued case.
How One Is Built
A chapter of Agentic Engineering Patterns describes the internals, and its organising claim is that a coding agent is a harness for a language model: software that extends the model with additional capabilities, powered by prompts the user never sees and implemented as callable tools. Everything else follows from that separation.
At the centre is the model itself, which completes text and works in integer tokens rather than words — which matters, the chapter notes, because providers charge by token and are limited in how many they can consider at once. Interaction with it is expressed as a Chat Templated Prompt: a completion prompt formatted as a labelled conversation. Because models are stateless, the harness keeps its own state and replays the whole conversation each turn, so input cost grows as a session lengthens — partly offset by Token Caching, which is why agents are built to avoid modifying earlier conversation content.
A tool is a function the harness makes available to the model. At prompt level it is described in
a system turn, the model ends its turn by emitting a call, the harness extracts that call — the
chapter’s illustration is a regular expression — executes it, and appends the result as a further
turn. The chapter reports that most coding agents define a dozen or more tools, the most powerful
being code execution such as a Bash() or Python() tool. The hidden system prompt carries the
instructions that make the agent behave as it does and can run to hundreds of lines. Reasoning,
where the model spends extra tokens working through the problem before replying, is described as
particularly useful for debugging, since it lets the model follow complex code paths and mix in tool
calls; many agents expose a dial for how much of it to spend.
The chapter’s conclusion is deliberately deflationary: an LLM plus a system prompt plus tools in a loop is most of what it takes to build a coding agent, a simple tool loop is achievable in a few dozen lines on top of an existing API, and it is a good tool loop — not the basic mechanics — that represents the real work.
How the Research Literature Frames It
A Survey on Code Generation with LLM-based Agents reaches the same category from the research side and names it a code generation agent, characterising it by three features that it says distinguish such agents from earlier code generation techniques. The first is autonomy: the ability to independently manage the entire workflow, from task decomposition through coding to debugging, where traditional code generation models assist a human developer passively through code completion or function generation. The second is an expanded task scope: earlier research typically involved tasks with clear boundaries and well-defined specifications, such as completing a line from context or generating a function body from a signature, whereas an agent can cover most of software development — handling ambiguous requirements, implementing entire projects, testing and refactoring, and optimising iteratively on real-time feedback. The third is an enhancement of engineering practicality: a shift of research emphasis away from algorithmic accuracy and toward engineering implementation — agent reliability, complex workflow management, and efficient invocation of external tools — which that survey describes as moving the problem into territory closer to classical software engineering.
The survey draws the line between a language model and an agent architecturally rather than by capability. A model’s operation is a single, passive response process that lacks active planning, state maintenance or continuous interaction with an environment; an agent builds a dynamic workflow with autonomy, interactivity and iterativity, with the model serving as the reasoning engine that decides the next action from the current environmental state. That framing puts the same weight on the loop that the practitioner accounts above do, and adds the claim that what has changed is not only what the software can do but which part of the job a person is left holding: the survey describes the developer’s role as moving to task definer, process supervisor and final result reviewer.
Related Terms
The first source names this term alongside DefinedTerm/tool-use, Plan-Act-Observe Loop, Guardrails, Human-in-the-loop, and Agentic Engineering as related glossary entries, without defining any of them.
- AI Agent — the general category this specialises
- Harness Engineering — the discipline of building the scaffolding described above
- Chat Templated Prompt, Token Caching — two mechanisms the internals account turns on
- A Survey on Code Generation with LLM-based Agents — the academic survey whose framing is summarised above