Coding agents 101: what they are, how they work, and which kind to use

What is a coding agent?

A coding agent is software that gives a language model a goal, a view of a codebase, and tools it can use to pursue that goal. The tools usually include file search, file reads, edits, a shell, git, and sometimes a browser or external systems through Model Context Protocol. After each action, the result goes back to the model. The model then chooses another action, asks for help, or stops.

That last sentence is the category boundary. A chatbot can write a function when you paste enough context. Autocomplete can predict the next lines at the cursor. A coding agent can run the function, read the exception, find the caller, change two files, rerun the test, and report the diff. If you want the deeper mechanics, the agentic coding guide follows the loop turn by turn. The broader AI coding agents guide maps the current tool landscape.

goal
  -> assemble context
  -> choose a tool
  -> execute within permissions
  -> return the observation
  -> update the plan
  -> repeat, ask, or stop
  -> human reviews the result

The word agent does not imply that the system is reliable, independent, or entitled to merge. It describes a control loop. Autonomy is a separate setting: how long the loop may run, which tools it may use without approval, and who accepts the result. Keeping those ideas separate prevents most category confusion.

The four kinds of coding agent

Products overlap, but their primary work surface exposes the bargain they make about supervision. A feature checklist hides that difference. The taxonomy below starts with where the person sits while the agent works.

IDE agents

An IDE agent keeps the human close to the cursor. It sees open files and editor state, applies multi-file edits, and usually has a terminal tool. Cursor Agent is a representative shape: search, edit, terminal, web, and MCP tools sit inside the editor. This is the strongest category for work where the desired result changes as you see it, such as a UI pass, an unfamiliar refactor, or debugging that depends on taste. The cost is attention. You are still operating one conversation and one working tree unless the product adds a separate background-agent path.

CLI agents

A CLI agent starts in a directory and treats the repository as its workspace. Claude Code, Codex, Aider, OpenCode, and similar tools are strongest when the task can be stated as an outcome: fix this regression, add this endpoint without changing the public type, or explain why this test flakes. The terminal is not cosmetic. It gives the agent the same build, test, git, and search commands a developer uses. Read the category comparison before treating every terminal harness as interchangeable.

Autonomous software engineers

An autonomous engineer moves the start of work out of the repository and into the backlog. You assign a ticket or send a message; the platform provisions an environment, plans, implements, tests, and returns a pull request. Devin is the defining example and is unusually clear about the tasks it wants: focused work with explicit success criteria, available context, and tests. This category buys asynchronous capacity and managed infrastructure. It also delays feedback, so a bad brief can consume a full run before the mismatch becomes obvious. The autonomous software engineer guide covers that fork without pretending it is just a longer CLI session.

Agent workbenches

A workbench is not another coding model. It is the operational layer around native agents: sessions, worktrees, status, permissions, diffs, pull requests, quota state, and a review queue. Conductor and Continuum are examples with different breadth. This category becomes useful after the second or third simultaneous session, when remembering which terminal owns which branch becomes a real problem. Before that point, it is extra surface.

How the loop works

A coding-agent turn begins before the model sees your prompt. The harness assembles a system instruction, tool definitions, repository instructions such as CLAUDE.md or AGENTS.md, environment details, and recent conversation. It may add git status, editor state, memories, skills, or a repository map. That packet is the agent's current view of the world.

1. Interpret the goal. The model converts the request into a tentative plan or an immediate information need.
2. Select a tool. It may search for a symbol, read a file, run a test, edit code, call an MCP service, or delegate research.
3. Apply the policy. The harness allows, denies, sandboxes, or asks you to approve the proposed action.
4. Observe. Tool output enters the conversation: file contents, command output, a compiler error, a diff, or an external response.
5. Revise. The model updates its plan from the observation and chooses another tool.
6. Stop. It declares completion, reaches a configured limit, encounters a blocked action, or asks a person to decide.

The loop is why verification can happen inside the task. A generator emits plausible code once. An agent can discover that the package does not compile, then make a second attempt. That is a large improvement, but it is not proof of correctness. The agent chooses what to test unless the brief names the gate, and it can stop after a narrow test while a broader regression remains.

Loops also explain the economics. Context accumulates and is sent again so the model can choose the next action. More exploration means more turns; more turns mean more input processing and a longer transcript to review. Precise filenames, a bounded task, and a named validation command are therefore cost controls, not merely prompting style. See agentic coding for the arithmetic and context engineering for what belongs in the window.

Tools, context, and permissions

Model comparisons attract attention because model names are easy to rank. In practice, three harness decisions often matter more: what the agent can do, what it can see, and what it can do without stopping.

Tools are capabilities

Read, search, edit, and shell tools form the basic coding set. Browser tools add visual checks. MCP tools can reach issue trackers, databases, design files, and production-adjacent systems. Each addition makes more tasks possible and enlarges the trust boundary. A tool should be present because the task needs it, not because the integration was easy to install.

