Three things get called AI coding tools and only one of them is an agent. The difference is not model quality. It is whether the thing can take an action, look at what happened, and decide what to do next.
Short answer: an AI coding agent runs a loop. It reads context, plans, calls a tool, observes the result, and revises. Autocomplete does not loop and cannot observe. A chat assistant loops through you. An agent closes the loop itself, which is why it can finish a task and also why it can be wrong for four minutes without anybody noticing.
The three tiers, plainly
Completion. Predicts the next token given what you have typed. Fast, cheap, no memory of the session, no ability to run anything. GitHub Copilot started here and the inline suggestion is still what most developers use most of the time. It is genuinely useful and it is not an agent.
Chat. You describe a problem, it produces an answer, you paste the answer somewhere. The loop exists but you are the part that closes it: you run the code, you read the error, you paste the error back. Every editor has this now.
Agent. It has tools. It can read files, write files, run commands, search the codebase, and see the output. Given “make the tests pass”, it will read the failure, edit a file, run the tests again, and repeat until they pass or it gives up. Claude Code, OpenAI’s Codex, Aider and Cline are all this shape, with very different surfaces around it.
The jump from tier two to tier three is the one that matters, and it is a jump in kind rather than degree.
The loop is the whole thing
Strip away the interface and every agent is the same five steps.
- Read. Gather context: your instructions, relevant files, previous turns, tool definitions.
- Plan. Decide what to do next. On current models this is often explicit reasoning before any action.
- Act. Call a tool. Edit a file, run a command, search, fetch.
- Observe. Read the result, including the error you did not expect.
- Revise. Fold that into the next iteration, or stop.
Everything vendors compete on sits inside one of those five boxes. Better planning is step two. A bigger context window is step one. MCP is step three. Hooks and permission prompts are constraints on step three. Test-running is step four.
Understanding that makes the market legible. When a tool claims to be smarter, ask which box it improved.
What is the difference between an AI agent and an AI assistant?
An assistant produces output for you to act on. An agent acts, then reports.
The practical consequence is accountability. When an assistant is wrong, you notice, because you were the one running the code. When an agent is wrong, it may have written eleven files, invented a naming convention, added a dependency and committed, all before you looked. The failure mode moves from “bad suggestion” to “bad state in your repository”.
That is not an argument against agents. It is an argument for constraining them at the boundary rather than trusting the output, which is the entire subject of giving an agent access without giving it everything.
What an agent can and cannot know
The most common misdiagnosis in this field is calling a context problem a capability problem.
An agent cannot see anything you have not given it access to. It does not know your conventions unless they are written down. It does not remember last session. It cannot tell whether the function it is about to duplicate already exists three directories away unless something told it to look.
So a large share of “the agent is bad at this” is really “the agent was given nothing to work from”. The fixes are unglamorous and they work: written conventions it reads on startup, a searchable codebase, tests that fail loudly. There is more on the mechanics in why your agent forgets and on the instruction side in writing instruction files an agent will follow.
The tool surface is the capability
An agent is exactly as capable as the tools it can call. A model with no tools is a very expensive text generator.
That is why MCP became load-bearing so quickly: it standardises how a tool describes itself to a model, so an agent can discover what operations exist and what arguments they take rather than reading a documentation page and guessing. There is a fuller account in MCP explained, including what it does not solve.
It is also why the interesting differences between agents are often not about the model at all. Two products running the same model behave very differently depending on what they let it touch, how they present the codebase, and where they interrupt it for permission.
Where agents are genuinely good
Being specific is more useful than being enthusiastic.
- Mechanical change across many files. Renames, signature changes, migrating a pattern. Tedious for a person, well specified, easy to verify.
- Tasks with a clear pass condition. Make the test green, make the type check pass, make the build succeed. The loop has something to observe.
- Unfamiliar territory with fast feedback. A language or framework you do not know well, where the agent’s guess plus a test run beats your guess plus a documentation search.
- First drafts of well-understood things. Scaffolding, boilerplate, a migration script.
Where they are not
- Anything with no observable result. If the agent cannot tell whether it succeeded, it will report success anyway.
- Decisions with context that lives outside the repo. Why the schema is weird, which customer depends on the old behaviour, what the team agreed in March.
- Long-horizon architectural work, where the correct move depends on where the system is going rather than on what compiles today.
- Anything where being subtly wrong is cheap to produce and expensive to detect. Concurrency, money, auth, permissions.
The last one is the real hazard. An agent generates plausible code faster than you can carefully read it, and plausible is the failure mode. That is why reviewing code your agent wrote is a different discipline from ordinary review.
The part nobody warns you about
The agent makes infrastructure decisions too, not just code decisions.
Ask for file upload and it picks a storage approach. Ask for auth and it picks a library. Ask for a queue and it picks one. Those choices land in your repository as facts, on the first build, chosen by something with no view of where the project is going and no memory of what it decided last time.
That is the argument in the infrastructure your agent picks for you, and it is the decision category with the longest half-life. Code gets rewritten. A storage layout survives.
Where to start
If you are new to this, do not start with the most autonomous tool available. Start with one that shows you every action before it takes it, on a repository with tests, on a task you could do yourself in an hour.
You are calibrating two things at once: what the tool is good at, and how much you can stop watching. Both take about a week of real work to learn and neither is answered by a demo. When you are ready to pick, the best AI coding agents sorted by what they are for covers the shapes, and terminal agents vs IDE agents covers the split that most affects daily use.
Related field note
Continue with How to document agent failure recovery for the next operator.