9.1 Choosing a model for prototypes

The goal for prototypes

For prototypes, your goal is speed-to-feedback. You want to answer questions like:

• Is this idea viable?
• Can I build a runnable skeleton quickly?
• What are the tricky parts?
• What does the minimal “ship point” look like?

A prototype model choice is less about “perfect output” and more about keeping your iteration loop short.

Your default choice: fast + constrained

Most prototypes should start with a fast, cost-efficient model and strong constraints:

• tight scope (“build the walking skeleton only”),
• clear output format (file tree + code blocks),
• acceptance criteria (2–8 checks),
• no unnecessary dependencies.

This combination often beats “use the smartest model” because it reduces overreach and keeps diffs small.

When to upgrade from fast to smart

Upgrade when the problem is no longer “type code quickly.” Upgrade when it’s “think correctly.” Signs you should switch:

• you’ve tried 2–3 times and keep getting the same conceptual mistake,
• the task requires careful multi-step reasoning (e.g., parsing, tricky edge cases),
• the model keeps missing constraints even with a tight prompt,
• you need a trustworthy plan or tradeoff analysis.

Prototype-friendly settings (practical)

The exact UI will vary, but the intent is stable:

• Lower randomness: keep temperature low-to-moderate so it doesn’t invent features.
• Short outputs: ask for minimal runnable code first; refine later.
• Clear formats: file tree + code blocks; or JSON schema outputs when needed.
• Short context: don’t paste long histories; summarize state instead.

A prototype workflow that stays sane

1. Scaffold: generate file tree + stubs.
2. Make it run: implement one walking skeleton.
3. Lock: add a few tests and commit.
4. Iterate: add one feature per loop with acceptance criteria.

This is the same loop you practiced in Part II’s “Hello, Vibe” chapter—now applied with model selection discipline.

Common mistakes (and fixes)

Mistake: using the smartest model for everything

Fix: default to fast; escalate only when you need deeper reasoning. This keeps loops cheap and fast.

Mistake: relying on the model to choose architecture

Fix: constrain structure (modules, boundaries, output formats) and require a plan for anything non-trivial.

Mistake: staying in the playground

Fix: export to a repo and run code locally as soon as you have a skeleton. The playground is for drafting, not shipping.

Where to go next

• 9.2 Choosing a model for complex refactors
• 10. Prompt structure in AI Studio