The coding pipeline for AI coding agents

The coding pipeline is the route every code change at AR Labs takes, from a rough intention to code that has been specified, built test-first, reviewed by a second model and merged by a person. AI coding agents (AI agents that write code, such as Claude Code or Codex) do the work at each step. Scripts check the result before the work may move on, and a person approves the plan and merges to main. Coding Planner is the pipeline's tooling. This page is the map: how AR Labs engineers software gives the approach in brief, and the other pages in this section describe each practice in detail.

The pipeline exists because an agent working from memory drops steps without noticing. When the steps live in written command files, and the move from one step to the next runs through a script that checks for proof, a skipped step becomes a refusal instead of a silent gap.

The vocabulary

A few terms recur on every page in this section.

• Bead: one tracked task in Beads, Steve Yegge's open-source issue tracker for coding agents. Every piece of pipeline work is a bead, and all the beads with their dependencies make up the task graph.
• Lone task: one coherent piece of work, tracked as a single bead.
• Campaign: work planned in one PRP and split into a tree of beads. The beads that hold other beads are containers; the beads at the bottom, where code is written, are leaves.
• Step: one stage of a bead's route, such as writing its spec or reviewing its code.
• Floor: a machine proof attached to a step. A script inspects git, the filesystem or the code host and answers yes or no.
• Gate: a point work cannot pass until a condition is met; here, the checkpoint a step must satisfy before it counts as done. A human gate waits for a person; a step with no human gate is settled by its floor.

How work flows

The route map shows both ways in joining at the spec, and the one route every leaf then takes to main. Each circle is a station with a floor. A filled diamond is a decision a person makes at every autonomy level, such as approving the PRP; an open diamond is one an agent may pass when the bead's autonomy level allows it (see how much a person watches).

1. Route the work. The first decision is whether the work breaks into pieces worth tracking separately. If it does, it is a campaign. If it is one piece, however many files it touches, it is a lone task. When in doubt, the work enters as a lone task: the spec step detects work that turns out to be compound and sends it to fan-out, so the first decision does not have to be right. Work too small for a bead, such as a comment fix, does not enter the pipeline at all.

2. Grill (campaigns only). The agent interviews the person, one question at a time, until every branch of the design is resolved. The technique comes from Matt Pocock's open-source grill-me skill. The output is a design brief in four blocks: resolved decisions, scope boundaries, how the system decomposes, and acceptance criteria written as Gherkin scenarios (plain-language Given/When/Then statements).

3. Design record and PRP. The brief can be formalised into a design document, architecture decision records and C4 diagrams (see architecture documentation). It then becomes a PRP, a product requirement prompt (Rasmus Widing's format, adapted): a plan that keeps a classic requirements document's goal and justification and adds the context, design-level approach and validation an agent needs. A person approves the PRP. This gate holds at every autonomy level, because every later step is delegated against it.

4. Fan out into issues. The PRP is split into vertical slices: thin pieces of function that each cross every layer of the system, with the thinnest end-to-end slice (the tracer bullet) first. Each slice becomes a bead with its own acceptance criteria and blocking edges to the slices it depends on, and is classed as HITL (needs a person in the loop) or AFK (safe for an agent to run unattended).

5. Per-task spec. For each bead, an agent researches the codebase as it stands now and writes an implementation spec: goal, scenarios, a table saying how each criterion will be proved, the files in scope and the commit the spec was grounded against. See spec-driven development.

6. Implement. On its own branch in an isolated checkout (worktree isolation), an agent builds the bead test-first, writes a walkthrough as it goes, and captures evidence for every criterion.

7. Review. A model from a different family, reached through OpenAI's Codex CLI and given only the diff, the spec and the proof manifest, reviews the work on four separate axes. One automatic fix round is allowed after a failed review; anything still failing after a second review goes to a person. See the code review gate.

8. Deliver. The step closes only when the reviewed commit is actually on the target branch. An open pull request does not count.

9. Integrate (campaigns). When every child has landed, the campaign's own acceptance scenarios must each appear in a test file, and the campaign's test suite must pass.

Three routes

Containers and leaves do different work, so the pipeline declares three routes. A bead's route follows from whether it is the campaign root and whether it has been split into children.

All of this lives in one manifest file. The scripts contain no step names of their own; they read the manifest, so changing the process means editing data rather than logic. An excerpt, in the manifest's shape:

"leaf": ["generate-spec", "implement", "review", "deliver"],
"deliver": { "gate": null, "verify": [{ "kind": "landed_on_target" }] }

Floors never pass on anyone's say-so

The founding rule is that a floor answers from evidence or does not answer. When it cannot pass, it says why in one of two ways. Refuse means the work is not done yet, and the pipeline may dispatch an agent to do what is owed. Escalate means the floor cannot answer at all, because the repository is missing or the code host is unreachable, so the bead is parked for a person and the run carries on elsewhere. Keeping the two apart tells a person whether to fix the work or fix the machinery.

The pipeline's whole memory is metadata on the beads, written only by one transition script. A session can crash, or a laptop can close, and nothing is lost: the next session reads where each bead stands.

How much a person watches

Each bead carries an autonomy level that decides which human gates an agent may pass on its own. Every floor runs at every level; the level only removes the person's hand from approving the step.

Some steps never pass without a person at any level: the design record, the PRP and the merge to main. A step that is waiting for a person does not stop the run; the question and a recommended answer are written on the bead, and the run moves to other work.

What exists today

The pipeline runs our own development. It can be driven from an interactive session, where a person answers gates in conversation, or unattended, where a runner dispatches one headless agent session per step. Work an agent discovers mid-run is filed at once as a new bead linked to the bead that found it, then worked when the current tree is done.

Where it came from

The task-versus-campaign split, vertical slices, HITL/AFK classification, review in a fresh context and the grilling interview follow Matt Pocock's published workflow for AI coding. The tracker is Steve Yegge's Beads. Our own additions are the deterministic floors, the autonomy levels and the rule that state lives on the tracker rather than in any running process.