Building a Software Factory

Yesterday I wrote about the state of software factories in 2026. One fact stood out: most software factories stop at the pull request. An agent writes the code, a person merges it, and deploy is somebody else’s problem.

We want a factory that owns everything, from the issue to the deployment. This post is our design. It is not a product yet. Parts of it already run at Astrohacker, and the rest is what we are building next.

The factory is a graph

A software factory is a graph of nodes and edges. Each node is a stage, such as “implement” or “review”. Each edge takes a work item from one stage to the next.

The graph has no cycles. A work item goes into the graph, moves forward through the nodes, and ends in one of two states:

• Deployed. The work is done and in production.
• Human required. The factory stopped and waits for a person.

There is no third state. A work item never loops forever, and it never sits in a stage that nobody watches.

The simplest graph

This is the simplest useful graph:

issue
  └─> classify
        ├─> not automatable ──────────────────────────────> human required
        └─> automatable
              └─> implement ─> review
                    └─> implement ─> review
                          └─> implement ─> review
                                ├─> fail ──────────────────> human required
                                └─> pass ─> merge ─> deploy ─> deployed

A work item starts as an issue. The classify node decides if the factory can do it alone. If not, the item goes straight to a person. If it can, the item goes down the automatic branch.

Classification is what Anthropic calls routing: a step that sorts each input and sends it to the path that is best for it. Later, the factory will have many branches, and the classifier will choose among them.

Three chances, then stop

Why does the automatic branch repeat implement and review three times, and not use a loop?

A loop is the obvious design. An agent implements, a reviewer checks, and the two repeat until the review passes. But a loop has no natural end. A bad task can burn tokens all night, and in the morning nobody knows which pass did what.

So we unroll the loop. The graph has three implement nodes and three review nodes, in a line:

• If the first review passes, the later implement and review nodes do nothing. The item goes straight to merge.
• If a review fails, the next implement node gets the review’s findings and tries again.
• If the third review fails, the item goes to human required, and it stops.

Each work item gets three chances. The cost of each item has a limit, every item ends, and the record shows exactly which pass did what.

Stripe came to the same rule. Its Minions get at most two rounds of CI. After the second push and CI run, Stripe sends the branch back to the human who started it, because more rounds cost tokens and time and help less each time. Anthropic gives the same advice in general: give an agent a stopping condition, such as a limit on the number of iterations.

Human required is the andon cord

Toyota had this idea more than a century ago. In 1896, Sakichi Toyoda built a loom that stopped itself when a thread broke. Toyota later made it a rule of its production system, called jidoka: “automation with a human touch”. A machine that detects a problem stops, and a person comes to fix it. Any worker can also pull the andon cord to stop the line.

The reason is simple. A defect that stops at its station costs little. A defect that moves down the line costs much more.

The human required state is our andon cord. A work item that the factory cannot finish stops in a known place, with its full record: the issue, the classification, each implementation and each review. The person who picks it up does not start from nothing.

Review is where the quality comes from

Every serious software factory teaches the same lesson: generating code is easy, and verifying it is hard. Addy Osmani calls it back pressure: automation can grow only as far as you can check its work cheaply and reliably. StrongDM proves changes against a simulated copy of the services that it depends on. Alan Wells’s team stopped all product work for six weeks to build validation that they could trust.

In our graph, that work goes into the review nodes. A review node is not one prompt that asks “is this good?” It is a curated set of checks, such as:

• the build, the typechecker, the linter and the tests;
• the issue’s own verification criteria;
• a browser test of the changed page;
• a review agent that did not write the code. A generator should not grade its own work, because the same mistakes that made the bug also explain it away.

You will not get the review right the first time. You will see bad work pass, and good work fail. Each time, you change the review node, and the next work item gets a better review. The same is true of every node in the graph.

Agents ask the factory for work

A human developer opens GitHub, finds an issue, and works on it. In our design, agents do the same: they ask the factory for work. The factory gives an agent one work item at one node. The agent does that step and reports the result. The factory moves the item along its edge.

OpenAI’s Symphony works in a similar way. It watches a Linear board, starts a Codex agent for each open task, and treats the ticket states as a state machine.

Because the agents pull work, they can run anywhere:

• on a developer’s computer;
• in an agent product such as Grok Bot;
• in the cloud.

The factory does not care where an agent runs. It cares only that each node gets its work done and that each result is recorded. The factory is the source of truth, not the agent’s machine. Most of the agents will be super intelligent agents, not people. But a person can also take a work item, in the same way.

Each company builds its own graph

The simplest graph is only a start. Over time, you add branches for the kinds of work that you do often:

• a dependency update that needs only the tests;
• a bug that must first be reproduced with a failing test;
• a blog post that needs a fact check, not a typechecker;
• a database change that always needs a person before deploy.

Some nodes call an agent. Other nodes run plain code, with no model at all. Stripe’s blueprints mix the two: agent nodes such as “implement task” and “fix CI failures”, and fixed nodes such as “run linters” and “push changes”. At the Background Agents Summit, Shardul Vaidya of AWS showed a dark factory whose orchestrator splits each request into a graph of tasks, with deterministic gates that send failed work back for rework.

So the graph can look like anything. It depends on what your company builds, and it changes as your company learns. A new company’s graph sends most work to a person. A mature company’s graph sends most work to deploy. The work of the people moves from writing code to building the graph. Zach Lloyd of Warp calls this factory engineering.

The factory owns everything

This is the main idea. The software factory is not a coding agent, and it is not a CI pipeline. It is an app and a set of tools that own the full path of each work item, from the issue to the deployment. It knows where each item is, who or what is working on it, what each step produced, and why it stopped.

Checkly argued last week that the factory should not stop at deploy: a failed check in production should start the next repair. In our design, a failure in production is one more issue at the start of the graph.

What runs today

At Astrohacker, part of this already works. Every change starts as an issue. Agents solve each issue with experiments. Each experiment has a design, a result (Pass or Fail) and a record of its evidence. For each issue, we choose who reviews the design and the result: a person, an agent or nobody. Our ah command keeps the records and runs the deploys.

But today a person moves each issue from stage to stage, and the agents run on one Mac. The graph, the classifier, the three-chance review branch and the work queue for agents are what we are building next.

If you want a software factory for your company, or you are building one, I want to hear from you. Get in touch.