Coding Agents: What They Do Well and Where They Break

A coding agent doesn't suggest the next line. It reads the repository, edits several files, runs the tests, reads the failure, and tries again — looping until the task is done or something stops it.

That loop is the entire difference from autocomplete, and it's why this category works better than most agent applications. Code is machine-checkable. The compiler and the test suite tell the agent whether it succeeded, without a human in the middle. Almost no other agent use case has feedback that good.

What follows from that:

• Agents are strongest where a test can prove the work — bug fixes, refactors, migrations, test writing.
• They're weakest where correctness is a judgment call — architecture, API design, anything involving "should we."
• The bottleneck moved. It's no longer typing code; it's reviewing code you didn't write.

The three shapes

Terminal agents — Claude Code is the reference implementation — sit in your shell with access to the file system, git, and whatever tools you give them. The advantage is composability: they inherit your environment, so they can run your actual build and your actual tests.

In-editor agents put the loop where you already are. Cursor and the agent modes in GitHub Copilot are the common examples. Review is immediate, which is the main argument for this shape.

Async agents take a ticket and come back with a pull request. Codex and similar tools work this way. The appeal is obvious and the catch is real: reviewing a large diff you didn't watch get made is harder than writing it, and the review is where the risk concentrates.

What they're genuinely good at

Mechanical refactors across many files. Rename a concept, change a signature everywhere, migrate a deprecated API. Tedious, well-defined, verifiable — the ideal shape.

Bug fixes with a reproduction. Give it the failing test and it can iterate against a clear target. Without a reproduction it's guessing, and the loop has nothing to check against.

Test writing. Underrated. Agents write thorough, boring tests, which is exactly what tests should be and exactly what humans avoid writing.

Getting oriented in unfamiliar code. "Where does authentication happen in this repo" is answered faster by something that can grep and read than by you scrolling.

Version migrations. Framework upgrades where the changes are documented and repetitive.

The pattern: the task has an unambiguous definition of done that a machine can evaluate. When you can't state that, the agent has nothing to iterate toward. Anthropic's guidance on building effective agents makes the same point from the builder's side — the loop is worth its cost only when the next step genuinely depends on what the last one found.

Where they break

Ambiguous requirements. An agent given a vague ticket produces a confident, complete, wrong implementation. It doesn't come back to ask — it fills the gap with an assumption and keeps going.

Architecture. Decisions with long-term consequences and no immediate test. The agent optimises for making the current thing work, which is often the wrong objective for a design choice.

Silent scope creep. You asked for a fix; the diff also touched six other files "for consistency." Every one of those needs review.

Context exhaustion. Long sessions accumulate stale intermediate results until quality degrades noticeably. Short, scoped sessions beat marathon ones.

Plausible wrongness at scale. The dangerous failure. It compiles, tests pass, and the logic is subtly wrong in a case no test covered. Volume makes this worse, because more generated code means more surface nobody read carefully.

None of these is a reason to avoid agents. They're the reason review discipline matters more now, not less.

Working with one without losing the thread

Give it a target it can check. A failing test, a type error, a lint rule. "Make this better" gives the loop nothing to terminate on.

Scope it small. One task per session. The instinct to hand over a big feature is where most bad experiences start.

Read the whole diff. Every line. Code you didn't write and didn't read is code nobody has read, and it's now in your repository with your name on the commit.

Keep sessions short. Start fresh rather than pushing through degraded context.

Write the repo conventions down. Agents follow explicit instructions about how your project works far better than they infer them. This is what Claude skills formalise — packaged instructions the agent loads rather than rediscovers.

Cap the loop. An iteration limit prevents an agent from spending twenty minutes and a lot of tokens converging on nothing.

Is a coding agent the same as an AI agent?

Structurally, yes — it's an LLM agent with a specific toolset: file read and write, shell, test runner, git. Nothing about the loop is unique to code.

What's unique is the feedback. Most agents operate where success is a matter of opinion, so nothing corrects them mid-task. A coding agent gets told it's wrong by the test suite, immediately and unambiguously, and can act on that. This is the single best argument for why this category matured first, and it's a useful lens for judging other agent products: ask what checks the work. If the answer is "a person, eventually," expect the reliability of a first draft. The general version of that argument is in agentic workflows.

Running someone else's setup

The gap between "I read about a good agent configuration" and "I'm using it" is larger than it should be.

Working setups get shared as repositories — dependency lists, environment variables, API key configuration, assumptions about a runtime you don't have. Reproducing somebody's environment routinely takes longer than understanding what they built, and that wall shows up whenever you want to start from something proven rather than from scratch.

Taku is an AI-native desktop workspace aimed at that step: mirror a working AI setup into your own workspace, run it, and remix it for your files — without reproducing the original environment first. The free app library is the fastest way to see what that looks like. Taku is in Beta, and the Mac app is available now.

FAQ

What is a coding agent?

An AI system that edits code in a loop rather than suggesting completions. It reads the repository, makes changes across files, runs tests or builds, reads the results, and iterates until the task passes or a limit stops it.

What's the best AI agent for coding?

Depends on where you want the loop to run. Terminal agents like Claude Code suit supervised work in a repo you know; in-editor agents suit multi-file edits you want to review as they happen; async agents suit delegating a well-specified ticket and reviewing a pull request. The shape matters more than which vendor.

Are agentic AI coding tools reliable enough to use unsupervised?

For tasks with a machine-checkable definition of done — a failing test, a type error — they're genuinely useful and improving. Unsupervised on ambiguous work, no: the characteristic failure is a confident, complete implementation of the wrong thing. Review the whole diff regardless of how clean it looks.

Do coding agents replace developers?

They change where the time goes. Typing code stops being the constraint; specifying work precisely and reviewing generated code becomes it. Both of those are senior skills, so the effect looks less like replacement and more like a shift in what the job consists of.

Why does my coding agent keep making unrelated changes?

Usually an under-specified task. Given a vague target, the agent optimises for what looks like improvement, which includes tidying things you didn't ask about. Scope it to a single change, give it a check it can run, and cap the iterations.