Three tools, three jobs, and the entire lesson lives in the boundaries between them. v0 ships a working component prototype wired to your design-system tokens, and it produces the "looks-right, behaves-wrong" moments you now know to catch. Bolt - five million users and forty million dollars of ARR inside five months as of late 2025 - produces a polished throwaway demo for a sales conversation that you explicitly retire after the meeting. Replit Agent extends a Lovable prototype into a small production-ready internal tool, with engineering paired on review. These are bundled deliberately, because the skill is not operating any one of them; it is knowing which job you are doing and refusing to let one tool's output drift into another tool's territory. You walk away with three artifacts that encode the boundaries: a v0 component preview with a behavior audit, a Bolt throwaway URL with a retirement note, and a Replit pair-review log - and with the judgment to know where each becomes overreach.

Why Bundling These Is the Lesson

You could write a lesson on each of these tools. The reason they are together is that the dangerous failures are not within any tool but at the seams - using v0's component prototype as if it were production, treating Bolt's throwaway as a build commitment, extending Replit's internal tool toward something customer-facing without the engineering rigor that scope demands. Each tool is genuinely good at its job and genuinely dangerous one step past it, and the one step past is exactly where the excitement pushes you. The lesson is a map of three territories and, more importantly, the borders between them, because the border crossings are where the program's whole theme - knowing what kind of thing you are holding - gets tested at the prototyping limit.

The unifying question for all three is: what is this artifact for, and what happens to it next? A v0 component is for proving an interaction works against real tokens, and next it informs the real build. A Bolt demo is for making a sales conversation concrete, and next it is deleted. A Replit tool is for solving a real internal need, and next it runs in production with engineering owning it. Confuse the "what next" and you get the characteristic disasters: a v0 prototype quietly shipped, a Bolt demo mistaken for a roadmap commitment, a Replit tool sprawling into an unmaintained customer-facing liability. Hold the "what next" clearly and each tool is a gift. The artifacts exist to make the "what next" explicit and binding.

v0: Component-First Prototyping, With the Behavior Audit Attached

v0's job is component-first prototyping connected to your design-system tokens. You give it a component spec and your tokens, and it produces a working React component preview - a real, interactive thing you can click, not a picture. This is genuinely valuable: it proves an interaction works, it surfaces states a static mock hides, and when wired to your actual tokens it shows the component in something close to its real visual context. For proving out a single component's behavior and look against the real system, v0 is excellent.

And it produces the "looks-right, behaves-wrong" moments this whole program trained you to catch, now in code rather than in a mock. The v0 component will look correct and have a focus state that does not meet contrast, a hover interaction that has no keyboard equivalent, a token that drifted two pixels, an empty state that was never designed, a loading state that does not exist. The behavior audit is the artifact that pairs with the v0 preview: a structured pass over the component's actual behavior - every state, every interaction, every accessibility property - flagging where the working-looking component behaves wrong. This is the L3 version of the L1 generated-mock audit, applied to working code: the component runs, which makes it more convincing and therefore more in need of a behavior audit, because a thing that runs is even easier to mistake for a thing that is done.

The overreach for v0 is treating the component prototype as the production component. v0 is for proving the component's behavior; it is not for shipping. The prototype informs the real build - it shows engineering what the interaction should be, it surfaces the states to handle - but the production component gets built (or rebuilt) with the rigor v0's fast output skips. The moment someone says "v0 already built it, let's just ship this," you are across the border, and the behavior audit is your evidence for why that is a mistake: it lists exactly what the prototype gets wrong that production cannot.

Bolt: The High-Fidelity Throwaway, Retired On Purpose

Bolt's job is different and its danger is sharper. Bolt produces a polished, working, full-app demo fast - which is why it grew to five million users and forty million dollars of ARR in five months by late 2025 - and the right use for that capability is a high-fidelity throwaway: a demo that makes a sales conversation or a stakeholder pitch concrete, that lets the room see and click a possible future, and that is deliberately retired the moment the meeting ends. The throwaway is a communication artifact, not a build artifact, and its value is entirely in the conversation it enables, not in any code it produces.

