FIG. 2 — A plain-English description in, a running verified application out
Factory
An autonomous software factory: a frontier model designs the app, a local LLM builds it chunk-by-chunk in a sandboxed test loop, failures feed a retrieval-and-fine-tuning learning loop, and nothing ships unless the assembled app actually runs.
- Status
- Working system
- Context
- 2026 · Independent work
- Role
- Sole designer & engineer
- Code
- Private — on request
The telemetry station, read from the run log: 86% of tokens stayed on the local rung, escalation held to 22% of tasks, and per-project spend shows which builds needed frontier help at all.
The problem
Turning a plain-English description of an application into working software is exactly the loop everyone runs by hand: prompt, run, read the failure, prompt again. Done naively with a frontier model, every iteration of that loop is a paid API call, and the expensive model spends most of its tokens on work a cheaper one could have handled.
Local models running on your own GPU invert the economics — iteration becomes free — but they fail more often, and a build system that fails more often needs real machinery for failure: recording it, learning from it, and knowing which failures a retry can never fix.
And there's a gap at the end of every pipeline like this: tests passing is not the same thing as software working. A GUI app can exit cleanly having never drawn a frame.
How it works
- 01
A frontier model designs; a local model builds
The frontier model drafts the design: the app broken into dependency-ordered chunks, each with its own spec and test suite. A local LLM on my own GPU then fabricates each chunk in a locked-down Docker sandbox, iterating until the tests pass.
- 02
Escalation is the exception, not the loop
Only chunks the local model can't crack escalate up a two-rung ladder of frontier models. The telemetry shows the shape that produces: the bulk of tokens stay on the local rung, and frontier spend attaches to the handful of chunks that demonstrably needed it.
- 03
Failures become a dataset
Every failure is recorded, embedded, and stored in a vector database, so later fix attempts retrieve how similar failures were solved before. The accumulated corrections export as LoRA training data — the factory generates the dataset for fine-tuning its own local model.
- 04
Contract gaps get a guarded repair
Some failures a retry can't fix: a chunk's tests demand behavior its dependency never promised. That's flagged as a contract gap, and the system attempts a guarded repair — amending the shared module and adopting the change only if the dependency's own tests and every already-built consumer still pass.
- 05
“Done” means the app runs
After assembly, a wiring gate statically resolves every cross-module reference, and a startup gate launches the app in the sandbox — the only pass is still being alive when the clock kills it, because a crashed GUI app can exit cleanly having never drawn a frame. A failing gate is traced to the responsible chunk, which is rebuilt with the failure baked into its definition of done.
- 06
Finished apps host straight from the console
Web apps get a published port; desktop apps stream through noVNC and are playable in a browser tab. A web console and CLI cover design review, build monitoring, and per-project token spend telemetry.
General note
“Done” means the app runs, not that the tests passed. Every gate in the factory exists to close the distance between those two claims.
Why it matters
Cost control is structural, not behavioral: the cheap loop is the default and escalation has to be earned, so the economics hold without anyone watching a meter.
The learning loop compounds: the same machine that builds software builds the training data that makes its builder better.
The startup gate encodes a lesson most codegen pipelines skip — passing tests is a proxy, and proxies get gamed. The gate checks the thing itself.
It's the same design instinct as a well-run OT system: process close to the source, escalate on defined exception criteria, and never confuse a healthy-looking signal with a running process.
Stack
- Service
- Python 3.12FastAPIPydanticSQLite
- Build loop
- Docker sandboxpytestPostgres / pgvector
- Models
- vLLMllama.cppOllamaAnthropic / OpenAI / MoonshotLoRA export
- Delivery
- Web consoleCLInoVNC streamingPublished ports
Want the architecture in more depth, or a walk through the code? I'm glad to go there.
Get in touch