Human-executed
People do every step. AI, if it’s there at all, is autocomplete in the editor.
Where most teams start: people at every station and a single code review before release.
Output: a few tasks per engineer per day.
The impact
This is where the six stages lead: an SDLC that runs as a line of dark micro-factories, with your people at the sides, shaping intent, deciding what ships and watching the signals.
Most teams move through the same four eras. Each one builds on the last, and the work is knowing which one you’re in and what the next step needs.
You may have seen AI coding described as a ladder of autonomy, ending in a “dark factory” where code ships with nobody reviewing it. For most businesses, and every regulated one, we aim somewhere more useful: many small dark micro-factories, each bounded by rules and guardrails, with people at the seams.
People do every step. AI, if it’s there at all, is autocomplete in the editor.
Where most teams start: people at every station and a single code review before release.
Output: a few tasks per engineer per day.
People still drive every step, with agents helping. Output rises, and so does the review queue.
New: an agent working beside every person, the first rules taking shape, and more checkpoints.
Agents do most of the work. People direct every station and red-pen every change, so review becomes the bottleneck.
New: dark micro-factories at every station and written rules. Every change still waits at a checkpoint.
The line runs as dark micro-factories. People sit at the seams: shaping intent, agreeing scope, deciding what ships and watching the signals.
New: guardrails, collaboration before Plan and before Build, one review before release, and live signals.
Output: a few features per engineer per day.
Zoom into Build. It runs with the lights off because everything it needs to behave well is written down and enforced.
An agreed spec and the scenarios it must satisfy.
Conventions, architecture and a definition of done it must follow.
A sandbox, scoped permissions, protected paths and a spend limit.
Tests and automated review at the gate; exceptions go to the red pen.
What it did, what it cost and what failed, visible to the people who care.
One named person who tunes it and can switch it off.
From writing every line to designing micro-factories and reviewing the exceptions.
From writing tickets to shaping intent and agreeing scope.
From testing by hand to designing the scenarios every micro-factory must pass.
From status meetings to watching signals and tuning governance.
The same pattern works wherever work is repeatable, starts from documents and data you already have, and has a clear point where a person should check before anything goes out. Three natural places to start:
A micro-factory turns your handbook, policies and role guides into a tailored onboarding plan, practice exercises and answers for each new starter.
A micro-factory drafts replies to user queries from your help centre, product docs and resolved tickets, and routes anything unusual straight to a person.
A micro-factory gathers figures from the systems you already use and drafts the regular report, with every number traceable to its source.
Each one runs on the same rules, guardrails, checkpoints and named owner as the micro-factories in your delivery line. We usually start where the proof is, in engineering, and widen from there.
Thirty minutes to talk through where your team is today, what’s slowing it down, and whether we’re the right people to help. If we’re not, we’ll say so.