PREVC Against the Methodologies

Part 8 closed the loop: Confirmation's output feeds Planning's input, and the five phases turned out to be a circle rather than a pipeline. Which raises the question this series has been deferring since part 1, one borrowed credit at a time. PREVC's Review phase leaned on Scrum's refinement; its inner loop leaned on Kent Beck; its retrospective leaned on PDCA and Kaizen; its traceability leaned on the safety-critical standards. At some point the honest move is to stop crediting piecemeal and put the whole workflow next to the methodologies it keeps borrowing from — and say plainly where it repeats them, where it genuinely differs, and where it is simply them, renamed.

The mappings below are my analysis, not anyone's official crosswalk, and the conclusion is worth stating up front so nothing later reads as a reveal: PREVC is not a methodology and does not compete with one. It is a phase structure, sized to a single piece of work, that operates inside or alongside whatever methodology already runs your team. If the comparison table makes it look derivative — good. It is derivative, deliberately, of things that worked for decades; what changed is who does the implementing.

The mapping, on one table

Every column lines up suspiciously well, which is the point: these are the same five concerns — decide, verify the decision, build, verify the build, learn — that every serious delivery framework eventually names. The differences live below the table, in granularity, in who holds the pen, and in what each framework assumes about the builder.

PDCA — the cycle underneath everything

Plan-Do-Check-Act is the deepest ancestor here, and its lineage deserves getting right because it is so routinely compressed to one name and one decade: the cycle originated with Walter Shewhart at Bell Labs in the 1920s, was popularised by W. Edwards Deming in 1950s Japan, and Deming himself came to prefer PDSA — Study over Check. Part 8 made the retrospective's debt to the Act step explicit; here is the whole-cycle view.

PREVC diverges from PDCA in two structural moves. First, it splits Plan into two phases — agent Planning, then human Review — because the two halves are now done by different kinds of mind. An agent can generate structure at a speed and coverage no human matches; it cannot encode organisational intent. One PDCA step, two PREVC phases, one seam between them where the handoff from part 3 lives. Second, PREVC refuses to treat Do as atomic: inside Execution runs the Code-Review-Simplify loop with explicit exit conditions, a Do-Check micro-cycle spinning at work-package granularity inside the outer cycle. PDCA assumed the doer was a human team that checks itself continuously and stops when tired; an agent does neither, so the structure PDCA left implicit has to be built in.

Scrum — same instincts, finer grain

Against Scrum the difference is almost entirely granularity. A sprint is a couple of weeks; a PREVC cycle is a piece of work, and a single sprint may contain many of them. The ceremonies map, coarser to finer: Sprint Planning to Planning, backlog refinement to Review, the Sprint Review to Validation, the Retrospective to Confirmation — but where Scrum runs each once per sprint, PREVC runs the whole set per work item, because the feedback that used to arrive at sprint boundaries now needs to arrive before an unattended agent compounds a misunderstanding for forty minutes.

What PREVC adds that Scrum never needed is the AI-specific machinery: plan-readiness scores, hallucination review, a step whose only job is deleting excess code, and constraint documentation aimed at readers with no tribal knowledge. And one apparent conflict dissolves on inspection: all this documentation looks distinctly un-agile next to the Agile Manifesto's preference for working software over comprehensive documentation. I think the preference survives intact. The documents PREVC produces are not comprehensive documentation in the manifesto's sense — status theatre, written for nobody; they are operational context, written for the next agent session, and they earn their existence the same way working software does: they get executed.

Waterfall — the rigour without the wait

Waterfall is the comparison PREVC courts most visibly, because on paper the five phases are a waterfall: sequence, gates, documents. The difference is time and topology. Thoughtworks, writing about spec-driven development, named the failure precisely: “The problem with traditional waterfall development is its excessively long feedback cycles.” Requirements aged for months before implementation contradicted them, and the contradiction surfaced too late to be cheap.

PREVC keeps the sequencing and collapses the calendar. Its phases are separated by minutes or hours, not months; Execution loops internally; and Confirmation feeds Planning, which no waterfall ever did — water does not flow back up. The spirit of it was caught by Les Orchard, in a phrase Addy Osmani quotes in his account of his own LLM coding workflow: it is like doing a “waterfall in 15 minutes” — a rapid structured planning pass that buys the rigour of upfront design without the multi-month loop that made the original infamous. If waterfall's phases were the disease, they were never the whole disease; the delay between them was. Remove the delay and the phases turn out to be worth keeping.

Spec-driven development — the principle to this process

Spec-driven development is the odd one out in the table because it is not a rival lineage — it is the practice PREVC operationalises. Thoughtworks named SDD one of 2025's key new AI-assisted engineering practices: formalise requirements into structured specification files before code is written, and the specs buy you shorter, workable feedback loops than pure vibe coding ever allows. Their claims are carefully verbed, and I keep the verbs: structured specs help reduce model hallucination — reduce, never prevent — and drift remains inherently difficult to avoid. Tooling has followed the practice; GitHub's Spec Kit is the visible example, an open-source toolkit for running spec-first agent development.

But SDD, as practised, answers what — write the spec, then implement against it — and stays largely silent on how: when does a human examine the spec, against which criteria, what loop governs implementation, what happens when the build and the spec disagree, who updates what afterwards. PREVC is one answer to the how. Planning authors the spec; Review validates it and encodes intent; Execution generates against it under an exit-conditioned loop; Validation verifies acceptance with receipts; Confirmation feeds what was learnt back into the next spec. SDD is the principle; PREVC is an operational process for it — one of several possible ones, and the sibling series opener on what changed when agents stopped checking in covers the discipline stack that sits underneath both.

The V-Model — the quiet cousin

The least fashionable comparison is the one PREVC's Validation phase owes the most. The V-Model pairs each descent-side development phase with an ascent-side testing phase — requirements with acceptance testing, design with integration testing, implementation with unit testing — so that everything specified on the way down is verified, at matching altitude, on the way up. PREVC compresses the ascent into a single Validation phase rather than parallel tracks, but the load-bearing idea is adopted whole: verification is defined by reference to a specific upstream artefact, not by general quality feeling. Part 7's traceability matrix is the V-Model's handshake between the two arms, drawn as a table.

What the comparison settles

Read the five comparisons together and PREVC's actual position becomes plain. From PDCA it takes the cycle and splits the Plan. From Scrum it takes the ceremonies and shrinks the grain. From waterfall it takes the gates and deletes the delay. From SDD it takes the principle and supplies a process. From the V-Model it takes traceability and flattens the V. The one genuinely new pressure running through all five adaptations is the same one this series opened with: the implementer is now an agent — fast, tireless, literal, and unsupervised between gates — and every borrowed structure got re-shaped around that fact and none other.

Which leaves exactly one part to write, and it is the one the style of this series has been promising all along: the honest ledger. What the borrowed skeleton and my extensions actually cost, what I can and cannot evidence, and what I would do differently. Next, an honest ledger for a borrowed skeleton.