{"slug": "one-model-to-think-two-to-build", "title": "One Model to Think, Two to Build", "summary": "A solo developer building seven products uses three different AI models in a pipeline: one for reasoning and planning, two for code generation. The approach separates thinking from building, using a written plan as a contract between models to reduce drift and improve output quality.", "body_md": "*Ep 1 of building in public on Yanz Dev.*\n\n*Fable 5, Opus 4.8, or Sonnet 5 —\nwhich one is best?* And every week I give the same annoying answer:\n\nI'm not dodging. I use all three, most days, across seven products I build solo. And\n\nthe biggest jump in my output this year didn't come from picking a winner. It came\n\nfrom making them work *together* — one model to think, two to build.\n\nThe \"which model is best\" framing assumes you're going to marry one of them. Pick the\n\nchampion, run everything through it, done.\n\nBut these models aren't the same tool in three sizes. They have different shapes. One\n\nis unreal at holding a messy problem in its head and reasoning out a plan. The others\n\nare relentless at taking a plan and turning it into working, tested code. Asking which\n\nis \"best\" is like asking whether a whiteboard is better than a keyboard. Best at what?\n\nOnce I stopped hunting for the single best model, I started getting a lot more done.\n\nHere's the pipeline I've landed on. Nothing fancy — it just respects that thinking and\n\ntyping are different jobs.\n\n**Fable 5 does the thinking.** Before a single line of code, I hand it the problem: the\n\nfeature, the constraints, the parts of the codebase it touches. Its whole job is to\n\nreason — argue with itself about the approach, weigh the trade-offs, and hand back a\n\nplan. A real spec: what we're building, the architecture, the files that change, the\n\nedge cases I'd forget, the order to do it in. No code yet. Just the map.\n\n**Opus 4.8 and Sonnet 5 do the building.** They take that plan and execute it. This is\n\nwhere the plan earns its keep — I can point a model at *\"step 3 of the spec\"* and it\n\nhas everything it needs, because the thinking already happened. Opus for the gnarly,\n\ncross-cutting pieces; Sonnet for the fast, well-scoped chunks I can fire off in\n\nparallel. Same plan, two builders, no re-litigating the design every message.\n\nOne model to reason. Two to build. The plan is the handoff between them.\n\nThe reason this works isn't that any one model is magic. It's that a written plan is a\n\n*contract*. When the thinking is separated out and written down, the builders stop\n\nguessing. They're not reinventing the architecture on every request — they're filling\n\nin a blueprint that already survived an argument.\n\nI noticed this the hard way. When I let a single model plan-and-build in one breath, it\n\ndrifts. It makes a reasonable architectural call in message two, forgets it by message\n\nnine, and I'm left reviewing code that quietly contradicts itself. Splitting the phases\n\nforces the decision to exist *on paper* before anyone builds against it. The plan\n\nbecomes the thing I review — and reviewing a plan is a hundred times cheaper than\n\nreviewing the wrong code after it's written.\n\nThis is qualitative, not a benchmark. I'm not going to wave a number at you. But the\n\nfelt difference is real: fewer dead-end diffs, less thrash, more shipping.\n\nNone of this removes the human. If anything it sharpens where I matter.\n\nI still decide *what* to build and which trade-offs I'll live with — Fable 5 gives me a\n\nplan, but the plan is only as good as the problem I framed. I still read every diff\n\nbefore it merges. And when production breaks at 2am, it's me, not a model, who's\n\nresponsible. Orchestrating three models doesn't outsource the judgment. It just means I\n\nspend my judgment where it counts — on the plan and the review — instead of babysitting\n\na single model trying to do two jobs at once.\n\nWrong question. The gain isn't in the pick. It's in the orchestration.\n\nStop trying to crown one model and start routing work to the shape that fits it: let\n\nthe one that's best at thinking do the thinking, and let the ones that are best at\n\nbuilding do the building. That handoff — a plan good enough to build against without\n\nre-explaining it — is where the real leverage is hiding.\n\nOne person, seven products, three models pulling in the same direction. That's the\n\nsetup. I'll keep sharing what breaks and what works as I go.\n\n*This is Episode 1 of my build-in-public journey — I'm documenting how I build all\nseven products, with AI, in the open: the wins, the bugs, the real process. Follow\nalong on *", "url": "https://wpnews.pro/news/one-model-to-think-two-to-build", "canonical_source": "https://dev.to/yanz/one-model-to-think-two-to-build-1511", "published_at": "2026-07-03 22:36:32+00:00", "updated_at": "2026-07-03 23:18:30.825952+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-tools", "developer-tools", "ai-agents"], "entities": ["Fable 5", "Opus 4.8", "Sonnet 5", "Yanz Dev"], "alternates": {"html": "https://wpnews.pro/news/one-model-to-think-two-to-build", "markdown": "https://wpnews.pro/news/one-model-to-think-two-to-build.md", "text": "https://wpnews.pro/news/one-model-to-think-two-to-build.txt", "jsonld": "https://wpnews.pro/news/one-model-to-think-two-to-build.jsonld"}}