Yanz
Ep 1 of building in public on Yanz Dev.
Fable 5, Opus 4.8, or Sonnet 5 — which one is best? And every week I give the same annoying answer: that's the wrong question.
I'm not dodging. I use all three, most days, across seven products I build solo. And the biggest jump in my output this year didn't come from picking a winner. It came from making them work together — one model to think, two to build.
The "best model" trap
The "which model is best" framing assumes you're going to marry one of them. Pick the champion, run everything through it, done.
But these models aren't the same tool in three sizes. They have different shapes. One is unreal at holding a messy problem in its head and reasoning out a plan. The others are relentless at taking a plan and turning it into working, tested code. Asking which is "best" is like asking whether a whiteboard is better than a keyboard. Best at what?
Once I stopped hunting for the single best model, I started getting a lot more done.
How I actually split the work
Here's the pipeline I've landed on. Nothing fancy — it just respects that thinking and typing are different jobs.
Fable 5 does the thinking. Before a single line of code, I hand it the problem: the feature, the constraints, the parts of the codebase it touches. Its whole job is to reason — argue with itself about the approach, weigh the trade-offs, and hand back a plan. A real spec: what we're building, the architecture, the files that change, the edge cases I'd forget, the order to do it in. No code yet. Just the map.
Opus 4.8 and Sonnet 5 do the building. They take that plan and execute it. This is where the plan earns its keep — I can point a model at "step 3 of the spec" and it has everything it needs, because the thinking already happened. Opus for the gnarly, cross-cutting pieces; Sonnet for the fast, well-scoped chunks I can fire off in parallel. Same plan, two builders, no re-litigating the design every message.
One model to reason. Two to build. The plan is the handoff between them.
Why the handoff is the whole trick
The reason this works isn't that any one model is magic. It's that a written plan is a contract. When the thinking is separated out and written down, the builders stop guessing. They're not reinventing the architecture on every request — they're filling in a blueprint that already survived an argument.
I noticed this the hard way. When I let a single model plan-and-build in one breath, it drifts. It makes a reasonable architectural call in message two, forgets it by message nine, and I'm left reviewing code that quietly contradicts itself. Splitting the phases forces the decision to exist on paper before anyone builds against it. The plan becomes the thing I review — and reviewing a plan is a hundred times cheaper than reviewing the wrong code after it's written.
This is qualitative, not a benchmark. I'm not going to wave a number at you. But the felt difference is real: fewer dead-end diffs, less thrash, more shipping.
The part that's still on me
None of this removes the human. If anything it sharpens where I matter.
I still decide what to build and which trade-offs I'll live with — Fable 5 gives me a plan, but the plan is only as good as the problem I framed. I still read every diff before it merges. And when production breaks at 2am, it's me, not a model, who's responsible. Orchestrating three models doesn't outsource the judgment. It just means I spend my judgment where it counts — on the plan and the review — instead of babysitting a single model trying to do two jobs at once.
So which model is best?
Wrong question. The gain isn't in the pick. It's in the orchestration.
Stop trying to crown one model and start routing work to the shape that fits it: let the one that's best at thinking do the thinking, and let the ones that are best at building do the building. That handoff — a plan good enough to build against without re-explaining it — is where the real leverage is hiding.
One person, seven products, three models pulling in the same direction. That's the setup. I'll keep sharing what breaks and what works as I go.
This is Episode 1 of my build-in-public journey — I'm documenting how I build all seven products, with AI, in the open: the wins, the bugs, the real process. Follow along on X, Threads, or the Yanz channel on YouTube.
