Coding agent

What is a coding agent?

A coding agent is a program that gives a large language model a set of tools and lets it use them in a loop. The tools are the ones a developer uses all day: read a file, edit a file, search the codebase, run a shell command, fetch a web page. The model decides which tool to call, the program executes it, the result goes back into the conversation, and the model decides what to do next. It stops when it judges the task done or when you stop it.

Simon Willison's description is the shortest accurate one: a coding agent is a harness for an LLM, extending the model with capabilities that are implemented as callable tools. Most agents define a dozen or more tools, and the ones that matter most are the ones that execute code, such as a Bash tool for terminal commands.

That loop separates a coding agent from the two things it is often confused with. Autocomplete proposes the next few lines while you type and never runs anything. Chat answers a question with a block of code that you copy, paste and test yourself; when it fails, you paste the error back. A coding agent runs the test itself, reads the failure itself and tries again, and it can keep doing that for an hour without you in the middle.

Claude Code, OpenAI's Codex, Google's Gemini CLI and Copilot's agent mode in the IDE are the well-known examples of the interactive kind. Codex cloud, Google's Jules, Copilot cloud agent, Cursor's cloud agents and Claude Code on the web are the background kind: you hand them a task, they work in a remote sandbox and hand back a pull request.

The loop, step by step

Take a small, ordinary job. Every night a Python script exports the day's orders from the ERP to a CSV for the accountant. Since yesterday it crashes. You open a coding agent in the project folder and type: the export script fails since yesterday, here is the error.

1. Read. The agent finds the script, reads it, and reads the error you pasted. It sees a KeyError on a column name.

2. Run. It runs the script against the sample file in the test folder to reproduce the crash. Same error.

3. Edit. It finds that the ERP export now names the column differently, and changes the mapping so both names are accepted.

4. Run again. Clean exit this time. It also runs the two existing tests in the folder, because they are there.

5. Report. It tells you what it changed, shows the diff and the test output, and asks whether it should commit.

Each step is one round trip to the model, with the whole conversation so far sent along. Willison points out the consequence: as the conversation gets longer, every prompt gets more expensive, because the input grows every turn. A ten-minute session is cheap. A four-hour session on a large codebase is where the bill comes from, which is why agents compact their history and why the background variants come with spend caps.

The loop only works when the agent can tell success from failure on its own. A test suite, a script that has to exit cleanly, a build, a screenshot compared to a design: give it one of those and it iterates. Give it nothing and it stops when the code looks finished.

Permissions and sandboxing

An agent that can run any shell command in your project can also delete your project, read your .env file or push to your production branch. Two layers hold it back, and they are different things.

Permissions decide which actions the agent may take without asking you. In Claude Code's manual mode, reads inside the project folder and a fixed set of read-only commands such as ls, cat and grep run without a prompt, and every edit or other shell command asks first. Other modes shift that line: plan mode lets the agent read and explore but not edit, and auto mode has a second model review each action instead of you. Codex has the same idea with read-only, auto and full-access presets. These rules are enforced by the program, not by the model, so a prompt cannot talk the agent past them.

Sandboxing is enforced by the operating system and limits what any command the agent runs can reach, whatever the model decides. Claude Code and Codex both use macOS's Seatbelt framework and, on Linux, bubblewrap with a seccomp filter, to restrict the filesystem and the network. Gemini CLI offers Seatbelt on macOS and Docker or Podman containers elsewhere. Codex's default sandbox mode keeps network access off unless you turn it on.

The reason both layers exist is prompt injection. The agent reads files, web pages, issues and pull request comments as part of its job, and any of those can contain an instruction the model may follow. Permissions catch the model asking to do something unusual. The sandbox catches the case where it does not ask. Every vendor also has a mode that skips all prompts; Claude Code's documentation says to use it only inside a container or VM where the agent cannot do damage, and Codex labels its equivalent as not recommended. That isolated setup is what the background agents ship with by default.

