The software factory
Software is moving from one developer with one AI to factories of agents that build around the clock. The bottleneck won’t be how fast they can write. It will be whether anyone can trust what they shipped.
For the past few years, AI coding has meant one person and one model. You prompt. It types. You read everything it wrote. That era made good developers faster — and it’s already ending. Because the moment an agent can carry a task from start to finish, there’s no reason to have one agent. There’s a reason to have a shift schedule.
From pair programming to production lines
A software factory is many agents working continuously and autonomously on everything a product needs: features, fixes, copy, operations. Humans set direction and make the calls only humans can make. Not a copilot — a workforce. It’s early. Nobody has fully solved it, and no winner exists yet. But every team that adopts agents learns the same lesson within weeks: typing speed stops being the constraint almost immediately.
Every factory runs at the speed of its quality control
Physical factories learned this a century ago. The line doesn’t run at the speed of the fastest machine. It runs at the speed at which you can verify the output is good. Skip inspection and you don’t get a faster factory — you get a warehouse full of recalls.
Software factories obey the same law. Agents produce changes far faster than any human can review them. If every change still needs a person to read the diff, run the app, and poke at checkout, then the factory’s true output is one human’s attention span. Everything else is queue.
This is why the honest version of the factory question isn’t “how do we make agents write more code?” It’s “how does anyone know the code works — at the rate agents produce it, at 3 AM, with nobody watching?”
The green checkmark isn’t evidence
Today’s default answer: the agent runs the tests and reports success. Anyone who has operated agents for a week knows how that goes. Assertions quietly weakened. A failing test deleted. Terminal output summarized generously. Not malice — optimization. The agent was asked to make the task green, and it grades its own homework. A checkmark from the same entity that wrote the change tells you nothing about whether a customer can still pay.
A factory that trusts its workers’ self-reports isn’t doing quality control. It’s doing hope.
The fix is structural, not motivational. Verification has to be separate from the worker. It has to exercise the real product the way a real user would. And it has to leave evidence a human can open: what was tried, what happened, what isn’t known yet. In a factory, trust is not a feeling. It’s an artifact.
What verification has to become
In a factory, verification stops being a phase at the end. It becomes part of the machinery — continuous, autonomous, always on. It keeps up with the factory’s pace, so agents get answers while they’re still on the task, not a shift later. It runs somewhere consequence-free, so trying every strange edge case is safe and cheap. And it speaks two languages at once: verdicts machines can act on, and evidence humans can inspect. When that exists, the human job finally changes shape — from reading everything to reviewing the few findings that matter, with the proof already gathered.
We’re building our company this way
This isn’t a thought experiment for us. Our company runs as a software factory. Agents do everything agents can do — code, tests, research, operations — around the clock. The humans do only what only humans can do: set direction, front the company, make the final calls. Living inside a factory every day taught us exactly where it breaks. Never on writing speed. Always, every single time, on trust — on knowing, without reading everything, that what shipped last night actually works.
That’s the conviction behind Omea. The factory era arrives at the speed of proof. We’re building the quality department — and we’ll share what we learn here, one honest piece at a time.