Marty Cagan’s recent piece on prototyping tools draws a clean line: build-to-learn tools on one side, build-to-earn tools on the other. He’s right about the hype problem: product managers confusing high-fidelity prototypes with production-ready systems. But the binary he describes is already dissolving.
The categorization reflects tool architecture. Lovable and Bolt for prototyping, Claude Code, and Cursor for production. UI-first tools abstract complexity and accelerate visual validation. Terminal-based tools expose code and configuration, giving engineers control over reliability, observability, and scale.
But that architectural difference doesn’t lock tools into single purposes anymore.
What’s Shifting
Claude Code sits in both camps. Non-technical product managers can use it to generate working prototypes that run on live data and simulate complex business logic. Then they hand that same generated code to engineering, who refactor what’s useful and discard what isn’t. But they continue building in the same environment with the same tool.
This isn’t theoretical. It’s happening now with Claude Code, Codex CLI, and tools like Droid Factory. The learning curve exists. Terminal interfaces intimidate at first, but the investment pays off in continuity. One tool, two phases, no translation layer.
Why the Convergence Matters
When prototyping and production share infrastructure, handoffs get cleaner. Product managers generate testable hypotheses in code, not static mockups. Engineers inherit working logic they can evaluate and extend, not wireframes they interpret from scratch. The gap between discovery and delivery narrows.
This doesn’t erase Cagan’s core warning: prototypes still aren’t products. Business complexity, runtime demands, and operational constraints (reliability, telemetry, fault tolerance, compliance) remain non-negotiable for commercial-grade systems. Prototyping sophistication doesn’t eliminate that work.
But it does change the question. It’s not “Can this prototype become a product?” It’s “How much of this prototype’s logic survives into production, and how quickly can we validate the rest?”
The Implications
For product managers: Learning terminal-based tools is now a leverage move, not a technical detour. If you can prototype in the same environment engineering uses for delivery, you reduce interpretation overhead and accelerate feedback loops.
For engineering teams: Code generated during discovery becomes a starting point, not a distraction. You’re evaluating real logic against real constraints, not translating concepts across tool boundaries.
For organizations: The “build-to-learn versus build-to-earn” framing still holds. Separating discovery from delivery remains essential. But the tooling gap that once reinforced that separation is closing. That’s a workflow shift, not a conceptual collapse.
Open Questions
Can these converged tools handle the full complexity Cagan describes (thousands of use cases, enterprise-grade reliability, zero-downtime deployments) within the next three years? Unknown. The spec-driven development is picking up, so I am optimistic.
If tools serve both discovery and delivery well enough to accelerate learning and reduce handoff friction, that’s sufficient. Perfect continuity isn’t the goal. Better sequencing is.
The hype Cagan warns against (thinking prototypes are products) still deserves the warning. But the tools enabling that confusion are also solving a different problem: making the path from prototype to product less lossy. That’s not hype. That’s progress.