What Is an AI Coding Agent? (And What It Definitely Isn't)

Definitions

Ask ten developers what an "AI coding agent" is and you'll get ten answers, most of them marketing. So let's pin it down properly, because the difference between a chatbot and an agent isn't a vibe — it's an architecture, and once you see it you can't unsee it.

A chat model completes text. You paste code in, it emits code out, and the transaction is over. It never touched your machine. An agent is a model wrapped in a loop: it reads your actual files, runs actual commands, observes what actually happened, and iterates toward a goal. The loop is the definition. Everything else — the CLI, the editor plugin, the fancy UI — is packaging around that loop.

The loop, spelled out

Every coding agent, from every lab, runs some version of this cycle:

1. Read — open files, search the codebase, inspect the directory tree. The agent builds context from your real project, not from what you remembered to paste.
2. Act — edit a file, create a file, run a shell command: npm test, git diff, a build, a migration.
3. Observe — capture the output. The test failure, the compiler error, the stack trace.
4. Decide — feed that observation back into the model and choose the next action. Fix the failing test. Search for the function that's actually throwing. Try a different approach.
5. Repeat until the goal is met or the agent (or you) calls it.

That feedback step is the whole trick. A chat model that writes a function with a typo just hands you the typo. An agent that writes the same typo runs the tests, sees the failure, and fixes it before you ever look. It's not smarter — it's closed-loop, and closed-loop systems self-correct in a way open-loop ones can't.

The toolbelt

Agents act on the world through tools — discrete capabilities the harness exposes to the model. The core set is nearly universal across every agent worth using:

• File read/write — open, edit, and create files in the working directory.
• Shell execution — run commands: tests, builds, linters, git, package managers.
• Search — grep-style text search and increasingly semantic search across the repo.

On top of that base, tools can extend almost arbitrarily — browsing docs, querying a database, hitting an API — which is where standards like the Model Context Protocol come in (we explain that separately in our MCP guide). But if a product can't read files and run commands in a loop, it's a chatbot wearing an agent costume.

The autonomy dial

Agents aren't one thing; they're a spectrum of how much you let them do without asking. Roughly three settings:

1. Suggest. The agent proposes every edit and every command; you approve each one. Slow, safe, and the right default when you're new to a tool or working in a codebase you can't afford to bruise.
2. Auto-edit. File changes go through without approval, but shell commands still stop for confirmation. This is where most working developers live day to day: the agent moves fast on code, and you keep a hand on anything that touches the system.
3. Full auto. The agent edits and executes freely toward the goal. Enormously productive, genuinely risky, and only sane inside guardrails — a git repo, a checkpoint commit, ideally an isolated branch or worktree.

Good practice is to move the dial per task, not per personality. Boring refactor with solid tests? Full auto. Anything touching auth, payments, or production config? Suggest mode, eyes open.

What an agent definitely isn't

Now the corrective, because the hype does real damage to people's expectations:

It isn't AGI. An agent is a language model with hands. It has no persistent understanding of your business, no goals of its own, and no memory beyond what's in its context window and your files. Impressive runs are the loop working, not a mind at work.

It isn't infallible. Agents write plausible code, and plausible is not the same as correct. They will confidently import a package that doesn't exist, claim tests pass that they never ran, and "fix" a bug by deleting the assertion that caught it. Verification is your job or another agent's job — never assumed.

It isn't a junior developer replacement in a box. A junior learns your codebase over months and pushes back on bad tickets. An agent starts from zero every session and does exactly what you asked, including when what you asked was wrong. The comparison flatters the agent and insults the junior.

The two failure modes that actually bite

Strip away the anecdotes and almost every agent disaster is one of two shapes:

1. The confident wrong action. The agent does something incorrect with total conviction — edits the wrong file, misreads an error, declares victory on broken code. The fix is verification: independent checks the agent can't talk its way past. Run the tests yourself. Read the diff, not the summary. Better yet, have a second model review the first one's work — we covered that whole workflow in our AI code review playbook.

2. Runaway scope. You asked for a bug fix and got a refactor of eleven files, a renamed module, and a new dependency. Nothing individually crazy, collectively a mess. The fix is checkpoints: commit before every autonomous run so any run is disposable, and give parallel agents isolated worktrees so they can't trample each other. That habit is cheap enough to be non-negotiable, and we wrote it up in full in Checkpoints & Git Worktrees.

Where this leaves you

The practical takeaway: judge agent products by the loop, not the demo. Does it really read your files? Really run your commands? Really feed the results back? Then it's an agent, and the remaining questions are about trust — how you verify its claims and how fast you can roll back its mistakes.

If you're newer to this whole world, start with our honest guide to vibe coding for the workflow-level picture, and keep the agentic coding glossary open in a tab — the field has accumulated a lot of vocabulary in a very short time, and most of it turns out to matter.