Specs in, verified code out: how the factory pipeline works

The pipeline from a product specification to a merged change: how the factory reads your architecture, derives tests from acceptance criteria, verifies its own output, and stops at a human gate inside your pull request process.

The promise of the AI Software Factory fits in one line: product writes the spec, the factory produces the code, the tests, and the evidence, and an engineer approves what merges. This piece walks that line end to end.

Step 1: a spec, the way product already writes it

The input is not a technical design document. It is a specification the way product writes it: what should happen, the acceptance criteria, and the scenarios. It describes behavior, and the factory decides the implementation. Teams do not need a new document format to start; they need three specs from their backlog.

Step 2: the change, in the right layer

The pipeline reads your architecture before touching it. The change lands where your team would have put it, following your conventions: the right service, the right layer, the right patterns. This is what separates a factory built for your architecture from generic code generation.

Step 3: tests derived from the acceptance criteria

Each acceptance criterion maps to a functional test that exercises real behavior, including the failure paths. Where the change touches the interface, the factory also produces visual tests, on desktop and mobile, with evidence you can inspect.

Step 4: the independent check

The fastest way to make a test pass is to make it check less. So every test the factory produces is reviewed by a verifier that did not write it, looking for assertions loosened, steps skipped, and validations emptied. What looks like that gets blocked. The same discipline applies to visual baselines.

Step 5: the human gate

Nothing merges without an engineer's approval, and the gate runs inside your existing pull request process. Alongside the change, the reviewer gets a traceability record (which requirement produced which file, and which test covers it) and the run log (what was produced, what was verified, what failed and was corrected along the way). The approval is informed, not ceremonial.

What this changes for an engineering team

Each change stops costing what it cost last year. The pipeline produces the code, the tests, and the first round of verification; engineering time concentrates on deciding what to build and approving what lands. The output stays in your repository and runs in your CI, so nothing about your delivery infrastructure changes.

Frequently asked questions

What does the factory need from my team to start?

Three specifications from your backlog, written the way product already writes them: what should happen, the acceptance criteria, and the scenarios.

Where does the factory's output land?

In your repository, running in your CI. The human gate runs inside your existing pull request process.

What evidence comes with each change?

Functional tests mapped to each acceptance criterion, visual tests where the interface changed, a traceability record linking requirements to files and tests, and the run log of the production and verification steps.

What stops the factory from writing tests that always pass?

An independent verifier that did not write the tests reviews every one of them, looking for loosened assertions, skipped steps, and emptied validations, and blocks what looks like that. Visual baselines get the same review.