What is a coding agent, and how much does it do on its own?

What is a coding agent, and how much does it do on its own?

A coding agent is a tool that plans and makes changes across many files, runs the code, and reacts to what happens. A developer reviews the work before it ships. It is the agent idea from the previous module applied to writing software: a goal goes in, the tool chooses its own steps, and a finished change comes out.

How much it does on its own is the interesting question, because the answer is a range. At one end, a tool suggests the next line and a developer accepts or ignores it. At the other, a tool takes a written task, works alone for an hour, and hands back a complete change with the tests passing. Developers describe this range as a ladder, and each rung up means the tool does more between human decisions.

The rung matters more than the tool. Cursor, Copilot, and Claude Code can each be used at several rungs, so two developers who name the same tool may work in very different ways. A developer who says "I run background agents against our ticket queue" and one who says "I use the autocomplete" have told you more about their daily work than the tool name ever could.

What are the rungs of the ladder?

The ladder has four rungs, and each one moves the human decision later in the work.

Autocomplete. The tool suggests the next few lines while the developer types. The developer decides every few seconds, by accepting a suggestion or typing over it. This is the oldest rung and the one Copilot made famous.

Chat. The developer describes what they want and the tool drafts a block of code in a side panel. The developer reads it, takes what works, and adjusts the rest. Decisions come every few minutes.

Supervised agent. The tool works across many files while the developer watches. It reads the codebase, edits, runs the code, and reports what it did, and the developer approves or redirects it at each step. Decisions come every few minutes to every half hour.

Background agent. The tool works with nobody watching. The developer writes the task, walks away, and reviews the finished result. One decision at the start and one at the end.

The rungs are not a maturity scale for developers. A senior engineer drops to autocomplete for delicate work and climbs to background agents for routine work, sometimes within the same hour. The rung tracks the task.

What does a supervised agent do?

A supervised agent works while a developer watches, in the editor or in the terminal. The developer gives it a goal in plain language, such as "add an export button to the invoices page." The agent finds the relevant files, plans the change, edits, runs the result, and narrates as it goes. The developer approves steps, corrects course, and answers the agent's questions.

The session looks like a conversation with work happening inside it. The agent might propose touching four files, and the developer says yes to three and redirects the fourth. The agent might hit a failing test and announce how it plans to fix it, and the developer either agrees or explains what the test is actually protecting.

The skill on display is steering. The developer holds the picture of what the change should be and uses the agent for the labor of getting there. This is also where the vibe coding line from the previous lesson sits: a developer who reads and shapes what the agent produces is supervising, and one who accepts everything unread has stopped.

What does a background agent do?

A background agent takes a task and works unattended. The developer writes a ticket or a task description, hands it over, and does something else. The agent reads the codebase, makes the change, runs the tests, fixes what fails, and opens a pull request for a human to review. Nobody watches it work, and its first human contact is the finished result.

The name is literal. The work happens in the background of the developer's day, usually on a machine in the cloud rather than the developer's laptop, and often on several tasks at once.

What changes at this rung is where the developer's effort goes. With nobody watching mid-flight, the task description carries everything: what to build, what to leave alone, and how to tell when it is done. A vague ticket comes back as a confident change that solves the wrong problem. Developers who work this way get good at writing tasks the way a strong manager writes a brief, and that writing has become a real engineering skill.

Where does the human approval sit?

Developers call the checkpoint human in the loop: a person approves or corrects what an AI system did before the result takes effect. The phrase appears constantly in job descriptions for AI work, and it names a design decision rather than a tool feature. Somebody chose where the person sits.

Each rung of the ladder is really a different placement of that checkpoint. Autocomplete puts a person on every line. A supervised agent puts one on every step. A background agent puts one at the end, on the pull request. The loop never actually closes without a person on almost any team, because the agent's pull request goes through the same code review a human's would. The module 1 lesson on how a change reaches customers applies unchanged: review, then merge, then deploy, whoever or whatever wrote the code.

Why do teams draw the line in different places?

The checkpoint follows the cost of a mistake. A first draft of a test suite can be generated freely, because a bad draft wastes minutes and touches nothing real. A change to a payment system keeps a person on every step, because a bad change moves real money. Same tools, same team, different rungs.

Other factors move the line too. Code that runs in production gets tighter checkpoints than a prototype. A codebase with strong tests can afford looser supervision, because the tests catch what the agent breaks. A regulated industry may fix the line by policy rather than by engineering judgment.

This is why two truthful developers can describe opposite setups. One says "agents write most of their code," the other says "their team barely lets agents off autocomplete," and both may be strong engineers responding sensibly to different stakes. The setup describes the environment as much as the person.

What changes when a team runs several agents at once?

The bottleneck moves. When background agents produce five pull requests in a morning, writing the code stops being the slow part, and reviewing it becomes the limit on how fast the team ships. Teams working this way report that review capacity, the number of changes their people can carefully judge per day, now sets their pace.

That reshapes what the developer's day looks like. Supervising one agent is steering, step by step. Running a fleet is task specification up front and code review at volume afterward, which is close to what a senior engineer has always done with a team of people: define the work clearly, then judge the results.

For reading resumes, this gives the ladder its payoff. "Used Copilot" places someone in the era. "Ran background agents against our backlog, reviewed and merged the output" describes an operating mode: writing precise tasks, judging finished changes, and owning what ships. The next lesson covers context, skills, and MCP servers, the plumbing developers build so an agent working alone can actually find what it needs.