Prompt Patterns That Actually Ship Production Websites (And the Ones That Don’t)

Most prompt advice dies at the door of production. You can get an agent to produce a stunning demo with five casual sentences; you cannot get it to ship a paying product that way. The gap between "it works on the happy path" and "it holds up on day ninety" is almost always a prompting gap. Same agent. Same model. Different discipline.

This piece is a short, tactical playbook. Four failure modes to recognise and eliminate, seven patterns that consistently produce shippable output, and a copy-paste prompt pack for the tasks you run every week. Everything below is battle-tested on real codebases with real users.

Four failure modes that keep you in demo-forever mode

1. The kitchen-sink prompt

"Add a settings page, wire Stripe, add dark mode, and hook up Sentry." Five minutes later, nothing works and you cannot tell why. The agent touched fifteen files; at least three are wrong in ways you will not catch without writing your own tests. Scope is the single highest-leverage constraint in vibe coding. One slice per prompt. Always.

2. The make-it-nicer prompt

"Can you make this look a bit nicer?" The agent will happily comply, by inventing a new button style, a new shade of gray, and a gradient you did not ask for. Vague qualitative feedback produces qualitatively random output. Describe the specific change, or describe a reference you want it to match. Never both vague and aspirational.

3. The can-you-also prompt

Mid-session scope creep. "Now can you also update the settings page while you are there?" This is how a clean 20-line diff becomes a 400-line one that fails code review. Pushback rule: if the "also" was worth a prompt of its own, it is worth a separate commit. Close the current task, start a new one.

4. The just-trust-me prompt

"Refactor the auth flow." No acceptance criteria, no scope list, no file budget. The agent will do something, rarely what you had in mind. Treat every non-trivial request like a JIRA ticket: what is the outcome, what files are in/out of scope, how do we verify.

Seven patterns that consistently ship

Pattern A, Anchor-and-task

Every meaningful prompt opens with two lines of brand/product context before it gets to the task. "This is a fintech product for indie founders in Europe. Tone is confident, quiet, adult." The agent stops defaulting to SaaS-beige and starts making choices aligned with your product. This is the single pattern with the highest return on investment.

Pattern B, Contract-first

For anything touching a function, API, or component, state the contract upfront: the signature, the input shape, the output shape, the empty state, the error state. The agent goes from "creative writing" to "fill in the blanks", and the output becomes verifiable on sight.

Pattern C, Propose-before-edit

For anything that will touch more than one file, ask for a plan first. "Propose a plan. Do not edit anything yet." You read the plan, push back on the bits that miss something, then let the agent execute a version you actually agree with. Five minutes of planning saves an hour of untangling.

Pattern D, Scope-lock

Explicitly list the files the agent is allowed to touch, and the files it must not. "You may edit: src/components/Pricing.tsx and messages/*.json. You must not edit anything else." Scope-locks convert the agent from a creative collaborator to a precise executor for the duration of a single task.

Pattern E, Repro-driven

For bugs, give the agent a failing case and a passing case. "Input X currently produces output Y. We expect output Z. Here is the failing test." The fix rate goes up sharply when the agent has both sides of the contract to hold.

Pattern F, Rollback-plan

Before any risky change, ask for three ways it could go wrong and three ways to roll back. You will occasionally discover a problem the agent flags that you would have missed; more often, you just end up with an informed plan instead of an optimistic one.

Pattern G, Review-mode

After the agent finishes a change, switch modes and ask for a self-review. "Review the diff as if you were a senior reviewer. What would you push back on?" The agent is surprisingly good at this when explicitly asked, and will flag issues it would not spontaneously surface.

Copy-paste prompt pack

Drop these into Claude Code, Cursor, v0, or Lovable. Edit the bracketed parts for your project, keep the skeleton. Each template composes the patterns above into a prompt that ships.

New feature slice

Product: [one-line description]. Tone: [three adjectives]. Task: add [one feature slice in one sentence]. Contract: the component takes [props shape] and renders [outcome]. Empty state: [what shows]. Error state: [what shows]. You may edit: [file list]. You must not edit: anything else. Propose a short plan first, then execute.

Bug fix with repro

Product: [one-line description]. Bug: [what the user sees]. Reproduction: [exact steps]. Current behaviour: [observed]. Expected behaviour: [desired]. Failing test (if any): [path]. Scope: the fix must live in [file] or propose why a broader change is required. Rollback plan: list three ways the fix could regress something and how to catch it.

Refactor with invariants

Product: [one-line description]. Refactor goal: [what changes, what stays]. Invariants that must not change: [list the public API, behaviour, types that remain stable]. Files in scope: [list]. Files out of scope: [list]. Show a short plan before editing. After the edit, do a self-review: what did you change, what did you not, and what would a senior reviewer flag.

Design-to-code from a reference

Brand: [paste your brand spec here]. Task: render [section or page]. Reference: [URL or description of the aesthetic target]. Constraints: use only tokens from [design system file]. Must ship: [list of mandatory elements]. Must not invent: new colors, new fonts, new spacing tokens. Before editing, list the tokens you plan to use and confirm they exist.

Code review on your own diff

Review the current branch against main as if you were a senior reviewer at a serious team. For each file changed: is the scope appropriate, does the change respect the existing conventions, are tests sufficient, is anything unsafe (auth, money, data access, unescaped output). Output a numbered list of concrete concerns, most important first.

Test writing

Function under test: [path/signature]. Inputs: [what varies]. For each of the following, write one test: happy path, empty input, invalid input, boundary case, and one realistic edge case specific to this domain. Keep each test under 20 lines. Do not mock beyond what is strictly necessary.

Documentation

Target reader: [persona]. Their question: [what they need to answer in 60 seconds]. Write the doc as if answering that question. Maximum [N] words. One runnable code example. No marketing copy. If the question cannot be answered without a concept they do not yet know, put that concept in a two-sentence primer at the top.

When to stop iterating

Vibe coding loops can compound, each fix is 90% of the problem, so you are always one more prompt away from done. The trap is real. Two stop conditions that save time:

• If the same issue has round-tripped three times without progress, stop. Delete the branch, re-read your own prompt, rewrite it tighter. The agent is not going to un-dig the hole.
• If the diff has grown beyond what you would review in a single sitting, stop. Commit what is good, push the rest into a separate task with its own scope lock.

The one upstream step that makes every prompt better

Every pattern above compounds on one thing: the first two lines of context. "This is a [product] for [audience], tone is [adjectives], design principles are [three lines]." Without it, each pattern works half as well. With it, even your worst prompt produces passable output. That two-line context is the portable output of a real brand spec, and you build it once, not every session.

Keep going

The headline from all five pieces in this series: tools multiply output, but only in the direction you already pointed them. Point them with a brand, constrain them with scope, review every diff. Then watch a one-person team ship at the pace of a five-person one.