Vibe Coding - Blessing or Curse?

Photo generated by Nano Banana

Vibe Coding has been all the rage this year, and I’m ready to add my two cents. Are you ready as well? If not, here’s the TL;DR:

  • Vibe Coding is a massive accelerator for Product Discovery, turning ideas into testable prototypes faster than ever.
  • Left unchecked, it produces high technical debt, making it risky for direct use in production systems.
  • With strong context engineering, small iterations, and clear separation between prototyping and delivery, Vibe Coding can meaningfully reduce waste and speed up real-world development.

So what is Vibe Coding again?

It’s your entrepreneurial ideas turned into deployable, working code within minutes! Imagine Pieter Levels as a Service—unlimited change requests included!

Here's another accurate description:

It’s easy to see why this practice has been wholeheartedly embraced by designers, serial entrepreneurs, and product people: it dramatically lowers the barrier to product development. There’s no longer a strict need to partner with an engineer if services like v0, Bolt, or loveable make building a web app as easy as—or even easier than—writing a Product Requirement Document.

It’s equally unsurprising that many developers look at this trend with skepticism. Vibe Coding appears to do parts of their job—cheaper and more efficiently. The main concern, however, is that it resembles building a house without a structure: the generated code is often unmaintainable, leading to an astronomical increase in technical debt over time.

"Vibe Coding may be a horrible, horrible idea from a maintenance standpoint, if you actually tried to make a product."

—Linus Torvalds at the Open Source Summit in Korea 2025

At the same time, large language models are improving at an unmatched, unprecedented pace. The truth, as usual, lies somewhere in the middle. To better understand how Vibe Coding performs in real-world scenarios across the SDLC I’ll share a tale from my own, slightly engineering-biased experience. For the sake of simplicity, I’ll break the process down into just two phases:

  • Product Discovery
  • Product Delivery

From 0 to 1: The Product Discovery Process

There’s clear value in making a product idea interactive at a previously unattainable speed. Transforming a mental model into a working prototype can surface insights and flaws that would remain entirely hidden in a static mockup. At least in the discovery phase, this makes Vibe Coding a significant process accelerator.

Ben Sufiani from Pirate Skills recently discussed this on the Produktwerker Podcast (German). He explains that Vibe Coding an interactive prototype—one that can actually be shipped to users—is a real game-changer, as it shifts the focus away from technical feasibility and toward a deeper understanding of user needs, the underlying problem, and the quality of the proposed solution.

The six levels of the Builder Codex on pirateskills.com

In his Builder Codex, Ben helps non-technical people fill the gaps required to become proficient “vibe coders.” It not only teaches how to take an idea from 0 to 1, but also outlines the steps needed to go way beyond the prototyping phase—going as far as enabling builders to connect Stripe to their app and start charging users. If you’ve read The Mom Test, this should ring a bell: getting people to pay for your product is the strongest form of idea validation on the road to Product–Market Fit.

Reality check

While all of this sounds promising, the reality is often less impressive. Although AI handles much of the initial heavy lifting, reaching the point where you can actually charge money is usually where the real challenges emerge—and where substantial grit is required to build a great product. I speak from years of experience with ideas that never took off.

That said, fast-tracking the initial “ideation gap” and reaching validation sooner can surface uncomfortable truths much earlier, ultimately saving significant time and money. Knowing whether you’re onto something and battle-testing an idea allows you to explore more options and identify the ones that might work, all within a much shorter timeframe.

In a nutshell, the goal is to build a lot, build fast, and focus on where the traction is. In other words: product goals outweigh engineering quality by a huge margin.

Now for the second part…

From 1 to 10: The Product Delivery Process

One of the interesting aspects of Vibe Coding is that you reach the product delivery stage with most of your assets already available as code, rather than having to translate them into code first. Even without Vibe Coding, tools like Figma MCP can significantly simplify this process, turning layouts into code in a matter of seconds.

That’s great—but what does that code actually look like? In my experience with Vibe Coding tools, and without sufficient guidance, it often reflects the architectural maturity of a junior developer. While the UI may work as expected (which is the whole point of Vibe Coding), it can result in less-than-ideal engineering artifacts: oversized “god components,” heavily mixed concerns, and a major misalignment with your existing tech stack.

From throwaway code to reusable units

This may work for a one-person operation (hello Pieter Levels!), but it is rarely mature enough to fit into a larger codebase with multiple collaborators. If such code were taken directly into production on a regular basis and without sufficient oversight, technical debt would quickly spiral out of control. In other words, Vibe Coding produces a huge amount of throwaway code, and taking it from 1 to 10 requires a lot of additional work:

  • refactoring it into smaller, reusable units
  • testing it against edge cases
  • integrating it with your custom backend
  • verifying its correcntess and security
  • making it pass your CI pipeline
  • documenting it for others

