How to build a software factory
Build the records and the boundaries first. Earn autonomy last, one consequence at a time.
Most attempts at a software factory start with the exciting part: many agents, running unattended. They end with someone manually untangling branches and deciding from scratch how to test each result. That is production capacity, not a production system.
The sequence below inverts it. Each step adds one of the seven primitives in the order that makes the next one safe. None of it requires a particular language, model or vendor.
-
Step 1
Choose one lane and write down what done means
Pick one narrow, repeatable class of work, such as a small change to one application. Write its definition of done in plain language before any agent runs. A factory that tries to do everything first does nothing reliably.
-
Step 2
Make the work order the only way work enters
Define the order format: objective, scope (paths, tools, network), definition of done, budget for time, tokens, spend and retries, and prohibited effects. If it is not an order, the factory does not do it.
-
Step 3
Start the ledger before you need it
Append a record for every order, attempt, gate verdict, cost and decision from day one. Every later question, from "why did this ship?" to "is the cheaper model good enough?", is answered from this record.
-
Step 4
Wrap your agent runtime in a runner adapter
Generate the prompt, permissions and settings for each attempt from the order, and normalize the runtime's output into neutral events. Keep everything vendor-specific inside the adapter.
-
Step 5
Run every attempt in a fresh ephemeral cell
Create a deny-by-default environment per attempt with only the capabilities the order grants. Discard it afterward. Retries begin from recorded state, not from a long-lived session.
-
Step 6
Build the gate wall outside the cell
Run deterministic checks on scope, secrets, migrations, formatting, static analysis and tests where the attempt cannot reach or rewrite them. Fail closed. On red, return the failure output to the order and retry within budget.
-
Step 7
Generate a review deck for every green order
Summarize the order, the diff under a size budget, the gate table and the cost into one page. Start every lane at explicit approval: a person reads the deck and decides.
-
Step 8
Turn failures into skill edits
After a red or flagged order, run a retro whose output is a proposed change to exactly one skill document. Review and merge it through the same factory, and check that the skill still passes its examples.
-
Step 9
Earn autonomy per consequence, not per factory
Let bounded work run unattended early, but authorize lasting consequences separately. Only a narrow, reversible action class with a sustained verified record should move past one-tap approval, and one qualifying failure should demote it.
On autonomy levels. A useful policy separates permission to work from permission to create a lasting consequence. New lanes start at explicit approval (A0). A1 prepares the consequence and asks for one judgment. A2, pre-authorization without a contemporaneous approval, is reserved for narrow, reversible action classes with a sustained verified record. The autonomy ladder, in full ↗