Engineer-led delivery with AI-powered code review on every change
Our engineers build to a plan, one verifiable step at a time. Every change then goes through an AI-powered review that reads it cold and tries to break it, and a quality gate that checks the numbers, before a person merges it.
At a glance
- 200+
ledger entries recording shipped work
- 7
metered build lanes
- 2
fix rounds before a person steps in
- 2
days from approved plan to live, on one build
The challenge
Fast delivery and careful delivery usually pull against each other. Reviews get rushed at the end of a sprint, tests pile up without proving anything, and done means someone believes it's done.
We wanted every change checked independently, every single time, without slowing our engineers down, and with design decisions and production firmly in human hands.
Architecture
Swipe to explore the diagram
Nobody grades their own work. The quality gate checks the numbers, the AI-powered review checks the behaviour, and a person merges and deploys.
What we built
Roles
- A technical lead who plans the work, dispatches it and runs the quality gate
- Engineers who implement one step at a time, inside the paths that step declares
- An AI-powered reviewer that reads every diff cold against the step, probes each invariant and writes a report, never code
The quality gate
- A 329-line Python gate that runs the suite and lint once and checks the change stayed in scope
- The test-to-code ratio held to a budget per lane, with one tagged test per invariant
- Tests that read source code as text are rejected as defects
The process
- Plans in a fixed step form: dependencies, goal, paths, at most five invariants and a verify command
- A small process core shared byte-for-byte across repositories and capped at 300 lines
- One pull request per step, carrying the gate's output and the review's invariant table
Engineering decisions
Done means a command and its output
Nobody's word finishes a step, human or machine. It's done when the verify command has run and its output matches what the step requires.
The step is the spec
Scope never widens in the middle of a change. A design question becomes an explicit decision for a person, and the plan only changes by amendment.
Review that can't be talked round
The reviewer sees the diff and the step, not the author's explanation, so it judges what was built rather than what was meant.
Production stays attended
Reviews probe a local test rig only, never live systems or production data, and every deploy waits for a person.
Outcome
Several production applications have been delivered this way, each step with its own audit trail. One build went from approved plan to live in two days.