The problem
Building a small app with AI help still eats hours of back-and-forth: pinning down scope, arguing about the architecture, chasing phases that broke halfway, reviewing work that is only half done. The Factory pushes all of that to the edges. There is one human conversation at the start and one reveal at the end, and everything in between runs on its own and leaves an audit trail.
The pipeline
The engine runs six stages. Each one is a versioned skill with a contract, and every run writes an append-only event log it can be resumed from.
F1, intake. A fixed interview, nine questions at most, turns a plain-English brief into a locked product spec: goal, users, core loop, non-goals, risk posture, and a design-taste setting. Locking the spec is what starts the autonomous window.
F2, blueprint. Two structurally different architectures get drafted and compared on bottlenecks, repercussions, and scalability, and that comparison stays in the architecture document instead of being thrown away. What comes out is a machine-parseable dev plan of three to six phases, each with its own goal, file scope, runnable verification, risk ceiling, and token budget.
F2.5, design pass. Three throwaway HTML mockups try different visual directions. One gets picked and locks a design spec, a token file, and a compliance checker that later UI phases have to pass in their verification. The taste is settled before any product code exists.
F3 and F4, scaffold and build loop. The app is stamped from maintained templates, then a driver works down the dev plan phase by phase: reserve task IDs, dispatch to executor agents, run the phase's verification, move on. If a phase fails three times it escalates instead of thrashing on it.
F5.5, felt-quality analysis. Before anything is delivered, four lenses run against the actual running prototype: QA driving the core loop in a real browser, UX heuristics, a pass for delight and dead spots, and design-token compliance. A broken core loop fails the run; advisory findings never block it.
F6, reflect. Once the app has been revealed, the run log and phase history get mined for lessons that would compound. Those become improvement tasks filed against the machinery, and any tightened quality bars are appended to a ratchet ledger. The ledger only ever appends, and bars are only ever allowed to tighten.
Hard walls
The autonomous window runs inside constraints that do not bend: no public exposure, no spending, no secrets committed to code, no writes outside the app's own repository, and a hard token budget. Autonomy stops at the prototype. Anything that moves the app toward real users stays behind a human gate, and that is permanent.
The proof run
The v1 engine was proven on an app picked at dispatch time rather than a rehearsed demo. The interview opened at 11:17, the spec locked at 11:36, and the finished prototype landed at 12:37: about 80 minutes from the first question to a running app, roughly 60 of which were the autonomous build after spec-lock. It came out working on both the web and mobile lanes, with a green test suite, no failed phases, no escalations, and a cross-lane parity sweep of around 1,300 cases confirming the two builds produced the same outputs. The machinery itself needed no fixes during the run.
What it taught me
The interview matters more than the build loop. Almost every downstream failure I traced went back to something the spec had left ambiguous, which means the nine questions at the front are the highest-leverage engineering in the whole pipeline.