What’s the real cost of an in-browser AI prototype?
An in-browser AI prototyping tool can take you from nothing to a working, clickable concept in minutes. What it can’t do is produce something your engineering team can merge as-is. The prototype was built in an isolated sandbox, without ever seeing your actual component library, design tokens, auth layer, or the architecture decisions your team has already made — so before it can ship, someone has to rebuild it against the codebase it was never grounded in. That rebuild is the real cost, and it rarely shows up until after the demo.
Why sandbox prototypes can’t merge as-is
Tools like Bolt.new and v0 solve a real problem well: going from an idea to something you can click through, with no setup and no repo access required. Bolt runs your app in a sandboxed browser environment. v0 generates React components, usually against a generic design system like shadcn/ui. Neither needs — or uses — your actual codebase to produce something that looks finished.
That’s exactly the job they’re built for: validating an idea before anyone commits engineering time. It’s not the job of shipping a change into a codebase that already has users, a design system, a review process, and an engineering team that has to trust what gets merged.
The port-over tax: where the “saved” time actually goes
This is the part that doesn’t show up in the demo. The prototype took five minutes to generate, so it looks like five minutes of work got removed from the project. What actually happened is the work moved downstream: an engineer has to go through the prototype line by line, swap in the real components, rewire it to the actual data layer, pass the existing test suite and CI, and build out the states a demo usually skips — loading, empty, error. Someone now has to understand two things at once: what the prototype was trying to express, and how the real system actually works. That’s often slower than building the feature from scratch.
A tool that produces something nobody can merge without a rewrite hasn’t removed engineering work. It’s relocated it, downstream, and added a translation step.
Sandboxes and delivery layers are solving different problems
Bolt and v0 are doing exactly the job Wave 1 tools are built for: taking an idea from nothing to a working concept, fast, in an isolated environment. That’s a different job from shipping a change into a codebase that already has users and a review process that has to trust what it approves. Judging a sandbox tool for not doing the second job isn’t fair to the tool — but using it for the second job is where teams lose the time they thought they were saving.
What changes when the AI works inside your repo instead
Fei Studio, AutonomyAI’s Autonomous Delivery Layer, is built for the second job specifically. It learns your actual components, design tokens, conventions, and existing PR patterns before it writes anything, builds the change against that context, boots your app, renders the result, and checks it against the original intent — loading, empty, error, and success states included — before anyone sees it.
The output is a pull request scoped to your repo, in your patterns, ready for the review your team already runs. An engineer still reviews and merges every change — that gate doesn’t move. What changes is what arrives at it: a working, already-checked change instead of a sandbox export someone has to rebuild by hand. The review is fast not because the tool is fast, but because the PR is already grounded in the system it has to live in — the PR is the receipt, not the pitch.
We run this on our own product: our PM has opened 50+ PRs against our production codebase since January 2026, roughly 70% merged, without writing a line of code — each one still reviewed and approved by an engineer. That’s one data point, but it’s a real one, checked against a real codebase instead of a sandbox.
Three questions worth asking before you pick a tool
- Does it run in your actual repo, or generate in an isolated sandbox that someone then has to port over by hand?
- Does the output use your real components and design tokens, or generic ones that look right until they sit next to the rest of your app?
- Does an engineer review and merge it, or rewrite it first? Those are very different amounts of work, even when the starting demo looks identical.
FAQ
Not without rework. These tools generate against a generic stack and don’t have access to your repo, so an engineer has to rebuild the output against your real components, data layer, and test suite before it can ship.
A sandbox (Bolt, v0) generates in an isolated environment with no knowledge of your codebase — it’s built for validating ideas fast. A delivery layer (like Fei Studio) works inside your actual repo, using your real components and conventions, and produces a pull request your team can review and merge directly.
No. An engineer still reviews and merges every change — that step doesn’t change. What changes is what arrives at review: a change already checked against your codebase, instead of a prototype that needs to be rebuilt first.
Want to see what a change looks like when it’s built against your actual codebase instead of a sandbox? Book 20 minutes and we’ll run it on yours.
Discover what the future of product teams looks like!