...to name just a few! This is a long and often intimidating list of tasks, especially for a Vibe Coder with limited understanding of front-end technologies. So why not do it “properly” from the start, if you might end up spending roughly the same amount of time refactoring a Vibe-coded mess as you would building it from scratch?

I recently found myself in this situation several times and resisted the temptation to discard everything my designer colleagues had produced. Instead, I saw an opportunity to understand which parts needed improvement and how to better align the code with our tech stack from the start next time they were running a prompt.

Each unit of code can go through a polishing process, just like a diamond.

What I learned is that this approach can work surprisingly well for isolated units of work that implement and validate a single feature. Keeping iterations small further supports the transition from Vibe-coded raw material to more polished and maintainable components.

Bridging the gap between discovery and delivery

In many cases, it may not make sense to further process any Vibe-coded raw material at all—especially when the initial idea turns out to be flawed.

In other cases, however—particularly when a prototype delivers solid results or is based on a valid feature request—the option of polishing that raw code into something production-ready becomes far more compelling.

Context Engineering

The biggest lever here is context. Providing an LLM with clear information about your tech stack, coding conventions, and best practices can make a significant difference in how much “pre-polish” you achieve through prompt engineering.

The goal is to address technical debt earlier in the process without compromising creativity, flexibility, or productivity.

If you're using Cursor—which is probably part of most engineers’ toolbelt nowadays—you'll want to define detailed rules. If you’re using Vibe Coding tools like Bolt instead, you can still enrich the model’s context with additional instructions:

  • Bolt allows you to define a system prompt via the “Knowledge” tab in its settings.
  • v0 offers a system prompt option called “Custom Instruction” under “Preferences.”
  • loveable lets you paste in contextual information when the “Chat” feature is enabled.

Some of these tools also allow you to define a custom theme or reference an existing UI library. Both of these, along with context engineering, are particularly important when working with designers, who may not be aware of the nuances of your tech stack—or of how far prompt tuning can go in pre-polishing code to better match it.

In Bolt settings, you can define a global system prompt using the "Knowledge" option.

Regarding the global prompt, here are some suggestions for the context you should provide:

  • Libraries of choice: Specify your preferred framework—React, Vue, or Svelte—as they are difficult to interchange. For visual consistency, indicate if you are using a UI library like Radix, Tailwind, or PrimeVue, or the generated code may quickly go off-track.
  • Coding Conventions: The more conventions you establish from the start, the better. Clear documentation helps the LLM produce code that aligns closely with your existing tech stack.
  • Examples: Ideally, your vibe-coding project already serves as a clean, organized boilerplate or template. This not only guides the LLM in the right direction but also provides concrete examples for how new features should be implemented.

If you’re unsure where to start, check out the GitHub repository awesome-cursorrules which offers a ton of ready-to-use templates for different tech stacks. For Claude Code, you can find a similar set of starter kits in the awesome-claude-code repository.

Managing expectations

Finally, it’s important to remember that AI is unlikely to produce fully production-ready code. Make sure to set the right expectations with your team and stakeholders—you don’t want anyone thinking a prototype can be shipped directly to production. Inevitably, there will always be work left to do. With the right prompts and instructions, however, you can shift the balance between throwaway and reusable code in your favor.

Another approach that worked well for us is clearly separating the prototyping from the development environment. This allows designers to have an isolated playground to experiment and present to clients, while developers can selectively cherry-pick reusable components from the prototype repository and gradually integrate them into the main application.

Although there is still a long journey from Vibe-coded prototypes to robust, battle-tested features, following these tips can help reduce tedious and repetitive work, allowing your team to focus on the tasks that truly matter.

Closing thoughts

Vibe Coding is a powerful process accelerator in Product Discovery, capable of turning weeks of uncertainty into hours of learning.

However, it is not a silver bullet. Its real advantage lies in understanding exactly where it fits within your workflow: optimizing for speed and early learning, while applying constraints and engineering rigor to ensure alignment with your existing tech stack.

For purists, this shift can feel uncomfortable, as it requires letting go of the idea that every line of code must be written by hand. Yet our roles evolve: from pure implementers to prompt engineers, architects and reviewers.

By separating prototyping from production, investing in context engineering, and keeping iterations intentionally small, Vibe Coding becomes less of a risk and more of a tool to reduce wasted effort, assumptions, and time spent building the wrong thing.

Additional resources

For those who want to dive deeper, here are some helpful resources on effective prompting and context engineering: