Where the three-tier stack was overkill: an honest retrospective

I've spent five weeks telling you the three-tier stack is how serious work gets built. Fable speaks machine better than human. The architect tier is for decisions, not typing. The whole thing maps cleanly onto the RPIQ loop. All true. All still what I'd argue on a stage.

And for a good chunk of the work I actually did this month, reaching for it was a mistake. This is the retrospective post. Not a victory lap — the opposite. Where the stack was overkill, where the hand-off cost more than it saved, and the one-question filter I now run before I stand up the architect tier at all.

The pattern I kept catching myself in

The failure mode isn't dramatic. It's that the stack is satisfying. Standing up an architect to reason about a plan, watching it decompose, farming tasks to workers — it feels like engineering. So I did it for things that did not remotely need it.

I went back through the month and tagged every task where I'd reached for the full stack. Roughly four in five of the "architect-worthy" ones didn't clear the bar. Three that still make me wince:

The one-line config fix. A timeout value was wrong. I knew the file, the line, the new number. I stood up an architect to "plan the change." It produced a tidy three-step plan for a one-token edit. Net result: a five-minute job took twenty, and the plan was longer than the diff.

The rename that became a committee. Renaming a function across a handful of files. Mechanical. Instead I let the orchestrator "decompose" it into per-file tasks and fan them to workers. The hand-off overhead — writing scoped task specs, collecting outputs, reconciling them — cost more than just doing the find-and-replace myself. The stack turned a two-minute chore into a coordination problem I invented.

The plan for a thing I'd already decided. This is the subtle one. I knew exactly what to build and why. But I ran it through the architect anyway, "to be safe." It dutifully reviewed a decision that wasn't in question and handed it back to me unchanged. I paid architect-tier latency and spend for a rubber stamp. The first Quality gate only earns its keep when direction is genuinely uncertain — the whole point of the front-loaded Q. Point it at a settled question and it's theater.

The tax nobody prices in

Every hand-off has a cost, and it's not the token bill (diagram 2). It's the overhead of translation: writing a spec precise enough for another tier to act on, then reconciling what comes back against what you meant. For a high-leverage feature, that overhead is trivial against the payoff. For a small, well-understood change, the overhead is the whole job — you spend more effort briefing the stack than the work contains.

I started calling this the overengineering tax. On the config fix, the tax was 4x the actual work. On the rename, the coordination overhead exceeded the task by a wide margin. Three tiers didn't make those faster or safer. They made them into projects.

The uncomfortable version: the stack's legibility is exactly what makes it seductive on work that doesn't need it. It always looks like the responsible choice. It frequently isn't.

The one question I now ask first

So before I stand up the architect tier, I run one filter:

Is the shape of this work actually uncertain?

Not "is it important." Not "is it big." Is the shape uncertain — do I genuinely not know what to build, in what order, or whether it's worth building at all? That's the only condition the architect tier is priced for. Judgment under ambiguity, fuzzy intent in, defensible plan out. If I already know the shape, every tier above the worker is overhead wearing a lab coat.

The flow that falls out of that question:

• Shape is clear and the change is small → just do it. No stack. A worker, or my own two hands.
• Shape is clear but the work is large → skip the architect, keep the orchestrator. Decomposition earns its seat; planning doesn't, because there's nothing to decide.
• Shape is genuinely uncertain → now the architect tier earns it. This is the case it was built for, and it's rarer than my enthusiasm wanted it to be.

Most work lives in the first two branches. I was routing it to the third because the third is the fun one.

Why the honest version matters

None of this retracts the series. The stack is right for the work it's right for. But a methodology you only ever praise isn't a methodology, it's a brand — and the fastest way to discredit a good framework is to apply it everywhere and let people watch it underperform on a config change.

So: the three-tier stack, used when the shape of the work is the question. And a worker and some discipline for everything else. Knowing which is which is the actual skill. The stack is just the tool that skill picks up when the job calls for it.

Next week I take the opposite swing — BowSmith, one full feature shipped end-to-end through the stack, with the numbers, where every tier did earn its seat. The case that makes the overkill worth tolerating. And then, the week after, I'm taking all of it to a stage: CAST 2026, August 3–5, Cocoa Beach, FL.

If you're testing Fable / Opus Max too, where did it land for you? Specifically: where did you reach for the architect tier and later realize a worker would have done? I'm collecting the honest answers, not the highlight reel.