We call our delivery workflow the AI Dark Factory. AI agents write, test and review code in parallel. People decide anything that carries risk.
This post explains how it works. It is how we work today. The workflow was first written down for one product line, and its shared steps are now used across our projects. We do not claim that every change made before it existed went through every stage.
Why we call it a dark factory
In manufacturing, a dark factory is a plant automated enough to run with the lights off. We use the name for the level of automation. People still run the line.
Agents do the repetitive work that can be checked: reading code, writing tests, building and reviewing. People keep the decisions that carry risk: what gets built, what merges when anything is uncertain, and anything involving credentials, money or customer data.
The name is a little provocative on purpose. It makes people ask the right question: who is watching? The rest of this post is the answer.
The line
Every change moves through the same twelve stages, grouped in five zones: plan, build, prove, ship and close. A change that fails a check goes back to the build. A failed live check opens a revert right away. Lessons from each run go back into shared field notes, so the next run does not repeat the same mistake.
Twelve stages and a merge gate
Every change moves through the same line. A change that fails a check goes back to the build.
-
Plan
-
Build
-
Prove
-
Ship
- Merge gate: rules plus a person when anything is uncertain.
People handle credentials, approvals and money.
-
Close
- Findings go back to the build
- Failed live check: revert opened right away
- Lessons go back into the field notes
- AI agent step
- Human decision
- Pass/fail gate
What happens at each stage
-
Ticket first
Bugs, features and follow-ups each get a written issue. Before work starts, related issues and pull requests are found and folded in, and anything missing is filed. Every line of code traces back to a request someone can read.
-
Field notes
Agents read a shared log of lessons from earlier work: build quirks, deployment surprises, approaches that failed. They also check for work in progress so two efforts don't collide.
-
Design and security questions
Scout agents read the code, the issues and the product plans, and two or three design options are drafted and critiqued. Each design answers four questions up front: who may call this, whose records it reads or writes, which identity it trusts, and what data leaves the system.
-
Tests written first
A separate agent that sees only the issue writes failing acceptance tests. The builder cannot change them; if one changes, the reason has to be stated and accepted in review.
-
Parallel build
Several agents build at once, each in its own isolated copy of the code and database. Anything new that runs gets at least one test that drives the real entry point and checks what a user would see.
-
Honest evaluations
When a feature ranks, picks or writes content, it is scored against a stated bar (an evaluation). Test data is split, and the held-back set, examples kept aside until the end, is used once for the final number. Results are compared across several runs.
-
Adversarial check
On sensitive paths such as sign-in, permissions, customer separation or anything that sends data out, a fresh agent gets only the change and the issue and tries to break it. Every real break is fixed, and its test stays in the suite.
-
Independent review
Each change is reviewed for correctness, security and customer isolation, test quality, user experience and fit with existing code. Findings are verified before they count, and fixes go to a fresh agent.
-
Green build
A green build means every automated check passed: type checks, lint, formatting, the build and the tests, run on the latest version of the code. The workflow also calls for a nightly full run that opens an issue when it fails.
-
Gated merge
A change merges only when review approved it, every verified finding is fixed, the build is green, and the change adds no risky database or infrastructure changes. If anything is uncertain, a person decides. Deployments happen only through an approved merge.
-
Live verification
After the merge, we confirm the new build is the one running and check the feature on a live test environment. If the live check fails, a revert is opened right away.
-
Changelog, docs and report
Every change a user could notice gets a changelog entry that starts with one plain sentence. Help pages are updated, temporary environments are removed, and a one-page report lists what was built, honest results and anything that needs a person.
Three stages worth a closer look
Tests written by someone else
The acceptance tests for a change are written before the code, by a separate agent that sees only the written issue. It does not see the design or the code. The agent that builds the change cannot edit those tests. If one changes anyway, the reason has to be stated and accepted in review.
This rule catches more problems than any other. An AI model is very good at writing code that looks right. A test written from the request, by someone who never saw the code, is how we find out whether it is right.
The adversarial check
On sensitive paths, such as sign-in, permissions, separation between customers, or anything that sends data out, a fresh agent gets the change and the issue and tries to break it. It never sees the builder’s reasoning. Its job is to leave failing tests, not opinions. Every real break is fixed, and its test stays in the suite.
This runs on sensitive changes, not on every change. A typo fix in a help page does not need an attacker.
The merge gate
A change merges only when all of these hold: the review approved it and every verified finding is fixed, the build is green on the latest code, and the change cannot break the running environment. That last condition means no deploy in progress, no new cloud resource or secret, and database changes that only add.
If any condition is unsure, the agent opens the pull request, asks a person and moves on to other work. Deploys happen only through an approved merge.
The rules the factory runs on
- Measure, don’t claim. Numbers come from real runs. If a target was missed, the report says so.
- Tested beats fast. Speed comes from automation. Every step still runs.
- People own credentials, approvals and money. Agents never handle passwords, approve access, create cloud resources or change billing.
- Security by default. Every change states who can call it, whose data it touches and what leaves the system.
- Escaped bugs get traced. When a bug reaches users, we find the check that should have caught it, and add it.
What this means for our customers
- Faster delivery without skipping review. Agents work in parallel. Every change still goes through tests and an independent review, and sensitive changes also get an adversarial check.
- Every change is traceable. Issue, tests, review, build, changelog. You can always ask what changed and why, and get a real answer.
- People approve what matters. Your data, your credentials and your money never depend on an unsupervised agent.
- Fewer surprises after an update. Tests are written before the code, sensitive changes are attacked before release, and the live build is checked after the merge.
- Updates in plain language. Each changelog entry opens with what you can now do, in words a customer reads.
If you want this way of working on your own codebase, our services page explains how we help development teams set it up.