What is a software factory for AI coding agents (and what it isn't)
An agent writes code. A factory decides what happens to that code before it reaches main.
Ler em português Markdown version
The short definition
A software factory for AI coding agents is an orchestrator that turns a plain-language request into a reviewable pull request by moving it through a sequence of states nobody gets to skip. Each state is run by an agent with a defined role (planner, developer, QA, reviewer, security), and moving from one state to the next is decided by deterministic code, not by the agent itself.
The word "factory" is meant literally. On an assembly line, the person tightening the bolt doesn't decide whether the car leaves the lot. There are stations, inspection between them, and someone who signs off on the output. Swap "bolt" for "diff" and "lot" for "main" and you have the idea.
Why a single agent isn't enough
Claude Code, Codex and Cursor already write code good enough to change how teams work. The open question is no longer "can the agent do this?" but "how do I trust what it did, at volume, without reading every line in a terminal?"
Running an agent straight in your checkout has three costs that grow with use:
- The agent grades itself. Whoever wrote the code also says it's done. A report that ends in "APPROVE" is the model's guess, not a check.
- State is implicit. Nothing tells you "this task is in QA, failed twice, and is waiting on plan approval." There is a terminal conversation.
- The blast radius is the whole repo. The agent works in the same directory as you, on the same branch, with the same credentials.
A factory exists to make those three things explicit: who evaluates, what state the task is in, and where the agent is allowed to touch.
The path of a task
In T25, a task moves through this state machine. Legal transitions live in a single file (src/core/state-machine.ts), and no part of the system changes state without going through it.
| State | What happens | Who decides the exit |
|---|---|---|
RECEIVED |
The task arrives as free text with a type and a risk level | Triage |
SPEC |
The request becomes verifiable acceptance criteria, with a checklist | Human (approves the spec) |
PLAN |
The planner slices the work | Plan parser |
AWAITING_APPROVAL |
The factory stops and waits for a person, depending on risk | Human |
IMPLEMENTING |
Developer agents write code in an isolated worktree | Diff limits |
QA |
Tests and checks; a failure goes back to IMPLEMENTING |
QA verdict |
REVIEW |
Reviewer and security read the diff; in-scope findings send it back | evaluateReview() |
PR_OPEN |
The pull request exists and waits for a merge | Human |
DOCS → DONE |
Post-merge documentation | Pipeline |
Three escape states (NEEDS_INPUT, FAILED, CANCELLED) cover a task that needs an answer, broke, or was dropped. The column that matters is the last one: there are three points where only a person can move the task. The spec is always approved by someone, the plan depends on risk, and the merge is always human.
The four parts that make a factory
1. States with closed transitions
If any part of the code can write task.state = 'DONE', you have a script, not a factory. Funnelling every transition through one function that rejects illegal moves is what lets you trust the board. QA can send work back to implementation; so can review. Implementation cannot jump straight to a pull request.
2. Separate roles, with fallback
Planner, developer, QA and reviewer are different roles, each with its own prompt and references. In T25 every role has a preference list of CLIs rather than one fixed CLI. By default the backend developer tries Codex, then Claude, then Kimi. If a CLI isn't installed or signed in, the factory moves to the next one. That removes the single-vendor dependency without needing an API key: agents run on the subscriptions you already pay for.
3. Isolation per task
Every task gets its own git worktree and its own branch. No implementation agent runs in the main checkout. That one has its own post: One task, one worktree.
4. Gates that don't depend on the model
Plan approval is decided by policy (the task's risk and the project's config). The review outcome is recomputed from the findings instead of copied from the verdict the model wrote. Also its own post: The model's APPROVE is not the merge.
What a software factory is not
Not a new agent. T25 has no model of its own and doesn't compete with Claude Code, Codex or Cursor. It calls those CLIs.
Not auto-merge. "Dark factory" is the term for factories that run with nobody watching. You can get close on low-risk tasks, but merging into main stays a human decision in T25, by design.
Not an IDE. You don't edit code inside the factory. It produces a pull request, and the pull request gets reviewed wherever you already review.
Not just a long prompt. A prompt that says "plan, then implement, then test" still lets the model decide when each step is done. The factory takes that decision away from it.
Limits for the agent that won't stop
Anyone who has used a coding agent has watched one rewrite half a repo to fix a test. The factory measures the diff after implementation and fails the task when it crosses the configured limits. T25's defaults are 40 changed files and 2,000 diff lines, plus a duplicate-line detector for mass copy-paste. The numbers change per project; what matters is that the limit lives outside the agent.
There is also a retry ceiling, so a repeating error doesn't turn into an endless "let me try again."
When it makes sense
A factory pays off when the bottleneck has moved from writing code to reviewing it. Two profiles feel that first:
- The solo operator already running two or three agents in parallel and losing track of which terminal was doing what.
- The team with a scarce reviewer, where the senior spends the day reading generated diffs and needs each one to arrive with a plan, tests and a review already done.
If you run one agent at a time on a task you follow end to end, the CLI on its own is probably enough. The factory starts paying when there are more tasks than attention.
FAQ
Is a software factory the same as a dark factory?
Not quite. A software factory is the structure: states, roles, gates and isolation. A dark factory is a way of operating that structure with as little human involvement as possible. T25 is a software factory that keeps the merge human on purpose.
Do I need an API key to use T25?
No. T25 calls the agent CLIs already installed and signed in on your machine, so it uses the subscription you already have with each tool.
Does T25 replace Claude Code or Codex?
No. They keep writing the code. T25 decides the order each role runs in, the directory, and the limits, and it stops the task when it needs a person.
Does my code leave my machine?
T25 is self-hosted: the orchestrator, the database and the worktrees live in your environment. What each agent CLI sends to its own provider follows that CLI's configuration.