How We Used Two AIs to Design Our Next Product (And Why You Should Too)

November 19, 2025
Erik Bethke
22 views
AIArchitectureDeveloper ToolsProduct StrategyWeb Development

How we used two independent Claude Code instances to architect a major product feature, why their convergence validated our approach, and why their divergence revealed the best synthesis. A practical guide to parallel AI exploration for CTOs and engineering leaders.

Share this post:


Export:

How We Used Two AIs to Design Our Next Product (And Why You Should Too)

By Erik Bethke, CTO November 2025


The Problem with Single-Path Thinking

As CTOs, we face a recurring dilemma: How do you know if your architecture is the best architecture?

You can run it by your team. You can review similar systems. You can prototype and iterate. But there's always that nagging question: "What if there's a better approach we didn't consider?"

Traditional solution: Bring in consultants, run design sprints, debate for weeks.

Our solution: Let two AIs explore the problem space in parallel.


The Experiment

We had a significant technical challenge: transforming an expensive, manual, multi-team workflow into an automated, AI-powered system. Think of it as moving from "hire researchers → groom data → build dashboards" to "AI agents collect data → auto-generate everything."

Instead of architecting this myself or delegating to one team, I tried something different:

I briefed two separate Claude Code instances on the exact same problem and let them design solutions independently.

Same problem. Same context. Zero collaboration between them.

Then I compared the results.


What Happened: Convergence + Complementarity

They Converged on the Big Picture

Both AIs independently arrived at:

  • Same problem diagnosis: Manual processes don't scale, data goes stale, personalization is impossible
  • Same paradigm shift: Transform static artifacts (reports, spreadsheets) into living databases
  • Same core components: AI agents for data collection, structured schemas for intelligence, auto-generation of outputs
  • Same value proposition: Massive cost reduction + new revenue opportunities + competitive moat

This convergence validated the approach. When two independent intelligences reach the same conclusion, you're probably onto something real.

But They Diverged on Execution Strategy

AI Instance #1: "Move Fast"

  • Timeline: 12-week sprint to MVP
  • Team: Lean (CTO + 1-2 developers)
  • Investment: $122K
  • Philosophy: Prove value quickly, scale after validation
  • Strength: Concrete implementation details (agent interfaces, dashboard schemas, week-by-week tasks)

AI Instance #2: "Build for Scale"

  • Timeline: 18-month phased rollout
  • Team: Growing (5 → 10 → 13 FTEs over phases)
  • Investment: $1.68M
  • Philosophy: Thorough validation, robust infrastructure, monetization from day one
  • Strength: Data validation rigor, multi-source verification, revenue expansion vision

This divergence was the goldmine. Neither was "right" or "wrong" - they were optimizing for different constraints.


The Synthesis: Best of Both Worlds

After analyzing both approaches, we identified:

What Instance #1 Did Better

  1. Speed to market - 12 weeks vs 6 months for Phase 1
  2. Lean execution - $122K vs $1.68M investment
  3. Actionable details - Production-ready interfaces, schemas, and task breakdowns
  4. Monitoring infrastructure - Agent execution tracking we'd have missed otherwise
  5. Urgency mindset - "Death Star weapons should be built fast, not slow"

What Instance #2 Did Better

  1. Data validation rigor - Multi-tier source classification, confidence scoring, contradiction detection
  2. Event-centric architecture - First-class tracking of all changes for audit trails
  3. Personalization depth - Explicit algorithms, customer-specific overlays, alert systems
  4. Revenue vision - API products, premium tiers, custom services ($3.1M/year opportunity)
  5. Proof through examples - Side-by-side scenarios showing exactly how it works

Our Hybrid Strategy

  • Timeline: 30 weeks (not 12, not 18 months)
  • Investment: $622K total (lean initial sprint + robust foundation)
  • Execution: Instance #1's speed + Instance #2's depth
  • ROI: 2,000%+ over 5 years

