What Gordon Ramsay Taught Me About Vibe Coding

This post was originally published on my Substack publication as What Gordon Ramsay Taught Me About Vibe Coding.

I hope your week started with better choices than mine, as I spent my entire weekend deep in a YouTube rabbit hole watching hours of Hotel Hell clips.

Fans of Gordon Ramsay know the specific joy of these videos. He visits a struggling inn where the wallpaper peels off the walls and the owners panic in the corner while the kitchen creates biological hazards. He eventually sits down for lunch and demands the menu, at which point the owner hands him a heavy leather book.

These sixty-four pages usually hold everything from sushi and lasagna to artisan burgers and Pad Thai. Ramsay explodes and screams about fresh ingredients, but his main point cuts deeper than food quality. He argues that they do too much and therefore do all of it badly.

He never tries to fix the lasagna recipe. He brings out the guillotine and shreds the sixty-four page menu to force the kitchen to cook four dishes. The kitchen calms down, the food improves, and the business survives.

AI turns builders into stubborn hotel owners because Claude and Cursor provide an army of line cooks where adding menu items requires zero effort. You intend to build a simple tool, but you decide to add a dashboard and social login because they look impressive. You look up at 3 AM to find that your MVP contains twelve distinct features. While you wrote zero lines of code, you successfully designed a product impossible to debug.

You built the doomed restaurant by trying to serve sushi and lasagna on opening night. You must channel your inner Ramsay to ship, and that requires the Scope Guillotine.

Coding changed fundamentally in recent years because manual coding imposed a heavy pain tax. Adding a dashboard previously required manual route setup, building UI components from scratch, and handling complex state management. This friction was a useful filter because you naturally avoided the dashboard when the effort cost too much.

AI removed the pain tax. Claude builds the dashboard in ten minutes and scaffolds the admin panel in five, reducing the cost of generation to near zero.

Even so, owning code remains expensive even if generating it costs nothing.

Asking AI for social login feels like magic, yet this single request introduces a massive chain of liabilities. You must now manage OAuth tokens and validate session security while updating database schemas for user tables. You also need to test Forgot Password flows and handle edge cases where external providers go offline.

Three weeks pass and you remain in the "almost done" phase because you have a login system and a settings page, but the core product breaks when users try to perform the primary action.

Decision making replaced coding as the bottleneck, meaning the MVP dies from feature bloat unless you apply a guillotine.

To stop your feature list from growing out of control, we will apply the Scope Guillotine as a simple yes-or-no filter for everything you want to build. You need to look at every feature and ask if your user can actually complete the main task without it in the first version.

If they can get by without it, you have to cut it immediately because it doesn't matter how easy it is for AI to write the code.

Think about how airport security handles your luggage. The TSA agent never looks at your water bottle and thinks about how nice it would be to have a drink on the plane.

They only check if it follows the rules and toss anything that fails. You need to treat your features the same way by sorting them into three buckets.

Bucket 1 holds The Oxygen

These features represent the core value because the user fails to complete their goal without them. Removing this leaves a blank screen. Requesting a ride on Uber fits here.

Bucket 2 holds The Vitamins

These features improve the health of the experience, yet the user survives without them for the first week. Splitting a fare on Uber fits here.

Bucket 3 holds The Jewelry

These features look professional but solve no survival problems. Custom avatar icons fit here.

Most AI builders fill their MVP with items from the second and third buckets because AI makes these features easy to build. Experienced builders fill V1 entirely with items from the first bucket and might include one item from the second bucket only if the product fails completely without it.

The reason I push so hard to cut features is that every line of code you add creates new liability for you to manage. When a beginner looks at a "Social Login" feature, they just see a simple button on the screen, but a senior developer immediately sees the massive iceberg of logic hiding under the water.

• State Management: You have to track that user's session across the entire app and make sure it doesn't vanish the second they refresh the browser.

• Validation: You need to write logic that stops people from entering fake emails or signing up twice with the same account.

• Security: You have to handle the complex handshake with Google, where one wrong redirect or expired token will crash your whole application.

• Database Migrations: You have to change your database structure to store this new info, and if you change your mind later, you have to painfully migrate all that data back.

• Testing: It becomes a headache to test your app because you can't just fake a user anymore; you have to manually log in with Google every single time you want to check a feature.

