Plan
Confirm the smallest change, files affected, assumptions, and expected result.
DiscoveryVIP Field Guide • Version 2Vibe Coding
Vibe Coding
Field Guide V2
A practical, reusable playbook for building software with AI while keeping the work focused, understandable, testable, and safe to release.
Start with one complete user outcome
Vibe coding is most effective when the first target is small enough to understand and complete. Describe one person, one problem, one action, and one visible result. This becomes the thin slice that proves the idea before more features are added.
Field rule: If you cannot describe how a person verifies the result, the outcome is not yet specific enough.
Use this 15-minute setup
- Write the user outcome in one sentence.
- List three essential behaviors and move everything else to “later.”
- Name the technology, hosting limits, and existing files.
- Define a manual test for the complete journey.
- Ask the AI to expose assumptions before it changes code.
Create a project brief the AI can follow
A strong brief prevents the model from inventing requirements or choosing incompatible technology. Keep it short, concrete, and testable; update it when a decision changes.
PROJECT: [short name]
USER: [who this helps]
OUTCOME: [one result the user can achieve]
CURRENT STATE: [files, URL, or starting point]
STACK: [languages, framework, hosting]
MUST HAVE: [three to five behaviors]
CONSTRAINTS: [security, privacy, accessibility, browser, budget]
NOT NOW: [features deliberately postponed]
DONE WHEN: [observable checks that must pass]
Use the Plan → Change → Check → Explain loop
Change
Implement one reviewable unit without unrelated rewrites or surprise dependencies.
Check
Run syntax checks, automated tests, and the real user flow. Record what actually happened.
Explain
Summarize the change, evidence, remaining risks, and the next smallest step.
Repeat the loop for every meaningful feature. Small loops make failures easier to locate and successful changes easier to keep.
Prompt for decisions and evidence
Planning prompt
Turn this goal into the smallest end-to-end version a real user can complete. List assumptions, affected components, acceptance checks, and features that should wait. Do not write code yet.
Implementation prompt
Implement only the agreed step. Preserve existing behavior and style. Show the files changed, explain important decisions, and give exact verification steps. Do not add dependencies unless they are necessary and explained.
Review prompt
Review this change for correctness, security, privacy, accessibility, performance, edge cases, and unnecessary complexity. Separate confirmed problems from possible risks and provide a test for each claim.
Build a compact context package
More context is not always better. Supply the smallest set that lets the AI reason correctly without burying the important details.
- The goal and definition of done.
- The relevant file tree and only the files involved.
- Framework and runtime versions.
- Existing conventions, reusable components, and design tokens.
- The exact error, input, reproduction steps, and expected result.
- Constraints such as supported browsers, hosting, privacy, and accessibility.
Remove passwords, API keys, private customer data, access tokens, and environment secrets before sharing context.
Verification is part of the build
Generated code can look polished and still be wrong. Verify behavior at several levels, starting with the fastest useful check.
- Syntax and type checks pass
- Automated tests pass
- Primary user journey works
- Invalid input is handled
- Empty and loading states work
- Keyboard navigation works
- Mobile layout remains usable
- Errors are clear and recoverable
Use an evidence note
CHANGE TESTED: [feature or fix]
ENVIRONMENT: [browser/runtime/device]
STEPS: [exact actions]
EXPECTED: [observable result]
OBSERVED: [what happened]
STATUS: PASS / FAIL / PARTIAL
FOLLOW-UP: [remaining work or risk]
Debug by narrowing the problem
- Reproduce the failure consistently.
- Capture the exact error and the smallest failing input.
- Identify the boundary where correct data becomes incorrect.
- Ask for ranked hypotheses and one diagnostic check per hypothesis.
- Change one variable, rerun the reproduction, and compare the evidence.
- Add a regression test before closing the issue.
Do not fix the code yet. Using the error and reproduction below, rank the three most likely causes. For each, provide the smallest check that can confirm or reject it. Clearly label assumptions.
Pass four review gates
Behavior
Does the feature meet every acceptance check, including failures and edge cases?
Trust
Are inputs validated, secrets protected, permissions limited, and data handled appropriately?
Experience
Is the interface responsive, accessible, understandable, and useful without special knowledge?
Maintainability
Can another developer understand the structure, decisions, dependencies, and tests?
Release with a rollback path
- Production configuration checked
- Secrets kept server-side
- Database backup confirmed
- Dependencies reviewed
- Analytics and logs avoid private data
- Error pages are useful
- Performance checked on mobile
- Rollback steps are documented
- Smoke test completed after release
- Known limitations recorded
After deployment, run the shortest complete user journey in the real environment. A successful build is not the same as a successful release.
Reusable field templates
Change request
GOAL: [one outcome]
SCOPE: [what may change]
PRESERVE: [behavior that must remain]
ACCEPTANCE CHECKS: [observable tests]
OUT OF SCOPE: [what not to add]
DELIVER: [changed files, explanation, verification]
Session handoff
CURRENT GOAL: [outcome]
COMPLETED: [working changes]
EVIDENCE: [tests and observed results]
DECISIONS: [important choices and why]
OPEN ISSUES: [known failures or risks]
NEXT STEP: [one smallest action]
DO NOT CHANGE: [protected behavior or files]