I recently came across a story that perfectly encapsulates something I’ve been thinking about for months. It’s about a CPO who was handed an unlimited token budget and told to vibe code three MVPs for Q1 2026.
They did something unexpected instead.
Rather than firing up Lovable or Bolt to start generating code, they opened Claude Code with the browser extension. Their first prompt wasn’t “build me a dashboard.” It was “load the top 100 users from our app.”
The second prompt: “Send each user a personal email asking what they would like to see in the app.”
That afternoon, instead of debugging AI-generated React components, this CPO was having real conversations with their most valuable customers.
Eighty-five responses came back. One hundred fifty feature requests. Three common asks emerged from the noise.
A week later, those three small features shipped. Not three MVPs. Three focused improvements that users actually wanted.
By month’s end, sales were up 10% on $20M ARR.
That’s $2 million in new revenue. From a single prompt. And not a single new app was built.
The Seduction of Vibe Coding
I get the appeal. I really do.
There’s something intoxicating about describing an app in plain English and watching it materialise in front of you. It feels like magic. It feels like the future. And honestly, it is impressive technology.
The demos are incredible. Someone types “build me a project management tool with Kanban boards and real-time collaboration” and boom there’s a working prototype in minutes. It’s hard not to get swept up in the excitement.
But here’s what the demos don’t show: what happens three months later when that prototype hasn’t moved the needle on any meaningful business metric.
The problem isn’t the technology. The problem is what we’re optimising for.
Shipping Fast vs. Shipping Right
The startup world has long celebrated speed. “Move fast and break things.” “Ship or die.” “If you’re not embarrassed by your first version, you launched too late.”
There’s wisdom in these mantras. Analysis paralysis kills more companies than bad code ever will. Getting something out the door and learning from real usage beats theorising in a vacuum.
But somewhere along the way, we conflated “shipping fast” with “building fast.”
Vibe coding optimises for building fast. You can generate a complete application in hours. The code might even be decent. The UI might look polished. You can certainly ship it.
But shipping a thing nobody wants, faster, doesn’t make you more successful. It just makes you fail quicker.
The CPO in this story understood something crucial: the bottleneck wasn’t development velocity. It was understanding what to build.
AI as a Research Multiplier
Here’s what strikes me most about this example. The CPO didn’t abandon AI, they repositioned it.
Instead of using AI to generate code, they used it to:
- Query their own database for high-value users
- Craft and send personalised outreach at scale
- Process and categorise 150 feature requests
- Identify patterns across qualitative feedback
This is AI as a research multiplier, not a development shortcut.
Think about how long that process would have taken manually. Pulling user data. Writing individual emails. Sending them one by one. Reading and categorising responses. Finding patterns across dozens of open-ended answers.
A week’s work compressed into an afternoon. But the work wasn’t skipped, it was accelerated. The human judgment stayed in the loop. The decisions remained human. The AI just made the research process feasible at a scale that would have been impractical otherwise.
The Laws of the Market Don’t Care About Your Tech Stack
There’s a fundamental truth that gets lost in the excitement around new AI capabilities: market dynamics haven’t changed.
Product-market fit still matters. Unit economics still matter. Solving real problems for real people still matters.
You can generate a complete SaaS platform with AI in an afternoon. You still can’t skip the work of understanding whether anyone will pay for it.
The companies that win aren’t necessarily the ones with the best technology. They’re the ones that understand their customers most deeply and serve them most effectively.
This CPO understood that. Rather than using their unlimited AI budget to produce more software, they used it to understand their users better. The three features they shipped probably could have been built without AI assistance at all. They were “small asks” not complex technical challenges.
The AI didn’t write the code that mattered. It enabled the conversations that mattered.
Pushing AI Further Up Your Stack
The phrase that keeps echoing in my mind is “push AI further up your stack.”
Most conversations about AI in software development focus on the implementation layer. Code generation. Bug fixing. Test writing. Refactoring.
These are valuable applications. I use them myself. But they’re all downstream of more fundamental questions: What should we build? For whom? Why will they care?
The further upstream you push AI assistance, the higher the leverage. A 10% improvement in coding speed might save you a few hours. Correctly identifying what to build in the first place can save you months and millions.
This is where the real opportunity lies. Not in generating more code faster, but in understanding problems more deeply, reaching customers more effectively, and making better decisions about where to invest limited resources.
What This Means for Technical Leaders
If you’re a CTO, technical founder, or engineering leader, this story should prompt some reflection.
How much of your AI experimentation is focused on code generation versus upstream activities? Are you using these tools to understand your market better, or just to build faster?
Consider the entire product development lifecycle. Customer discovery. User research. Competitive analysis. Feature prioritisation. Technical architecture. Implementation. Testing. Deployment. Monitoring. Support.
AI can assist with every stage. But we’ve collectively focused most of our attention on implementation arguably the stage where traditional developers were already most capable.
The stages where most teams struggle aren’t technical. They’re about understanding, prioritising, and communicating. They’re about finding signal in noise.
A Different Kind of Artisanal Coding
I’ve written before about artisanal coding the idea that thoughtful, intentional software development beats rapid code generation. This story reinforces that perspective, but extends it.
Artisanal development isn’t just about how you write code. It’s about how you decide what code to write.
The CPO in this story practiced artisanal product development. They resisted the temptation of unlimited AI tokens and the allure of rapid prototyping. They chose a slower, more deliberate path: talking to users, understanding needs, building only what was validated.
The result wasn’t just better software. It was better business outcomes.
The Uncomfortable Truth About MVPs
Let’s be honest about what often happens with MVPs.
Someone has an idea. They build it quickly. They ship it. Nobody uses it. They iterate. Still nobody uses it. Eventually they run out of runway or patience.
The post-mortem usually focuses on execution: should have marketed better, should have iterated faster, should have pivoted sooner.
But the root cause is often earlier: they built the wrong thing in the first place.
An MVP is supposed to be a learning tool. Minimum Viable Product emphasis on “viable.” It’s the smallest thing you can build to test a hypothesis about customer needs.
Too often, though, the hypothesis being tested is “can I build this?” rather than “will anyone want this?”
Vibe coding makes the first hypothesis trivially easy to answer. You can build almost anything now. The question of whether anyone wants it remains exactly as hard as it ever was.
Three Practical Takeaways
If this story resonates, here are three ways to apply these insights:
First, audit your AI usage. Look at how your team is using AI tools. What percentage is focused on code generation versus research, analysis, and customer understanding? Consider deliberately shifting that balance upstream.
Second, invest in customer connection infrastructure. The CPO in this story could query their user database and send personalised emails through AI because they had the systems to support it. Make sure you can easily identify your most valuable users, reach them, and process their feedback at scale.
Third, resist the urge to build. When you have a hammer, everything looks like a nail. When you have unlimited AI tokens and tools that can generate complete applications, every problem looks like it needs a new app. Sometimes the right answer is a few targeted improvements to what already exists.
The Future of AI-Assisted Development
I don’t think this is an either/or situation. Vibe coding and AI-assisted user research can coexist. They serve different purposes.
But I do think we’re going to see a maturation in how teams think about AI assistance. The initial gold rush around code generation will settle. The novelty will fade.
What will remain is a more nuanced understanding of where AI creates genuine leverage. And increasingly, I believe that’s going to be in the upstream activities; the research, analysis, and decision-making that determine whether what you build matters.
The companies that figure this out early will have a significant advantage. Not because they can build faster, but because they’ll know what to build.
Conclusion
$2 million in new revenue from a single afternoon of AI-assisted user research.
No new apps. No vibe coding. No prototypes that never found product-market fit.
Just a CPO who understood that the most valuable use of AI wasn’t generating code, it was enabling conversations that would have been impossible otherwise.
The tools don’t matter. The approach does.
Push AI further up your stack. Talk to your users. Build what they actually want.
The market will reward you for it.
Ivan Turkovic is a technology consultant and fractional CTO helping startups and scale-ups build the right things, not just build things fast. He writes about software development, AI’s impact on programming, and cutting through the noise in technology decision-making.