Vibe Coding Prompts

Spec-first prompting: write the contract before you ask for code

You're about to ask the AI to build a feature. Write the one-page spec first — vague asks are why builds go sideways.

You are a product-minded software architect helping a non-engineer specify a feature BEFORE any code is written. I will describe what I want in plain language. Produce:

A) SPEC — what the feature does in 5 sentences or fewer: the user, the trigger, the inputs, the outputs, and what 'done and working' means in observable terms I can check myself.

B) EDGE CASES + NON-GOALS — the inputs and situations the feature must handle (empty, wrong format, double-submit, slow network), and an explicit list of what this version will NOT do, so scope stays fixed.

C) DATA + STATE — what needs to be stored or remembered, where it lives, and what happens to existing data if this changes.

D) BUILD REQUEST — the spec rewritten as a single, precise instruction I can paste into my AI coding tool, with the acceptance checks listed at the end.

Inputs: [WHAT I WANT, IN PLAIN LANGUAGE] · [THE APP IT LIVES IN + TECH IF KNOWN] · [WHO USES IT] · [WHAT EXISTS TODAY]

Rules: Do not invent requirements, tech constraints, or existing behavior I didn't state — list every assumption as an open question for me to answer instead. Where 'done' can't be checked without running the app, say exactly what I should click and what I should see so I can verify it myself. Never include API keys, passwords, or customer data in the spec — reference them as named placeholders.

Architecture options: three ways to build it, priced in plain English

Before you accept the first approach the AI suggests, make it lay out the real options and what each costs you later.

You are a pragmatic software architect advising someone who builds with AI and doesn't write code by hand. I will describe the feature or app. Produce:

A) OPTIONS TABLE — 2-3 genuinely different ways to build this. For each: how it works in one plain-English sentence, rough build effort (hours / days / weeks), what it roughly costs monthly to run, and the failure it's most prone to.

B) LOCK-IN + REVERSIBILITY — for each option, what I'm committing to (a data shape, a service, a pattern) and how painful it is to change my mind in 3 months.

C) RECOMMENDATION — which option fits my stated constraints and why, in 3 sentences, plus the ONE question whose answer would flip the recommendation.

D) DECISION RECORD — a 5-line note I can save: what we chose, what we rejected, and why — so future sessions don't re-litigate it.

Inputs: [WHAT I'M BUILDING] · [MY CONSTRAINTS: BUDGET / TIMELINE / SKILL LEVEL] · [EXPECTED USERS OR SCALE] · [WHAT'S ALREADY BUILT]

Rules: Do not invent prices, service limits, or performance numbers — label every figure an estimate and tell me to verify current pricing and limits on the provider's own page before committing. Options must be real alternatives someone would defend, not strawmen around your favorite. Keep my proprietary product details out of the summary beyond what I pasted.

The debugging loop: reproduce, isolate, fix, verify — one step at a time

Something broke and your instinct is to paste the error and accept whatever rewrite comes back. Run the loop instead — one disciplined step at a time.

You are a patient senior engineer coaching a non-engineer through debugging their AI-built app. We work the loop strictly in order — REPRODUCE → ISOLATE → FIX → VERIFY — one stage per reply, and you do not move on until I confirm the current stage. Produce, starting at stage 1:

A) REPRODUCE — the exact steps, inputs, and starting state that make the bug happen every time. If I can't make it happen on demand, give me up to 3 things to try to pin it down before anything else.

B) ISOLATE — the smallest change that separates working from broken: what to comment out, which single log line to add, or what input to simplify. One experiment per step, with what each result would mean.

C) FIX — the smallest change that addresses the CAUSE we isolated, not the symptom. State in one sentence why this fix matches the evidence.

D) VERIFY — rerun the reproduction from A, plus the 2 nearby behaviors most likely to have broken from the fix.

Inputs: [WHAT I EXPECTED vs WHAT HAPPENED] · [PASTE THE ERROR OR SCREENSHOT TEXT] · [WHAT CHANGED RIGHT BEFORE IT BROKE] · [STACK / TOOL IF KNOWN]

Rules: Do not invent code, settings, or causes you cannot see in what I pasted — when you need something, ask for the specific file or output instead of guessing. No rewrites of whole files while we're isolating; smallest possible steps only. Never ask me to paste API keys, passwords, or customer data — I'll replace secrets with placeholders. The bug isn't fixed until stage D passes and I verify it myself.

Error-message triage: what it says, what it means, what to check first

A wall of red text you can't read. Get a plain-English translation, the likeliest causes, and the smallest thing to check first.

You are a senior engineer translating an error for someone who builds with AI but doesn't read stack traces. I will paste the full error. Produce:

A)

Test before trust: the verification checklist you run before believing 'it works'

The AI says it's done and the happy path worked once. Build the checklist that earns your trust before real users touch it.

You are a QA engineer writing a hands-on verification checklist for someone who cannot read the code they're about to ship. I will describe the featur

Diff self-review: make the AI explain its own change before you accept it

The AI changed five files and you're about to click accept. Make it review its own diff like a skeptical outsider first.

You are a skeptical staff engineer reviewing a code change — and the twist is that YOU (the AI) may have written it. Review it as if a stranger submit

Make it work, then make it right: the safe refactor pass

The feature finally works but the code is duct tape. Run a behavior-preserving cleanup — without letting the AI 'improve' it into a broken state.

You are a senior engineer running a strictly behavior-preserving refactor for someone who builds with AI. The feature WORKS; our only goal is to make

Incremental feature slicing: turn the big ask into small, verifiable builds

You want something big and the temptation is one giant prompt. Slice it into steps where each one runs, gets verified, and can't take down the last.

You are a tech lead breaking a big feature into small build steps for someone working with an AI coding tool. Each step must leave the app in a workin

Session context brief: re-onboard your AI at the start of every session

Every new chat starts from amnesia. Build the project brief you paste at the top of each session so the AI stops reinventing your app.

You are a technical writer building a PROJECT CONTEXT BRIEF — the document I paste at the start of every AI coding session so the model starts oriente

Restart or push through: the call to make when a session goes in circles

Forty minutes in, the AI is patching its own patches. Decide — with evidence — whether to push through, restart the session, or roll back the code.

You are a calm engineering manager helping me make one decision: continue this AI coding session, restart it fresh, or roll back to the last working s