The factory.
A software factory is the system around coding agents that turns written requirements into software you can trust. It builds, checks every change, refuses what fails, releases safely, and learns from every miss. Ours has five stations and a loop.
In the 30 days to November 4, 2026, we closed 703 issues and merged 825 pull requests across 26 repositories, and 2,560 CI runs checked them. 276 runs failed, and the work went back to be fixed.
Every day’s numbers
| Day | Issues closed | Pull requests merged | CI runs | CI runs that failed |
|---|---|---|---|---|
| Oct 6 | 24 | 32 | 59 | 4 |
| Oct 7 | 3 | 21 | 34 | 0 |
| Oct 8 | 7 | 69 | 218 | 14 |
| Oct 9 | 53 | 89 | 353 | 30 |
| Oct 10 | 54 | 40 | 198 | 19 |
| Oct 11 | 61 | 43 | 178 | 9 |
| Oct 12 | 9 | 21 | 64 | 4 |
| Oct 13 | 7 | 15 | 40 | 2 |
| Oct 14 | 24 | 42 | 169 | 23 |
| Oct 15 | 75 | 76 | 39 | 5 |
| Oct 16 | 26 | 31 | 15 | 0 |
| Oct 17 | 27 | 5 | 15 | 1 |
| Oct 18 | 9 | 18 | 43 | 3 |
| Oct 19 | 5 | 36 | 64 | 4 |
| Oct 20 | 12 | 18 | 85 | 32 |
| Oct 21 | 42 | 19 | 88 | 8 |
| Oct 22 | 3 | 18 | 78 | 15 |
| Oct 23 | 10 | 25 | 96 | 18 |
| Oct 24 | 2 | 13 | 52 | 8 |
| Oct 25 | 6 | 21 | 28 | 2 |
| Oct 26 | 47 | 29 | 104 | 11 |
| Oct 27 | 39 | 25 | 86 | 5 |
| Oct 28 | 15 | 16 | 63 | 2 |
| Oct 29 | 27 | 14 | 45 | 4 |
| Oct 30 | 11 | 16 | 49 | 7 |
| Oct 31 | 6 | 10 | 24 | 0 |
| Nov 1 | 15 | 5 | 11 | 2 |
| Nov 2 | 31 | 18 | 90 | 15 |
| Nov 3 | 26 | 16 | 64 | 7 |
| Nov 4 | 27 | 24 | 108 | 22 |
| Total | 703 | 825 | 2,560 | 276 |
Requirements
What should exist, written down: the spec, the scenarios it has to pass, the edge cases, and the rules it must follow on privacy, compliance and accessibility.
Who decides People. This is the most senior work in the factory, and you are in the room for it.
What it is made of
- Specs with acceptance scenarios, written before anything is built
- Operating manuals for agents (AGENTS.md, CLAUDE.md), rules and skills, kept short
- A codebase laid out so the right context sits next to the work
Build
Many agents work at once, each in its own isolated copy of the code. They get the tools they need and never hold a password or a key.
Who decides Agents, inside limits we set.
What it is made of
- Agent hosts and one worktree, with its own running stack, per change
- Secrets brokered by a vault: the agent calls a tool that holds the key
- Module boundaries that let parallel changes merge cleanly
Checks
Every change is tested: fast tests, end-to-end runs against a real stack, scenarios kept where the agents cannot see them, review agents, and security and accessibility scans.
Who decides The checks. Most teams skip this station, and we build it first.
What it is made of
- One command that runs the same checks on a laptop and in CI
- Holdout scenarios the agents never see, so they cannot be gamed
- Review agents with narrow briefs, sized for hundreds of changes a week
Gate
What passes goes through. What fails goes back to its agent with the reason. Changes that touch money, data or permissions, or that the checks cannot settle, wait for a person.
Who decides Policy, and a person where it counts.
What it is made of
- Merge rules written down, so the gate decides the same way every time
- A person called in when a change needs judgment
- Every decision recorded, with its reason
Release
It ships in stages, proves which version is live, rolls back in one step, and is watched once it runs.
Who decides The pipeline, with people alerted when it matters.
What it is made of
- Deploys that verify themselves and roll back in one step
- Progressive delivery and environments that match production
- Observability that agents and people can both read
The loop
Every miss becomes a fix in the factory. A bug a check should have caught becomes a new check; a question an agent should not have had to ask becomes a new guide. The next build starts from there.
Mitchell Hashimoto calls this engineering the harness: every mistake an agent makes becomes a change to its environment, so it cannot make it again. It is why the factory gets better with each build, and why we want real problems to build.
Lights on
Every change is visible, every decision is recorded with its reason, and any of it can be rolled back. A person can walk the floor at any time and see what is happening and why.
Nobody has to approve every change for that to hold. Reading every change is the bottleneck agents were meant to remove, so the gate is a policy, and it calls a person in where judgment matters. Birgitta Böckeler puts the aim of a harness the same way: not to remove human input, but “to direct it to where our input is most important” (Harness engineering for coding agent users). Some call the end state a “dark factory”, where no person reviews the code (StrongDM’s factory is one). Ours keeps the lights on.
How we count
Startly, Rhystic Collect and Grain Smith each went from first spec to a usable product in under a week.
The count at the top of this page was taken on November 5, 2026 from both forges we work in, GitHub and our own, for every repository with work in the window. We often group several related issues into one pull request, which is one of the ways the factory keeps moving, so the two counts do not match one to one; some projects merge work without filing an issue at all. On GitHub we count issues closed as completed, and on our own forge every closed issue. Merged pull requests miss commits pushed straight to a branch, CI runs include deploys as well as checks, and a failed run is sometimes a flaky test rather than a defect. We recount every month.
We run it every day.
We are a small group of engineers who share one working space and one factory. We try a method on our own products, compare notes on what held up, and only then take it to a client.
Our own factory
- Agent hosts, so many agents work in parallel, one worktree per change
- Heka Vault, so agents and pipelines get scoped keys and credentials stay out of context windows
- Every change a gated pull request, on GitHub and on our own forge and CI
- A notification channel per project for builds, deploys and failures
Our own products go first
Rhystic Gaming, Grain Smith, Ghost and this site are where we try a method first. If it breaks, it breaks on our own work.
We learn in the open
What we learn goes into our writing, and some of the tools are public on GitHub. Agents maintain this site through the same factory: every change is a pull request through a CI gate, and a person reviews every post an agent drafts.
Want one of your own? We teach it.
Tell us what should exist.
Bring us something you want built, or something painful you want gone. Talk to our agent now, or email us and an engineer answers.
A voice call with our AI agent. Email us instead