Autonomous coding agents

An autonomous coding agent takes a goal rather than an instruction. It reads the repository, plans, creates and edits files, installs what it needs, runs the tests, reads the failures and tries again, then hands back a finished change, usually as a branch or a pull request. Many run on a machine somewhere else, so you can start one, close the laptop and come back to a result.

This is the only category on the Delegated execution rung, and the layer page covers what the rung costs: invented decisions, review as the bottleneck, stand-ins, early instructions slipping, and attempts that count against your usage whether you keep them or not. This page is about the three things you control around the agent: the brief it starts from, what it can reach while it works, and how you judge what comes back.

What it is for

• A behaviour with its acceptance criterion written down, in a codebase with tests that can check it.
• A bug with a failing test that reproduces it.
• A mechanical change across many files that the type checker or the test suite confirms.
• Work you would give a capable contractor with a written ticket, and expect back finished.

Who it suits

Engineers who already review agent changes reliably on the rung below, and who write requirements before they write prompts. Teams whose test suite can judge a change without someone in the room. Tech leads who can turn a feature into tasks with a check on each one.

How to tell this is your category

• You start a task and stop watching it.
• What comes back is a finished change with a description of what was done.
• Your question on review is whether it is right, not what to do next.
• If you are watching each step and approving commands as they run, you are using the same kind of tool as a terminal agent, on the rung below.

What it costs you later

• The brief is the specification, and nothing else is. Whatever the brief leaves out, the agent decides. A brief that says what to build and not how it fails gets its failure path invented. One that names the behaviour and not the data gets its schema invented. A brief has to carry the acceptance criteria, the failure cases, the design decisions that are expensive to change, the parts of the codebase to leave alone, and the check that says it is done. That is a page, not a sentence. Writing requirements an AI coding agent can build from and Designing a feature an AI coding agent cannot improvise cover the two halves of it.
• What it can reach is what a wrong decision can damage. An agent working unattended has whatever its environment gives it: write access to the repository, the network, package installs, and any secret its tests need. Give it a branch, not the main line. Test credentials, never production ones. No deploy rights and no access to live data. Anything that touches money, identity or migrations should stop for a person before it changes, whoever wrote the change.
• Its tests come from the same hand. An agent that writes the code and its tests in one pass can produce a suite that confirms whatever the code does. Green then means consistent, not correct. Write the acceptance tests yourself, or have them written from the requirements before the code exists, and read them first when the change comes back.
• The description is a claim, not evidence. The change arrives with a summary of what the agent believes it did, written as confidently as everything else. Review the diff against the acceptance criteria, not against the summary. Where the two disagree, the diff is what ships. Reviewing a change an agent made sets out the order to do it in.

A brief that leaves less to invent

A task brief holds one behaviour, the requirement it satisfies, what it depends on and the check that closes it. It can be this small:

**Request a refund**
 
- Satisfies: R1, R2
- Depends on: task 1, the refund record and its states
- Done when:
  - a valid request writes a refund row in `requested`, with an
    idempotency key, and calls nothing external yet
  - a request outside the return window is rejected, with the
    window in the message
  - both cases have tests, and the suite passes on a clean checkout
- Leave alone: `src/payments/` and every merged migration
- If something this task needs does not exist, stop and say so.
  Do not build a stand-in.

The last line is the one most briefs leave out, and it is the cheapest defence against the stand-ins the layer page describes. Sizing tasks an AI coding agent can finish works through the whole task list this one comes from, and Writing a brief for an unattended agent takes the next task on it through a full brief: what it carries and leaves out, the environment it runs in, and the checks to make before handing it over.

When not to delegate

• The requirements are still in your head. Write them first, or stay in the editor, where you can answer the questions the agent will not ask.
• The work is exploratory, and the point is to find out what you want.
• The change touches money, identity or data you cannot recreate, and there is no written design for it yet.
• You could not review the result in one sitting. Split it first.