The danger is that Bolt's output is too good to look disposable. A polished, working demo looks like a product, and the people in the sales conversation - who are not designers or engineers - cannot tell the difference between "we built a thing that demos this" and "we built this." The throwaway gets screenshotted into a deck, referenced as if it were a commitment, forwarded to a customer as a preview, and three weeks later someone is asking why "the product we showed" is not in the sprint. The polish that makes Bolt useful for the conversation is exactly what makes it dangerous after the conversation, because it does not announce that it is a throwaway.

This is why the artifact is a throwaway URL with a retirement note - the note is the whole point. The retirement note states, in writing attached to the demo: this is an exploratory throwaway built for [the specific meeting], it represents a possible direction not a build commitment, it will be retired on [date], and it is not to be forwarded as a product preview. The note is what converts a dangerous polished artifact into a safe one, by making its disposability explicit and binding rather than relying on everyone to remember that the impressive thing they saw was not real. Retiring the artifact - actually taking it down - is the discipline that prevents the throwaway from having a second life as a phantom commitment. The senior IC who builds the Bolt demo is also the person who writes its obituary in advance.

Bolt's polish is the feature and the trap. A throwaway too good to look disposable becomes a phantom commitment the moment it leaves the room. The retirement note - written in advance, binding, and followed - is what keeps the demo a conversation and not a promise.

Replit Agent: The Real Thing, With Engineering Paired

Replit Agent's job is the most consequential and the one where a designer most needs a partner. The pattern is extending a Lovable prototype - a working app that proved a concept - into a small, production-ready internal tool that a real team will actually use. Not a throwaway, not a prototype that informs a build: an actual tool that goes into production for an internal audience. This is real software with real users, even if the users are forty people in your own company, and that changes the rules entirely.

The defining discipline here is that engineering is paired on review. A designer can drive Replit Agent to extend the prototype, but the moment the output is headed for production, it needs the rigor a designer working alone cannot supply: real error handling, data handling that does not lose or corrupt the team's data, security appropriate to what the tool touches, and maintainability so it is not an unowned liability the day after it ships. The designer brings the product judgment and the speed; engineering brings the production rigor and owns the parts that, done wrong, cause real harm. The pairing is not a courtesy - it is the thing that makes "production-ready" true rather than aspirational, and the pair-review log is the artifact that records it: what the designer built, what engineering reviewed, what engineering changed or flagged, and the explicit sign-off that the tool is fit for its production scope.

The overreach for Replit Agent is scope creep past "small internal tool." An internal tool for forty trusted colleagues has a blast radius you can reason about; the same tool pointed at customers, or handling sensitive data, or becoming load-bearing for a real business process, has a blast radius that demands far more than a designer-plus-one-engineer review. The pattern works precisely because it is bounded to small, internal, and paired-reviewed. The moment any of those three constraints is removed - it goes external, it grows large, the engineering review lapses - you are building production software without the structure production software requires, and the pair-review log is where that boundary is supposed to be enforced, by naming the scope the sign-off covers and refusing to let the tool quietly exceed it.

The Three Borders Where Each Becomes Overreach

Lay the three overreaches side by side and a single pattern emerges. v0 overreaches when the prototype is treated as production. Bolt overreaches when the throwaway is treated as a commitment. Replit overreaches when the small internal tool grows external, large, or unreviewed. In every case, the overreach is the same move: taking an artifact built for one "what next" and pushing it into a "what next" that demands more rigor than it was built with. The tools do not enforce their own boundaries - they will happily let you ship the v0 prototype, forward the Bolt demo, and scale the Replit tool to customers - so the boundary has to live in you, and in the artifacts that make the boundary explicit.

This is why each artifact is shaped to encode its border. The v0 behavior audit lists what the prototype gets wrong, so "just ship it" runs into a documented list of why not. The Bolt retirement note makes the throwaway's disposability binding, so "let's reference the demo" runs into a written statement that it was never a commitment. The Replit pair-review log names the production scope the sign-off covers, so "let's point it at customers" runs into the fact that no one reviewed it for that. The artifacts are not documentation for its own sake; each is a tripwire placed exactly at the border its tool is most likely to be pushed across. The senior IC's contribution is not just using the three tools well but installing the tripwires that keep the team from using them past their job.

Choosing the Right Tool by the Job, Not the Output

