Pilot2Service Rapid Prototype & Vibe Coding Craft
Purpose
Build a prototype as fast as possible that is just credible enough to prove one specific hypothesis — no more. The most common mistake in an AI consultant's prototyping isn't a prototype that's too rough, but a prototype at the wrong level: either too thin to prove anything, or needlessly polished (time wasted on finishing touches nobody has asked for yet). This skill helps you pick the right fidelity level and use AI-assisted coding ("vibe coding") with discipline, so that speed doesn't buy invisible risk.
Anchored in research
- Vibe coding best practices 2026 (synthesis of multiple sources, see References): tool selection by task type, a tight iteration cycle, a PRD before prompting, known risks, and limits on where vibe coding is worth using.
- Prototype fidelity research (low vs. high fidelity): low-fidelity prototypes identify a large share of structural problems at a fraction of the cost of high fidelity — see References.
Method
- Define EXACTLY one hypothesis the prototype has to prove before you open any tool. Example of a good hypothesis: "AI can extract the correct supplier business ID and amount from 20 random purchase invoices without human correction." Example of a bad (too broad) hypothesis: "AI could help with the purchase-invoice process." If you can't state the hypothesis in one sentence that can be scored yes/no, you're still too early for prototyping. Keep the framing explicit throughout the build: a prototype is a tool to reduce strategic uncertainty about whether this is worth building for real, not a rough draft of the eventual product — treating it as the latter is what causes scope and polish to creep in past what the hypothesis actually needs. Give the team an explicit kill mandate: the authority and standing instruction to drop a prototype early once it's clear it won't prove the hypothesis, rather than continuing to invest in something already known not to work because stopping feels like admitting failure.
- Choose the fidelity level based on the hypothesis, not convenience:
- Low fidelity (a static mockup, a hand-built example, no working code) — enough when the question is structural: does the user understand the workflow, does the UI sequence make sense, is the vision appealing at all. The fastest, cheapest way to find fundamental problems before any code is written.
- A working, narrow prototype (genuinely functional, but on only one path, without error handling, without production infrastructure) — needed when the hypothesis is technical in nature ("can AI do X on our data with sufficient accuracy"). This is the core territory for vibe coding.
- High fidelity — only once a lower level has already validated the idea and the next question concerns the real user experience in a production-like environment. This usually isn't the job of a consultant's first demo. Watch for the high-fidelity trap: once a prototype looks visually finished, stakeholders reliably start discussing button colors and copy wording instead of the strategic question the prototype was built to answer — the moment a review conversation shifts from "does this prove the hypothesis" to cosmetic detail, the prototype has done its job too well for its own fidelity level, and it's a sign to either name the shift explicitly or deliberately roughen the finish back down.
- Choose the tool by task type, don't use one tool for everything. A rough rule of thumb: a full-stack application sketch → a general-purpose AI coding agent; complex editing/refactoring of existing code → an agent with good whole-codebase context; a fast, non-data-persisting demo/mockup → a lightweight no-code/low-code tool. Combine several tools as needed rather than forcing one tool onto every task.
- Write a short PRD (one page is enough) before prompting, even for a small prototype: what input is processed, what output is expected, which 2-3 cases REALLY have to work for the demo. This prevents the most common vibe coding pitfall: an AI agent building something technically functional but wrong, because the task was under-specified.
- Keep the iteration cycle tight and short: prompt one bounded change → review the result → test it right away with real (or realistic) data → commit or revert. Don't let errors pile up across a chain of several prompts before review — at that point it's hard to trace which change broke what.
- Apply "do the last thing first" to building too: build the part that
produces the demo moment's "aha" effect first (see
../demo-delivery-and-storytelling/SKILL.mdstep 3), don't start with infrastructure or edge cases the demo will never show. - Deliberately check before presenting or feeding in real data:
is authentication/authorization even roughly in place, are there
obvious hallucinated interface calls in the code, does the prototype
actually process sensitive data (if so, don't use real data without
separate permission and safeguards). Clearly mark what has NOT been
checked, and never give the impression that "the demo works" means
"it's production-ready" (see the pack's
../../CLAUDE.md). - Hand off the output either directly to
../demo-delivery-and-storytelling/SKILL.mdfor the presentation, or, if the hypothesis wasn't yet clear enough to test in code, to../opportunity-visioning-with-pr-faq/SKILL.mdto deepen the vision before the next prototyping round.
What this skill does NOT do
- Doesn't design production-ready application architecture — produces a narrow, hypothesis-proving prototype.
- Doesn't guarantee the security or reliability of AI-assisted code —
always remind yourself to check authentication, error handling, and the
correctness of interface calls before the prototype is used with real
data or shown to outsiders (see the pack's
../../CLAUDE.md). - Doesn't choose the technical architecture for a production phase — if the
hypothesis is proven and the next step is a production-grade solution,
use
../../../ai-strategy-and-governance/skills/ai-use-case-feasibility-and-poc-scoping/SKILL.mdand../../../ai-strategy-and-governance/skills/build-vs-buy-vs-partner-ai/SKILL.md. - Doesn't measure or calculate ROI from the prototype's results — that's the
job of
../demo-to-business-case-bridge/SKILL.md.
Refinement notes
Areas to keep deepening with real practice:
- your own favorite tools and when to use each (which tool for which task type in your own practice)
- concrete examples of prototyping efforts that failed and what went wrong (wrong fidelity level, hypothesis too broad, etc.)
- your own PRD template for a short prototype (into
../../references/)
This is an internal working note, not a claim about the skill's current
usability. Track depth privately via the maturity field in
skills_index.json (see
../../../meta/maturity_levels.md).
Don't add new fields to the frontmatter — name and description are
the only ones allowed (see
../../../meta/frontmatter_schema.md).
Continue from here
- Next in this pack:
../demo-framing-and-expectation-setting/SKILL.md— frame what this prototype MEANS for the customer before presenting it. - In this pack (delivery):
../demo-delivery-and-storytelling/SKILL.md - If the hypothesis wasn't yet clear before coding:
../opportunity-visioning-with-pr-faq/SKILL.md - Before this (if a fitting industry pattern is still missing):
../../../ai-strategy-and-governance/skills/ai-capability-pattern-matching/SKILL.md - A ready-made skill chain for this situation: see
../../../playbooks/ - This pack's shared guardrails:
../../CLAUDE.md
References
- Vibe coding best practices 2026 — tool selection, iteration cycle, PRD-first principle, and known risks (hallucinated interfaces, gaps in auth/authorization logic, maintainability) — synthesis of multiple 2026 sources
- Prototype fidelity research (UX research tradition: low-fidelity prototypes reveal a large share of structural problems at a fraction of the cost of high fidelity)
- The "kill mandate" and "reduces strategic uncertainty, not a pre-version
of the product" framing in step 1 is attributed in its source material
to AI-engineering practitioner Joshua Ebner; his general practice area
is confirmed, the exact quote is not — see
../../../human-ai-collaboration-design/references/hitl-partnership-heuristics-research.mdfor the verification detail ../../references/— the pack's shared background material../../CLAUDE.md— the pack's shared guardrails