I'm a product manager who doesn't know how to code.
If you looked at my GitHub commit graph before April 2025, you'd see mostly empty squares. Nothing unusual for a PM. Then I started using Builder.
Those commits are features and bug fixes, live in production, used by thousands of users every day. I shipped them alongside my team, reviewed by our engineers, merged into our actual codebase.
What changed? I learned how to prototype with AI in a way that connects to our real product. The person closest to the problem can now build solutions without waiting on anyone else.
If you're a PM who already knows AI prototyping matters but you're stuck on the "how," this guide is for you. Especially if you've tried tools like Lovable or Bolt, built something exciting, and then hit the wall of "cool, but how do I get this into our actual product?"
Let's fix that.
Why prototyping beats PRDs
A PRD tells your team what you want to build. A prototype shows them.
You know the old saying: a picture is worth a thousand words. A working, interactive prototype is worth a million. It lets stakeholders experience your idea instead of interpreting your documentation. It lets users give feedback on something real instead of reacting to wireframes.
The traditional cycle looks like this: write PRD, meet with design and engineering, create wireframes, revise PRD, revise wireframes, demo internally, revise again, demo to customers, revise again.
AI prototyping compresses this. You can have something working in hours. A real, functional prototype that stakeholders can use and react to.
But here's where tools diverge.
The standalone prototype trap
Tools like Lovable and Bolt have made prototyping dramatically easier. You describe what you want in plain language, and you get a working application. The barrier to entry is low. You don't need to connect a repo or think about your existing codebase. You can start building right away.
That low barrier is both the strength and the limitation.
When you prototype in these tools, you're building on an island. The components are generic. The styling doesn't match your product. The code has no awareness of your patterns or conventions.
You can demo the concept, but you can't use the work. When you want to ship it, engineering starts from scratch.
For early-stage exploration or brand-new product ideas, that's fine. But if you're a PM prototyping features for an existing product, you need something that works inside your world.
You need prototypes that use your design system, reuse your components, and fit the patterns your team already follows. You need prototypes that can become pull requests.
How Builder.io approaches AI prototyping differently
Builder connects to your existing codebase. You open your repo in Builder the same way you'd open it in VS Code or Cursor. You run your standard setup scripts, and your application runs locally. Then you build on top of it.
When you prompt Builder to create a feature, it uses your actual components.
If your codebase has a Modal component, Builder uses that Modal. If you have specific patterns for handling forms or state, Builder follows them. The generated code looks like it was written by a developer on your team, because it learned from your team's codebase.
This is powered by something called Design System Intelligence. You run a single command that indexes your codebase, and Builder learns your components, how they work, and when to use them.
Combined with a Figma plugin that lets you paste designs as context, you can say "build this design" and Builder will implement it using your real building blocks.
The result: prototypes that exist inside your product. You can see how a new feature interacts with existing pages. You can test real user flows. And when you're happy with it, you click "Create PR" and your prototype becomes a code review, ready for your engineers to approve and merge.
[Screenshot: Builder interface showing a prototype with the "Create PR" button]
The AI prototyping workflow
Here's how to approach prototyping for any feature.
Break your feature into small pieces
This is the most important step, and where most PMs go wrong with AI tools.
Don't prompt "build me a referral program." That's too big. The AI will make assumptions you don't want, miss requirements you didn't state, and produce something that's harder to iterate on.
Instead, decompose your feature the way you'd write acceptance criteria:
- The core experience: A modal where users see their unique referral link, how many referrals they've sent, and how many have converted
- The rules: What counts as a successful referral? Does the referee need to sign up, or complete onboarding, or make a purchase? What do both parties get, and when?
- Discovery: Where do users encounter this? A banner on the dashboard? A prompt after checkout? A persistent nav item?
- The feedback loop: When a referral converts, how does the referrer know? A notification? An updated count in the modal? An email?
Each piece is small enough to build, test, and refine independently. You'll move faster by going smaller.
Plan before you build
Don't fire off a prompt and hope for the best.
Builder has two modes: Plan and Build. In Plan mode, you have a conversation with the AI. You describe what you want. The AI asks clarifying questions. You provide context. Maybe you paste a Figma design or reference a PRD.
The AI proposes an approach: which files it'll modify, which components it'll use, how the pieces fit together.
No code gets written during planning. You're aligning on the approach before anything happens. When the plan looks right, the AI asks if you want to implement it and switches to Build mode.
This back-and-forth prevents the "one-shot prompt and pray" problem. You've effectively briefed a developer before they start coding. Except that developer is AI, and the briefing took minutes instead of a meeting.
Execute and preview
Once you approve the plan, Builder generates the code. Because it's running on a branch of your actual codebase, you can preview the change immediately in your real product context.
This is where Builder differs from standalone tools. You're looking at your product with the new feature integrated. You can click through existing flows and see how the new work fits.
Refine visually
AI gets you most of the way there, but rarely 100%. You'll need to refine.
Builder offers a Figma-like visual editor for this. You can adjust layouts, spacing, and styling without writing code. Drag elements around. Tweak padding. Change colors.
The visual controls are accessible to PMs and designers, but you can also drop into the code directly if you prefer.
This is also where collaboration happens naturally. Share a link with your designer. They can refine the visuals, ensure everything conforms to the design system, and sign off before you proceed.
Ship it (or don't)
Your prototype doesn't have to be throwaway.
Click "Create PR." Builder generates a pull request with an auto-written description. Your engineers review it the same way they'd review any code. If it passes, it merges. Your prototype is now a feature.
But you don't have to ship everything. Sometimes you're prototyping to explore different approaches. You build three variations, share them with stakeholders, gather feedback, and discard two.
That's still valuable. The point is that you have the option to ship when something hits. There's no rebuild tax.
Integrating AI prototyping into your workflow
AI prototyping does not replace your process. You still need to define the problem clearly. You still need stakeholder input. You still need design review and engineering sign-off. But instead of those conversations happening around a document, they happen around something people can interact with.
Before sprint planning: Prototype the feature you're proposing. Show the team what you're thinking instead of describing it. Debates get more productive when everyone can see and touch the thing.
During stakeholder reviews: Send a share link. Let stakeholders click through the experience themselves. You'll get higher-quality feedback than you would from a slide deck.
When validating with users: If your prototype is in the actual product (on a branch), you can do realistic usability testing. Users interact with real data and real flows.
When handing off to engineering: If your prototype is solid enough, the PR becomes the starting point. Developers refine and harden rather than building from zero. If it needs significant work, the prototype still serves as a detailed spec that's impossible to misinterpret.
What you're probably wondering
Do I need to know how to code?
No. The entire point is that you don't. You need to know how to describe what you want clearly, break problems into small pieces, and review whether the output matches your intent. Those are PM skills.
What if the AI generates bad code?
Because Builder uses your existing components and patterns, the code quality is consistent with the rest of your codebase. Your engineers will review the PR regardless.
The question to ask: does AI write code that's good enough to start from? In our experience, yes. Developers are often surprised by how clean it is.
Does this work with any tech stack?
Builder supports most modern web frameworks. If your codebase runs locally, you can connect it to Builder.
What if I don't want to ship the prototype?
Then don't. Delete the branch. The work still had value: you explored an approach, got feedback, maybe ruled out a direction. Prototyping is about learning fast. Shipping is optional.
How is this different from Cursor or other AI coding tools?
Cursor is built for developers who are comfortable in code. Builder is built for cross-functional teams.
The visual controls, Plan mode conversations, and design integration make it accessible to PMs and designers. And the focus on connecting to existing codebases means you're prototyping in production context.
Getting started
The fastest way to understand this is to try it.
Connect a repo. Pick a small feature or improvement you've been thinking about. Break it into pieces. Use Plan mode to align on the approach. Build it. Refine it. See how it feels.
You'll ship your first prototype faster than you'd schedule the kickoff meeting for the traditional process.
Try Builder for free and see what your commit graph looks like in a few months.
