Decisions

Use AI for research synthesis, first drafts, boilerplate, and exploration across options you will still choose between.

Do not use AI to skip the decision you are paid to make — what to build, what to cut, what truth the product owes users.

Think product engineer first when the risk is building the wrong thing, shipping the wrong scope, or mistaking a demo for trust.

Think software engineer first when the risk is data loss, payment errors, security, or unmaintainable architecture — even if AI wrote the first draft.

Use AI to map problem spaces, summarize interviews, compare existing solutions, and stress-test your one-sentence problem statement.

Do not use AI to replace contact with reality — compliments, synthetic personas, and "market research" that never names a specific human with a specific Tuesday are not discovery.

Use AI after you have raw material: transcripts, clips, support tickets, interview notes. Ask for themes, quotes tagged to speakers, competing explanations, and "what would change your mind."

Do not use AI as the only research subject — synthetic users, hallucinated quotes, and "personas" without a source row are fiction dressed as rigor.

Validate with experiments when you have a problem bet and need proof of demand, willingness to pay, or repeat behavior — before you invest in architecture.

Skip to vibe or code only when the risk is *shape* (Chapter 06) or *engineering truth* (auth, data, compliance) — not when the risk is still *whether anyone cares*.

Invest in taste when the product competes on trust, identity, or delight — fintech, health, creative tools, anything where "generic SaaS" is a liability.

Accept good-enough defaults when the bet is still workflow truth (Chapter 04) or internal tooling — polish later, but never confuse ugly with *unclear*.

Vibe prototype when the open question is *shape*: does this workflow feel worth finishing? Can a stranger grasp the value in ninety seconds?

Stop vibing when the open question is *truth*: billing, permissions, data integrity, performance under load, or "will they come back Tuesday?" — those belong in a codebase or a validation experiment, not a generated UI.

Stay in vibe tools until all three are true:

1. One paying or committed user (not a friend who said "cool"). 2. One workflow run ten times — you know the steps, not just the demo path. 3. One hard limitation the tool cannot carry (auth edge case, billing, compliance, performance, real data model).

Move to your own codebase when the next experiment is about reliability and revision, not about whether the idea deserves to exist.

Own the codebase when Chapter 07 exit criteria are met — committed users, repeated workflow, hard limits the vibe tool cannot carry.

Delay ownership when you are still falsifying demand or shape. A repo too early is expensive theater; a repo too late is trap in someone else's export format.

Pair with AI for bounded tasks — a ticket, a function, a test file, a refactor with clear before/after. You can state done criteria in one sentence.

Type it yourself (or pair human-to-human) when the change touches core architecture, security boundaries, or product calls you cannot yet explain — or when you are learning a new stack and need the muscle memory.

Use agentic workflows for repeatable multi-step work with clear verification — migrations across files, test-driven fixes, docs sync, scripted refactors with CI.

Do not delegate product scope, security policy, production deploy approval, or customer-facing copy without review — even if the agent "finished."

Invest in explicit architecture when the product has multiple contributors, paying users, regulated data, or expected life beyond six months.

Stay deliberately simple (monolith, one database, one deploy) when you are still falsifying scope — but write the simplification down as a *decision*, not an accident.

Automate tests for business rules, auth paths, payment webhooks, and regressions you have already fixed once.

Spot-check manually for taste, copy, and novel UX — but do not use manual QA as a substitute for tests on logic that will break silently.

Deploy automatically to preview on every meaningful PR — strangers never see it, you see behavior in a real URL.

Deploy to production only through a human-approved gate (or CI you trust) after checks pass — agents do not own the production button.

Instrument the core workflow and one north-star metric tied to your validation hypothesis (Chapter 04) — completion, return, payment, or time-to-value.

Do not instrument everything on day one — vanity pageviews and heatmaps without a decision rule are procrastination.

Iterate when metrics, support, or repeated user behavior disconfirm your current hypothesis — and you can name the smallest change that tests the revision.

Hold when signal is thin — one angry email, one competitor launch, one model saying "add AI chat" — unless it maps to your north star.

Scale infrastructure or team when a measured bottleneck blocks the north star — users cannot complete the workflow, you are losing money per user, or you cannot ship safely.

Do not scale to impress investors or because the model suggested Kubernetes — stay boring until the graph bends wrong.

Add governance when multiple people merge to production, customers depend on uptime, or agents run with repo access — light docs beat heavy bureaucracy.

Stay informal only while one human owns all gates and users are few — but write AGENTS.md and deploy rules anyway so future you is not guessing.