How to Vibe Code (Without Breaking Everything Later)

Do you remember the first time you asked AI to build something and it actually worked? You probably spoke to it like a real person and got back a real, working app.

It feels like cheating, and for simple stuff it genuinely is that easy. A landing page, a contact form, a basic tool for yourself or your team. You can talk it into existence.

This is why everyone's obsessed with vibe coding right now. You can one shot prototypes, pilots and demos. And even when you start to push it a bit further and notice it doesn’t always work, you’re still excited - because this is the worst it will ever be.

But this is also where the quality drop-off starts.

There's a skill ladder to vibe coding. Most people - including a lot of experienced developers - start out at what I'd call the "prompt and pray" level. I'd guess the average person using AI to build things is still here.

You can go a lot further. But only if you're willing to change how you work.

The Skill Ladder

At the bottom, simple stuff. One page sites, simple tools, things that don't need to remember anything or talk to other systems.

At the top, systems with users, data storage, payments, third-party integrations, things that need to work reliably.

Somewhere in between is where a lot of people hit a wall.

What the wall looks like

You're building something bigger than a demo. An actual product, with real data & workflows. And suddenly:

• That feature you added yesterday broke another feature
• Users are finding bugs you didn't know existed
• You can't figure out why something works (or doesn't)
• Every change is like a game of Jenga

My buddy Nev built https://realmarketcap.xyz/ in a day. It went viral, traffic spiked, the site crashed. He tagged me in, we patched it up, and Guillermo Rauch (CEO of Vercel) DM'd him to say good job.

That's the vibe coding dream, right? Build something in a day, it blows up, you shipped.

Since then, Nev and I have been talking a lot about workflows that he (not a developer) could incorporate so that he doesn't need me (a developer) to achieve production-readiness.

There are absolutely times when you'll need an actual developer. But equally there are plenty of ideas that these workflows will get you far enough to validate and prove it's worth investing in properly. And keep in mind, if you are a developer - these workflows will help you ship faster anyway.

Worth saying, over time I bet tools will continue to bake more of these optimizations in and hide the complexity from you. But if you're building right now and want to ship something real, understanding how the best builders work with AI will bridge that gap.

From Prompt Engineering to Context Engineering

So prompt engineering is the ground-floor, that's just about phrasing your request cleverly. There's tools online that can optimise your prompts, and a lot of tools you're likely to use are going to do it behind-the-scenes anyway.

Context engineering is the natural progression - it's about giving AI everything it needs to succeed before it writes a single line of code. More accurately it's about providing the optimal amount of context, and it's important to know that does not mean as much context as possible.

What this looks like in practice:

Let's say I want to add user authentication to my application. Rather than jumping straight into an agent on Cursor or Claude Code and saying "Build me user authentication" I would start in planning mode - now as a developer I'm most likely to say something like:

Before you write any code, review PATTERNS.md for our component architecture and form handling patterns. Use Context7 MCP to check Clerk's latest Next.js 16 documentation for their recommended setup with App Router.

I need a sign-in page at /sign-in with email and password fields. Use Zod for validation with human-readable error messages - not 'string must contain at least 8 characters' but 'Password must be at least 8 characters long'. Handle these states: empty fields, invalid email format, password too short (min 8 chars), and authentication failures from Clerk.

After successful sign-in, redirect to /dashboard. Make it look consistent with our design system (check the Button and Input components in /components/ui).

Create a plan that shows:
1. Which files you'll modify/create
2. The validation schema
3. Error handling approach
4. How it integrates with our existing layout

Don't write code yet - just the plan.        

That's not a prompt. That's a specification. And when AI comes back with a plan, I can review it, catch any misunderstandings, and approve it before a single line of code gets written.

Here's where it gets interesting though.

When you use tools like Cursor and Claude Code you can see a Context Window in the UI - it shows you how much "memory" the AI is using up from your conversation. Every message, every piece of code it reads, every file it references eats into that window.

So after generating that plan, I'm now paying attention to how much of our context window we've already used up. All that back-and-forth planning conversation is taking up space.

Sometimes I'll make the call to start a completely fresh chat, paste my approved plan straight into agent mode, and let it execute from there. Why? Because now my window is fresh and focused on just the implementation, not the entire planning conversation.

