The Code Factory is our own AI-native engineering platform. A team of specialist agents plans, builds, tests and reviews software on a git backbone. Every change is fenced, logged and independently reviewed, and an engineer approves the plan and the release.
Every job runs in the Studio, our control room for the Code Factory. A lead agent splits the work and hands each piece to the right specialist. Reviewers check what was delivered, and the job waits for a person before anything ships.
Click through the views to see what our engineers see.
reminders/send.py line 48log.info(f"sent to {customer.email}")Illustrative screens, based on the Studio · example job and figures
General-purpose agents drift. Ours are built for specific jobs, each with its own instructions, tools, permissions and step limits. Builders and reviewers are kept strictly apart.
Gets oriented, splits the problem and delegates each piece to the best agent. It has the results reviewed and sends fixes back if needed. It doesn't write code itself.
Turns the brief into requirements with acceptance criteria, so every test has something to trace back to.
The builder. It works on its own branch, within the permissions set for the job, and can delegate or hand off to a better-suited teammate.
Writes tests in the project's existing style, including real-browser checks for anything a user will click.
Reads only the delivered code, cold. It needs a file, a line and quoted evidence for every finding.
Checks correctness, error handling, test coverage and maintainability, alongside a deterministic quality and security scan.
Triages any job that fails while running unattended, works out why, and queues it for a person to decide.
Produces consultant-grade documentation alongside the code, covering architecture, runbooks and handover notes.
Every job follows the same AI-native delivery lifecycle. The agents do the volume, and the gates in green are where a person decides.
Every job starts on its own git branch, with commits as it goes. Whole jobs can be reviewed or reverted in one step.
The analyst writes requirements and acceptance criteria, and the lead proposes a plan. Nothing is built until the plan is approved.
Builders and test writers work in parallel lanes. The checks live in the repository, including real browser tests, so they run the same way every time.
Reviewers inspect the pull request cold. Low-risk changes move on, and anything higher-risk is routed to an engineer.
Continuous integration runs every check. Failures go back to a builder for a fix, but only a set number of times before a person is called in.
Releases go to staging automatically and are security-gated. Promotion to production is manual, with rollback ready and the live system monitored.
A reviewer that knows what the builder meant to do tends to see what it expects. Ours sees only what was delivered: the changed files and the diff. It can read the rest of the repository to judge whether something is exploitable, but it can't change a thing.
Each finding records its severity, file, line, quoted evidence, impact, recommended fix, compliance references and the reviewer's confidence. That gives you an audit trail you can hand straight to a security questionnaire.
For a more independent second opinion, the reviewer can run on a different model from the builder.
Agents left to themselves will keep finding more to do. We learned that on real projects, and built the Code Factory to stop it.
Agents work to the literal scope of the job. Anything else they notice is logged as a follow-up for a person to prioritise, not acted on.
Agents that loop, re-read the same files or stop making progress are halted and flagged, rather than left to burn time and tokens.
Every job and every shift has a token and spend cap. Circuit breakers pause the line when something is wrong.
Delegated agents inherit the stricter of the caller's and callee's permissions. Delegation is capped in depth and count, and reviewers can't delegate at all.
Work items are accepted only from trusted authors, and their text is fenced against prompt injection before any agent reads it.
Jobs can be locked to a single model, so no agent quietly switches to a more expensive one on its own.
An agent that's finished the task should stop. Every guardrail on this page started as a real problem on a real project, found and fixed by our own engineers.
The Code Factory works with frontier models, local models and private endpoints. We pick per role: a strong model to lead, a different one to verify, and smaller, cheaper ones where they do the job just as well. Prompt caching keeps repeated work cheap.
The factory can run unattended, working through approved jobs in parallel lanes within a budget cap. People make the calls that matter in the morning.
Plans approved, budget cap set, lanes chosen.
Separate lanes, each on its own branch, with reviews and CI on every change.
Failed jobs are diagnosed and parked, not forced through.
Morning report reviewed, findings decided, staging checked, and production promoted by hand.
No. Releases go to staging automatically after passing security gates, but promotion to production is always done by an engineer.
A security and compliance reviewer that sees only the delivered code, never the brief; a code quality reviewer; deterministic scanners; and an engineer, who approves every merge.
Agents are fenced to the literal task, stopped if they stop making progress, held to token and spend caps, and can be locked to a single model. Anything extra they notice is logged for a person to prioritise.
No. We only use AI services on business terms that exclude training on your data, or models we host ourselves.
The Code Factory is how a small, senior team delivers production-grade AI systems on an SME budget. It sits alongside our Data Factory inside every Build engagement.