My rule of thumb after a year of watching these tools ship: keep one agent in the terminal, one in the editor, and one that can drive a browser. That’s the stack. Everything else is a side quest.
The reason is simple. A chat window that spits out a function is not an agent. An agent takes a goal, plans steps, edits files, runs commands, reads what comes back, and adjusts. That act-observe-correct loop is the whole difference. Once you’ve watched one grind through a failing test suite and fix the second failure it caused along the way, autocomplete stops feeling like the same category of product.
What makes an agent worth installing
- Tool use that includes your tooling. If it can’t run pytest, cargo test or your package manager, it’s guessing.
- Context discipline. A repo with 4,000 files will overflow any window. Good agents search first and read second.
- Recovery. The tell is what happens after an error. Strong agents read the traceback and change the plan. Weak ones retry the same edit three times with a differently named variable.
Score candidates on those three things and half the market disappears immediately, usually the half with the loudest landing pages.
The best AI agents for developers, sorted by job
Terminal work: Claude Code
Runs in your shell, reads the repo, edits files and executes your build and test commands in a loop. It’s what I reach for on multi-file refactors, migration scripts and “work out why CI is red on this branch” afternoons. Give it a rules file listing your build command, your test command and the three conventions your team actually enforces, and the quality jump is noticeable. Without that file it invents a package manager and picks arguments with your linter.
Editor work: Cursor’s agent mode
Different posture entirely. Cursor’s value isn’t the tab completion, which is table stakes now, but the agent panel where you approve or reject a diff hunk by hunk. For feature work inside a codebase you already understand, watching the diff beats reading a wall of prose about it. This is also the agent I’d hand to a teammate who has no interest in learning another CLI.
Git-first edits: Aider
Open source, and it commits every change with a message you can read in git log months later. It works best when you tell it which files to touch, which keeps it from wandering into files it has no business editing. Point it at your own API key and a mid-tier model and a session costs cents.
Delegated tickets: Devin and OpenHands
Both run an agent in a sandboxed VM with a shell and a browser, so you can hand over a ticket and walk away. Devin is the commercial option; OpenHands is the open-source equivalent you can self-host. They’re slower and pricier per task than a terminal agent, so the fit is narrow: well-specified chores like bumping a dependency across 20 packages, adding pagination to an endpoint, or porting a test file to a new framework. Vague tickets produce confident nonsense at four dollars a pop.
Browser work: Skyvern
Some jobs have no API. That’s the gap Skyvern, the AI browser agent that automates the web like a human fills. You describe a workflow and it drives a real browser, clicking and typing and reading the page state to decide the next move. I’ve seen it used for smoke-testing signup flows after a deploy and for pulling figures out of vendor portals that never shipped a public endpoint. Brittle UIs make it wobble, but the alternative is a Selenium script that breaks every other Tuesday.
Watch the model layer, not just the wrapper
Most of these products are a loop wrapped around somebody else’s model, which means a single release can change your tool’s behaviour overnight. The current shift is toward models that spend more time reasoning before they act, and that has moved agent planning further than any UI feature this year. It’s the thread running through the new kind of AI model that’s thrilling developers: longer deliberation, fewer half-finished edits, better handling of the “why did this test fail” loop. So when a vendor announces a benchmark jump, assume your agent’s failure modes have moved too and re-test it.
When the code can’t leave the building
Anyone with a customer database, or a compliance officer, can’t ship a repo to a hosted API. Two options. Self-host the loop, with OpenHands or Aider against a local model, and accept that you’re trading quality for control. Or buy hardware that can actually hold a useful model in memory. The new Nvidia-chip AI PCs with a revamped Windows 11 ship with enough unified memory to run a workable coding model locally, which wasn’t realistic on a laptop two years ago. Benchmark it on your own code before you sign the purchase order.
Choosing without burning a week
- Start where your output lives. Shipping pull requests? Cloud agent. Living in a shell? CLI agent.
- Cost per merged PR beats cost per million tokens. A cheap agent that loops is the expensive option.
- Read the issue tracker, not the homepage. Search for “loop”, “deleted my file”, “ignored instructions”.
- Sandbox it on day one: no production credentials, no deploy rights, no writes to main.
- Give it a week on a side repository first. The guide to AI agents for beginners and which ones to skip saves a surprising amount of subscription money.
Where they still break
Hallucinated package names are the classic failure. The model invents a plausible library, and if the agent has install rights it will cheerfully try to fetch it. Give it open network access and you’ve opened the door to a squatted package someone registered last month. Allow-lists exist for a reason.
Looping is the second. You’ll see the same edit applied three times with slightly different formatting, each attempt reverting the last. That’s a signal the model has lost the plot, not that it needs another nudge. Kill the run and restart with a narrower prompt.
Third, agents are bad at knowing when they’re finished. They’ll keep improving adjacent code and quietly delete a test that was failing for a legitimate reason. Diff review isn’t bureaucracy here. It’s the only thing standing between you and a green build that means nothing.
A setup that holds up
Put a rules file in the repo root and treat it like onboarding docs. Build command, test command, lint command, naming conventions, files the agent must never touch. Every decent agent reads it, and every decent agent gets measurably worse without it.
Keep a scratch branch. Hand over one ticket at a time. Run the tests yourself before believing the summary. Keep a short log of which tasks came back clean and which got botched, because after two weeks that log tells you more about fit than any leaderboard.
The race for who owns your daily driver is only getting louder, and the battle to be your personal AI agent has dragged every major lab into developer tooling. The practical answer stays boring: one terminal agent, one editor agent, one browser agent, all of them sandboxed, all of them reviewed by a human who reads diffs before merging.