Because the three tools overlap in what they can produce - all three can make something that looks like a working app - the choice between them cannot be made by looking at the output. It has to be made by the job, the "what next." Are you proving a single component's behavior against your tokens, to inform a build? That is v0, and the output gets a behavior audit and feeds the real build. Are you making a sales or stakeholder conversation concrete, with no intention of keeping anything? That is Bolt, and the output gets a retirement note and gets deleted. Are you solving a real internal need that a team will use in production? That is Replit Agent with engineering paired, and the output gets a pair-review log and a bounded production scope.

The discipline is to decide the job before you open the tool, because deciding by output after the fact is how the borders get crossed - you build something impressive in Bolt, it looks production-ready, and now the job is being redefined to match the output instead of the output being built to match the job. Senior judgment is choosing the tool from the "what next" and then holding the artifact to that "what next" with the audit, the note, or the log. A designer who can do this fluidly - pick v0 for the component proof, Bolt for the throwaway, Replit for the real internal tool, and keep each in its lane with the right artifact - is operating at the prototyping limit exactly as L3 demands: using the most powerful generative tools of 2026 at full speed while never once losing track of what each output is for.

Why This Is "At the Limit"

The chapter is called prototyping at the limit because these three tools are where prototyping stops being clearly distinct from building, and the limit is the point where that distinction has to be held deliberately or it collapses. A v0 component is real code. A Bolt demo is a real working app. A Replit tool genuinely runs in production. In every case the tool has pushed the prototype so close to the real thing that the only difference left is the discipline you impose - the audit that says this component is not production-ready, the note that says this demo is not a commitment, the review that says this tool is fit only for this bounded scope. Without that discipline, the tools dissolve the boundary between prototype and product, and the dissolution is where the damage lives.

Holding the line at the limit is the senior-IC capability this lesson certifies. It is not anti-tool - the tools are extraordinary and using them at full speed is the right move. It is the recognition that the more capable the tool, the more the boundary depends on the human, because the tool will not draw it for you. v0 will let you ship the prototype, Bolt will let the throwaway become a promise, Replit will let the internal tool become a customer liability, and none of them will warn you, because warning you is not their job - it is yours. The three artifacts are how you do that job: each one is a small act of holding the line, a written commitment to what the output is for, placed exactly where the tool's capability is most likely to carry you past it. Master the three tools and you are fast; master the three borders and you are a senior IC who can be trusted with fast tools, which is the rarer and more valuable thing.

Key Takeaways

• The three tools are bundled because the skill is not operating any one of them but knowing which job you are doing and refusing to let one tool's output drift into another's territory. The dangerous failures are at the seams, not within any tool.
• The unifying question is "what is this artifact for, and what happens to it next?" A v0 component informs the real build; a Bolt demo is deleted after the meeting; a Replit tool runs in production with engineering owning it. Confuse the "what next" and you get the characteristic disasters.
• v0 is component-first prototyping against your tokens, and it produces "looks-right, behaves-wrong" moments in code. The behavior audit pairs with the preview to flag every state, interaction, and accessibility property the working-looking component gets wrong. Overreach: treating the prototype as the production component.
• Bolt (5M users, $40M ARR in 5 months by late 2025) produces a polished throwaway for a sales or stakeholder conversation, retired the moment the meeting ends. Its polish is the feature and the trap - too good to look disposable. The retirement note, written in advance and binding, is what keeps it a conversation and not a phantom commitment.
• Replit Agent extends a Lovable prototype into a small production-ready internal tool, with engineering paired on review. The pairing makes "production-ready" true rather than aspirational - engineering owns error handling, data, security, maintainability. The pair-review log records what was built, reviewed, changed, and the bounded scope the sign-off covers. Overreach: scope creep past small, internal, and reviewed.
• Every overreach is the same move: taking an artifact built for one "what next" and pushing it into one that demands more rigor than it was built with. The tools do not enforce their own boundaries, so the boundary lives in you and in the artifacts that make it explicit.
• Each artifact is a tripwire at its tool's most-likely border crossing: the behavior audit blocks "just ship it," the retirement note blocks "reference the demo," the pair-review log blocks "point it at customers." Choose the tool by the job, not the output, decide the job before opening the tool, and hold each output to its "what next." Master the three tools to be fast; master the three borders to be a senior IC who can be trusted with fast tools.