Gru's Phase Gates: Validated, Not Attempted
Ask Claude for a design and it will write a polished one, even for the wrong problem. Gru is a persona that conducts Claude through a software design in five phases: the problem, the needs, the principles, the components, and the assembled design. Its one rule: no phase produces valid output until the phase before it…
Gru's Phase Gates: Validated, Not Attempted
Ask Claude for a design and it will write a polished one, even for the wrong problem. Gru is a persona that conducts Claude through a software design in five phases: the problem, the needs, the principles, the components, and the assembled design. Its one rule: no phase produces valid output until the phase before it has been validated, not just attempted. This film shows why that rule matters, on a checkout design where every section has words in it and a recommendation widget nobody asked for still ships.
Liam, in for Bear, with INFO 7375, Computational Skepticism for AI, at Northeastern.
Series: Claude & Agentic AI Topic: INFO 7375 · TL;DR
Chapters
0:00 TL;DR: what this film is about 0:22 Why you should care 0:40 The question, and four terms 1:06 A design that looks finished 1:26 Every component traces to a need 1:44 A component with nowhere to land 2:00 The obvious approach: one pass 2:19 Five phases, five gates 2:38 Predict, then the fog collapses 3:00 A phase gate 3:16 Back to two in the morning 3:31 Two deliberate exits 3:49 Verdict 4:10 Your turn
YOUR TURN
Paste this into Claude:
Act as Gru, a phase-gated software architect. My system, in one sentence: [describe something you are building]. Run only the first two phases. First, restate my problem so that it could not describe ten other systems. Then list my needs, and reject any need that could not turn out to be wrong. Do not propose components or write any design yet.
Before you run it, predict which of your needs gets rejected. Then check three things:
- Did it refuse to design anything before the needs were fixed?
- Did it reject a need you thought was fine?
- Could its problem statement describe ten other systems? If it could, send it back.
Source: the Gru persona prompt used in INFO 7375 (its "Phase Gates" note, session menu, and behavioral rules). The checkout design, the address form, the recommendation widget, and the 2 a.m. page are a constructed example built from the persona's own examples.
@NikBearBrown
Part of the Claude & Agentic AI series.
▶ The full series playlist — Brutalist https://www.youtube.com/playlist?list=PLG9H-C6rp5RU
What this video covers
- 0:00 — TL;DR: what this film is about
- 0:22 — Why you should care
- 0:40 — The question, and four terms
- 1:06 — A design that looks finished
- 1:26 — Every component traces to a need
- 1:44 — A component with nowhere to land
- 2:00 — The obvious approach: one pass
- 2:19 — Five phases, five gates
- 2:38 — Predict, then the fog collapses
- 3:00 — A phase gate
- 3:16 — Back to two in the morning
- 3:31 — Two deliberate exits
- 3:49 — Verdict
- 4:10 — Your turn
Transcript
A lightly formatted transcript of the video, with timestamps so you can jump to any section on YouTube.
TL;DR: what this film is about
[0:00] Hello, this is Liam in for Bear with info 7,375 computational skepticism for AI at Northeastern. This film is about Claude, a persona that conducts Claude through a software design. Claude runs a design in five phases and no phase starts until the one before it is validated. You'll watch that rule catch a component nobody asked for. The trap, a document with words in every section looks finished.
Why you should care
[0:22] Why should you care? Ask Claude for design and it will write a polished one even for the wrong problem. In Claude's telling, the outage doesn't come from bad code. It comes from a decision nobody made explicitly. Vague needs upstream turn into mush in every section downstream. The gates force each decision into the open before Claude starts typing.
The question, and four terms
[0:40] The real question, how does Claude stop Claude from writing the wrong design? Not how it writes one faster. Claude says it outright, "I'm not here to build your rocket faster." Four terms in SDD, a software design document, the written record of what a system does and why. A need, a user or business requirement that a component exists to serve. A component, a named part of the system with its own job. And falsifiable, stated so that it could turn out to be wrong.
A design that looks finished
[1:06] Here's a design document for a checkout page. Five sections, the problem, the needs, the principles, the components, and the assembled design. Every one of them has words in it. Two months later, 2:00 in the morning, checkout breaks inside a recommendation widget. The on-call engineer opens the document and asks one thing, "Why does this exist?" Every section has words, none of them says why.
Every component traces to a need
[1:26] Claude's fourth phase has one rule, every component has to trace to a need from phase two. Take the need Claude itself offers as a good one, reduce checkout abandonment caused by the three-step address form. Now propose a component, a single-page address form. Draw its line back, it lands. That component has a reason to exist and the reason is written down.
A component with nowhere to land
[1:44] Vary one thing, someone says we might as well add recommendations. Propose a recommendation widget and try to draw its line back. Nothing in phase two is about recommendations. The line has nowhere to the Claude stops right here and asks which need it serves or calls it scope creep.
The obvious approach: one pass
[2:00] Now the obvious approach, skip the phases, ask Claude for the whole design in one pass, then review it at the end. All five sections fill at once and the need section says what first drafts often say, improve user experience. Watch what that does. The address form traces to it, so does the widget. Everything traces to a need that vague. Every check passes and the widget ships.
Five phases, five gates
[2:19] Change the picture, put a gate in front of every phase. Gru's rule, you cannot get a valid output from the next phase until this one has been validated, not attempted, not mentioned earlier in the chat, validated. The problem passes. Now the needs gate asks its one question, could this need turn out to be wrong? Improve user experience can't be wrong. It fails the gate. Before it moves,
Predict, then the fog collapses
[2:39] Commit. Gate two is about to force that need into something specific. When it does, where does the widget's line land? Pick your answer. It doesn't land anywhere. The need becomes specific and the fog it sat in collapses to one point. The address form's line finds it. The widget's line finds nothing. Gate four holds and the widget goes back with a question instead of into the design.
A phase gate
[3:00] This deserves a name, a phase gate. No valid output from the next phase until this one is validated, not just attempted. Skip one and Gru names exactly what's missing and holds the line because a decision made without its prerequisite is, in Gru's words, a guess wearing a decision's clothes. Back to
Back to two in the morning
[3:16] 2:00 in the morning, checkout breaks but not inside a recommendation widget because there isn't one. The engineer points at the address form and asks the same question, why does this exist? Follow the line. The answer is sitting in phase two in words that could have turned out to be wrong.
Two deliberate exits
[3:31] Two things this film didn't cover. Silent mode skips every gate for when you already know exactly what you want and need output, not supervision. And slash Claude, the boondoggle score, ignores the gates on purpose. It scores whatever exists at any stage across the five supervisory capacities. Neither is the default. The gates are the point.
Verdict
[3:49] Let's recap with Claude. Gru conducts Claude through five phases. The problem, the needs, the principles, the components, and the assembled design. Each phase is gated. No valid output from the next phase until this one is validated, not attempted. Needs have to be falsifiable, and every component has to trace to one, or it's scope creep. And a finished looking document proves only that every section has words. Your
Your turn
[4:10] Turn, paste this into Claude, act as grew a phase gated software architect. My system in one sentence, describe something you are building. Run only the first two phases. First, restate my problem so that it could not describe 10 other systems. Then list my needs and reject any need that could not turn out to be wrong. Do not propose components or write any design yet. Before you run it, predict which of your needs gets rejected. Then check three things. Did it refuse to design anything before the needs were fixed? Did it reject a need you thought was fine? And could its problem statement describe 10 other systems? If it could, send it back. Grew's phase gates, validated not attempted at Nick Bear Brown.
