From issue to pull request, with you at two points.
Label an issue
The factory reads the issue, the code and your product claims, asks you 3 to 5 questions and writes the acceptance criteria that define done: spec-driven development, built in. Then it stops and waits.
Answer the questions
Your answers change what gets built. A wrong reading caught here costs a comment, not a pull request.
Agents build and check
One agent writes the code in a draft pull request. A second reviews it on every push. A third, which didn't write it, tries to break it.
You read and merge
You read the diff, the tests and the criteria. The factory never merges; a person on your team does.
Checks that run before a person looks.
Review against the criteria
Each push is judged against the agreed acceptance criteria and your review rules. The reviewer names what it checked and what it deferred.
Adversarial audit
When a pull request is ready, a separate agent tries to disprove that the criteria are met, and ranks what it finds with a failure scenario for each.
Product claim checks
Your product's key promises are written as checkable claims. Every pull request shows which still hold, and how much of the product is checked at all.
CI fix
A red build on a factory branch gets one fix attempt. If that fails, you get one clear question, not a loop.
Review replies
Comment on a factory pull request and it fixes the real problems, pushes back with reasons on the rest, and asks you about product decisions. Capped at two rounds.
Small, safe work while you sleep.
Each loop earns only as much freedom as its checks can prove. Scheduled loops open draft pull requests, reports or proposals. None of them merges.
Nightly tidy
One small clean-up pull request a night, or a note that nothing was safe to change.
Weekly health report
What the factory tried and kept, its revert rate, cost per kept change, questions asked twice and runs left unfinished.
Proposed team rules
When the same question keeps coming up, the factory proposes a standing rule for your team. You decide what goes into your AGENTS.md.
Two loops that meet at your eval run.
One loop grows what "good" means: real failures that no eval covers yet become new eval cases. The other improves code until those evals pass. Improve code without growing evals and you drift into failures nobody measures; grow evals without fixing code and the gates stay red. Both loops switch on when your repo has an eval suite or a metric, and we help you add one.
Keep-or-revert improvements
An agent tries one change a night toward a metric, such as speed or bundle size. Code measures before and after and keeps the change only if the number improves and every guard passes.
Eval gate
Your eval suite runs on every pull request and fails the check below the score you set. No model grades its own work.
Eval growth
The factory finds failures your evals don't cover yet and reports them as candidate test cases for your team to add.
Every agent job runs in a throwaway sandbox.
Agents do their work inside isolated sandboxes that we run for you. Five independent layers keep them to pull-request branches, and none of those layers trusts the model.
A fresh sandbox per job
Each job starts in a new sandbox, with the same kind of kernel isolation Google Cloud Run uses. It is deleted when the job ends, so nothing carries over.
Short-lived, limited access
Each run gets its own GitHub access that can only write branches and pull requests. It can't change branch protection or workflows, and it expires with the job.
A push guard
Before anything leaves the sandbox, a guard refuses pushes to your main and release branches.
Rules agents can't rewrite
The same guard blocks edits to the files agents are judged by: your AGENTS.md, the workflows and the factory's own controls. An agent can't loosen that list from its own branch.
Restricted network
Outbound network access from the sandbox is restricted, so an agent has fewer ways to send data anywhere it shouldn't.
Every change traces back to a decision.
Supervised AI coding agents, built to be trusted.
What it takes to start.
Software teams with more backlog than engineers.
Before you ask.
What is an AI code factory?
A set of AI coding agents wired into your GitHub repo. They take labelled issues through framing, coding, review, audit and testing, and open pull requests. People decide what merges.
Does the factory merge code on its own?
No. It opens and updates pull requests, and its audit agent can approve one, but a person on your team always merges.
What happens when an agent gets stuck?
It stops. Every run has turn and time limits, and fix attempts are capped. When a limit is reached, the factory asks one question instead of trying again.
Which AI models does it use?
Claude, through Claude Code's GitHub Action. Only models on an approved list can be configured, and we set turn and time limits for each stage.
Where do the agents run?
In isolated sandboxes we run for you. Each job gets a fresh one that is deleted when it ends, with short-lived access that can only open and update pull-request branches. You don't manage any servers.
What do we need to start?
A GitHub repo, a test command, the Claude GitHub App and an Anthropic API key. We handle the workflows, labels and branch protection.
What does it cost?
The factory is set up and run within your advisory hours, from $3,500 a month. Model usage bills to your own Anthropic account, so you see every dollar.
Get your free AI audit.
Twenty minutes, and we are honest about where AI helps your business and where it doesn't. If there's nothing worth building yet, we'll tell you.