Bolt.new Prompting Guide (2026)

Prompting Bolt.new is not like prompting a chat model or an in-IDE assistant. Bolt.new is StackBlitz's AI-powered full-stack generator, and what makes it distinct is where the generated app runs: in a WebContainer, directly in your browser. That constraint shapes everything. The short version: write app-level briefs, pin the tech stack, and treat the browser runtime as part of the spec, not an afterthought.

What Bolt.new Is

Bolt.new is an AI coding agent that generates full-stack web applications and runs them inside a WebContainer — StackBlitz's in-browser runtime for Node.js-style projects. You describe an app, Bolt writes files across the stack, installs packages, and boots a preview next to the chat. No remote VM to wait on, no local toolchain to set up.

Bolt is not a chat model suggesting code to paste, and it is not an in-IDE agent editing files you already opened. It is a full-stack generator that wants to produce a running app from a description. For the category, see agentic AI; for the broader landscape, see the pillar: The Complete Guide to Prompting AI Coding Agents.

The WebContainer Constraint — And Why It Belongs in the Prompt

The WebContainer is the most load-bearing fact about Bolt.new and the one most likely to get ignored. WebContainers are real tech — an in-browser runtime that executes Node.js-style code client-side, without a remote server. That is what makes Bolt feel instant.

The tradeoff is that "runs in the browser" is a different surface than "runs on a Linux VM." Native binaries, OS-level tooling, and some system calls behave differently or are unavailable in a browser runtime. Exactly which dependencies work cleanly evolves over time, so the honest posture in a prompt is: name the runtime, flag the concern, and let the agent pick browser-friendly options.

Practically, that is one line: "Runs in Bolt's WebContainer; prefer pure-JS dependencies and avoid anything that needs native binaries or a traditional server runtime." That sentence steers the generator away from stacks that look fine on paper but fight the runtime.

How Bolt.new Prompting Differs From v0 and Replit Agent

It is easy to lump Bolt in with other AI-generates-an-app tools, but the prompt shapes differ. Bolt sits next to v0 (UI-only, component-level) and Replit Agent (full-stack, VM-based) on the same map — different units of work, different runtimes, different things to specify.

Two things fall out of the table. First, Bolt's unit of work is a whole app, so one-line prompts underperform — too much to decide. Second, the in-browser runtime changes what a good constraints section looks like. You are specifying an app that has to run where Bolt runs. For an in-IDE comparison, see the Cursor prompting guide.

App-Level Briefs — Not Component Requests

The biggest prompt shift when moving to Bolt is zooming out from "build me this screen" to "build me this app." An app brief names the product, the users, the flows, the data model, the auth story, and the pages — in plain language, not as code. Six short blocks:

• What the app is. One or two sentences. The product in a line.
• Who uses it. The user and their job. A sentence, not a persona paragraph.
• Main flows. What a user can do. Sign up, create X, view Y, edit Z. Numbered helps.
• Data model. The shapes that persist — users, projects, tasks — with the fields that matter.
• Auth and pages. How users log in (or whether they do) and what pages exist.
• Out of scope. Flows v1 does not include. Stops the agent from inventing a billing page.

Skip any of these and Bolt fills the gap with a default: a login page you did not ask for, a data model that does not match the flows, pages that duplicate each other. The brief is not bureaucracy — it is the cheapest way to keep the first generation close enough to iterate on.

Specifying the Tech Stack — Don't Let Bolt Pick Blind

Bolt will cheerfully pick a stack for you. It has to — you asked for an app, not a framework. The question is whether you own that decision in the prompt or discover it in the preview pane.

Under-specifying gets you a running app faster, at the cost of a stack your team may not use. Over-specifying turns the prompt into a spec document and slows iteration. The middle path — pin the load-bearing pieces, let the agent choose the rest — works here for the same reason it works elsewhere.

What counts as load-bearing:

• Framework. Next.js, Remix, Astro, Vite + React SPA. The framework sets the mental model. Pin it.
• Database / storage. Is there a database? In-memory, browser-local, or an external API? This changes what "persistence" means in a WebContainer. Pin it.
• Auth. Email + password, magic link, social, or none for v1. Pin it.
• Styling. Tailwind, CSS modules, a component library, or agent's choice. Pin if you care.

WebContainer compatibility is part of the stack decision, not a separate concern. A stack that looks great in a blog post may fight the runtime. When in doubt, tell Bolt to "prefer WebContainer-compatible dependencies." For a different read on stack-pinning, see the Replit Agent guide.

The In-Browser Iteration Loop

What Bolt does best is iterate fast. The app runs in the same tab you are prompting from, so the round-trip between "change the prompt" and "see the new behavior" is shorter than almost any other coding tool. That speed rewards a specific loop:

• Generate. Submit the brief. Let Bolt scaffold the files and boot the preview.
• Click through. Walk the main flows. Happy path, not every edge case.
• Pick one or two changes. "Make the dashboard a sidebar + content layout." "Add a delete action." Not ten.
• Prompt the change. Reference observed behavior, not code. Bolt regenerates the affected parts.
• Repeat. Two to five tight loops is normal. If the change list keeps growing, rewrite the brief.

Resist the urge to edit files line-by-line in the Bolt editor. That works, but it burns the speed advantage. If you want line-level control, an in-IDE agent like Cursor is a better home. If you want to iterate on the app shape, stay in the prompt loop.

Where Bolt.new Shines vs. Where It's Weaker

