Most "AI coding" demos stop at a chat window that writes a function. A software factory is different: it starts from a ticket and ends at a pull request a reviewer can trust, with nobody typing in between. This is how one is put together, station by station.
Why stations, not one big agent
A single agent asked to "fix the ticket" has to plan, edit, test and explain all at once. When it fails, you can't tell which part failed. Splitting the work into narrow stations — each with one job and one check — means a failure is caught where it happens, and the fix is local.
Station 1: Task
A ticket is raised in the project tool. A webhook starts a run with the ticket text, its links, and a snapshot of the repository. Nothing is cloned onto a shared machine; every run gets an isolated branch and an isolated environment.
Station 2: Planner
The planner reads the ticket and the codebase and writes a short plan: which files it expects to touch, what the change is, and how it will prove the change works. The plan is saved with the run. If the planner can't find a plausible place to make the change, the run stops here and a person is told why.
Station 3: Coder
The coder edits only the files in the plan. It can run the project's existing commands — build, lint, test — but it cannot push, cannot touch the main branch, and cannot reach the network beyond the package registry. Scope is a permission, not a suggestion.
Station 4: Verifier
The verifier runs the test suite and, for UI changes, takes before-and-after screenshots of the affected screens. It compares them to what the ticket asked for. If something fails, the failure goes back to the coder with the logs attached, for a limited number of retries.
Three retries is usually enough. If a change can't pass by then, the ticket was ambiguous or the tests are wrong — both are a person's call.
Station 5: Pull request
The PR carries the plan, the diff, the test results, the screenshots and a link back to the ticket. A reviewer sees exactly what the agent intended, what it did, and how it checked itself. Merging is always a human action.
What to measure
- Merge rate — the share of PRs merged without edits. This is the number that tells you whether the factory is earning its keep.
- Cycle time — ticket to reviewable PR.
- Escalation rate — how often a person had to step in, and the reason each time. The reasons become new tests or better ticket templates.
- Cost per ticket — model and compute spend. Cheap tickets subsidise expensive ones; watch the tail.
Where it fits, and where it doesn't
It fits a steady stream of small, clear tasks on a large or old codebase, where most of the cost of a change is rebuilding context. It doesn't fit architecture work, open product decisions, or code with no way to verify a change. The honest answer to "can it do everything?" is no — it does the routine 60% so people can do the other 40%.