Ask a room of engineers whether AI writes their code and most hands go up. Ask whether an agent has opened a pull request that merged without a human touching the keyboard, and the hands drop. That gap, between “the model suggested a line I accepted” and “the agent read the issue, wrote the fix, ran the suite, and shipped a PR,” is the whole story of AI coding agents. It is a bigger jump than the marketing implies, and it quietly changes what the job looks like.
Autocomplete predicts. Agents iterate.
A completion model watches your cursor and guesses the next few tokens. Genuinely useful, but it is still a suggestion engine. An agent takes a goal and gets tools: search the repository, read files, write patches, run the test suite, read the failure, try again. The intelligence matters, but the loop is the product. A mid-tier model with a fast test command and readable error output will beat a smarter one that has no way to check its own work.
You can see that in the benchmark curve. On SWE-bench Verified, which grades systems on real GitHub issues, the best results sat in the low single digits in early 2024. By late 2025 the leaders were clearing 70%. Only part of that is raw model quality. The rest is scaffolding: tighter tool definitions, sandboxed execution, and agents that retry instead of apologising.
Where AI coding agents genuinely earn their keep
The tasks that work today share one trait: success is checkable by a machine. If a test can prove the job is done, an agent can usually grind its way there.
- Test backfill. “Write tests for this module, get coverage from 41% to 80%, don’t change behaviour.” Boring, verifiable, and a genuine time sink when done by hand.
- Dependency and framework migrations. Renaming an API across 200 call sites, swapping a deprecated library, converting a config format. Tedious work with a compiler as the referee.
- Glue code. A new REST endpoint that mirrors three existing ones, a logging wrapper, an adapter for a third-party SDK. The thousand small pieces nobody enjoys writing.
- Codebase archaeology. “Where is retry logic handled for outgoing webhooks?” Agents are excellent at following a thread through an unfamiliar repo and coming back with file paths.
- Small bug fixes with a reproducing test. Give it a failing case and the loop does most of the work.
The pattern is not glamorous, and that is the point. Teams getting real leverage are not handing over architecture. They are handing over the backlog items that have been sitting in “good first issue” for eight months. The agent deployments that actually shipped mostly look like this once you strip out the demo videos.
Where they fall over
Changes that cross repository boundaries
An agent that can hold one repo in context struggles the moment a change touches a shared library, a Terraform module, and a mobile client. It will confidently update the first two and forget the third, then report success.
Flaky tests
Non-deterministic suites are poison. The agent sees red, assumes its patch is wrong, and starts editing unrelated code to satisfy a test that fails on main. If your suite is flaky, fix that before you point an agent at it.
Anything requiring taste
Naming, API ergonomics, whether a feature should exist at all. Agents produce plausible structure, which is worse than bad structure, because it survives review. I have watched a model rename a perfectly good module across 40 files because the task description implied a tidier abstraction. The diff was clean. The idea was worse.
Performance work without instrumentation
Ask an agent to make a slow endpoint faster and you get micro-optimisations aimed at whatever looked suspicious. Without a profiler feeding it real data, it is guessing with extra steps.
The tooling landscape, in brief
Claude Code, OpenAI’s Codex CLI, Cursor’s agent mode, Cline, Aider, GitHub Copilot’s coding agent, and Devin all attack the same loop from different angles. Some live in your terminal and work on your working copy. Others run in a cloud VM and hand you a pull request. The split matters more than the model choice, because it decides how much of your environment the agent can see and break. If you want a comparison grounded in completion rates rather than launch posts, this rundown of the best AI agents judged by what they finish is a reasonable starting point.
Cost stopped being the objection
An agent burns far more tokens than a chat session. A single non-trivial task might read 15 files, run the test suite four times, and rewrite a patch twice, which easily runs into six figures of tokens. Eighteen months ago that was a budget conversation. Now it is noise. Cheaper inference from labs like DeepSeek and the pricing reset it triggered means the constraint has shifted from spend to review capacity.
How to run them without regretting it
Most disappointment with coding agents traces back to a badly scoped task, not a bad model. A few habits fix the majority of it:
- Write the issue like a brief for a contractor. What is broken, how to reproduce it, what done looks like, which files to ignore. Two extra minutes here saves an hour of review.
- Keep tasks under about an hour of human work. Beyond that, the diff grows past the point where you can review it properly.
- Give it a fast, reliable test command. Under 30 seconds beats thorough. The agent will run it dozens of times.
- Demand a failing test first. “Write a test that reproduces the bug, show me it fails, then fix it.” This one instruction kills more hallucinated fixes than any prompt engineering.
- Cap the blast radius. No production credentials, no network egress beyond package registries, no force pushes. Sandbox it like you would sandbox a new hire’s first week.
- Review the diff as a stranger’s work. Not as your own. The failure mode is plausible code that passes tests and does the wrong thing in production.
The honest comparison here is not agent versus human. It is agent versus the chat window you were already pasting into. The difference in practice, and where the friction shows up, is covered well in this piece on what ChatGPT for coding genuinely saves you and where it bites back.
The bottleneck moved, and nobody updated the process
If an agent can produce four pull requests before lunch, your team does not get four times faster. It gets a review queue. The limiting factor becomes how fast a human can read, reason about, and trust a diff. That is slower than writing the code was, because reading unfamiliar code with no memory of writing it is the hardest kind of review there is.
This is why the interesting experiments are not about autonomy levels. They are about review design: smaller PRs, stricter linting, contract tests that make a diff self-evidently safe or unsafe. Long-running autonomous AI agents that work without a human watching are impressive in a lab. In a real codebase, the value comes from narrowing what a human has to check.
Three numbers worth tracking
If you are rolling agents out to a team, ignore the benchmark scores and track your own. The first is merge rate: of the PRs an agent opens, how many land without substantial rework? Anything under about half means your task scoping is off. The second is revert rate: how often does agent-written code get rolled back within two weeks? A spike there is a review problem, not a model problem. The third is mean review time per PR, because that is where your actual capacity is going.
Track those for a quarter and you will know more about what AI coding agents can do for your codebase than any leaderboard will tell you. The teams getting real value are not the ones with the most autonomy. They are the ones who figured out, task by task, which parts of the job were never really about writing code in the first place.