Validate Before You Vibe Code: How I Use Claude as an Adversarial PM
Before vibe coding, validate your idea with an adversarial AI PM. This two-phase framework helps you avoid building the wrong thing fast — with Claude or Codex.
The fastest way to waste a week is to vibe code something nobody wants.
I’ve done it. You probably have too. The AI writes fast, the feature looks good in the demo, and then you ship it and — silence. No users. No feedback. Nothing. Because the idea was wrong from the start, not the code.
Vibe coding solved execution speed. It didn’t solve demand judgment. And that’s exactly where most solo founders and indie devs are getting stuck in 2026.
Here’s the two-phase framework I now run before I write a single line of code.
The Common Mistake: Treating Speed as Validation
When a feature takes three months to build, you’re forced to think hard about whether it’s worth doing. When it takes an afternoon, that friction disappears — and so does the thinking.
The result: a lot of polished apps with zero market fit. Speed is not validation. Shipping is not validation. The fact that Claude built it for you in four hours is definitely not validation.
Shopify’s Head of Engineering Farhan Thawar made this point clearly: when AI eliminates the coding bottleneck, the constraint shifts to planning and judgment. The question is no longer “can we build it?” It’s “should we build it at all?”
The Better Approach: Hire Claude as Your Devil’s Advocate PM
I now use Claude (or Codex) as an adversarial product manager before I open a code editor. Not a yes-man PM that helps me flesh out my idea — a PM whose job is to try to kill it.
The setup is simple. When you drop an idea, Claude’s default mode is devil’s advocate. It plays the skeptical user, the harsh product reviewer, the funding committee that’s seen a hundred of these before.
Phase 1 — Demand Debate
The rules I enforce in my system prompt:
One gap per round. Claude asks about one weakness at a time. It doesn’t pile on.
No moving forward without an answer. If I dodge the question, it stays on it.
Flag every unvalidated claim. Any time I say “I feel like,” “users will probably,” or “everyone does this” — Claude marks it as pending validation and won’t let me use it as a premise.
No premature closure. Claude can’t end the debate session until it explicitly states “no new high-value objections remain” — and I agree.
Three outcomes only: Go, Pivot, or Stop. No “it depends.”
Running one round is uncomfortable. That’s the point. Most features I was confident about either get pivoted or stopped here. The ones that survive are the ones worth building.
Phase 2 — Discovery Toolkit
Only if the idea survives Phase 1 does it enter proper discovery. This is just structured user research, but run as a Claude conversation:
User segment matrix — who else has this same pain that I haven’t considered?
Persona — specific user, specific context, specific skill level
Current workaround — how are they solving this today, and where’s the friction point?
Market landscape — what tools already exist, and what gap is actually uncovered?
Pain intensity — is this a hair-on-fire problem or a “nice to have”?
Willingness to pay — the most brutal filter. Not “do you want this?” but “how much would you pay?”
Direction verdict — Go / Pivot / Stop, synthesised from all of the above.
The willingness-to-pay question alone has killed more features for me than all the others combined. If someone can’t name a number, the pain probably isn’t real enough to build around.
Real Example: How This Changed a Feature Decision
I was going to build a recurring export feature for one of my projects — users export a report weekly, so an automated email seemed obvious.
Phase 1 stopped me in round two. Claude asked: “How many users have explicitly asked for this versus how many do you think would want it?” I had zero data. Marked as pending validation.
Phase 2 pushed me to ask three actual users. Two of them said they’d prefer to trigger the export manually because the automated one would “just become spam.” The feature died. Saved probably two days of work.
The Takeaway
AI didn’t make product judgment easier. It made the cost of skipping it higher — because now you can build the wrong thing twice as fast.
The framework is simple: before you open Claude to write code, open Claude to kill your idea. If it survives, the build phase is actually fun. If it doesn’t, you saved yourself a week.
Run Phase 1 before you write a single component. Run Phase 2 before you commit to a full build. If you skip both — you’re vibe coding in the dark.
FAQ
Q: What’s the difference between vibe coding and just coding with AI assistance?
A: Vibe coding typically refers to low-friction, AI-driven development where you describe what you want and the AI builds it with minimal manual intervention. The speed is real — but so is the risk of building the wrong thing fast. Standard AI-assisted coding usually involves more deliberate design decisions upfront.
Q: Do I actually need to set up a system prompt to run this, or can I just ask Claude in a normal conversation?
A: You can run Phase 1 in a normal conversation by telling Claude at the start: “I want you to play devil’s advocate on this idea. Your job is to try to kill it, not help me build it. Ask me one hard question at a time and don’t let me move on until I answer directly.” That’s enough to get 80% of the framework working without any formal system prompt setup.
Q: What if my idea survives Phase 1 and Phase 2 but still fails in the market?
A: The framework doesn’t guarantee success — no framework does. What it does is eliminate the most common and most avoidable failure mode: building something nobody needs. Market timing, distribution, and execution still matter. But at least you’re not failing because you skipped the thinking.
Q: How long should Phase 1 actually take?
A: In my experience, 20–40 minutes for a typical feature or product idea. If it takes less than 10 minutes, you either have a very obvious idea or you’re not pushing hard enough. If it takes more than an hour, the idea is probably too vague to evaluate and needs to be scoped down first.
Q: Is this framework only useful for solo founders or does it work for teams?
A: It works well for teams too, especially small ones. You can run the Phase 1 debate as a team exercise with Claude as the moderator — one person defends the idea, Claude pushes back, and the rest of the team watches for the gaps that emerge. It often surfaces disagreements that the team had but nobody said out loud.
Q: What should I do if Claude keeps agreeing with me instead of pushing back?
A: Explicitly tell it not to. Add this to your prompt: “Do not agree with me, validate my assumptions, or say ‘that’s a good point.’ Your only job is to find holes in this idea. If you find yourself being encouraging, you’re doing it wrong.” Models default to being helpful and agreeable — you have to override that explicitly for adversarial reasoning to work.
Q: Can I use this framework with other AI tools besides Claude, like Gemini or GPT-4o?
A: Yes. The framework is model-agnostic — it’s about the prompt design, not the model. Claude tends to handle adversarial reasoning particularly well, but any capable LLM can run Phase 1 if you set the instructions clearly. The key is the explicit constraint that it cannot move on until you’ve answered the current objection.