The sweet spot is prototypes, demos, internal tools, and the v0 of a product idea. Anywhere "I want a running version of this app today" is worth more than "I want the code to live in our main repo for three years." For those jobs, the WebContainer runtime is a feature: zero setup, shareable URL, fast feedback.

Weaker spots, to be honest about:

• Long-lived codebases. Bolt optimizes for generating and regenerating, not minimal-diff changes against existing conventions.
• Heavy native dependencies. Tools needing native binaries or OS-level access do not fit a browser runtime the way they fit a VM.
• Arbitrary production deploy targets. Bolt can export and you can deploy, but an app generated for a browser runtime may need adjustment before it runs the same way on your production infrastructure.
• Massive apps. A twenty-page, multi-role enterprise product from one brief is asking too much. Scope v1 ruthlessly.

Rough decision heuristic:

• Prototype or demo, running today. Bolt.new is a strong default.
• Full app with VM-hosted persistence and a real deploy target. Replit Agent may fit better.
• UI component or page, not a whole app. Use v0.
• Targeted change in an existing codebase. Use an in-IDE agent.

A Good App Brief Example

A hypothetical app brief for Bolt.new. Replace the specifics with your own — the shape and the constraints section are what matter.

APP
  "Readlog" — a personal reading tracker. One user logs the
  books they are reading, marks progress, and sees a simple
  history of finished books.

WHO IT IS FOR
  A single user (me). No accounts, no sharing.

MAIN FLOWS (v1)
  1. Add a book by title + author.
  2. Update a book's status: to-read, reading, finished.
  3. Record a short note when finishing a book.
  4. View three lists: currently reading, finished, to-read.
  5. Delete a book from any list.

DATA MODEL
  Book:
    - id (string)
    - title (string)
    - author (string)
    - status ('to-read' | 'reading' | 'finished')
    - note (string, optional, for finished books)
    - createdAt, updatedAt

OUT OF SCOPE (v1)
  - Multiple users, accounts, login.
  - Book covers, external metadata, ISBN lookup.
  - Ratings, tags, categories.
  - Mobile app; a responsive web app is enough.

TECH STACK
  - Framework: Next.js App Router.
  - Storage: a single SQLite file via a pure-JS SQLite driver,
    or an equivalent WebContainer-compatible option. Agent's
    choice if there is a cleaner fit.
  - Styling: Tailwind. No component library.
  - Auth: none.

WEBCONTAINER CONSTRAINT
  App runs in Bolt's in-browser WebContainer. Prefer pure-JS
  dependencies. Avoid anything that requires native binaries
  or a traditional server-only runtime.

PAGES
  - "/" — current reading + quick-add input.
  - "/finished" — finished books with notes.
  - "/to-read" — queue.

SUCCESS CRITERIA (what I will click through)
  1. I can add a book from the home page.
  2. I can move a book from to-read → reading → finished.
  3. Finishing a book prompts me for a short note.
  4. Deleting a book removes it from its list.
  5. Data persists after a page reload.

NOTES
  - Keep the UI minimal. This is a personal tool.
  - Prefer fewer screens over more.

Every block closes a gap Bolt would otherwise fill with a default. The WebContainer constraint line is cheap to write and does real work. The out-of-scope list stops quiet scope creep.

Common Anti-Patterns

• One-line prompts for a whole app. "Build me a habit tracker." The generator picks the stack, schema, auth model, and page structure — none of which you reviewed. Fix: write the six-block brief above.
• No WebContainer constraint. Skipping the runtime note lets the agent pick dependencies that fight the browser runtime. Fix: one line naming the WebContainer and preferring pure-JS deps.
• Pinning every dependency. Over-specifying turns the brief into a spec doc and stalls iteration. Fix: pin framework, storage, auth; leave the rest.
• Line-by-line editing in Bolt's editor. Fighting the generator kills the speed advantage. Fix: refine the prompt, regenerate the affected parts.
• Confusing Bolt with an in-IDE agent. Treating Bolt as a place for surgical changes against an existing repo produces frustration. Fix: Bolt for generation, in-IDE agent for editing mature code.
• No out-of-scope list. The agent adds login, onboarding, and a settings page you never asked for. Fix: name what v1 does not include.

FAQ

How is Bolt.new different from v0?

v0 generates UI — components and pages, built on React + Tailwind + shadcn/ui. Bolt generates full-stack apps and runs them inside an in-browser WebContainer. A v0 prompt is a component brief; a Bolt prompt is an app brief with a stack and a runtime constraint. See the v0 prompting guide.

How is Bolt.new different from Replit Agent?

Both produce full-stack apps from a description. The runtime differs: Bolt runs in an in-browser WebContainer; Replit Agent runs on Replit's hosted VM. That changes which dependencies are safe to assume and which constraints belong in the prompt. See the Replit Agent prompting guide.

Should I pin the tech stack or let Bolt pick?

Pin the load-bearing pieces — framework, storage, auth — and let the agent choose the rest. Add one line about WebContainer compatibility so the agent picks browser-friendly options inside the pieces it owns.

Is Bolt.new good for long-term codebases?

It is better suited to prototypes, demos, and v0s than to multi-year codebases. Mature codebases want minimal-diff edits, tight tests, and code review — an in-IDE agent like Cursor is usually a better fit for that phase.

Does Bolt.new replace writing code?

No. It replaces the slow parts of starting a new app — scaffolding, wiring, first boot — and gives you a running version fast. Once the app exists and you want to grow it, normal engineering practices apply. See the pillar guide.