We're building Instance #1's 12-week sprint, but architecting Instance #2's validation layer and revenue expansion from day one.


The Meta-Lesson: Parallel Exploration Works

Why This Technique Is Powerful

1. You Clear the Cognitive Market

Running one AI gives you an answer. Running two in parallel gives you the solution space.

When they converge → Confidence. When they diverge → Options.

2. You Find Blind Spots

Instance #1 caught tactical details (monitoring, caching strategy) that Instance #2 glossed over. Instance #2 caught strategic opportunities (revenue streams, personalization algorithms) that Instance #1 under-emphasized.

Neither was complete. Together? Comprehensive.

3. You De-Risk Architecture Decisions

Instead of betting everything on one design path, you've stress-tested the idea from two independent angles.

If both AIs identify the same technical debt → It's real. If both AIs recommend the same infrastructure → It's probably correct. If they propose opposite approaches → You need to dig deeper.

4. You Get Better Outcomes, Faster

Combined time investment: ~4 hours (2 hours per AI briefing + 2 hours synthesis) Traditional approach: 2-3 weeks of design sprints, debates, revisions

The parallel approach gave us:

  • Faster consensus (hours vs weeks)
  • Higher confidence (validated by convergence)
  • More complete solution (synthesis of complementary strengths)

How to Run Your Own Parallel AI Exploration

Step 1: Frame the Problem Identically

