Forget "Which Model Is Best." Ask What Job It's Doing.

Say you're starting completely from scratch. No product yet, just an idea and a blank prompt window. This is the exact moment most non-technical builders freeze, because the first decision that seems to matter is which model to open, and there are more options this month than there were last month.

This week alone, Google shipped three new Gemini models in one go, 3.6 Flash, 3.5 Flash-Lite, and a cybersecurity-tuned 3.5 Flash Cyber, and pointedly did not ship the 3.5 Pro everyone had actually been waiting for. Coding scores on 3.6 Flash jumped from 37% to 49% on the DeepSWE benchmark, and output pricing dropped by roughly 17%. Meanwhile Anthropic now has four models live at once, Haiku 4.5, Sonnet 5, Opus 5, and Fable 5, and OpenAI didn't ship one GPT-5.6 either, they shipped three: Sol, for the hardest coding and cybersecurity work, Terra, for large-scale business and document reasoning, and Luna, for light everyday tasks.

None of that is noise. It's the industry telling you something plainly: there is no single best model in 2026, there are models that are best at a specific job, for a few months, until the next release reshuffles the leaderboard again. If the labs building these things have stopped pretending one model can do every job, you probably shouldn't build your first product around finding "the one" either.

The question you're actually asking

When someone starting from scratch asks "which model should I use," what they usually mean is "which model do I open first, and do I keep using it for everything." That's the wrong shape for the question, and it's the reason so many first-time builds stall out somewhere between a good idea and a working product.

The better question has two parts. First: what is the job in front of me right now, does it need careful reasoning or does it need speed and volume. Second: has this exact model already made the decision I'm about to ask it to check. If the answer to the second question is yes, you're not reviewing anything, you're just asking the same opinion twice.

Why skipping the PRD is the real mistake, not picking the wrong model

Here's the uncomfortable part for anyone starting from scratch: 63% of people building with AI coding tools today are non-developers, and a narrowly scoped product can go from idea to demo-ready in two to three days, with a further one to two weeks of iteration after that. Building has never been this fast for someone who's never written a line of code.

That speed is exactly why the PRD matters more, not less. When building took months, a vague brief got caught and corrected somewhere along the way, because there was time for someone to notice. When building takes two days, a vague brief just gets built, fast, wrong, and confidently. The PRD is the one artefact in this whole process a non-technical founder can actually judge directly. You can't review the code. You absolutely can review whether the brief says the true thing you meant, and that's where your leverage actually sits.

Skipping the spec because typing a description straight into a build tool feels faster isn't actually faster. It just moves the slow part to later, dressed up as a bug.

Picking a model for the spec-writing job

This is where model choice genuinely matters, because mistakes in the PRD cascade into everything built on top of it. A comparative test running the same PRD-writing task across ChatGPT, Claude, Gemini, Grok, and the purpose-built tool ChatPRD found Claude came out ahead. That's a useful data point, not gospel, comparisons like this shift every few months.

Fable 5, Anthropic's top-tier model, has a specific reputation for this job right now. A hands-on comparison for product-manager use cases found Fable 5 completed a scoped task in around 13 minutes against roughly 20 minutes for Opus 4.8 and Sonnet 4.6, while using about 24% of available context compared to 60% for the other two. That's a real, measured efficiency gap, and it's the kind of gap that shows up specifically in spec-writing and planning work, where the model needs to hold a lot of context and reason about tradeoffs rather than just produce volume.

Worth being honest about the limits too. The same round of testing found Fable 5 got narrow and noticeably less useful when handed an ambitious, days-long specification instead of a tightly scoped one, and multi-agent runs on bigger jobs showed stalls after around three hours. The lesson isn't "avoid Fable," it's "don't hand your entire six-month roadmap to any model in one sitting, however good it is at planning." Write one PRD, for one scoped piece of the product, at a time.

If you don't have Fable 5 access, Opus 5 is a reasonable substitute for this role; it's the frontier-tier model Anthropic ships more broadly, at half of Fable's price, and reasoning quality is still the point of that tier.

Picking a model for the building job

Once the PRD exists, the builder's job is different in kind, not just in degree. This is volume work: turn the spec into working code or copy, fast, and cheaply enough that redoing a section doesn't sting. This is exactly the role Gemini 3.6 Flash is built for right now, its jump on the DeepSWE coding benchmark paired with a roughly 17% price cut is precisely the kind of upgrade that matters for high-volume execution and nowhere else. Anthropic's own Haiku 4.5 sits in the same lane, quick and inexpensive, built for the model to do a lot of a well-defined thing rather than think hard about a small thing.

The industry's own model lineups back this up without anyone needing to argue for it. Anthropic runs four tiers side by side instead of one flagship. OpenAI split GPT-5.6 into Sol, Terra, and Luna rather than shipping a single model for every job, and priced them accordingly: Luna at $1/$6 per million tokens for light volume work, Terra at $2.50/$15 for heavier business reasoning, Sol at $5/$30 for the hardest coding and cybersecurity tasks. When the labs building these things design for role separation and price it that way, building your own workflow around one model for everything is working against the grain, not with it.

Picking a model for the review job

The reviewer's brief is simple to state and easy to skip: does the built thing match what the PRD actually said, not does it look roughly fine. Feed the PRD in as the ground truth and ask the model to check against it line by line, rather than asking an open-ended "does this look good."

The model matters here specifically because it needs to be different from whichever one did the building. If Fable 5 or Opus 5 wrote the spec and Gemini 3.6 Flash or Haiku 4.5 built it, a sensible reviewer is Sonnet 5, or a different family entirely, Grok 4.5 or an open-weight model like Kimi K3, whichever one wasn't already invested in the way the thing got built. I run a version of this on my own delivery work: one pass drafts, a separate pass reviews against the brief, a separate pass again checks the finished thing against what was actually promised, and none of those passes share a model with the one before it. That's not caution for its own sake, it's the entire reason the review step catches anything at all.

The loop back to the spec

Starting from scratch is rarely one pass through these three jobs. Real use throws up something the PRD didn't anticipate, a case nobody thought of, a customer asking for the thing just slightly differently than you specced it. When that happens, update the PRD first, then rebuild against the updated version. Skip that step and you're patching the built thing directly against a spec that no longer describes it, and the next review has nothing accurate to check against.

This is the difference between a product that stays legible to you as it grows and one that quietly drifts until you can't tell what it's actually supposed to do anymore (which is a worse place to be than not having shipped yet at all).

The cost logic, in one line

Spend on reasoning where a mistake is expensive to unwind: the spec, and the review. Spend on speed where the only cost of a miss is redoing one small thing: the build. Most first-time builders do this backwards without noticing, they burn their best model on boilerplate because building feels like the real work, and they rush the spec because writing a brief feels like the thing standing between them and building. It's the other way round. The spec is where the expensive mistakes actually live.

Next time you sit down to start something from scratch, don't open with "which model should I use." Open with "what are the three jobs here, who's doing each one, and which one of them has never seen this brief before." The model question sorts itself out after that, and it stays sorted through the next release, and the one after it.