# Vibe coding patterns

> Three patterns that turn a one-line prompt into something genuinely good. One-shotting, content + form, and the make-it-better loop

_12 min · intermediate · track: vibe-coding · id: vibe-coding-patterns_

> **Team:** 
>
> Vibe coding is one of the most powerful ways to use [Claude Code](/course/claude-code).
> The range is wide: a one-sentence prompt that produces something working
> in five minutes, all the way to a long evening where you keep nudging the
> agent until the result is genuinely good. Everything happens in plain
> English. A few simple patterns are the difference between a throwaway
> result and one you actually want to share.

## Vibe coding vs. agentic engineering

**These are two different disciplines, and the difference matters.**

**Vibe coding** is what this course covers. You go with the flow. You point the agent in a direction, watch what shows up, react. No spec, no test plan, no review checklist. The output is fun, often surprising, sometimes shippable to an internal audience, almost never production-grade for a customer.

**Agentic engineering** is the other end. You design a system around the agent: feedback loops, sub-agents, eval harnesses, real skills, real test coverage. The goal is for the agent run to deliver code at the same quality bar you would set if you wrote it by hand, or above. It is closer to software engineering than to play.

Both are useful. They reward different habits. Vibe coding is the right starting point. Once you outgrow it, the Agentic engineering track at Level 4 is where you go.

## A common misconception

**The default narrative sells vibe coding short.** "It's just firing off a vague prompt and seeing what comes out." A vague one-line prompt is the floor. The ceiling is "twenty minutes of thinking about what I actually want, then a paragraph that lays it out, then the agent runs." That extra twenty minutes is still vibe coding (no spec, no tests, no engineering rigour) and it produces a different class of result. The three patterns below are the cheapest ways to spend that extra thought.

> **Warning:** 
>
> Take a snapshot before you start. The [version control](/course/version-control)
> habit applies double in vibe-coding sessions. Claude Code can rewrite forty
> files in a minute, and you want a clean way back to the version that made
> you smile.

## Pattern 1: One-shot it

**Throw a prompt in and let the model interpret. Don't shape the result.** No plan, no constraints, no examples. You want to see what the model does when given room.

The point isn't that you fully control the output. It is the opposite: the model brings its own reading of the prompt, and that reading is often more interesting than what you would have specified yourself. Vibe coding rewards staying out of the way on round one.

Lean into prompts that have no obvious right answer:

- "A webpage that explains my company's strategy as if it were a 1990s arcade cabinet manual."
- "An interactive page that simulates the inside of my brain at 4pm on a Wednesday."
- "A dashboard for measuring how badly I want to be in this meeting."

There is no template the model can pattern-match against here. Whatever shows up is the model's interpretation, and that is the part worth paying attention to.

When NOT to use: anything you will show a customer, anything that has to be defensible. One-shotting is for surprise, not production.

## Pattern 2: Content + form

**Take real content. Pair it with a form the model already knows cold. The agent fits one to the other.** This is the highest-payoff vibe-coding move, especially for turning dry material into something people actually engage with.

- **Form:** a layout the model has seen ten thousand times. A Jeopardy board, Duolingo flashcards, a Pinterest grid, a choose-your-own-adventure, a retro arcade dashboard. A game also fits here. The [Build a game](/course/build-a-game) course is a worked example: the TechWolf onboarding game pairs a Pokemon-style RPG (form) with the team's actual Slack history (content).
- **Content:** your strategy deck, the onboarding doc, the last quarter of customer-call notes, your product spec, your meeting recap.
- **Result:** the form is solid because the model knows it cold; your content slots in without you having to design either piece.

Quality goes up, time-to-first-version goes down. The agent does not have to invent both the form and the content from scratch.

> **Tip:** 
>
> **Try it.** Take a doc lying around that nobody reads (a strategy memo, a handbook, a meeting recap). In Claude Code, give it the doc as input and ask: "Turn this into a Jeopardy-style quiz as a single HTML file. Categories from the section headings, questions from the actual content." Open. Send to a teammate.

## Pattern 3: Make it better

**Say "make it better" two or three times after the first version. Read the diffs.** Each pass tightens layout, palette, and edge cases without you specifying what to fix. You felt this already in the [Build a game](/course/build-a-game) exercise.

Two limits: diminishing returns kick in around round four, and no number of polish passes will save a weak concept.

[Ethan Mollick](https://www.oneusefulthing.org/) has written extensively about how much of a delta this loop produces in practice. It is one of the cheapest, most underused moves in the toolkit.

## Reflect

- Next time you are tempted to skip vibe coding because "this isn't serious work", what would you actually lose by spending fifteen minutes on it before the real version?
- Pick one document at your work that nobody reads. Which form would the model fit it into well, and what does that say about the document?