The Vibe Coding Trap: Why Maximizing Output Doesn’t Make the Product Better
How many times have we heard it? With vibe coding, every idea can be brought to life instantly. You ponder a feature over coffee in the morning, dictate it into a language model during your commute in the S-Bahn, and by the time you open your laptop at work, the feature is already live. Bam! This (or something very much like it) is how the makers of large language models sell their products, and many tech companies parrot the same line with pleasure, or even dismantle entire departments to adopt it. Teams are measured against leaderboards of LLM token burn to ensure the expensive new technology is put into use somehow. A wave of hysteria (now labelled as "AI psychosis") and FOMO effects flows through the product management community.
The narrative fits perfectly into a time when companies want to move faster and faster, do more, and save costs in their expensive software development teams.
More Code, Less Compass? Why Product Managers Must Hit the Brakes in the Age of Vibe Coding
At its core, the ability to quickly validate product ideas is undeniably exciting. Rapidly turning rough sketches into simple prototypes with users for testing is, for the most part, a solid step forward. Especially in the infamous feature factories, there’s a newfound possibility to gather customer behavior data cheaply and efficiently.
But here’s the catch: When the focus shifts to maximizing output, or perhaps even training models on the side to improve that output, who’s left to steer the ship? Who ensures the right things are delivered at the right time, rather than just piling up technical debt and maintenance nightmares?
1. Intro: The Code Flows.. But Where to Exactly?
Framing the psychosis
Vibe coding refers to the rapid, AI-assisted generation of code through prompts, without diving deep into syntax or software architecture. It empowers non-engineers to build prototypes, or even MVPs, and test them with users. It also reduces the cost of knowledge work by shifting multiple software development roles into the language model.
Beyond pure vibe coding by non-tech people, most software engineering teams now use LLM-assisted coding, reviewing, and testing. Output increases here, too—for example, eliminating wait times for peer reviews since the LLM tool reviews code itself.
The problem: Teams are drowning in features because the technical barrier to implementation has dropped to nearly zero.
As the cost of software engineering plummets, so does the volume of features, and the code that must be maintained, much of which may not even have been written by a human. Proven software development practices are forgotten or deliberately skipped. Reliable data on the long-term costs is scarce, but from what I’ve seen, it’s a ticking time bomb. But that’s not the focus of this article.
The core thesis: Maximizing output has never been the primary job of product managers, and in the age of vibe coding, blindly chasing output is downright dangerous for the organization.
Let’s turn to product management and the role of PMs in this environment. Many PMs focus on delivery, which in turn means core product management tasks fall by the wayside. But here’s the truth: maximizing feature output has never been the primary responsibility of product managers, even if that’s how it’s often treated, especially in German companies based on my observations.
Yet now, product managers aren’t rewarded for the 11th feature released; they’re rewarded for successful solutions that help customers solve real problems. Strategic smarts, business impact, and a strong voice for customer problems and their context: that’s what modern product management is about.
2. The Misconception: Output vs. Outcome in the AI Age
The delusion: More features ≠ more value. When AI makes it effortless to build features, organizations tend to build everything.
Unfortunately, human decision-making isn’t rational: it’s shaped by biases, career backgrounds, and the stories organizations tell themselves (e.g., “BlackBerry made the best phone ever”, the rest is history). That’s why “faster” and “more” sound reasonable and seem like a competitive edge. But that’s not how great products, nor their users work.
Organizational shift: Engineering capacity is no longer the primary bottleneck; human validation and strategic clarity are.
If software development has become dramatically cheaper and the actual coding and designing of software is no longer the bottleneck, then the process and team dynamics shift. The bottleneck moves elsewhere: strategy work, thorough research, and human validation of output.
When the how (i.e., coding in product development) is partially automated, the why and what become the most valuable currency.
3. The True Role of the PM (1): The Art of Asking the Right Questions
Moving away from ticket scribes: PMs aren’t here to feed the best user stories to an AI.
Imagine a product manager who mostly writes tickets and oversees delivery, somewhere between requirements engineering and delivery management. With this mindset, it’s easy to end up as a “prompting rockstar,” churning out the best user stories and pre-built code.
Focus on discovery: Before a single line of (generated) code is written, the problem must be dissected.
But what’s being built so effortlessly? Yes, we ship solutions to market and try to monetize them. But the real value of product work lies in the problem space: solid classic discovery. Solution competence belongs with software engineering experts; that’s why they were hired. If solution competence shifts to product management or UX designers combined with language models, the PM’s focus drifts away from the problem space.
Key questions:
- What user problem are we really solving here?
- What happens if we don’t build this feature?
- What happens if we build this feature later?
And there's even more:
- Are we addressing a symptom or the root cause?
- How does this solution create value for the user?
- Are we following the market or leading it?
- etc etc.
4. The True Role of the PM (2): Strategic Timing Over “Everything at Once”
The temptation: “We can build this with vibe coding in two hours!” The pressure on PMs to greenlight every idea skyrockets.
Every PM knows the demands of stakeholders who want every possible product idea live by tomorrow, from “My grandma wants to print her wishlist” to “Let’s create a 30-question onboarding flow so users can navigate our app.” And when everything is possible thanks to LLMs, the pressure on PMs and teams grows, because the production cost has dropped to nearly zero, hasn’t it?
Rethinking prioritization: It’s not just what we do, but when.
Let’s revisit the core PM tasks: prioritization. Typically, decisions blend strategy, complexity, and business/user value. That prioritization is still valid.
My suggestion? Add one more question upfront: When? Prioritize based on “why now and not later.” This brings in cost-of-delay thinking from Kanban, a concept that, in my view, is highly relevant here.
Strategic context: Does this (quickly built) feature align with our product vision, or does it just add technical and conceptual baggage we’ll have to maintain later?
Conversations in my PM courses often reveal a harsh truth: many PMs don’t have a strategic role, and product strategy is withheld from them. But that must change. A core part of product work is defining: What should we be? What should users be able to do in a year? Where will we stand in two years?
Everything that doesn’t contribute to that vision is noise, whether cheap or expensive to produce.
5. The True Role of the PM (3): Empathy and Context Beat the Algorithm
_AI doesn’t know the user: An LLM-powered development component lacks nuance, emotion, and an understanding of the end user’s daily reality.
_
Product managers are the voice of the user and customer. They understand needs, jobs to be done, context, and habits, especially contextual and empathetic work, which provides the critical dataset for good prioritization.
An example from my own product work: We launched a medical app in an East African country enabling video consultations with doctors. Why not? It works well in Europe, the market is huge, and adaptation costs are low. Payment? Via credit card.
Missing discovery data:
- Mobile plans often include little or no data volume.
- Users rarely have private spaces for confidential calls.
- Few have credit cards; payments are made via mobile microtransactions using phone numbers.
Need I say more about the app’s initial success?
So, product work is about context. That’s the skill we’re trained for, through user interviews, UX research, behavioral data analysis, and more. Language models can’t do this; they calculate probabilities based on training data.
6. The Goal: Bridging User Value and Business Value
The real magic in product management lies at the intersection of user satisfaction and business viability.
As Marty Cagan writes in Inspired, successful products combine four things: user value, feasibility, usability, and business viability. Digital product management manages the risks around these pillars:
- The risk that the feature provides no value to the user, leading to unused maintenance debt, confusion, and churn.
- The risk that users can’t navigate the product.
- The risk that the feature is technically so complex it becomes unpredictably expensive to maintain (up to a full product rebuild).
- The risk that users won’t pay for the product or feature.
Missing from the list: the risk of not shipping enough features fast enough.
How does vibe coding become a superpower?
Especially for product managers or teams in less complex products (like e-commerce), it becomes a superpower when we use the increased output to rapidly prototype and validate our assumptions and hypotheses on real users. Not to ship noise and complexity into products without thoughtful consideration.
7. Conclusion & Call to Action: From Feature Factory to Value Navigator
Product takeaway: Vibe coding is a fantastic tool to enhance operational excellence in engineering. But it doesn’t absolve us of the need to do real product work.
So here’s my conclusion: Let’s use these new technological tools to improve our product work. And maybe even have some fun doing it. Let’s go out with bold hypotheses and validate them quickly with simple prototypes on real users. That’s what will set you apart in the market and in your organization.
Organizational takeaway: Companies must measure PMs by the bad ideas they prevented, not the number of features churned out thanks to AI.
From a competitive standpoint, pushing for speed and volume in product delivery doesn’t just increase output, it also piles on technical debt and strategic drift. What was once a competitive edge becomes "yet another me-too feature". That’s why it’s critical that organizations stop rewarding output metrics, whether number of features, story points (!!), or lines of code (!!!). These output metrics were abandoned over a decade ago because they lead nowhere.
Instead, organizations should reward metrics like:
- Number of prevented misinvestments
- ROI
- Customer metrics
Final thought for readers:
How has vibe coding changed the pace in your team? How do you guard against feature creep?
Join the discussion on the Fediverse under #prodmgmt or #productmanagement.
AI declaration: This article has been translated from German to English with Mistral 4 small reasoning.
Photo credit: Ian Taylor on Unsplash.