How to Build an AI Factory: Step-by-Step Considerations

“Feature factory” used to be an insult. It meant output without outcomes: a team shipping tickets nobody had priced, toward a roadmap nobody had argued about. Then AI made the output part nearly free, and the phrase came back with the sign flipped. Every leadership team is now being asked some version of the same question: when do we get our AI factory?

The ambition is right. Repeatable, AI-powered software production is the correct thing to want. The failures are not failures of ambition. They are failures of anatomy. Everyone bought the machines. Almost nobody built the factory.

This is a build guide. Seven considerations, in the order they bite, for anyone who has been handed the question.

Before step one: decide what “factory” means

A pile of AI tools is not a factory, for the same reason a pile of machine tools is not one. A factory is repeatable production with quality gates. It is not fewer humans. In our terms, it is AI-powered lifecycle execution under expert supervision: the agent does the work, a named person decides whether the work ships, and the record of both is produced as the work happens.

Hold that definition up against what most organizations have bought so far, and the stall makes sense. A coding assistant on every desk is a machine. A pilot that impressed the board is a machine running once, in a clean room. Production is where it went quiet, because production needs the rest of the building.

Anthropic’s AI-Native SDLC playbook, published in August 2026, is the most complete public description so far of what that building contains. Read it. It tells you what good looks like. What it does not do is decide for you how much of it to build yourself, and that is where the seven considerations come in.

1. Start from a model of the system, not from the tools

The first component of a working factory is a current, queryable model of the software it will operate on: architecture, dependencies, interfaces, history, and the reasons things are shaped the way they are. Agents without that context produce plausible nonsense, and plausible nonsense is the most expensive kind of wrong, because it passes a glance.

The playbook is honest about this prerequisite. Every play leans on a short, hand-maintained context file per repository, and its stated infrastructure requirement is one engineer who knows the codebase well. On a service your team wrote last year, that engineer exists. On the estate you inherited through an acquisition or a decade of turnover, that person left with the reasoning in their head, and what your codebase knows that your team forgot is now the whole problem.

Consideration: if nobody in the building can write one accurate page about your most important system today, the factory’s first job is not generation. It is mapping. Derive the description from the running system, verify it against tests and configuration, and keep it maintained as changes land. This is what a System Assessment exists to do, and it is why a semantic layer matters even with a very good coding agent.

2. Split the work into governed stages, not one heroic prompt

The demo version of an AI factory is a single long prompt that turns a ticket into a pull request. It works in the demo because the demo picked the ticket. A production factory runs the lifecycle as separate, governed steps: intent captured, requirements formalized, specification agreed, architecture validated, implementation with tests, documentation, release. Each stage ends by committing an artifact, and the next stage starts by reading it.

That chain is the factory’s spine. It is also its audit trail: who asked for what, what the agent produced, who approved it. Compress the stages into one generation and you lose both the control points and the record, which is the argument we made when we said raw coding agents are not a software development lifecycle.

Consideration: design the stage boundaries before you pick any tool. The stages and their artifacts are the durable layer. Models and tools change underneath them, which is exactly why AI tools come last in the decision order.

3. Size the gates to risk, and put a name on each one

A gate is where a human decides. The two design errors are symmetrical: gate everything, and the factory runs at meeting speed; gate nothing, and you have an agent with a merge button.

The rule that works is separation of duties with named people. The requester and the approver are different humans. The model’s output is input to the decision and never the decision itself. Gates are deeper on the components where a wrong change is expensive (security, access, billing, anything regulated) and lighter where a rollback is cheap. The playbook lands on the same principle: the agent may act up to the production gate and cannot pass it, and branch protection turns anything it writes into a proposal rather than a commit.

Consideration: write down, per system, who holds the verdict at each gate and what evidence they need to give it. If that list has a role name where a person’s name should be, the gate is decorative.

4. Make evidence the exhaust, not the homework

