There is a sense in stories going around the interwebz that a software factory (agents building your software while you do something else) is a big, scary, expensive, fail prone thing that takes a platform team to set up.
This write-up of Uber’s factory lists six pieces: a context graph with 40 million entries, a skills registry, two gateways, warm environments and an assistant interface. It is blunt: “Without the platform underneath, the AI Software Factory is a set of scripts that break the first time a repo moves or a model changes.” StrongDM sets the bar in dollars: “If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.” Dex Horthy’s “Why Software Factories Fail” got 394 points on Hacker News. He’s half right (below).
Well, I’ve been running one for the last 40 days and and most of it is process defined in markdown .
Not to assume it’s impossible because you find it hard. But to recognize that if it’s humanly possible, you can do it too. — VI. 19
Wait, who benefits?
Notice who says it’s hard. The Uber write-up was published by the CEO of a company that sells software factories to platform teams.
If it’s hard, somebody gets to sell you a platform and you as the buyer get to ask for headcount and a six month roadmap to get it online. And if it’s hard, you (yes you, with the factory strategy deck and nothing that runs your software) have your alibi.
My Factory
First some context, Tortie is a Mac app I built for running coding agents, and it’s open source. It keeps every agent session alive through a quit, a crash or a reboot, and around that sits an editor, a git graph, remote machines over ssh and self-updating releases. More than 1,600 commits in 40 days, 24 releases, over 14,000 tests, 866K loc entirely built by agents in my factory.
The factory I started with is three things:
CLAUDE.md. 347 lines. The rules.docs/BACKLOG.md. One file. The queue.Claude Code in ultracode mode with workflows (a script that runs a fixed sequence of agents) and a
/loop(a prompt that re-fires on its own) carrying one sentence: “chain the next batch immediately when one finishes, never leave the queue idle.”
I never built a gateway or a context graph. The rest the factory built for itself.
The general
Spec → Build → Verify → Fix → Reverify → Commit
Every builds phase that lands on my backlog is one workflow with that shape, a different set of agents on each step, each with something it may NEVER do. Verify never passes work by reading the code. It launches the real app, tries one thing Build did not, and answers on a form: pass or “needs work”, plus the evidence. There is no box for “looks good”, so it can’t say it.
I had an agent count. In 35 of 51 recent phases, Build called the work done and Verify still found something that then got summarily fixed.
The method doc defines how my agents verify changes. Furthermore:
Rules and the queue live in files, not the chat. Its sibling: “Written down, they bind every future agent; said once in conversation, they evaporate.”
Verify by doing, never by reading. The one day we kept count, reading the code caught “Nothing, all day.” I learned the other half the dumb way: a Verify agent crashed, my setup read silence as a pass, and two fresh ones then found 15 problems. A crash now counts as “needs work”.
Only the committer commits. A Build agent once ran
git add -Aand staged another agent’s half built work before I got this sorted.
Marcus Aurelieus kept a notebook to correct himself after he got things wrong. CLAUDE.md is the same practice for the factory albeit with much worse prose.
Keeping your product tidy
The fair worry is rot. No set of strict tests tells you the codebase is getting worse. So every few days a DIFFERENT set of agent (Codex, for example, not the Claude Code that built it) audits the tree at a pinned commit.. It scores twelve boundaries from 0 to 3 (state ownership, lifecycle, failure flow...), where 3 means the boundary is “explicit, narrow and protected by tests or build checks.” It benchmarks against a named exemplars and borrows best practice patterns.
The first scored audit gave 24 of 36. Four days later, 35. New features land and the audit charges them, so the latest reads 32, “for different reasons.”
The findings from this weekly process go back in the queue as ordinary tasks with one standing rule: audit numbers are baselines to remeasure. Same six words, and the task closes with a fresh audit told to “report the score the evidence supports.”
None of this needs my rubric. Pick a codebase you admire, have a second model score yours against it, forbid it from touching anything, queue what it finds. My whole prompt for the second one: “Please reverse engineer what the prompt likely was, and produce a new audit in similar format making astute recommendations for keeping the architecture of this app tidy.”
Some obvious objections
“You built a Mac app. Uber has more than 70% of its pull requests coming from agents.” True, and at 100 million model requests a day you will want a gateway. But none of the write-up’s six pieces is the step that tells you the software works.
“Models can’t keep a codebase good over time.” That is Dex’s real argument: “They can’t maintain and improve codebase quality over time -- not without a decent amount of human steering.” I agree. It’s why the audit process I use exists and why me, a person stays in the loop. His target is the lights-off factory. The loop doesn’t replace taste. But it sure as hell buys me the hours to have some!
What to do next
You do not need a platform team. Copy my claude.md and other method docs. If you’re adventurous, make Verify a different agent from Build, make it run the software, and give it no box for “looks good”. Have a second model score the codebase and queue what it finds. Add a line to the file every time you are wrong (you will be, I was, weekly).
It’s very early. But you can start anyway.