I lost my favourite tool and shipped faster anyway

Fable was the best tool in my stack. Then it went unavailable, and I had to give the architect seat to Opus Max on short notice.

I expected a downgrade. What I got was faster hand-offs. This is the post about why — and why I think losing the tool made the work better, not despite the constraint but because of it.

The comfortable version was making me sloppy

Here's the thing I didn't want to admit while Fable was around: it was so good at absorbing fuzzy intent that I got lazy about what I handed it. Half-formed asks, missing constraints, "you know what I mean" — Fable usually did know what I meant. It papered over my sloppy briefs.

That's a great tool and a bad habit. I was outsourcing not just the architecture but the clarity — and clarity is the one thing the human at the top of the stack actually owes the machines below.

What the constraint forced

When Opus Max took the seat, it held the role fine — the seat was defined, not the occupant — but it was less forgiving of a vague brief. It didn't paper over the gaps. It surfaced them.

And that was the upgrade. Losing the tool that tolerated my worst inputs forced me to write better ones (diagram 1, before/after hand-off). Concretely, three things changed the week Fable disappeared.

My briefs got specific. I started stating constraints up front instead of letting the architect infer them. The intent I hand over now is sharper, because I can't assume it'll be reverse-engineered.

The hand-offs got cleaner. A sharper brief decomposes into cleaner tasks. Less back-and-forth at the orchestrator layer, fewer worker outputs bouncing at the gate for "that's not what I meant."

I stopped worshipping the tool. The moment the architect seat became swappable, I started designing the seat instead of depending on the occupant. Which is a more durable place to stand.

Net: fewer round-trips, less rework, faster to a shippable result — with a model I'd have told you a month earlier was second-best for the job.

The lesson isn't about Opus Max

It would be easy to read this as "Opus Max is secretly better." It isn't the point. The point is that a constraint you didn't choose can expose a dependency you didn't notice. My dependency wasn't on Fable's capability. It was on Fable's tolerance — its willingness to succeed despite my bad inputs. Remove the tolerance and the real bottleneck shows up: me, under-specifying.

That's the portable lesson, whatever holds your architect seat, the demands you should make of it are the same — judgment under ambiguity, the spine to kill a bad plan, a clean interface to the tier below. And the demands you should make of yourself don't change when the tool does: hand over intent sharp enough that any competent architect tier could act on it. If your workflow only works with one specific model in one specific seat, you don't have a workflow. You have a favorite.

Losing the favorite is how I found that out.

This week — I'm at CAST26

I'm writing this from CAST 2026 in Cocoa Beach, FL — August 3–5, where this whole series lands on a stage. If you're here: come find me. I want to hear which tool you'd be lost without, and whether losing it would expose the same thing losing Fable exposed for me. If you're not here, the talk feeds straight into where this series has been heading all along — the reviewer-design ideas from the RPIQ post and the forthcoming "Quality at Machine Speed" chapter.

If you're testing Fable / Opus Max too, where did it land for you? And the sharper question this week: what's the tool you'd be lost without — and what would losing it force you to finally get right?