Write a clear, comprehensive brief that both AIs will receive. Include:

  • Current state (what's broken, what's expensive, what doesn't scale)
  • Desired outcome (what success looks like)
  • Constraints (budget, timeline, team size, existing infrastructure)
  • Context (your tech stack, business model, competitive landscape)

Critical: Give them the same brief. Don't bias one toward a particular solution.

Step 2: Run Separate Sessions

Open two completely independent AI sessions. No shared context, no cross-contamination.

Ask each:

  • "Design a technical architecture to solve this problem"
  • "Provide implementation details (schemas, interfaces, timelines)"
  • "Calculate ROI and business impact"
  • "Identify risks and mitigation strategies"

Let them explore freely. Don't guide them toward convergence.

Step 3: Compare the Outputs

Look for:

Convergence Points (Validation ✅)

  • Same problem diagnosis? → You've framed it correctly
  • Same high-level approach? → Strong signal this is the right direction
  • Same technical components? → Confidence in architecture

Divergence Points (Goldmine 💰)

  • Different timelines? → Understand the tradeoffs (speed vs robustness)
  • Different team sizes? → Reveals lean vs thorough approaches
  • Different priorities? → Shows where you need to make explicit choices

Unique Insights (Fill the Gaps 🔍)

  • What did only one AI mention? → Potential blind spot
  • Which one has more implementation detail? → Use that as your blueprint
  • Which one has better strategic vision? → Incorporate that into roadmap

Step 4: Synthesize

Create a hybrid approach:

  • Take the best timeline (usually the faster one, with validation layers added)
  • Take the best technical details (usually the more specific one)
  • Take the best strategic vision (usually the more comprehensive one)
  • Identify gaps neither AI addressed (there will be some)

Step 5: Validate with Your Team

Present the synthesis to your engineering team:

  • "Two AIs independently explored this problem. Here's where they agreed [convergence]. Here's where they diverged [tradeoffs]. Here's our hybrid approach."

You'll find this framing makes architecture discussions much more productive:

  • Less ego (it's not your design vs mine, it's synthesizing objective explorations)
  • More focus (the hard questions are about resolving divergences, not debating first principles)
  • Faster consensus (convergence points are pre-validated)

When to Use This Technique

Great For:

Architecture decisions - Multiple valid approaches exist ✅ Product strategy - Tradeoffs between speed, cost, and features ✅ Technical debt prioritization - What to tackle first? ✅ Build vs buy decisions - Objective comparison of options ✅ Greenfield projects - No legacy constraints, wide solution space

Not Great For:

Debugging - Single root cause, not architectural exploration ❌ Urgent firefighting - No time for parallel exploration ❌ Well-trodden paths - If best practices exist, follow them ❌ Highly constrained problems - If there's only one viable solution anyway


The Cost-Benefit Math

Traditional Architecture Process

  • Time: 2-3 weeks (design sprints, debates, revisions)
  • People: 5-10 stakeholders, 8-12 hours each
  • Risk: Single-path bias, groupthink, missed alternatives
  • Output: One design (hopefully the right one)

Parallel AI Exploration

  • Time: 4-6 hours (2 AI sessions + synthesis)
  • People: 1 person (you) + AI
  • Risk: Minimal (you can still do traditional process after if skeptical)
  • Output: Two independent designs + synthesis + confidence score

ROI on this technique alone: ~10-20x time savings

But the real value isn't time - it's confidence. You know you've cleared the solution space.


What We Learned

1. AIs Have "Personalities" (Even from the Same Model)

Same model (Claude Sonnet 4.5), same problem, different approaches:

  • One optimized for speed, the other for robustness
  • One was tactical, the other was strategic
  • One gave detailed schemas, the other gave high-level vision

Implication: Running two sessions diversifies your exploration, even with identical models.

2. Convergence Is a Strong Signal

When both AIs independently say "This is a paradigm shift from X to Y" → Listen.

We were 90% sure our approach was right. After seeing convergence, we're 99% sure.

3. Divergence Is Where the Value Hides

The areas where they disagreed (timeline, team size, validation depth) forced us to think critically about tradeoffs.

We ended up with a better plan than either AI proposed independently.

4. Synthesis Beats Delegation

Don't just pick one AI's approach and run with it. The synthesis is where magic happens.

Our final architecture:

  • 30% from AI #1 (speed, lean execution)
  • 30% from AI #2 (validation, revenue vision)
  • 40% synthesis (hybrid timeline, combined strengths, gap-filling)

5. Your Team Will Trust This Process

When you present "two AIs explored this independently and here's where they converged," engineers respect that.

It's objective. It's thorough. It's reproducible.

Much easier sell than "I designed this over the weekend."


The Future: Parallel AI as Standard Practice

This technique is stupidly easy and absurdly effective.

I predict that within 2 years, running parallel AI explorations will be standard practice for:

  • Architecture reviews
  • Product strategy
  • Technical RFCs
  • Build/buy decisions
  • Risk assessments

Why?

  1. AI is cheap (pennies per session)
  2. AI is fast (hours, not weeks)
  3. AI is unbiased (no political agendas)
  4. AI is thorough (explores paths humans wouldn't consider)

The firms that figure this out will ship better products, faster.

The firms that don't will still be running 3-week design sprints while we're already in production.


Try It Yourself

Next time you face a significant technical decision:

  1. Open two separate AI sessions (Claude, ChatGPT, whatever you use)
  2. Give them identical problem briefs
  3. Ask each: "Design a solution. Be specific."
  4. Compare the outputs
  5. Synthesize the best of both

Time investment: 4-6 hours. Potential value: Avoiding a $1M+ architectural mistake.

That's a pretty good trade.


Closing Thought

The best architecture isn't the one you design. It's not the one your team designs. It's not even the one an AI designs.

The best architecture is the one that survives exploration from multiple angles and emerges as the synthesis.

Parallel AI exploration gives you that synthesis - faster, cheaper, and more comprehensively than any traditional process.

We used it to design our next major product. You should use it too.


Erik Bethke is CEO of Bike4Mind and Million on Mars, and CTO of The Futurum Group. Game developer turned AI founder, he built Starfleet Command and GoPets, led at Zynga on Mafia Wars and FarmVille, and authored Game Development and Production and Settlers of the New Virtual Worlds. Former NASA/JPL engineer (Galileo, Cassini). He's biked across Japan, sailed with his family for 3 years, is a technical diver and member of the Explorers Club, holds a 100-ton master's license, and has voicemails from the ISS on his phone. Currently focused on applied AI and agentic systems to push the edges of human capability. LinkedIn

Want to discuss parallel AI exploration techniques? Reach out on LinkedIn.


Appendix: The Technical Details (For Engineers)

What We Actually Built

Without revealing proprietary specifics, here's the sanitized version:

Problem: Multi-team manual workflow ($500K+/year, 6-month lag times, zero personalization)

Solution: AI-powered data pipeline (continuous collection → validation → auto-generation → personalization)

Parallel Exploration Results:

  • Both AIs: "This is about transforming static artifacts into living databases"
  • Both AIs: "Use AI agents for data collection, structured schemas for storage, auto-generation for outputs"
  • AI #1: "Build it in 12 weeks with 2 developers"
  • AI #2: "Build it in 18 months with 13 developers at peak"
  • Our synthesis: "Build it in 30 weeks with 2-5 developers"

Outcome:

  • Investment: $622K total (5-year horizon)
  • Benefit: $12.6M+ (cost savings + new revenue)
  • ROI: 2,000%+
  • Confidence: Extremely high (validated by independent convergence)

The Meta-Architecture They Both Recommended

Both AIs independently proposed:

Data Collection Layer (AI Agents)
    ↓
Validation Layer (Multi-Source, Confidence Scoring)
    ↓
Structured Database (Temporal Versioning, Change Tracking)
    ↓
Generation Layer (Schema-Driven Auto-Generation)
    ↓
Personalization Layer (Customer Context Filtering)

This is a generalizable pattern for any "manual research → automated intelligence" transformation.

If you're considering a similar migration, this architecture is battle-tested by two independent AI explorations.

Key Technical Decisions (From Synthesis)

Where AI #1 Won:

  • AgentRun collection (monitor what agents are doing)
  • Schema-driven dashboard generation (truly zero manual work)
  • 12-week sprint mentality (prove value fast)

Where AI #2 Won:

  • MarketEvent collection (first-class change tracking)
  • Multi-tier source validation (prevent AI hallucinations)
  • Revenue expansion architecture (API products, premium tiers)

Where Synthesis Added Value:

  • 30-week timeline (not 12, not 78 weeks)
  • Lean initial team with robust foundations (not lean-but-fragile, not robust-but-expensive)
  • Phase 1: Speed, Phase 2: Scale, Phase 3: Monetize (best of both philosophies)

Postscript: If you're a CTO reading this and thinking "I should try this," please do. Then write about your results. Let's collectively figure out how to make AI a better design partner.

The more of us who experiment with parallel exploration, the faster we'll discover best practices.

This is day one of a new design methodology. Let's build it together.

Related Posts

The Control Plane: Maximizing the Human-Machine Interface

The paradigm shift as fundamental as mobile or cloud: humans commanding autonomous agent fleets. Not chatbots—control planes. Not UI-first—API-first. ...

AI
API Development
Architecture

Two Claude Codes, Two Repos, One Solution: A Multi-Agent Workflow Story

How two Claude Code instances collaborated across different repositories to solve a 500 error by mining proven patterns from production code. A meta-n...

AI
Claude Code
Multi-Agent Systems

The Mu Strategy: How to Build on Hyperscalers Without Being Owned By Them

The Norway essay showed hyperscalers running a sovereign-grade macro trade. This essay explains the third option: Mu — how to use hyperscalers as infr...

AI
Architecture
Cloud & Infrastructure

Subscribe to the Newsletter

Get notified when I publish new blog posts about game development, AI, entrepreneurship, and technology. No spam, unsubscribe anytime.

By subscribing, you agree to receive emails from Erik Bethke. You can unsubscribe at any time.

Comments

Loading comments...

Comments are powered by Giscus. You'll need a GitHub account to comment.

Published: November 19, 2025 2:09 AM

Last updated: November 19, 2025 2:17 AM

Post ID: c68eb226-b6f1-460b-8a99-87afbddc9856