Vibe Coding Doesn't Remove Decisions. It Hides Them.
Why skipping the friction doesn't save you from the consequences.
I recently visited San Francisco and caught up with former colleagues. All Product Managers. Beyond the small talk, we went straight into AI. How AI was transforming the software industry. What we were excited about. Which companies are struggling the most. We debated the benefits of vibe coding until someone said:
Developers are moving so fast that I have a hard time drafting product specs.
Vibe coding lets you ship an app in hours. With or without engineers. Tell Claude or Gemini what you want to build and it appears in front of your eyes. Pure dopamine. No more technological barriers between your idea and your customer.
The offer is seductive because it maps directly to what every business leader feels: you are on a clock to deliver. Software is a means to an end. Only results matter. Vibe coding promises all the upside — faster time to market, revenue growth, satisfied customers — with none of the traditional downside: long debates, slow development cycles, projects over budget.
Can it deliver?
What Building Actually Is
I’ve lived multiple professional lives. Engineer. Product manager. Entrepreneur. I’ve shipped enterprise software products that generated north of $300M in ARR and built startups that failed. My experiences shaped my POV on Vibe Coding.
Vibe coding compresses three jobs into one: product manager, designer, developer. What it doesn’t compress is the thinking those three jobs force you to do before a single line of code is written.
In software, building a feature is the final checkpoint. The hard work comes before. Drafting a vision from a blank page. Pitching it. Getting sign-off. Turning it into a roadmap your team can execute. The building phase is the result of weeks of work, arguments, debate, concessions, and tradeoffs you had to earn your way through.
The PM and UX designer combo exists for a reason. Product writes the spec, defines personas and jobs to be done. UX designs, researches, experiments, and delivers wireframes before creating high-fidelity designs.
You bring in your lead engineer before you sell anything upward. That conversation is where your dreams go to get stress-tested.
Senior engineers don’t cushion the blow. A “back to reality” session sounds like this:
The swiping card UI? Not a supported design pattern. Add four weeks.
The quick action buttons on insurance records? We don’t have the API. Add six weeks.
Combining data from two sources in one card? Don’t even think about it.
Why do engineers break your dreams? Because software is complicated.
That friction isn’t an obstacle. It’s the curriculum. It’s how you learn what you’re actually building.
What Vibe Coding Actually Skips
In traditional product management, the feature is part of a broader roadmap. That roadmap belongs to a strategy. That strategy articulates how you plan to win in your target market.
In traditional software development, system constraints force thinking. APIs limit what you can do. Architecture defines how things interact. Data models constrain behavior. Infrastructure sets performance and scale boundaries.
These constraints are by design. They force questions like:
Can this actually work?
What breaks if we do this?
What are we trading off?
This is where product, design, and engineering align.
When you vibe code, you never confront buildability. You don’t force a priority decision. You rarely model the cost of scale. You never surface the edge cases and limits. You delegate ownership. You put your full trust in AI without understanding what you’re shipping.
Vibe coding creates the illusion of speed. Features get built overnight, sometimes in hours. Businesses measure success by how often you ship.
The Product You Built Without Knowing It
Even when you adopt vibe coding, the system is constrained. The system forces decisions. You just don’t see them. Your choices are implicit.
Six months after you ship, something breaks in production. The developer who built the feature is gone. You call your senior dev. Within minutes, his face turns white reading the AI codebase. Spaghetti code. Lack of structure. Endless functions. Three weeks of debugging and refactoring, no guarantee he can fix it.
When you skip constraints, you don’t skip decisions. You make them implicitly:
what features exist
what edge cases are ignored
what user behavior is supported
They’re inferred by the model. This is what changes the nature of the work. You’re no longer in charge. You’re accepting decisions.
That’s the conclusion we reached that day in San Francisco.
Our candid solution? Bulletproof specs: user personas, clear acceptance criteria, edge cases, non-functional requirements. That input serves as guardrails to your engineers.
I hear you: “Fabrice, you’re back to square one. Your approach kills velocity.”
Indeed. But there’s no magic bullet. Software is no magic. You have to choose between speed and predictability.
The Counterargument: “You Learn Faster”
Towards the end of our PM huddle in San Francisco, someone said:
I’ve been vibe coding recently. Even if it’s messy, I can iterate and learn faster.
There’s truth in that. Vibe coding accelerates exploration. And to be frank, even a detailed spec is no insurance for shipping a quality software.
But learning in software doesn’t come from output alone. It comes from constraints.
You learn when a UX design breaks under testing, something doesn’t scale, a tradeoff becomes unavoidable. If you remove those constraints, you stop confronting limits, stop making explicit tradeoffs, stop building a mental model of the system.
You move faster. But you understand less.
Take Anthropic, the biggest Vive Coding proponent. They incidentally released 500K lines of code. The lesson isn’t the leak. The code is the real story.
Here’s a quote from from Denis Steskov’s excellent Substack:
64,464 lines of core TypeScript serving paying customers.A function spanning 3,167 lines. Regex for sentiment analysis at a company that builds the world’s most advanced language model. A known bug burning 250,000 API calls daily, documented in a comment and shipped anyway.
Vibe coding atrocity in full display.
But it worked? Yes, because cheating is easy with unlimited access to memory and GPUs. Same codebase in the infrastructure of a typical SaaS provider? It’s a death sentence. Service down.
Where It Actually Fits
This isn’t a ban on vibe coding. It has legitimate uses. Three, specifically.
Pre-PMF prototyping. If you don’t have product-market fit, there’s no point writing production-grade code. Vibe code your way to a demo, get in front of customers, learn fast. Then rebuild with comprehension before anything customer-facing scales. The latest batch of early-stage YC startups are encouraged to work this way.
Feature validation before commitment. Before locking a feature into your roadmap, vibe code an alpha to test the hypothesis. De-risk before you invest in engineering cycles. This is where the speed advantage is real and the downside is contained.
Single-purpose micro tools. Internal tools, dashboards, mini business apps, one-off automations. Low stakes, controlled environment, limited surface area. Claude artifacts work well here. Gemini canvas can do wonders with NotebookLM. Business and technical users can unlock instant value.
In these cases, speed is the goal. Structure can come later, or may not matter.
Production systems are different.
They require predictability, explicit decisions, ownership, and alignment across product, design, and engineering.
The founders who use vibe coding well stay in the loop long enough to understand what the AI decided on their behalf. They use it at the exploratory phase. Then they rebuild with comprehension.
The ones who get burned mistake velocity for understanding.
Eventually, the bill comes due
Vibe coding promises value through speed. It delivers speed by removing the friction of building software.
The “back to reality” session with your lead engineer isn’t a tax on innovation. Neither is the PM’s insistence on a clear problem statement before anyone writes a spec. Both exist to surface what you don’t know before it becomes expensive.
Every decision you didn’t make explicitly got made anyway: by the model, by default, by omission.
The PM forces the “what and why”: what to build, for whom, at what cost, with what tradeoff. That’s a strategy made concrete.
The engineer forces the “how and at what cost”: what’s actually buildable, on what timeline, with what risk. That’s a reality check.
Two checkpoints. Two filters between your idea and a costly mistake. Remove them both and you’re not moving faster. You have speed without direction.