HOW TO VIBE CODE
WITHOUT LOSING THE PLOT.
A practical guide to prompt-led software building. Use a fast first draft to learn faster—but make the unknowns explicit before somebody depends on the result.
Download the Field Guide ↓A language shortcut, not a standard.
Vibe coding describes a way of making software where a person uses natural-language instructions and generative tools to produce and revise code. Its exact meaning varies across communities. It can mean anything from exploratory prompting to heavier delegation. That is why a practical discussion should name the tool, task, constraints and review process, rather than treating a catchy label as a universal method.
AI tools can reduce the work needed to begin. They can also transfer work into testing, debugging, reviewing and maintaining. A short demonstration that “looks right” tells you little about the empty states, permissions, data flow and future edits.
The reality-check distinction
Prototype question: Can we make this idea legible enough to learn something?
Production question: Is it safe and reliable for intended users, in actual conditions, with a real owner and repair path?
The 2026 Stack Overflow Developer Survey reports many respondents checking generated output locally or against existing code context, rather than using the answer unchanged. The survey describes its respondents; it does not prove a universal productivity effect. Read the survey's detailed tables.
Five moves that preserve judgment.
- Specify: name the user, task, constraints, input shape, desired output and what counts as a failure.
- Draft: ask for the smallest testable version. Prefer understandable dependencies and a clear file structure.
- Inspect: read code paths that touch data, permissions, errors and external services. Ask where assumptions hide.
- Test: check happy paths, edge cases, keyboard usage, real device widths and cases you have not told the generator about.
- Hand over: document how to run, change, deploy, rollback and retire the thing you made.
Why small beats magical
A tiny program whose rules you can inspect is more educational than a mysterious 30-feature dashboard. Complexity becomes justified when users actually need it—not because it makes a launch screenshot look busier.
A brief that contains a test.
“Make me a calculator” leaves dozens of decisions unexplored. A better request includes intent, allowed inputs, error behavior, accessibility, privacy and what the tool must not pretend to do. Here is a reusable structure for any AI coding assistant:
USER: Someone doing a small calculation on a phone. TASK: Add two numbers, including negative and decimal values. INPUT RULE: Reject blanks; do not silently turn them into zero. OUTPUT: Readable result and clear error messages. CONSTRAINTS: Semantic HTML, keyboard input, no tracking. FILES: index.html, styles.css, app.js, README.md. EVIDENCE: Show three manual tests with expected outcomes. LIMIT: Do not claim security or accessibility certification.
The workshop's “Copy build specification” command generates a version of this brief from your selected case and constraints. The workshop itself is deterministic; the prompt is for use with an external assistant if you choose.
Tests are a conversation with reality.
A helpful test does not merely replay the demonstration. It tries to find where the stated contract breaks. For a portfolio search, ask what appears when nothing matches. For a neighbourhood order tracker, ask whether quantity zero is a valid order. For a calculator, decide whether blank and zero mean different things.
| Check | Question | Evidence needed |
|---|---|---|
| Function | Does the core task work? | Expected and observed outcomes for normal and unusual inputs |
| Accessibility | Can the task be completed without a mouse? | Keyboard route, focus, visible labels and announcement tests |
| Privacy | Where does information go? | Network inspection, storage inventory, documented retention |
| Security | Who may access or change data? | Server-side authorization and threat review where appropriate |
| Maintenance | Who repairs the result? | README, version history and rollback or decommissioning plan |
Consult MDN on client-side validation, WCAG 2.2, and the OWASP Top 10:2025 for different—but complementary—layers of this work.
What the workshop will not pretend.
The simulation does not call a live model, evaluate arbitrary programs, scan a repository, assess your cognition, certify security or predict how long professional development should take. Its tests are authored teaching checks. The downloadable starters are real code; they are intentionally tiny and omit servers, accounts and payments. A preview is not a production release.
A 2026 preprint reviewing vibe-coding research describes conflicting productivity findings under different tasks and measurement methods. Read it as a research synthesis in progress, not a settled universal rule. Read the preprint. For broader testing practice, see MDN's cross-browser testing guide.
Where craft enters
The question is not whether AI helped make the code. It is what the artifact actually does, what claims we can justify, who bears the cost of its failures, and whether its next maintainer can make a change without summoning its creator.
BUILD A TESTABLE IDEA.
Choose a starter, watch its edge case fail, repair it and take away the files.