AI is incredible at writing the "Happy Path" where everything works perfectly, but it struggles to predict the "Unhappy Path" where things break. If you build twelve features, you might have twelve happy paths, but you also create forty-eight ways for things to go wrong. If you cut that down to two features, you can actually manage the bugs and ship next week.

You can apply this process to your current project immediately to regain clarity.

Step 1

Start by defining your product's absolute core mission in a single, unbreakable sentence using this format:

"This app helps [user] do [specific action] without [current pain point]."

Step 2

Once you have that sentence, look at your backlog and run every single feature through this four-question filter:

• Can the user actually complete the Specific Action from Step 1 without this feature?

If they can technically finish the task without it, you must CUT IT from the first version.

• Does this feature try to serve a completely different use case than the core mission?

If it distracts from the main goal defined in your sentence, you must CUT IT.

• Does removing this feature make the app fundamentally "incomplete" or simply "less polished"?

You need to distinguish these carefully because "incomplete" means the product is broken, while "less polished" just means it looks a bit ugly. If it is merely less polished, you must CUT IT.

• Is this feature solving a problem that users will only discover after weeks of usage?

If the user won't need this until day thirty, you certainly don't need to build it for day one, so CUT IT.

Let's apply this framework to a hypothetical app called PlantPal, which uses AI to help people stop killing their houseplants.

The Nightmare Scope

If you sit down and brainstorm this with an AI, you will almost certainly end up with a "standard" feature list that includes photo uploads for diagnosis, push notifications, social login, a marketplace to buy fertilizer, a competitive leaderboard, dark mode, and a full admin panel. While this looks like a comprehensive product, it is actually a six-month development trap that will kill your momentum.

Applying the Guillotine

We need to look at each feature through the lens of survival. A user does not need to sign in with Google just to save a fern, so we cut social login in favor of simple local storage. The marketplace adds complexity without helping the plant survive right now, so that gets cut. Building a real-time leaderboard requires complex backend logic that distracts from the core mission, and since plants don't need dark mode, we cut that too. Finally, you don't need an admin panel before you have actual users, so we can stick to direct database access for now.

The Surviving V1 Scope

After the cuts, we are left with a focused product where you simply upload a photo, receive an AI diagnosis, and click one button that says "Remind me to water this." This is your food truck. If this core loop solves the user's problem, you have a business, but if it fails, a leaderboard for competitive gardening wasn't going to save you anyway.

Willpower is a finite resource that eventually runs out, and you will almost certainly say yes when Claude politely offers to add a user profile page while you're in the flow. We need to rely on systems rather than willpower, which means you need to create a pre-commitment Notion page or Google Sheet called the No List.

You do not need to create a markdown file if that doesn't fit your workflow, but you must create this list somewhere permanent before you write a single prompt. Whether you manage your life in a Notion dashboard, organize tasks on a Trello board, or simply use a physical sticky note taped to your monitor, you need to copy this list and keep it visible.

## THE GUILLOTINE LIST (NOT in V1)
## Building these counts as procrastination.

- Social login (Use email/password or Magic Links)
- User dashboard (Show single result page only)
- Analytics (Export raw data if needed)
- Admin panel (Edit database manually via Supabase/Firebase console)
- Email notifications (Email users manually via Gmail)
- Profile customization (Everyone gets a default avatar)
- Search functionality (Browser Ctrl+F suffices for V1)
- Multi-language support (English only)
- Forgot Password flow (Reset manually upon email request)

This simple list works effectively because it splits your personality into two distinct modes. The Planner sets the strict rules while sober and rational, and the Builder simply follows them while coding. When the temptation to add a feature arises later, you do not have to make a difficult decision because your Notion page or sticky note already says No, which allows you to stay focused on coding the core.

Senior developers know a secret that beginners often miss, which is that writing code should always be your last resort. You should strictly avoid writing code for your first version if a human being can perform the task manually.

• Avoid building an Admin Dashboard. You can simply use the data viewer provided by your database provider or connect your live database to Airtable for a friendly interface.

• Avoid building automated email onboarding. You can just configure a notification when a new user signs up and send them a personal welcome email directly from your Gmail.

• Avoid building a moderation system. You can place a simple mailto link in the footer that allows users to report issues directly to your inbox.

This manual approach saves you weeks of development time and forces you to have actual conversations with your early users.