Seven Tips for Vibe Coders

We build most new products the same way: gather a few inputs, point an agent at a template, and have something live the same day. The speed has little to do with clever prompting. It comes from decisions made long before any prompt gets typed, and those decisions repeat across every product. Here are seven of them.

1. Go deep on one stack

Every product we ship runs on the same four technologies: Nuxt, Nuxt UI, Supabase, and Vercel. Unless a project literally cannot use them, it uses them.

The payoff is depth. You stop worrying about dependencies and integration because you have wired each piece together a dozen times. You follow the release notes of four projects instead of forty. And when an agent proposes code, you can judge it at a glance. That judgment speed is the real bottleneck in agentic work, because the agent writes far faster than you can review.

The usual objection is that everything ends up looking the same. Theming solves that. All of our apps sit on one component library, restyled per product until they read as entirely different brands. One library you know cold gives you more range than a new UI kit every project, because you know exactly which knobs to turn.

2. Start from a full product template

Keep a starter repo that is a complete, running product: auth, database, background jobs, analytics, error tracking, a landing page, a deploy pipeline. Starting a new product means copying that repo, rebranding the chrome, and deleting what you do not need.

This collapses a hundred small decisions into zero. Which auth flow, which folder structure, how analytics events are shaped, how the app deploys: all answered before the idea exists. The distance from "I want to build this" to "it is live at a URL" shrinks from days to about an hour.

Treat the template as a living thing. When a product teaches you something, fold the lesson back into the starter so every future product is born already knowing it.

3. Prototype on the real product

This is the controversial one. Skip the wireframes. Do the prototyping phase in the production codebase, with the real components, the real data layer, and the real deploy.

Wireframes and Figma mocks earned their place when real implementations were expensive to change. Agents ended that. When rebuilding a screen costs Claude Code or Codex twenty minutes, the real screen is the cheapest prototype available, and the only one that surfaces integration problems while you are still sketching. We still storyboard the occasional fork in the road, like two directions for a hero or two shapes for an onboarding flow, when seeing alternatives side by side genuinely helps a decision. Everything else gets decided in the product itself.

4. Turn your process into skills

An agent session is improvised. A skill is written down. The most reliable parts of our process live as skills: a written implementation-plan procedure that turns a feature idea into ordered sprints, a ship-to-production procedure that tests, merges, deploys, and smoke-tests the live site, a verification pass that walks the product like a user before anything merges.

Skills compound in a way sessions cannot. When a deploy goes sideways, the fix lands in the skill, and that mistake retires permanently. After six months the value lives in the procedures, and any capable agent can execute them.

5. Give the agent durable memory

Every serious repo should carry an instructions file: CLAUDE.md, AGENTS.md, whichever your tools read. It holds the things code cannot state about itself: which port the dev server runs on, how API calls are structured, what the brand voice sounds like, which decisions are settled and why. Layer persistent memory on top so corrections survive across sessions.

The rule that makes this work: every time you correct the agent, ask where that correction should live. A correction that lands in a file happens once. A correction that lands in chat happens weekly, forever.

6. Find the minimal set of inputs that specifies the product

Before building anything, ask what documents would let a stranger build the right thing. The answer is usually smaller than people expect. A short PRD and one rough mock is often plenty. So are the notes from a single customer call plus a competitor's pricing page.

The discipline is recognizing the threshold. Once the inputs pin down what the thing is, stop gathering and start building. With a solid template and a stack you know, a working version can exist in under an hour, and a working version in front of a client or a market pulls sharper feedback than another week of discovery ever will.

7. Stop polishing prompts

Prompt engineering got a level of attention it no longer deserves in this workflow. What an agent builds is determined by the six practices above plus the raw inputs you hand it, and barely at all by the phrasing of your request. Spec-driven development has the same problem: with a settled stack and template, most of the spec is predetermined, with small variations where the product genuinely differs.

So gather the inputs, drop them into the session, turn on dictation (we use Wispr Flow), and talk at the agent the way you would brief a colleague, stream of consciousness included. It will figure it out. The craft moved out of the prompt and into everything around it.

All seven practices do the same job: they move effort out of individual projects and into machinery that gets reused on every one that follows. That is the actual work of vibe coding. The typing was never the bottleneck.