How we build
AI agents do the work. People own the decisions.
We call our delivery workflow the AI Dark Factory: agents write, test and review code in parallel, and people decide anything that carries risk.
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, and anything involving credentials, money or customer data.
Twelve stages and a merge gate
Today, 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. A full suite runs nightly, and a failure opens an issue automatically.
-
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.
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
Ticket, 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.
Want this workflow on your own codebase?
We help development teams set up the same practices: written issues, tests first, independent review and gated merges, with AI agents doing the repetitive work.