This is what people call context rot - the longer the conversation, the more diluted the important parts become. It's like the longer the conversation the more diluted the important parts become.

The manual way: You spot this happening, you start fresh chats strategically, you manage it yourself.

The automated way: This is where sub-agent architectures come in - systems that automatically break work into isolated chunks with fresh context for each step. The Ralph Wiggum loop is one example of this pattern...

The Ralph Wiggum Loop (Yes, Really)

This one sounds silly - it's named after the Simpsons character - but Ralph is an autonomous AI agent loop that runs repeatedly until all PRD items are complete.

Remember how I said the manual way is planning and then strategically starting fresh chats and managing context yourself? Ralph automates that pattern.

Here's the basic idea:

Instead of one long conversation where context keeps piling up, Ralph runs in a tight loop where each iteration gets essentially fresh context:

1. AI reads your spec for what needs to be done
2. AI makes one focused change
3. Automated tests run (or type-checker, or build process)
4. The loop exits and restarts
5. Next iteration: Fresh context = spec + current code + test result (if failed)
6. Repeat until the whole task is done

The key difference: You're not accumulating conversation history. Each iteration has fresh, tight context. It's the difference between:

• A 2-hour conversation where you're still referencing something from an hour ago
• vs. 50 separate 2-minute conversations, each starting fresh with just what matters

For non-technical builders:

Most AI tools don't expose Ralph-style workflows yet (though they're coming). But you can simulate it manually:

• Break your feature into 5-10 small tasks
• For each task, define what "working" means
• Have AI do one task
• Verify it worked (click around, test it)
• Move to next task with a fresh chat

It's slower than automated Ralph, but it gets you towards the same quality outcome: code that actually works because you verified each piece before moving on.

The bigger picture

Ralph is one example of sub-agent architectures - systems that break work into isolated chunks with fresh context for each step. Some tools are starting to build this in:

• Cursor's Agent Mode can work through multi-step plans with checks between each
• Claude Code supports multi-agent workflows where different instances tackle different parts
• Emerging frameworks are experimenting with teams of specialized agents

The principle is the same: keep context tight and fresh, verify each step, avoid the accumulation that comes from long conversations.

A Quick Field-Guide

Here's your cheat sheet for next time you're building:

• Set up rules: Create a markdown file called CLAUDE.md (or .cursorrules for Cursor) with your project basics: what you're building, design preferences, any specific rules you want followed. Tools like Claude Code and Cursor automatically read these files at the start of every chat - so you don't have to repeat yourself. There'll be plenty of good examples online.
• Install useful MCPs: In my prompt example earlier in this blog I mentioned Context7 MCP, which gives AI access to up-to-date documentation. Install it once, never deal with outdated tech examples again. I use a bunch of other MCPs depending on what I'm building.
• Plan before code: If your tool has a planning mode, use it. Get AI to write out what it's going to do first. Way easier to fix a bad plan than bad code.
• Break it way down: One small feature at a time. If a task feels big, it's too big.
• Watch your context window: Most tools show you how full AI's "memory" is getting. When you're past 60-70%, think about starting fresh. Context windows keep getting bigger with new models, so there's no hard rule - just remember that longer conversations can introduce more noise
• Be annoyingly specific: Use screenshots, examples, step-by-step flows. "Make it like this" beats vague descriptions.
• Actually test it: Click everything. Type weird stuff into forms. Try it on your phone. Have a friend use it. AI is a liar sometimes - verify everything works.
• Iterate with tight context: First version won't be perfect. Fix one thing at a time, preferably in a fresh chat.
• Learn the tools: Cursor's Agent Mode, Claude Code's multi-agent workflows, Lovable's integrated testing. They're adding this stuff fast.

Climbing The Ladder

Vibe coding is real, but there are levels to it.

Right now there's a gap between "wow this works" and "I trust this not to fall over."

The people building real products with AI haven't cracked some secret prompt formula, they've just changed how they work:

• They plan first
• They manage context
• They break everything down
• They test
• They use tools that enforce good workflows

These workflows work whether you’re technical or not. And the tools are rapidly automating the hard parts - what’s manual today will be built-in tomorrow.

But if you're building right now, if you've got an idea that needs to ship, understanding context engineering and tight iteration loops will be the difference between a cool demo and something people can safely use.

The vibes get you started. Structure gets you shipped.

Now go build something.