One process for every AI change.
The DayStorm Factory takes a short description of a change and returns a pull request with evidence. Every spec takes the same stations in the same order. It runs in your infrastructure, on your repos, under your merge rules.
From idea to proven pull request.
Autonomous until it matters: you decide what merges.
- 1
Describe.
In your terminal, in a visual workspace, or simply by voice. A few sentences are enough, the spec is drafted for you.
- 2
Sharpen.
The spec is checked against your codebase before a line is written. Unclear? The DayStorm Factory asks instead of guessing.
- 3
Build.
Gate after gate, on every spec. Whatever fails goes back to the build, gets fixed and runs through again.
- Tests first
- Unit
- End-to-end
- Regression
- Visual
- Security
- Senior review
- 4
Prove.
A pull request with evidence for every acceptance criterion. You merge, or your rules do.
Station by station. Checks inside every one.
These are the main stations. Inside each one run checks of their own, from a precision check on the spec to repeated test runs that tell a real failure from a flaky one. Each acceptance criterion travels as its own lane. Whatever a station holds goes back to the build with the reason, is fixed there and runs through the checks again. Nothing passes on a guess.
spec
The spec is checked for precision and grounded in your codebase. Each acceptance criterion becomes a lane of its own.
tdd
Tests for every criterion are written first. They have to fail before any code exists.
build
The code is written until those tests pass.
tests
Unit, end-to-end and regression tests run. A red test is run again to tell a real break from a flaky test.
visual
For changes with an interface, the result is reviewed on screen against what the spec asks for.
security
The change is assessed for security issues before anyone reviews it.
senior review
A separate AI reviewer, not the builder. It reviews the whole change against the spec and can send it back.
finalisation
The pull request is assembled: evidence for every criterion, test results, duration and model cost.
Stations are configured per repo. End-to-end and visual review run where a project has an interface.
You set the merge rule. Repo by repo.
Every pull request arrives with its evidence. What happens next is your call.
by hand
Your team merges
A developer reviews the evidence and merges. The Factory never writes to your main branch.
automatic
The evidence merges
When every gate is green, the Factory merges on its own, through a normal merge that your branch protection can still refuse. If anything is not green, nothing merges by itself.
Your choice for each repo. Either way, the history shows who merged and the evidence behind it.
Questions instead of guesses.
When intent is unclear, the DayStorm Factory does not fill the gap with a plausible guess. How readily it asks is a setting: per repo, and for a single spec if you want.
- Autonomous asks only when intent is missing or contradicts itself, or when a choice could not be undone.
- Guarded also asks about the hard cases.
- Supervised asks about every open point.
Whatever it does not ask, it records as an assumption with its reason. Questions arrive as a draft pull request, and the answer goes there too, so every decision stays traceable in your git history.
The Control Room.
Every factory comes with a Control Room on your own machine. It shows each build live, station by station, with its history, duration and cost. A company view brings several factories together.
It measures specs and builds, never people. The Factory works under its own technical identity.
What it doesn't do.
Clear lines, by design.
- It does not decide what to build. You do.
- It does not merge on its own unless you switch that on for a repo.
- It does not replace your CI/CD. It ends at the pull request, and your pipeline takes over.
What you need.
You provide
- A Linux machine or VM with Docker, running 24/7. On a Mac, a Linux VM works.
- At least 8 GB of memory for each factory.
- A git token for the repos it builds.
- Model access of your own: the Anthropic API or AWS Bedrock.
You get
- The DayStorm Factory, its Control Room and a company collector, as signed containers.
- Signed updates. The Factory tells you about them, you decide when they go in.
- Documentation for your risk assessment: data flows and the full field list.
How an engagement starts.
A scoped engagement on one of your repos. Real code from day one, nothing to migrate first.
- 1
Pick.
Together we pick one real repo and a handful of real changes your team wants anyway.
- 2
Install.
The DayStorm Factory goes into your infrastructure, with your model access and your merge rules.
- 3
Build.
It builds those changes. Your team reviews the pull requests and the evidence behind them.
- 4
Decide.
You decide whether it scales: more repos, more teams, more factories.
Questions engineering leads ask.
Why not just give everyone a coding agent?
Your developers keep their coding agents. The DayStorm Factory runs Claude Code as its engine too, but what it writes is not the answer to a single prompt. Every build starts from a spec sharpened against your codebase, and the builder knows the gates ahead of it: tests written first, unit, end-to-end and regression runs, a security assessment and an independent senior review. It writes for those checks from the first line, and whatever fails comes back with the reason.
And it learns. What earlier builds in your repo taught it, about your conventions, your tests and the fixes that worked, goes into the next build.
In a terminal, all of that depends on who sits at the keyboard and how their day is going. In the Factory, it is the path every change takes. Terminal to explore. Factory to ship.
Does our code leave our infrastructure?
Your code goes to two places only: your git host and your model provider, through access you control. DayStorm has no access to your machines.
What reaches DayStorm is pseudonymous operating data per build: times, status, station durations, cost. No code, no spec text, no repository names, nothing about your developers. The full field list is on the Trust page, ready for your risk assessment and your works council.
Which model runs, and who pays for it?
Claude, through your own access: the Anthropic API or AWS Bedrock. Model costs go straight to your provider, with no markup from us. Every pull request shows what its build cost.
Who merges, and what about our CI and branch protection?
You decide, per repo: a person on your team merges, or the Factory merges once every check is green.
The Factory works through ordinary pull requests from its own branches. Your CI runs on them like on any pull request, and branch protection stays in force. With automatic merging on, it merges only when every check is green, through a normal merge your branch protection can still refuse. Never with an admin override.
Does it work on our existing code, including a monorepo?
Yes, change by change, without a rewrite. The Factory makes no architecture decisions of its own. It builds on our own products in production and on public open-source code bases.
A monorepo works as one repo. Check and test commands are set per repo, so they run what your monorepo needs, for example a pnpm workspace.
We already use Claude Code with our own CLAUDE.md and harness.
Good. The agents of the Factory read the CLAUDE.md and the checked-in Claude Code settings of your repo, so your conventions apply to every build. Inside the Factory, a build runs only steps the Factory controls.
Your harness feeds the Factory, it does not compete with it. Specs from your own requirements or spec workflow go in as input. On your developers' machines, nothing changes.
Which stacks does it build?
TypeScript and JavaScript, Java with Maven or Gradle, and PHP with Composer, each with its own build profile. Another stack? Talk to us.
What if we switch it off?
Everything stays: your repos, your PRs, your specs. It is ordinary code with ordinary history. What stops is the engine and its updates.
How is it priced?
Every engagement starts with a scoped pilot on one of your real repositories. We agree on scope and pricing together before anything is installed, so there are no surprises.