Pipelining

Pipelining turns a design into a sequence of changes that build on each other. Each change produces behavior you can observe and passes a gate before the next one starts. An agent works on one stage at a time, with a context that holds only what that stage needs.

Why Work Moves In Stages

A single prompt that asks an agent to build a whole feature puts every requirement into one context. As the session grows, attention spreads thin and requirements start to drop out. Splitting the work keeps each session short. It also gives you a checkpoint after every stage, while a failure is still small and cheap to fix.

The control panel shows the shape. An editor accepts changes and storage preserves them. A runner starts stages and an adapter invokes the selected agent. Gates evaluate the results. Each stage touches one of these parts and names the connections it depends on.

Build In Dependency Order

Order stages so that each one stands on finished work. In the control panel the sequence runs like this:

• Save pipeline definitions, accepted when a pipeline survives a reload with its steps in order.
• Create run records, accepted when each start produces a distinct record with a frozen copy of the definition.
• Execute stages, accepted when the next stage begins only after the current result passes its gate.
• Add review, accepted when a waiting run advances only after an explicit decision.
• Recover interruptions, accepted when a restarted worker finds incomplete work before it retries.

Define each stage by behavior a person can see. A stage called “build storage” can finish with code nothing uses. A stage called “save and reopen a pipeline through the editor” includes the wiring that makes storage useful. Agents often leave new code unconnected as their context fills, and this framing guards against that failure.

One Requirement Per Stage

A large build starts from a master plan. Split it into ordered requirement documents with one document per stage. Each stage receives the master plan for orientation and its own document for detail. No session ever has to hold the whole build.

Write each requirement as an outcome a user would notice. “The editor saves and reopens a pipeline with its steps in order” is hard to fake. A requirement written as a list of functions invites stubs that pass a narrow test. An end-to-end check tied to the outcome exposes the difference.

Deterministic Steps And Model Steps

Some stages have one correct result for a given input. Validating a pipeline and reading a process exit code belong to ordinary code, which returns the same answer on every run. Model output varies between runs and needs evidence before the runner accepts it. Keep the two apart so each stage is easy to judge.

Stacked PRs

Dependent stages map well onto stacked PRs. The first branch adds pipeline storage. The second starts from the first and adds run records. Each pull request shows only its own diff, which keeps every review small enough to read. Some teams call the same pattern stacked diffs.

Merge the stack from the bottom up. When review changes the first branch, rebase the later branches onto the fixed version. Work on later stages continues while earlier ones wait, and nobody faces one enormous diff at the end.

Keep Earlier Stages Working

Every bug fix ships with a regression test that failed before the fix and passes after it. Tests from earlier stages join the gates of later ones. A later stage that breaks earlier work then fails a check instead of reaching review.

Hold acceptance criteria steady while stages run. If new evidence changes a requirement, record that decision before updating its checks. Deleting a failing case without a recorded decision hides a change in scope.

September, 2026