Interactive versus background coding agents

The two forms run the same loop. What differs is who watches while it works.

Interactive: you watch

The agent runs on your machine, in your checkout, with your credentials. You see every tool call scroll by, you answer permission prompts, and you can interrupt mid-task with a correction. That makes it the right form for work where the spec is still forming and you expect to steer: an unfamiliar codebase, a refactor where you have opinions, a bug nobody can reproduce yet. It also means one task at a time holds your attention.

Background: nobody watches until the pull request

The agent runs in a cloud sandbox the vendor provisions per task: it clones the repository, installs dependencies, works for as long as it needs, and pushes a branch. Codex cloud gives each task an isolated container, runs setup with network access and then runs the agent phase offline unless you enable internet. Copilot cloud agent works in an ephemeral environment on GitHub Actions, opens a draft pull request and adds you as reviewer when it is done. Jules writes a plan first that you can approve before any code changes. Cursor's cloud agents return the pull request with screenshots, videos and logs of how the agent checked its work. Claude Code on the web keeps git credentials outside the sandbox and lets a proxy authenticate on the session's behalf.

Because nobody answers prompts, a background agent runs with edits and commands pre-approved, and the sandbox does the containing. You can run several at once: Jules allows 3 tasks in parallel on its free tier and 15 on Pro, and Claude Code's web sessions and Cursor's cloud agents run as many as you start. The trade is that the first time you see the result is the finished pull request, so the task has to be described well enough to survive hours without a question. Vendors know this: Codex lets you start a task from a GitHub pull request, a GitLab issue, a Linear ticket or a Slack thread, and Copilot from an issue on your backlog, which pushes you to write the ticket properly first.

What you see as a business owner

You will rarely run a coding agent yourself. You will see its output.

Pull requests from your supplier. A developer who works with an agent produces more branches, more often, each with a written description and a test run attached. Ask two things: who read this before it was sent, and where did the agent run. A supplier whose agent runs on a laptop with full permissions against your live database is a different risk from one whose agent runs in a sandbox against a copy.

Internal tools that used to be too small to build. A form that replaces a shared spreadsheet, a script that renames the invoices your scanner produces, a page where planners drag delivery slots. Work that did not justify a quote now takes an afternoon with an agent, provided someone can read the result.

Agents replying under a human name. Claude Code's auto-fix feature can answer review comments on GitHub through the developer's own account, labelled as coming from Claude Code. Copilot's agent puts a link to its session log in every commit message. When you check who changed what, look for those labels.

Review and cost

The pull request is where the two questions meet. The agent does the typing; the review is the work you pay a person for.

For the interactive form, cost mostly sits inside a subscription or an API bill, and it scales with session length and codebase size. Gemini CLI's free tier with a personal Google account allows 60 requests a minute and 1,000 a day, enough to find out whether the tool suits you before spending anything.

The background form changes the shape of the bill. You pay per task or per session rather than per person. Copilot cloud agent uses GitHub Actions minutes plus a metered AI usage unit that depends on the model and the tokens processed. Cursor charges its cloud agents at API pricing for the model you pick and makes you set a spend limit before the first run. Jules meters tasks per day, 15 on the free tier and 100 on Pro. Claude Code on the web draws on the same rate limits as the rest of your Claude usage, with no separate charge for the VM. Parallel tasks multiply all of this.

The background form also changes the review. With an interactive agent you saw the reasoning as it happened. With a background agent you get a diff and a summary, and the summary was written by the thing you are reviewing. Read the diff. GitHub makes this concrete: workflows on a pull request opened by Copilot do not run until someone with write access clicks approve, because a workflow can hold secrets, and the docs tell you to look especially hard at any change under .github/workflows. Two habits carry over to every vendor: keep branch protection on so an agent cannot merge on its own, and give the agent a copy of the data, never the live system, until a person has read what it did.