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 ,

or the Yanz channel on YouTube.