What is an AI coding agent?
An AI coding agent takes an objective and works toward it over many steps using your real tools: reading files, editing them, running commands, reading the output and deciding what to do next. The loop is the definition. An assistant answers a question. An agent acts, checks itself, and acts again, and it can keep doing that while you are somewhere else.
The three categories, which matter more than the brands
Terminal-native
The agent runs as a process in your shell with access to the same tools you have. This category gives the most control and by far the best supervision surface, because everything it does is a command you could have run and everything it produced is visible in a session you can inspect. It is also the only category where you can wrap the agent in your own process management, which matters the moment you run more than a couple at once.
Cost: it is the least friendly to people who do not live in a terminal, and the isolation is whatever you set up yourself.
Editor-native
The agent lives inside the IDE and shares its context: open files, cursor, project index, diagnostics. The feedback loop is the tightest of the three and the diff review is the most comfortable, because reviewing a change is what an editor was already for.
Cost: you are in the loop by design, so this category does not scale past your own attention. It is a productivity tool rather than an operating model.
Remote and asynchronous
You hand over a task, the agent works in a hosted environment, and you get a pull request. This is the only category that scales beyond what one person can watch, and the only one where the review surface is a diff arriving with no memory of how it was produced.
Cost: it demands the most disciplined review, and it is where confidently-wrong output does the most damage, because the reviewer has the least context on how the change came about.
The five axes that actually separate them
- Permission model. What will it do without asking? The useful question is not whether a tool has an approval prompt but whether the prompt is granular enough to leave on. A permission system so noisy that everyone disables it is worse than none, because it produces a false belief that a control exists.
- Context strategy. Every agent hits the window. What it does then is a real product decision: silently truncate, compact and continue, or start fresh. Silent truncation is the worst of the three and the hardest to notice, because quality degrades before anything errors.
- Isolation. Can it run in a throwaway checkout or container? This is the difference between a bad run costing you a revert and costing you an afternoon. It is also what makes parallelism possible at all.
- Extensibility. Whether the agent can reach your systems: databases, ticketing, browsers, internal APIs. Standard protocols have made this much less differentiated than it was, which is a good outcome for buyers and a reason to weight it lower than vendors would like.
- Observability. When it fails, what can you see? Whether there is a transcript, whether the tool calls are logged, whether you can tell why it decided something. This axis is invisible in demos and decisive in production, and it is the one we would now weight highest.
How to actually choose
A sequence that avoids most of the wasted evaluation time:
- Pick the category from your review capacity. If a human reads every diff, editor-native is enough. If work must proceed while nobody watches, you need terminal or remote and you need the supervision to go with it.
- Test on your worst codebase, not your best. Every agent looks capable on a clean, well-tested repository. The differences appear in the legacy service with three test files and a build nobody understands.
- Measure review time, not generation time. The metric that predicts whether this works for a team is how long a change takes to become mergeable, including the arguing. Generation speed is not a constraint anyone still has.
- Run two. Model-level differences are real but small and they move. Harness-level differences are large and persistent, and having a second tool available costs little compared with being wrong about the first.
An honest caveat about this page
This is a comparison of a market that changes monthly, written by people who have opinions about it. We have deliberately kept it structural, with no feature grid and no ranking, because we have watched every ranked list of these tools become misleading faster than it could be updated. The trade is that this page will not tell you which product to buy. It will tell you which questions still matter after the product changes.
Our own setup notes, written while actually configuring these, are more specific and correspondingly more perishable: Claude Code, Codex CLI, OpenCode and Hermes.
Related reading
The craft around these tools is at agentic coding, the operating discipline at agentic engineering, and the orchestration layer at agentic workflows. For the security implications of giving any of these access to your systems, see agentic AI security. For measurement rather than opinion, METR's developer productivity trial and Google's DORA research programme are the two sources we return to.