The overengineering tax: when three tiers cost more than one

Last week I argued that every piece of work needs an independent reviewer — a different tier, stripped context, an adversarial brief — because the thing that wrote it can't be trusted to check it. I stand by all of it. So here's the honest counterweight, before someone takes that advice and puts a three-tier stack and two independent reviews on a one-line config change.

Because that's a real failure mode, and it's the one nobody warns you about. Everyone warns you about doing too little. This is about doing too much, and calling it rigour.

The tax, defined

Every tier you add and every review you bolt on buys you something. It also charges you something. The charge is the hand-off: context to pack, a plan to write down, an output to pass along, a check to run and read. That cost is roughly fixed per hand-off — it barely moves whether the task is a one-liner or a two-week feature.

That's the whole problem in one sentence. The overhead doesn't scale with the task. So on a big, ambiguous, high-stakes piece of work, three tiers and a cross-tier review are a rounding error against the value they protect. On a one-line fix, the same machinery costs more — in wall-clock, in tokens, in your own attention — than just doing the thing would have. And you didn't even buy quality with it. You bought ceremony.

I've paid this tax. A trivial change — rename a field, update a copy string — routed through the full stack out of habit. Architect writes a plan for a thing that needed no plan. Orchestrator decomposes a task with one step. A worker does the obvious. Then a reviewer, dutifully, reviews the obvious and finds nothing, because there was nothing to find. Four hand-offs, a pile of tokens, and ten minutes, to do thirty seconds of work. That's not diligence. That's a tax return.

Why good advice overshoots

Here's the uncomfortable part: the people who overengineer aren't lazy or sloppy. They're the conscientious ones. They read a post like last week's, internalised "same-model review is a rubber stamp," and concluded — reasonably — that the answer is more independence everywhere. Route everything across tiers. Gate every step. Never let a model check its own work.

And that reflex, applied without a throttle, is how the cure becomes the disease. Independence machinery is the single most expensive thing in the stack — it's a whole extra reasoning pass, in fresh context, framed to go looking for trouble. Point it at work that genuinely needs scrutiny and it's the best money you'll spend. Point it at everything, reflexively, and you've just built a bureaucracy: a committee that reviews the lunch order with the same solemnity as the merger.

Last week's post was about catching what the reviewer misses. This week's is about not reviewing what nobody needed to check. Both are true. They're the two walls of the same corridor.

How to tell the difference

The useful half of this post. You're paying the overengineering tax when:

• The hand-off costs more than the task would have. If packing the context for a tier takes longer than just doing the step, the tier is the overhead, not the work.
• The review has caught nothing, N runs in a row. A gate that never fails on a given task class isn't protecting you — it's a tollbooth on an empty road. Count the saves. If there are none, it's tax.
• You're tier-matching by prestige, not by task. "This is important, so it goes to the top tier" is not routing. Importance and difficulty are different axes. Important-but-trivial exists, and it does not need the architect.
• The plan is longer than the thing it plans. When the scaffolding outweighs the building, you built the scaffolding for its own sake.

And the flip side — when the machinery is earning its keep, pay the tax gladly:

• Irreversible or high-blast-radius changes. A migration, a billing path, anything you can't quietly undo. Here the review is cheap insurance against an expensive mistake.
• Unfamiliar territory. When you genuinely don't know what good looks like, independence is how you find out.
• Outputs other people build on. If a mistake propagates downstream into someone else's work, catch it here, where it's cheap.

The pattern underneath all of these: the ceremony should match the blast radius of being wrong, not how much you happen to care about the task.

The rule of thumb

Here it is, the whole post compressed: match the ceremony to the blast radius, not to how much you care.

Default to the cheapest path that's safe for this task class. Add a tier or a gate only when you can name — out loud, specifically — the failure it's there to catch. "What would this review catch that nothing else would?" If you can answer, keep it. If the honest answer is "nothing, but it feels responsible," you've found the tax, and you should stop paying it.

Caring is not a quality strategy. Targeting is.

The book-chapter version

This is the same ground the forthcoming chapter on "Quality at Machine Speed" stands on, just approached from the opposite edge from last week. Quality at speed isn't maximum review — it's right-sized review: independence placed exactly where being wrong is expensive, and nowhere it isn't. A stack that reviews everything equally is as unserious as one that reviews nothing; both have confused effort with judgement. (Still a forthcoming reference — I'll upgrade it to a real citation once the date lands. Which it hasn't, yet.)

Where the gates actually belong in the loop — not just how much review, or how little, but where — is the next deep one. The question after "how much scrutiny" is "scrutiny at which point," and that's its own design problem.

The short version

More tiers and more reviews are not more quality — past a point they're just a tax you pay in time, tokens and attention, for work that never needed them. The overhead of a hand-off is roughly fixed, so it eats trivial tasks alive and barely dents hard ones. Match the ceremony to the blast radius of being wrong, not to how much you care. Before you add a gate, name the failure it catches; if you can't, it's tax. Last week: don't under-review. This week: don't over-review. The skill is knowing which risk you're running this time.

If you're testing Fable 5 / Opus 5 too, where did it land for you? And the overengineering version: where have you caught yourself paying the tax — a stack heavier than the job needed, a review that's never once caught a thing?

Diagram: the overengineering tax — do-it-directly vs. full-stack cost against task complexity, with the tax zone shaded left of the break-even.

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 · Post 16 — The overengineering tax: when three tiers cost more than one]