An AI factory will be audited. Not eventually, this cycle: AI-generated change is entering audit scope now, and the organizations that will be fine are the ones whose evidence already exists as a by-product of how they work. Requirements traced to code, tests run against each change, the sign-off at each gate, all generated as part of the work rather than reconstructed afterward by whoever is unlucky enough to be asked.

Consideration: if your factory design has a step called “prepare compliance documentation,” the design is wrong. The stage artifacts from consideration two are the documentation. Build so that the record falls out of the process, then check that an auditor could read it without a guide.

5. Inventory the prerequisite chain honestly

This is the consideration most build plans skip, and it is the one that decides the budget.

Read the playbook end to end and list what a complete implementation assumes is already in place: an intent home with write access decided; standards encoded as reusable skills; policy skills with named owners; a maintained context file per repository; hooks in version control plus managed settings pushed through device management; a one-command test and build; curated evaluations running in continuous integration with an API budget attached; a written review policy; branch protection; per-environment deployment tooling; a sandbox with no standing production credentials; a rehearsed rollback path; a detection script that is itself version-controlled and tested.

Nothing on that list is exotic. Every item is recognizable platform-engineering work. That is what makes it dangerous: each piece looks like a sprint, and together they are a platform product with a roadmap, an owner, an on-call story, and a maintenance burden that does not end when the rollout does.

Consideration: price the chain as maintenance, not as build. Ask your platform team not whether they can stand it up, but whether they can carry it next year alongside what they already own. Build capacity is usually available. Maintenance capacity rarely is, and maintenance is what keeps the gates real.

6. Staff the operations job, because a factory is one

The pilot had an engineer watching it. Production does not. Somebody has to route work to the right model for the task and the budget, watch cost per change, notice the new failure mode the moment it appears anywhere in the estate, and update the guards before it appears again. Somebody has to own the review policy and the hook configuration, and be replaceable when they leave.

This is the honest cost of running your own factory, and it is the part vendor demos skip. It is also the part that distinguishes a factory from a fleet of assistants. Assistants are used. Factories are operated.

Consideration: name the operator before you name the tools. Then ask what your control posture looks like ninety days after that person resigns. If the controls would hold but nobody would dare change them, you have built something you cannot evolve.

7. Decide, per system, whether to build or to have it run

The six considerations above are the same whether you build the factory or have it operated for you. The controls do not differ. What differs is who builds, staffs and maintains them, and that is an operating-model decision, not a technology one.

Two criteria dominate. First, the documentation state of the estate: did people currently on your team write most of this code, and could one of them write an accurate page about it from memory? Second, your honest review capacity: how many people can competently review a hard change to this system, not how many have merge rights? Where both are healthy, run the playbook yourself; the guidance is public and detailed, and you have the conditions it assumes. Where either is weak, no control configuration compensates, because both failure modes are silent.

Most organizations are split. The newer services score well. The system that generates the revenue does not. That is a coexistence answer and it is the honest one: run your own factory where the conditions hold, and have the inherited estate operated for you under the same gate structure, with a named senior engineer accountable at each gate.

Consideration: the mistake is not choosing one side. It is choosing once, for everything, and calling it a strategy.

What to do this quarter

Three moves, in order.

Pick your most important production system and answer one question about it: who could write one accurate page about how it works, today? If the answer is nobody, that is the project, and everything else waits on it.

Draw the stage boundaries and the gates for one change, end to end, on a whiteboard. Put a person’s name on every gate. Where you cannot, you have found where your factory will stall.

Then decide, for that one system, whether you are building the operations job or buying it. AI-MSL is the factory CloudGeometry built for its own delivery work before offering it to anyone else, and there are two ways to have one: we run it under your brand, or we help your team stand up their own. Either way, the machines were never the hard part.

We are running 45 minutes on the backlog side of this on 8 October: why the pile of unpriced work never was a resourcing problem, and what has to be true before a factory can be pointed at it. The factory itself gets its own session in November