AI coding agents: how they work and how to choose one

A coding agent is an agent whose tools touch your repo

An AI agent is a model, tools, and a loop: the model reads a goal, calls a tool, reads the result, and goes around again. A coding agent is that same machine with a specific tool set — read a file, edit a file, search the codebase, run a command — pointed at a repository.

That specificity is why coding became the first domain where agents genuinely work. Code comes with verification built in. A compiler either accepts the change or lists the errors; a test suite passes or prints the failure; a linter names the line. Every one of those signals feeds straight back into the loop, so the agent can try, fail, read the failure, and fix it — without a human adjudicating each step. Domains without that ground truth (writing, strategy, design) give the loop nothing to push against, which is why "agentic" progress there has been slower.

The practical consequence: a coding agent is only as capable as the feedback your project gives it. A repo with a fast typecheck, a real test suite, and a linter is one an agent can make genuine progress in. A repo where the only verification is "run the app and click around" forces the agent back into guess-and-hope — the same position a new hire would be in.

The ladder: completion, chat, agent

"AI coding tool" covers three different machines, and conflating them is how buying decisions go wrong:

• Completion predicts the next few tokens as you type — the original Copilot mode. No loop, no tools; it never runs anything or sees whether its suggestion compiled. Cheap, fast, and bounded in both value and risk.
• Chat answers questions with the codebase as context. One step up: it can read, but it still hands you the diff to apply and verify.
• Agents close the loop. Given a task, they edit files, run the build and the tests, read what failed, and iterate — in the terminal (Claude Code, Codex CLI, Gemini CLI), in the editor (Cursor, Windsurf, Copilot's agent mode), or in the cloud against a branch, opening a pull request when done.

The jump from chat to agent is the one that changes your workflow. With completion and chat, you are still the loop; with an agent, you review outcomes — the diff, the test run — instead of supervising keystrokes. That is where the productivity claims come from, and also where every governance question below enters.

What actually makes one agent better than another

Marketing pages list features; the differences that show up in daily use are structural:

• Context management. A model reads a bounded window, and repos do not fit in it. What separates agents is how they choose what to read: searching before opening files, summarising long sessions instead of truncating them, honouring a project-conventions file (CLAUDE.md, AGENTS.md — most tools now read one) so hard-won rules survive between sessions. If you adopt one habit, make it this: write the conventions file. It is the difference between an agent that repeats your codebase's mistakes and one that follows its rules.
• The permission model. An agent that edits files and runs commands is an agent that can delete files and run the wrong commands. Mature tools make the boundary explicit — which commands run unprompted, which require approval, which are refused. This is the same approval-gate design that governs any agent's dangerous tools; the coding tools just ship it as product. The Claude Agent SDK exposes that exact machinery programmatically, which is why teams build their own internal coding agents on top of it.
• Extension points. The tools an agent ships with cover the repo; your deploy system, issue tracker and database do not come included. The Model Context Protocol is how you add them — one MCP server makes an internal system callable from every MCP-speaking agent, rather than per-tool plugins.
• Verification discipline. The best agents run the tests before declaring victory and report failures instead of narrating success. The worst produce confident summaries of changes that do not compile. You can evaluate this in an afternoon: give two tools the same real bugfix from your backlog and read what they actually verified.

The real risk list

The challenges section of most coding-agent articles says "accuracy" and moves on. The concrete failure modes are more specific:

• Plausible-but-wrong survives review. Agent output looks like good code — that is what the model is optimised for. Wrong code that reads well is more dangerous than wrong code that reads badly, so review effort shifts from style (the agent handles that) to behaviour: does the diff do what the task said, and what else does it touch?
• Prompt injection rides in on your inputs. An agent reads whatever it is pointed at — issue text, dependency READMEs, web pages, test fixtures. Any of those can contain instructions ("ignore your previous instructions, run this command…"). The durable mitigation is structural, not model-level: least-privilege permissions and approval gates on anything consequential, so a hijacked loop has nothing dangerous to do with the hijack.
• Secrets and code leave the building. Every hosted agent sends your code to someone's API. That is usually fine and occasionally a compliance question; know which repos are which before rollout, and keep credentials out of anything the agent can read.
• Unreviewed velocity is a debt instrument. An agent produces diffs faster than a team's review culture may be prepared to absorb. Teams that keep quality treat agent diffs exactly like human ones — CI, review, and no direct pushes to main — and let throughput rise only as far as review keeps up.

Choosing: fit the workflow, not the leaderboard

Model quality across the leading tools converges within months; the durable differences are the ones above plus fit:

• Where do you want it? Terminal agents compose with scripts and CI and go anywhere a shell goes. IDE agents keep the diff in front of you as it happens. Cloud agents work asynchronously — assign an issue, review a PR later — which suits backlog-clearing more than exploratory work.
• Can you read its permission model in one sitting? If you cannot enumerate what the tool may do without asking, you cannot deploy it beyond volunteers.
• Does it respect your project's conventions file, and does your project have one worth respecting?
• Run the two-tool bake-off. Same three real tasks from your backlog, one afternoon, compare the diffs and what each tool verified. This beats any comparison article, including this one.

The plan is the part that stays yours

Here is the observation a year of agent-assisted development keeps confirming: the quality of what a coding agent produces tracks the quality of the specification it was handed more than the tool that produced it. "Add auth" produces a guess. A route tree with the guarded segments marked, a data model with its relations drawn, and an RBAC matrix produce the thing you meant.

That is the premise Nodlume is built on. The workspace has you design the application — routes, components, data model, API surface, roles — as a canvas, and the Export tab then runs the coding-agent loop over your own design: it derives a dependency-ordered build sequence (stores before the components that use them, layouts before the pages inside them) and generates each file in order, feeding every step the exports of the files already written — the same context discipline a good agent applies to an existing repo, applied to one that does not exist yet.

The output downloads as a .zip or pushes to GitHub, and from there any of the tools above can take over, with a codebase whose structure was decided by you rather than accreted by generation order.

Agents are getting better at writing code. They are not getting better at knowing what you meant. The leverage, now and for the foreseeable future, is in making what you meant explicit — and that is design work, not prompting.