AI Prototyping

Core thesis

AI prototyping is not faster mockups. It is a new learning system. Working software is now a decision artifact. Build working artifacts to compress the distance between hypothesis and evidence. Prototype only to answer a decision. Store reusable context so every future build starts from accumulated intelligence, not zero. Ship production only after the prototype has produced conviction.

Prototype type selector

• Concept: which direction deserves more work? Low to medium fidelity.
• Design: what experience do we mean? Medium to high fidelity.
• Research: do users understand, want, or can use it? High enough for suspension of disbelief.
• Technical: does the hard thing work? Ugly but measurable.

Context engineering framework

Use Functionality + Design + Data. Functional context defines behavior (target user, core actions, system responses, all states, scope). Visual context defines look and feel (design system, typography, colors, spacing, tone, responsive behavior). Data context defines realism (entities, relationships, realistic samples, edge cases — never lorem ipsum). Context engineering beats long prompting.

The complexity ladder

Climb only as high as the decision requires. Static or lightly interactive prototype → hard-coded states with realistic samples → localStorage for single-user persistence → database for shared state → authenticated persistence for personalization and roles → external API for live capability → engineering-owned technical prototype for production feasibility.

API rules

Use APIs only when live data materially improves the signal. Before integrating: can this be mocked? Does live realism affect the decision? Is the key safe to expose client-side? Does this require backend routing? What loading, empty, and error states are needed?

Debugging ladder and three-strike rule

• Refresh preview → reload browser → describe expected vs actual behavior → add screenshot or selected element → copy console error into AI builder → ask AI to add logging → investigate without changing code → revert to last known good version → duplicate or fork and try different approach → rebuild from saved prompt or context → graduate to stronger tool

PRDs do not disappear — they shrink and sharpen

The prototype owns the "what." The PRD owns the "why," metrics, constraints, risk, rollout, and open questions. Prototype code is usually reference, not production. Handoff must separate intentional, incidental, and unresolved details.

Customer testing doctrine

Start with the research question, not the prototype. Better questions: can users complete setup without help? Do users understand the value before we explain it? Do users notice and use the key feature without prompting? Would this replace their current workaround? Where do they hesitate, misinterpret, or abandon? Use think-aloud testing. Ask representative users to perform representative tasks, then mostly shut up and observe.

The product-to-content loop

Identify opportunity or market hypothesis → build a focused prototype or artifact → test with target users, community, synthetic users, or analytics → capture before/after, decisions, failures, and surprising signals → publish artifact-backed content → feed replies and usage back into research. Working software is the new product memo. Prototype reviews should end with a decision, not opinions.