You ask an AI to “add pagination to the users table,” go make coffee, and come back to find it has edited six files, run the test suite, and written a commit message — without you touching the keyboard once. That is not autocomplete anymore. That is an agent, and it changes how you think about writing software.
An AI coding agent is a large language model wired up to actually do things in your codebase — read files, write files, run shell commands, execute tests — in a loop, working toward a goal you gave it in plain English, rather than suggesting one line at a time and waiting for you to accept it. The distinction sounds small. In practice, it is the difference between a very good spellchecker and a junior engineer who can independently execute a multi-step task.
Autocomplete, Chat, and Agents Are Three Different Tools
It helps to place agents on a spectrum, because “AI coding tool” has come to mean three very different experiences.
| Tool type | What it does | Example | You do |
|---|---|---|---|
| Autocomplete | Suggests the next few lines as you type | GitHub Copilot inline suggestions | Type, accept/reject constantly |
| Chat assistant | Answers questions, writes snippets you paste in | ChatGPT, a chat sidebar | Copy, paste, adapt manually |
| Coding agent | Plans a task, edits files, runs commands, iterates on errors | Claude Code, Cursor’s agent mode | Describe the goal, review the result |
Autocomplete is reactive — it fills in what you were probably about to type. Chat is conversational — it produces text you have to manually move into your project. An agent is autonomous within a scope: you hand it a task (“fix the flaky test in checkout.spec.ts”), and it reads the relevant files, forms a plan, makes edits, runs the tests, reads the failure output, and tries again — on its own, in a loop — until the task is done or it needs your input.
Why the Loop Matters
The defining feature of an agent isn’t the model — it’s the loop: read context → decide an action → execute the action → observe the result → decide the next action. A chat assistant does one pass. An agent keeps going, incorporating real feedback from your actual codebase (a failing test, a type error, a lint warning) instead of guessing blind.
This is why agents are so good at tasks that are tedious to describe but easy to verify: renaming a symbol across a codebase, migrating a config format, fixing every instance of a deprecated API call, writing tests for an existing function. You state the goal once; the agent does the repetitive verification work that used to be yours.
What a Typical Agent Workflow Looks Like
- You describe the task. “Add rate limiting to the
/api/uploadroute, 10 requests per minute per IP.” - The agent explores. It greps the codebase for existing middleware patterns, reads the route handler, checks what’s already imported.
- The agent plans and edits. It writes the middleware, wires it into the route, maybe adds a config value.
- The agent verifies. It runs the relevant tests or a linter, reads the output, and fixes anything that broke.
- You review. This is the step people skip and shouldn’t — more on that below.
- You merge (or don’t). If the diff looks right, it goes into your branch. If not, you correct course and let the agent try again.
That loop can run in seconds for a small change or for many minutes on something larger — and increasingly, developers run several of these loops in parallel, one agent per task, rather than waiting on each one sequentially.
When to Reach for an Agent (and When Not To)
Agents are excellent for well-specified, verifiable work:
- Mechanical refactors — renaming, restructuring, updating call sites after an API change.
- Test writing — given an existing function, generate coverage for edge cases.
- Bug fixes with a reproduction — a failing test or clear error message gives the agent something concrete to converge on.
- Boilerplate and scaffolding — new components, config files, CRUD endpoints that follow an existing pattern.
They’re a worse fit when the task is genuinely ambiguous — “make the onboarding flow better” has no verifiable end state, so the agent has nothing to converge toward, and you’ll spend more time re-explaining than you would have spent just writing it yourself. Agents thrive on tasks you could describe precisely to a new hire; they struggle with tasks you can’t describe precisely to anyone.
The Part Everyone Underrates: Isolation and Review
Here’s the catch that a lot of “just let the agent cook” advice glosses over: an agent editing files directly on your working branch is one bad prompt away from a half-finished refactor sitting on top of your uncommitted work. And an agent that ran five, ten, twenty tool calls while you were away produced a diff you have not actually read yet.
Two habits fix almost all of the risk:
Isolate every agent run
Give each agent task its own git branch and its own working directory — a git worktree is the natural tool for this — so an agent can never step on another agent’s files, or on your own uncommitted changes, no matter how many you run at once.
Review the diff, every time
Treat an agent’s output the way you’d treat a pull request from a contractor you’ve never met: read the diff, check the file:line references, run the tests yourself if you’re not sure. Fast is not the same as unreviewed.
This is exactly the gap Agents is built to close. It’s a lightweight macOS app for running parallel AI coding agents — each session gets its own git worktree and branch automatically, so nothing collides, and a Cursor-style diff panel sits right in the sidebar so you can see exactly what changed before anything touches your main branch.
Getting Started
- Pick one small, well-defined task — a test to write, a rename to run — and try it with whichever coding agent you already have access to.
- Notice how much of the value came from the loop (reading its own test output) versus the initial suggestion.
- Before you scale up to running several agents at once, put isolation in place first: separate worktrees, separate branches, and a diff you actually read.
- If you’re on macOS, download Agents and try running two or three sessions side by side — it’s a fast way to feel the difference a worktree-per-agent setup makes.
Agents are a genuine step up from autocomplete, but the leverage only pays off if you keep them contained and keep reviewing what they produce. Get that part right, and running a small fleet of them feels less like a leap of faith and more like delegating to a team you trust because you’re actually checking the work.