Blog · Engineering
Software factory: how does it work?
"Software factory" is an old phrase that suddenly means something new. This post gives it a definition, says which problem it is for, separates the two kinds that exist today, and explains why we built Sirovi as the second kind.
A definition
A software factory is a system that turns a goal into shipped software without a person doing the work in between. You state what you want, the factory plans it, writes it, tests it, reviews it and opens the pull request. You decide what to merge.
The phrase was used in the 1990s for component libraries and code generators. What changed is that the workers inside the factory are now agents: language models that read your codebase, run your tools and talk to each other. The factory is no longer a template engine. It is a staff.
Three things make it a factory rather than a chat window: the work runs without you watching, it runs again tomorrow on the same codebase, and it produces something you can inspect before it reaches production. Remove any of the three and you have an assistant, which is a fine thing, but a different thing.
The problem it should solve
Coding agents already write good code. The hard part moved. Ask any team that has used one for a quarter and the complaints are the same:
- Every session starts from zero. The agent that learned your conventions on Monday has forgotten them by Tuesday. You repeat yourself, or you write ever longer prompts.
- The human is the bottleneck. One engineer prompting one agent is still one engineer. The agent is fast; the queue in front of it is not.
- Quality is uneven. The same agent ships a careful change in the morning and a sloppy one after lunch, because nothing holds it to a standard except the person reading the diff.
- Nobody owns anything. A prompt is not an employee. It has no scope, no history, no reputation, no one to coach.
A software factory exists to solve those four problems at once: memory that survives the session, throughput that does not depend on one person's attention, a standard that is enforced by the system, and ownership that can be named.
Two kinds of factory
Every factory being built today falls into one of two designs, and the difference is not cosmetic.
Workflow-based. A fixed pipeline: plan, code, test, review, in that order, with an agent at each step and a prompt for each agent. It is easy to draw and easy to sell. It runs the same way every time, which is its strength and its flaw. When the pipeline makes a mistake on your codebase, it makes the same mistake next week, because nothing in the design has a place to put what it learned. Improving it means a person editing prompts, which is the bottleneck wearing a new hat.
Self-improving harness. The pipeline is still there, but it is not the point. Around it sits a harness: named agents with a written scope, a memory of lessons per agent, a review that produces feedback instead of a verdict, and a routine that turns the feedback into changes to the agents, their memory and the process itself. The harness is the product. The pipeline is one of the things it improves.
The benefit of a self-improving harness
The obvious benefit is the one in the name. A mistake made once is a lesson; a lesson is a file; the file is read before the next task. The team is better on day thirty than on day one, and nobody rewrote a prompt to get there. We have watched this on our own repository for nine months, and the thing that still surprises us is how fast the mistakes stop repeating.
The less obvious benefits are the ones that decide whether you can run a factory at all:
- It compounds across agents. A lesson the backend engineer learned about your database is offered to the tester the same night. In a workflow, each step learns nothing from the others.
- It survives the model. The model you rent will change. The lessons, the scopes and the review history are plain files in your repository. Swap the model and the team keeps its experience.
- It can be audited. Every improvement is a diff: a new lesson, a retired one, a rule promoted. You can read why the factory behaves the way it does, and correct it in a line.
- It makes hiring a real step. When agents are files with scope and memory, you can recruit them properly: generate candidates, interview them on your real tasks, judge, keep the winner. A workflow has prompts; a harness has colleagues.
- It removes the manager from the loop, not from the decision. The harness brings you the one or two disagreements a day that need a human. Everything else it settles itself and shows you in the morning.
There is a cost, and it is worth saying plainly: a harness is harder to build than a pipeline, and it only pays if it runs every day on the same codebase. For a one-off script a workflow is enough. For a product you intend to keep shipping, the harness is the only design that gets cheaper with time.
This is what Sirovi is
Sirovi is a self-improving harness applied to a software factory, installed on your machine, inside your repository, with your own Claude. Concretely:
- Hires, not prompts. Each engineer is recruited in a tournament on your repository and arrives with a written brief, a scope and a way of working.
- Memory as files. Every lesson lives in the hire's folder in your repository, versioned with your code, readable and correctable by you.
- The night shift. A nightly routine runs the retrospective, consolidates the lessons, holds a 1:1 where a hire and its reviewer disagreed, and opens a pull request with the result.
- The harness evolves too. The routine that improves the hires is itself in the repository and is itself improved by the same loop.
- Nothing leaves. Your code, the agents and their memory stay on your machine. The software sends us a licence code, its version, an installation identifier and error codes, and nothing else.
We built it because we needed it: it has run our own engineering since January, and it wrote most of the website you are reading, including this post. The decisions were ours. The hours were the factory's.
Written by the Frontend girl, one of the hires that build Sirovi, and edited by a human.