When NOT to reach for the architect tier, revisited

Fourteen weeks ago I gave you one question to ask before standing up the architect tier: is the shape of this work actually uncertain? If I already knew what to build and in what order, the architect was overhead wearing a lab coat. I still think that's the right first question.

It was also, I've since learned, half the question.

Because in the weeks after I wrote it, I stopped over-applying the architect tier — and started over-applying everything I'd built on top of it. The reviewer independence. The adversarial briefs. The falsifiable gates. The cross-tier checks I spent four posts telling you to install. I'd fixed one kind of overkill and walked straight into the next one, and it took me a while to notice because the new one looks even more responsible than the old one did.

This is the honest update to the overkill retrospective. Same spirit, bigger blast radius.

The new way I was wrong

Here's the pattern, with the receipts.

The adversarial review on a copy change. I was tweaking the wording of an error message. Cosmetic. No logic, no data, nothing load-bearing. And because I'd just spent three weeks preaching cross-tier review, I stood up an independent reviewer in a fresh context to adversarially check it. It dutifully found nothing, because there was nothing to find. I'd put a courtroom around a comma.

The falsifiable gate on scratch code. I wrote a throwaway script to eyeball a number once and delete. I then built a proper check for it — does this reconcile, does it handle the empty case — the full apparatus from the gate-design post. For code that existed for ninety seconds. The gate outlived the thing it was gating.

"Show me your basis" on a decision with no downside. This is the subtle one, and it's the exact twin of the mistake I confessed in the original retrospective. Back then I ran a settled decision through the architect "to be safe." This time I demanded a checkable basis for a choice where being wrong cost nothing — a reversible default, a thing I could change back in one line. I made the model justify itself to a standard the stakes didn't warrant. Theater, again. Just wearing a different costume.

The common thread: every one of these felt like diligence. That's the whole trap. The original overkill was seductive because the stack looks like engineering. This new overkill is worse, because quality discipline looks like conscience. Nobody questions the person who asked for one more review. But a review nobody needed is just the overengineering tax I warned about three weeks ago, with a better alibi.

The question, widened

So the one-question filter grows a second axis. The first question still stands: is the shape of the work uncertain? It decides whether you need the architect tier — judgment under ambiguity, fuzzy intent in, defensible plan out. If you know the shape, you don't.

The second question is the one Theme D forced on me: is being wrong here actually expensive? Not "is this important," not "is this visible." Expensive — does a mistake here cost something real and hard to walk back? That's the question that decides whether you need the review apparatus — the independence, the falsifiable gates, the adversarial second look. If a mistake is cheap and reversible, that machinery is a courtroom around a comma no matter how uncertain the shape was.

Cross the two and you get four honest routes, not one default:

• Shape clear, cheap to be wrong → just do it. A worker, or your own two hands. No architect, no gate. Most work lives here and I keep forgetting it.
• • Shape clear, expensive to be wrong → skip the architect, gate the output. You know what to build; you don't need anyone to decide it. But put one real, falsifiable check on the load-bearing claim before it ships.
• • Shape uncertain, cheap to be wrong → let the architect decide, then stop. Stand up the full stack to find the shape — and then resist the reflex to adversarially review a thing that costs nothing to get wrong. Decide fast, don't audit it.
• • Shape uncertain, expensive to be wrong → full stack and independent review. This is the only quadrant that earns the whole apparatus. It is rarer than either my enthusiasm for the stack or my enthusiasm for reviewing it wanted it to be.

The two overkill traps map cleanly onto the two axes. Reach for the architect in the left column and you're repeating the mistake from Post 5. Reach for the review machinery in the bottom row and you're making the new one. Both feel like care. Only one quadrant needs both.

Which brings me to the tool this series is named after

I have to be honest about something, because a retrospective is where you take stock or it's nothing.

This series started as a story about one specific tool. I lost it. I replaced it. It came back and didn't reclaim its seat. I settled on a different model on merit. And then — look at the last eight posts — that tool simply stopped mattering to anything I was arguing. Economics, routing, reviewer design, gate placement, confident-and-wrong, and now this. None of it depends on which model holds the architect seat. The name on the door was never the subject.

That's not a confession of drift. It's the point arriving. The thing worth writing about was never the favourite tool — it was the shape of the work and how you keep it honest at speed, which is exactly the two-axis question this post is built on, and exactly what the forthcoming chapter on "Quality at Machine Speed" is actually about: proportioning scrutiny to stakes, not maximising it. (Still forthcoming — it becomes a real citation the day the date lands.)

So from here the series drops the pretense and calls itself what it is: a running argument about building and reviewing through a multi-tier stack, pointed at that chapter. The tool that got me here can leave the argument. Nothing breaks. That was always the tell that the argument was the durable part.

The short version

One question became two. Ask whether the shape is uncertain — that's whether you need the architect. Ask whether being wrong is expensive — that's whether you need the review machinery. Standing up the architect when you already know the shape is the old overkill; standing up the review apparatus when a mistake is cheap is the new one, and it's sneakier because it wears conscience as a disguise. Only the uncertain-and-expensive quadrant earns the full apparatus, and it's rarer than any of my enthusiasms wanted. The rest of the time, the skill is knowing what to leave out.

Next week I'm opening the floor: the recurring question at the end of every one of these has piled up months of real answers, and the best of them deserve a post of their own.

If you're running a multi-tier stack too, where did it land for you? Specifically, the new version: where did you over-review something that was never going to hurt you if it was wrong? I'm collecting the honest answers, not the highlight reel.

Series: Post 1 — Fable 5 talks to machines better than to people · Show me the receipts · Show, don't tell · Why I took the architect tier out · The RPIQ loop · Where the stack was overkill · BowSmith case study · I lost my favourite tool · Opus Max as architect · Fable 5 came back · CAST26: open season as a quality gate · Opus 5: the middle ground I chose · Is the token even the right unit of account? · Routing rules: which tier gets which task · Stop prompting, start delegating · Reviewer design: catching what the architect tier misses · The overengineering tax: when three tiers cost more than one · Gate design 101: where quality checks belong in the loop · The model was confident and wrong · Post 19 — When NOT to reach for the architect tier, revisited