What an AI coding agent is, and how it differs

An AI coding agent is a program that takes a goal, decides on its own which files to read and which commands to run, does them, looks at the results, and repeats until the job is done or it gets stuck. The model is one component. The interesting part is the loop around it.

That distinction is not pedantry. It explains nearly everything people find surprising about these tools - why they are expensive, why they sometimes go badly wrong, and why "the model got better" does not automatically mean your agent got better.

The loop

How that differs from autocomplete

That last row is the one to sit with. An agent's failure mode is not a bad suggestion - it is an action. Which is why every serious agent has a permission model, and why the ones that ask nothing are the ones to be careful with. How a tool handles that is one of five things worth comparing.

Why does a better model not automatically mean a better agent?

Because most of what determines the outcome happens outside the model: which files got opened, whether the test output was passed back in full or truncated, whether the agent remembered what it learned three steps ago, whether it was allowed to run the command it needed.

A strong model on a weak harness loses to a mid-tier model on a good one, routinely. The harness is the product.

What they are genuinely good at

And what they are not

They are also prone to five specific failures worth learning to recognise. And they are bad at problems where the goal cannot be checked. If neither you nor the agent can tell whether the result is right, the loop has nothing to converge on and it will happily produce something plausible and wrong.

They are also bad at reading your mind about intent. "Make this faster" without a measurement is an invitation to optimise the wrong thing convincingly.

If you are starting today

1. Pick a task you can verify. Something with a test, a build or an obvious visual result.
2. Write down what "done" means before you start. This is the single biggest predictor of whether it goes well.
3. Watch the first few runs. Not to babysit - to learn where it goes wrong, which is what tells you what to put in your instructions.
4. Then write the instruction file. Conventions, what not to touch, how to verify. It is the single most useful thing you will write, and it survives a change of tool.

Did that land?

Three questions on the idea, not the vocabulary.

What most distinguishes an agent from a chat assistant?

It runs on a larger model with a longer context window It writes whole files rather than answering in fragments It runs in a terminal rather than inside a chat window It takes actions and reacts to what those actions return

Which task suits an agent best?

Adding tests that describe behaviour which already works today Deciding the architecture for a product that does not exist yet Judging whether the design of a screen feels right to a user Making the code better in the general, unspecified sense

Why can a mid-tier model on a good harness beat a frontier model on a poor one?

A good harness caches answers, so the model is asked far less often Mid-tier models are trained more heavily on code than frontier ones Frontier models are slower, so they complete fewer steps in the time Most of the outcome is set by what the harness feeds back each turn