One requirement through our AI lifecycle needed 12 manual interventions

The short version

Any process looks good on a slide. The test is to push one real requirement through all of it and count how often a person had to step in. We did that on 22 October 2026, through the lifecycle we redesigned earlier the same month. It needed 12. Six were defects in our own factory and are fixed. Four are still open as we write. Two were human gates doing what they were built to do.

This note is the account of that run, with the table left in. The reasoning and the practices that came out of it are in the full edition of the AI SDLC Playbook.

The requirement

"An architecture description can be checked for citations by one factory command." It was a real gap, found that same day: a pilot for another product had needed a hand-written citation check. Small enough to finish, real enough to matter.

What went through

• Intake: submitted to the live work-record service, which queued an analysis job.
• Analysis: a background analyst produced two stories and chose the brownfield track.
• Approval: an epic and a draft specification, created against a branch working copy.
• Specification: the product owner accepted it. A person, by design.
• Readiness gate: seven mechanical checks, run for both stories before either went into progress. Both passed once the specification was accepted. Until then the gate refused them.
• Build: the orchestrator, with a 150-turn budget. One story took 22 turns. The other stopped once, asking for a technical-lead decision it should not make alone, then finished in 17 turns.
• Review: the technical lead ran the tests and live checks, including a bad-input refusal on a copy of the pack.
• Landing: one command. The epic closed with its retrospective.

The interventions, grouped

Of the twelve, a person did these because the process could not:

• Accept the specification (a human gate, by design).
• Record the decision a build had stopped to ask for (a technical-lead decision, by design).

And these because the process should have done them itself. Six are fixed:

• Re-running the analysis: the background job had kept a 728-character summary instead of the 14,774-character answer.
• Re-routing both stories to the right owner before approval.
• Discarding the first approval, whose stories took a fallback path and lost their routing.
• Withdrawing two tickets filed as the wrong type and refiling them as stories.
• Binding the build working copies before landing.
• A help flag on the id allocator that allocated an id.

Four are open:

• Restarting a long-running service: it had been running nine-day-old code, so a recent change never took effect, and nothing restarts such processes after a merge.
• Approving with the right epic mode: the approve call takes it only from configuration, and a per-approval choice is the product owner's to make.
• Recording the specification's ticket list: the approval's bookkeeping did not land, and the cause is not isolated.
• Setting aside a stray draft whose specification id collided with this one's, because ids are taken from the working tree.

What it does and does not show

It shows that a requirement can travel intake, analysis, epic, readiness, build, review, landing and epic close with every gate firing where it was designed to. The readiness gate refused both stories until the specification was accepted. The build refused to guess a decision that belonged to the technical lead and stopped to ask.

It does not show the same path without a person watching. Until the four open items close, "autonomous" would be the wrong word, and we do not use it.

The thing worth taking away

At least five of the twelve were the same kind of fault: state that one part held and the next part did not see. A stale process, a lost summary, a routing dropped on a fallback path, bookkeeping that did not land, an id clash. Each part worked alone. The first end-to-end run found the joins. If you build a lifecycle from parts, expect your first month to go there.

Across the whole renovation our log of findings stood at 60 as at 28 October 2026. The most common shape is something reporting success for a reason that was not success: a boundary check that found nothing to enforce, a ticket marked done for work that never landed, a build that hit its turn limit and reported ok.

What we have not said

This is one requirement, in our own factory, with a person watching. It is a record of what happened, not a benchmark, and it says nothing about how the same path behaves on your system. The ticket ids and the full table are in our work record; the table above is the same content, lightly shortened.

Read next

• The AI SDLC Playbook →Two ceilings, six practices and the lifecycle around the code. The short version is the page; the full edition is a PDF.
• The full edition, 38 pages →Chapter 14 is this pilot in full. Chapter 15 is the fourteen things that were wrong before.
• Our own board →The delivery record, with the rework row left in.