One Model to Think, Two to Build

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.