Context is working memory, not a knowledge dump

Agents need repository facts that are specific and surprising: the test command, generated-file boundary, dependency policy, architecture constraint, and definition of done. They do not need a long essay describing TypeScript or clean code. Every irrelevant file competes with the relevant one and is likely to be processed again on later turns. Give the smallest useful map, point at concrete symbols, and clear the session between unrelated tasks.

Permissions are the real autonomy dial

Read-only or plan modes are appropriate for diagnosis, unfamiliar repositories, and proposed migrations. Workspace-write modes fit ordinary reviewed implementation. Unattended broad access belongs in an isolated environment with scoped credentials, not on a normal laptop because the prompt sounds harmless. The relevant security principle is capability, not intention: an agent reading untrusted content should not also possess a route to act on it. The full threat model is in AI coding agent security.

When to use which kind

Choose by feedback latency and environment ownership before price or benchmark. Ask how soon you expect to correct the work and where the necessary tools already live.

Use an IDE agent when the implementation itself is how you discover the requirement. Visual polish, API exploration, and local refactors benefit from a person noticing the wrong direction within minutes. Use a CLI agent when you can specify the outcome and the repository contains a cheap machine-checkable signal. A failing test with a named command is nearly ideal.

Use an autonomous engineer when the asynchronous handoff is the product you need. Backlog cleanup, dependency changes, focused migrations, test additions, reproducible bugs, and CI repairs can fit if the environment can be provisioned and the acceptance criteria are explicit. Do not choose autonomy merely because the task is large. Large, ambiguous work is the case most likely to need frequent decisions.

Use a workbench when operations become the bottleneck: multiple terminals, agents on different hosts, worktrees whose owners are unclear, plans awaiting approval, provider limits, or a growing queue of diffs. A workbench can make that state visible. It cannot rescue a vague task or review code for you.

What coding agents are good and bad at

Agents do best when the repository contains evidence that distinguishes done from plausible. Tests, type checks, linters, build commands, snapshots, and a concrete reference implementation all turn the loop into a search against a visible finish line.

The left column shares three properties: examples exist, the scope can be bounded, and a machine can check a meaningful part of the answer. The right column contains missing information, irreversible consequences, or subjective judgment. A stronger model can narrow the gap; it does not remove the structure of the problem.

Research is a good agent task when it remains read-only and the deliverable requires evidence. Let a focused worker search a repository, collect exact file locations, or compare official documentation. Claude Code subagents are useful here because verbose exploration stays in a separate context and returns a summary. They are less useful when the parent then accepts that summary without opening the cited code.

Implementation should be sized by reviewability, not by how long the agent can remain busy. A 2,000-line diff produced overnight is not necessarily more valuable than a 200-line diff produced in twenty minutes. If nobody can explain the larger change and inspect its deletion paths, the saved writing time has become review debt. Read reviewing AI-generated code before increasing task size.

How to run several coding agents at once

Parallelism starts with task design, not with opening more terminals. Two tasks are safe to run concurrently when they can land in either order, or when their dependency is explicit and scheduled. “One agent does the API and another does the UI” is not independent if both invent the wire contract. Define the contract first, then split production and consumption around it.

1. Bound each task. Give it one owner, acceptance gate, forbidden surface, and proof command.
2. Create one branch and worktree per editing agent. A worktree gives each session its own checkout and index while sharing repository history.
3. Isolate shared runtime state. Allocate ports, databases, simulator devices, caches, test accounts, and temporary directories per lane.
4. Keep authority narrow. Agents may prepare commits or pull requests; merge and production authority stay with a person unless a separately reviewed policy says otherwise.
5. Cap work in progress. Run no more editing lanes than the team can review promptly.
6. Integrate through one queue. Rebase or update, run the named gates against the combined state, review, then merge one change at a time.

Git worktrees are the file-level primitive. They prevent checkout fights and make one diff attributable to one task. They are not containers: git configuration, credentials, processes, ports, and external services may still be shared. Start with the practical git worktrees guide, then use the worktree definition when the shared and separate state needs to be precise.

Subagents solve a different problem. A subagent delegates a focused side task inside a parent session and returns a result. Independent worktree sessions remain visible to you as separate owners. Agent teams add peer coordination and a shared task list. Choose based on who coordinates and whether workers edit, not on which name sounds more advanced.

A first-week operating model

Start smaller than the product demo. The purpose of a first week is to learn which work transfers cleanly and how much review it creates, not to maximize the number of running sessions.

A healthy workflow reduces time to an accepted, understood change. Raw lines written, agents launched, and tasks marked complete by the model are activity measures. They can all rise while delivery slows because the human review queue grows.

Once the first week works, standardize the task brief, permission profile, worktree lifecycle, and proof bundle. Keep exceptions visible. The goal is not to make the agent look like a colleague; it is to build a process where its speed remains legible, reversible, and useful.

Questions people ask

Keep reading