Google AI Studio’s Build mode is the most direct expression of what vibe coding actually looks like in 2026. The user describes a web application in natural language, and AI Studio produces a working full-stack implementation in minutes: a frontend, a backend with API routes, data persistence, optional authentication, and a hosted preview URL that’s immediately shareable. The user iterates by asking for changes ("add a search feature," "make the buttons larger," "let users save favorites"), and AI Studio modifies the code and redeploys the preview. The full source code stays inspectable and exportable for users who want to take it outside AI Studio.
This piece walks through the Build mode workflow step by step, using a concrete example application as the running case. We cover what gets generated automatically, how the iteration loop actually works, the inevitable points where vibe coding hits limits and how to navigate them, what the deploy pipeline produces, and how to graduate from Build mode to a production deployment when the app is ready. The piece is intended as the operational walkthrough for developers and product builders who want to understand whether Build mode is the right tool for their early-stage app development.
The short version is that Build mode is genuinely useful for the first hour of a new app idea. Going from "I have an idea for a simple app" to "I have a working prototype I can share with stakeholders" takes minutes rather than days. The mode is also limited in specific ways that matter for sustained development: it produces code that is reasonable but not idiomatic for any particular framework’s conventions, it handles simple data models well but struggles with complex ones, and the integration with the broader Google Cloud production stack requires deliberate work to make the transition from prototype to production cleanly. For the first-hour use case it is excellent. For sustained development past the prototype stage, the right move is to export the code and continue in a proper IDE.
The example app: a personal book log
To walk through the workflow concretely, we will build a personal book log. The app lets a user record books they have read, with title, author, rating, and notes. The list shows the user’s books with the most recent entries first. The user can edit and delete entries. The app uses Google Sign-In so that each user sees only their own books.
This is a small but non-trivial application: it has data persistence, authentication, and per-user data isolation. It is realistic enough that the patterns generalize to the kinds of apps people actually build with vibe coding.
Step 1: Opening Build mode
Build mode lives at the top of the AI Studio sidebar. The entry point is a single text input prompting "Describe the app you want to build." Below the input, AI Studio shows recent Build projects (if any) and a gallery of example apps that demonstrate what Build can produce.
The first prompt for our example: "I want a personal book log where I can record books I have read with title, author, rating out of 5 stars, and notes. The list should show the most recent books first. I should be able to edit and delete entries. Users should sign in with Google so each user sees only their own books."
AI Studio acknowledges the prompt and begins generating. The status indicator shows what AI Studio is currently doing: deciding on the technology stack, generating the database schema, generating the frontend components, generating the backend API routes, deploying the preview.
The whole process takes approximately 2 to 4 minutes for an app of this scope. Simpler apps finish in under a minute. More complex apps with multiple data types or unusual interaction patterns can take 5 to 10 minutes.
Step 2: The first generated app
When generation completes, AI Studio shows three things side by side: the running preview of the app (in an iframe that simulates a phone-sized viewport by default), the file tree of the generated source code (so the user can inspect what was built), and the conversation history with AI Studio (so the user can ask for changes).
For the book log example, the generated app is recognizably what was asked for: a sign-in screen with a Google button, a list view of books once signed in, an "Add Book" button, an edit form for each existing book. The visual design is competent but not distinctive (clean modern web aesthetic, the kind of thing a generic component library produces).
The generated technology stack as of mid-2026 typically includes: React with the App Router conventions for the frontend, Firestore for data persistence, Firebase Auth for the Google Sign-In, and a thin API layer using Next.js’s serverless function support. The choice of stack is opinionated and tied to Google’s broader Firebase and Next.js stories; AI Studio does not generate Vue or Svelte by default, and it does not use non-Google database options unless explicitly asked.
The preview URL is shareable. Tap the share icon and AI Studio produces a link that anyone can open to see the app. The link expires after 14 days unless extended.
Step 3: The first iteration
The vibe-coding pattern is iterative. The first generation is rarely what the user actually wants; the value comes from being able to refine through additional natural-language prompts.
For our book log, the first iteration might address visual issues. Sample follow-up prompts and what AI Studio does with them:
"Make the rating stars yellow instead of grey." AI Studio modifies the relevant component’s styling and redeploys.
"Add a search box at the top of the list." AI Studio adds a search input, wires it up to filter the displayed list as the user types, and redeploys.
"Show the cover image for each book. Let me upload it when I add or edit a book." AI Studio adds an image upload widget, wires up Firebase Storage for the uploaded images, modifies the data model to include the image URL, updates the list view to show the cover, and redeploys. This is a more substantial change that touches the frontend, the data model, and the storage layer; AI Studio handles all three.
Each iteration takes 20 to 60 seconds depending on the scope. AI Studio shows what it is changing in real time so the user can see which files are being modified.
The iteration loop continues until the user is happy with the app or until they hit a limit that AI Studio cannot handle smoothly (more on this below).
Step 4: Handling the limits
Several specific patterns hit limits in Build mode that the user needs to navigate:
Complex data models. A single data type (books in our example) works cleanly. A second related type (book series, or reading lists, or friend recommendations) works less cleanly. The third or fourth related type can produce confused output where AI Studio loses track of how the types relate. For apps that need rich data models, the iteration approach is to add one type at a time and verify the model is correct before moving on, or to graduate out of Build mode into a proper IDE.
Custom business logic. Standard CRUD operations work well. Custom logic that has specific rules ("only allow users to edit a book within 24 hours of creating it," "send an email digest of new books every Sunday morning") works less smoothly. AI Studio can implement the logic but often needs multiple iterations to get it right and may produce code that is correct but not idiomatic.
Third-party integrations. AI Studio handles Google services (Firebase, Cloud Run, Cloud Storage) cleanly. Third-party integrations (Stripe for payments, SendGrid for email, OpenAI for AI features) work but with more friction. The user often needs to provide API keys, configure environment variables, and verify the integration is correct.
Unusual UI patterns. Standard web app UI (lists, forms, tabs, modals) works well. Unusual patterns (drag-and-drop reordering, real-time collaborative editing, complex animations) work less well or not at all. Build mode’s strength is the common patterns; for unusual UI, the user needs to either accept the standard approach or graduate to a proper IDE.
Performance optimization. AI Studio generates code that works but is not optimized. For prototype use this is fine; for production deployment with substantial traffic, the code typically needs performance work that AI Studio does not do automatically.
The right framing is that Build mode is for the prototype and early development phase. When you hit limits, the answer is usually "export the code and continue in your real IDE" rather than "try to push Build mode further."
Step 5: Inspecting and exporting the code
The "View Source" button in Build mode opens the file tree for inspection. Every file AI Studio generated is visible and editable. Users can directly edit code in the AI Studio interface, with changes taking effect on the next preview reload.
For users who want to take the code outside AI Studio, the export options:
Download as ZIP. Produces a ZIP file with the complete project, including the Next.js configuration, the Firebase configuration, and the package.json. Unzip, run npm install, run npm run dev, and the app runs locally.
Export to Git repository. Connects to the user’s GitHub account and creates a new repository with the project’s code committed as the initial commit. From there, normal Git workflow applies.
Export to Antigravity. Imports the project into the Antigravity IDE for continued development with full IDE features. This is the recommended path for users who want to keep developing in the Google ecosystem.
The exported code is standard Next.js plus Firebase. It runs anywhere Next.js can deploy (Vercel, Netlify, Cloud Run, AWS Amplify, custom Node.js hosting). It is not locked into AI Studio after export; the export is genuinely a free release of the code into the user’s possession.
Step 6: Deployment to production
The AI Studio hosted preview is sufficient for sharing the prototype but is not designed for production deployment. The preview expires after 14 days unless renewed, and the underlying infrastructure is provisioned for prototyping rather than production workloads.
For production deployment, two paths:
The "ship to Cloud Run" button in AI Studio (added in early 2026) deploys the current project to Cloud Run as a production service. The button handles the build, container packaging, Cloud Run service creation, and IAM configuration. The deployed service is a real Cloud Run deployment with the standard production capabilities (auto-scaling, monitoring, logging).
Manual deployment after export. For projects that have outgrown Build mode, the standard pattern is to export the code (typically to a Git repository), continue development in a real IDE, and deploy through whatever production pipeline the team uses. This is the right path for non-trivial apps that need real engineering work.
The cost economics differ between the two paths. The hosted preview is free during the preview window. The Cloud Run deployment is billed per Google Cloud’s standard Cloud Run rates, which is usually inexpensive for low-traffic apps but accumulates for high-traffic ones.
Costs
Build mode’s cost structure:
Build generation consumes Gemini tokens during the natural-language-to-code generation. AI Studio provides a free tier of token usage that is generous enough for prototyping. Beyond the free tier, usage is billed at the standard Gemini API rates. A typical app generation costs a few cents in tokens for the initial generation and a fraction of a cent per iteration.
Hosted preview is free during the 14-day preview window. After expiration, the preview URL stops working; the project itself is preserved and a new preview can be generated.
Production deployment via Cloud Run is billed at Google Cloud’s standard rates. For a low-traffic app, the cost is typically a few dollars per month.
Firestore and other Google Cloud services consumed by the deployed app are billed separately at the standard rates.
The combined cost is low enough that the cost is not usually the gating consideration for whether to use Build mode.
When Build mode is the right choice
Build mode is the right choice for:
Rapid prototyping of new app ideas where the goal is to validate the idea quickly. Build mode goes from idea to working prototype in minutes, which is the right pace for the validation phase.
Stakeholder demos where the goal is to show a working interaction model to people who need to see it rather than read a specification. The hosted preview URL is the right artifact for these demos.
Learning and experimentation for developers who want to understand what an app of a particular type looks like before they commit to building it themselves. Generating an example app and inspecting the code is a useful learning pattern.
Personal-tool development for utility apps that don’t need to be production-grade. A personal time tracker, expense logger, or note-taking app can live entirely in Build mode’s hosted preview without ever needing to graduate.
Build mode is not the right choice for:
Production application development where the team will sustain the app over months and years. Real IDE work is more productive past the first few hours.
Apps with substantial complexity in data model, business logic, or unusual UI. Build mode’s strengths are common patterns; unusual patterns hit friction.
Apps that need specific framework conventions. Build mode’s opinions (Next.js + Firebase + React) may not match a team’s existing stack preferences.
Frequently asked questions
Is Build mode free? The Build mode interface is free. Token consumption beyond the free tier and hosted-preview duration beyond 14 days incur charges, but typical prototyping use stays well within the free allowances.
Can I use Build mode with my existing Google Cloud project? Yes. AI Studio prompts you to select a Google Cloud project for the deployed services. If you have an existing project, Build mode can deploy into it.
What if I don’t know what stack I want? Build mode picks reasonable defaults (Next.js + Firebase). You can override by specifying in your initial prompt ("use Vue and Supabase instead") but for the typical user without strong stack preferences, the defaults work fine.
Can I use Build mode without Firebase? Yes, by specifying an alternative in your prompt. AI Studio supports a range of database options and authentication providers; Firebase is the default rather than the requirement.
Is the generated code production-ready? It is production-acceptable for low-stakes apps but is not optimized for performance, has no test coverage, and may not match your team’s conventions if you have specific standards. For production use, plan to invest some additional work after export.
Can I have AI Studio generate native mobile apps? Limited native app generation is available for Android through the AI Studio + Kotlin/Jetpack Compose path (which is its own specific workflow). iOS native generation is not currently available. Cross-platform via React Native is supported but with the caveats that come with cross-platform mobile development.
How does Build mode compare to Cursor or Antigravity? Build mode is for the first hour of an idea. Cursor and Antigravity are for sustained development. The natural workflow is Build mode for initial prototyping, then export and continue in Cursor or Antigravity for the longer development cycle.
What models power Build mode? Build mode uses Gemini 3 Pro by default. The model selection is not user-configurable in Build mode; if you need a different model, the regular AI Studio chat surface (not Build mode) supports model selection.
Can I see what other people have built with Build mode? The gallery section in Build mode shows publicly-shared example apps. Users can opt-in to share their own Build projects to the gallery.
Is the generated code mine? Yes. The code AI Studio generates belongs to you under Google’s standard customer-IP terms. You can use, modify, distribute, and license it however you choose.
