Preview · Full plan released under NDA
Preview — Page 02

The Approach

Where the work starts, the pipeline we would move to, and the order the stages run in

Where We Start

We measure first, then build

Stage 0 — the baseline
Your last 20 changes real, completed work Elapsed time, split seven ways Specification ? Working out what to touch ? Coding ? Testing ? Review ? Regression ? Release ? proportions measured, never assumed The baseline Agreed in writing, by both sides, before Stage 1 begins every later claim is compared to it
The measured split decides which agents get built first

The Order We Build In

Each step depends on the one before it

Audit, clear, write down, then build
STEP 1 · STAGE 0 Audit the code structure and conventions STEP 2 · STAGE 0 Clear what blocks only what stops agents working STEP 3 · STAGE 1 Write the context down conventions, glossary, docs STEP 4 · STAGE 2 Build the agents grounded in steps 1 to 3 Everything else is written up as a backlog, not fixed now it gets paid down later, with the fleet, once there is test coverage underneath it
Agents copy whatever quality level they find. That is why the audit comes first.

Why step 2 is deliberately narrow

We fix what stops agents working reliably in an area, and nothing more. The rest of the technical debt is real, and it gets written up and handed back to you as a backlog rather than pulled into the critical path. It is cheaper to work through afterwards anyway, once the agents exist and there is coverage to catch what a change breaks.

The Target Pipeline

An agent at each step. A named person at each gate.

Requirement to UAT-ready
Blue = agent work · Teal = human gate · Red = permanently off limits
1
Spec
The incoming requirement becomes a structured spec with acceptance criteria
✓
Product Owner
Scope and acceptance criteria confirmed before work starts
2
Design & change map
What gets touched, across code, UI and the data layer
✓
Tech Lead
Design and API contract approved
3
Build & self-review
Drafted on a branch, then checked against your standards before a person sees it
✓
Developer
Reads it, changes it, commits it under their own name
4
Test
Cases per acceptance criterion, with additional checks in restricted areas
✓
QA + named owner
QA validates. A named owner signs anything in a restricted area
5
Release pack
What changed, what to test, how to roll back — deployed to your UAT
✓
UAT sign-off
Signed off by a named person
✗
No auto-deploy
No agent deploys, merges to protected branches, or runs DDL

Behind each step sits a purpose-built agent. There is a set of them covering the services, the UI and the data layer, each with one job, one output, and one named person who approves that output. The full plan lists every agent, what it reads, what it produces, who signs it off, and the limits on what it may do unattended.

Governance

Three things we would put in place beyond a standard AI policy

⚖

Restricted areas

  • You decide which modules are restricted, and that list can change at any time
  • Agents may draft there, but merging needs a named owner's signature and a mandatory equivalence check against frozen reference data
  • You can mark any module generation-prohibited, at any time
  • Every AI-assisted commit is tagged, so its origin can be audited
🔒

Data handling

  • No production data in agent context at any point
  • Schema only. No production database access
  • Test data is synthetic, never an extract of live data
  • Read-only credentials for every agent
📋

Audit and override

  • Every agent run logged — prompt, input, output, timestamp
  • Retention period agreed jointly
  • A switch that disables any agent immediately, tested periodically
  • No deploy, DDL or protected-branch merge rights for any agent

Seven Stages, Fourteen Weeks

Stages overlap, because a small team cannot dedicate itself to one stage at a time

W1–2W3–4W5–6W7–8 W9–10W11–12W13–14
S0 — Foundation
W1–3
S1 — Knowledge Base
W2–5
S2 — Safety Net
W4–8
S3 — Pilot
W7–11
S4 — Measure & Refine
W10–12
S5 — Rollout
W11–14
S6 — Continuous
W13+
STAGE 0
Foundation
Weeks 1–3
STAGE 1
Knowledge Base
Weeks 2–5
STAGE 2
Safety Net
Weeks 4–8
STAGE 3
Pilot
Weeks 7–11
STAGE 4
Measure & Refine
Weeks 10–12
STAGE 5
Rollout
Weeks 11–14
STAGE 6
Continuous
Week 13 on

What each stage contains

In the full plan each stage has its own section: the work inside it, what has to come out of it, the gate that must be passed before the next stage starts, and what happens if that gate fails. Stage 4 is a decision point. If the numbers have not moved against the baseline, we report that and change the approach rather than scale it up.

Duration depends on team size

Fourteen weeks assumes one squad working on the pilot. A smaller team stretches the stages; several squads compress the rollout. The sequence holds either way, and the actual schedule would be agreed with you once the team shape is known.