Firebase Studio: how to review AI-generated full-stack code when Google’s cloud IDE builds the whole app for you

2026-04-28 · 5 min read · ZenCode

Firebase Studio is Google’s cloud-based vibe coding platform, built on the Project IDX foundation and deeply integrated with Gemini AI. You open a browser tab, describe what you want to build, and Gemini generates a full-stack app: Firebase Authentication for login, Firestore as the database, Cloud Functions for server-side logic, and Firebase Hosting to deploy it — all wired together in a cloud dev environment with a live preview that updates as you build. There is no local machine involved. Your code runs in Google’s infrastructure from the first line.

The platform is genuinely capable. For building standard Firebase app patterns — user auth flows, per-user data storage, real-time updates, simple CRUD backends — Gemini generates working code that follows Firebase conventions correctly. The review traps don’t come from Gemini being wrong about the Firebase API. They come from what a reviewer infers about safety and correctness when the whole stack appears in a single generation session inside a Google product.

The three traps

1. Emulator environment as production parity

Firebase Studio runs your code against the Firebase Emulator Suite by default. The Emulator Suite is a local simulation of Firebase services — Firestore, Auth, Functions, Storage — that runs inside the cloud dev environment. When you open the Studio preview tab, you see your app loading at a cloudworkstations.dev URL, authenticating users, writing to a database, calling functions. It looks and behaves exactly like a deployed app.

The trap is that the Emulator’s Firestore instance uses permissive security rules by default. When you initialize a Firebase project in “test mode” — the default option Gemini picks in most scaffolding flows — your Firestore rules allow any authenticated user to read and write any document in the database. This is intentional for development: it lets you build without getting blocked by rules. But code that works perfectly in the emulator can expose data in production once you deploy to a real Firebase project with the same test-mode rules still in place.

The trap compounds when reviewing generated code: you see `db.collection('users').doc(userId).get()` and mentally note “this is checking the user’s own document.” Whether that read is actually restricted to the authenticated user is a question about Firestore security rules, not about the client code. In the emulator, the rules let it pass regardless. A reviewer looking at client code that works in Studio cannot tell from the code itself whether it will be properly gated in production.

The fix: before reviewing any data access code in Firebase Studio, open firestore.rules in the file tree and read it first. Check whether the rules are still in test mode (allow read, write: if true or allow read, write: if request.auth != null with no document-level constraints). Treat test-mode rules as a signal that security review has not started, not a signal that it has been done and is fine. The code review for a Firebase app is not complete until the Firestore rules, Storage rules, and Function auth checks are reviewed as a separate pass from the client code.

2. Template security as actual security

When Gemini scaffolds a Firebase Studio app, it generates more than code — it generates a complete security posture. A typical generated firestore.rules includes rules like: authenticated users can read and write documents in a users collection only if request.auth.uid == userId. This is a correct, sensible rule. It prevents User A from reading User B’s profile document. For the field Gemini generated it for, the rule does what it says.

The trap is coverage. As you build features with Gemini — adding a posts collection, a messages subcollection, a notifications document — each new Firestore path requires its own security rule. Gemini does not always update firestore.rules when it adds a new collection. Sometimes it does, sometimes it adds a rule that covers the new path but is more permissive than you’d want, and sometimes it adds client code that writes to a path with no corresponding rule at all. An uncovered path in Firestore security rules defaults to deny in production — which means the feature silently stops working after deploy — or it defaults to the test-mode wildcard if the wildcard match is still in place, which means it’s publicly accessible.

The coverage gap is hard to see in the Studio UI because the feature works during development. The emulator allows the uncovered path just fine. Nothing breaks. The gap only surfaces in production or during a security audit. A reviewer reading generated code across multiple features sees each individual piece look correct and doesn’t necessarily build up the complete mental map of which Firestore paths exist and which rules cover them.

The fix: after a Gemini generation session that adds features touching the database, do a path audit. List every Firestore collection and document path that the new code reads from or writes to. Then open firestore.rules and verify that each path has an explicit, correctly-scoped rule. If a path is missing a rule, that’s the gap. This is a mechanical check — match paths to rules — that takes three minutes and is the most common source of security issues in Gemini-generated Firebase apps.

3. Gemini’s Firebase API expertise as security oracle

Gemini in Firebase Studio knows the Firebase API in detail. When it generates a Firestore query, it uses the correct query(), collection(), where(), orderBy(), and limit() syntax. When it sets up Authentication, it uses the correct onAuthStateChanged listener pattern and handles the sign-in/sign-out flow correctly. When it writes a Cloud Function, it uses the right onCall handler shape and returns properly formatted responses. The code is not only syntactically correct — it follows Firebase conventions that a developer unfamiliar with Firebase might get wrong.

This expertise creates an authority signal: Gemini clearly knows Firebase deeply. The trap is that API expertise and security expertise are different capabilities. Gemini knowing how to call query(collection(db, 'posts'), where('authorId', '==', userId)) is a question about the Firebase SDK interface. Whether that query, when called from the client, should be restricted to only the currently authenticated user is a question about your application’s security model and the Firestore rules that enforce it. Gemini can generate a query that is syntactically correct, semantically appropriate for the described feature, and still callable by any authenticated user to read any other user’s posts — if the Firestore rules allow it.

The implicit transfer is: “Gemini got the Firebase API right, so Gemini probably thought about this the right way.” This is the same trust transfer that happens with any authoritative-seeming source: confidence in one domain bleeds into an assumption of competence in adjacent domains. For Firebase specifically, the adjacent domain is the rules layer — which Gemini generates separately, less consistently, and with less reliability than the client code.

The fix: deliberately separate the “does this code do what I want?” review from the “is this code gated correctly?” review. They are different questions requiring different eyes on different files. The first question is answered by reading the client code; the second is answered by reading the security rules and Function auth checks independently, treating the client code as untrusted. When reviewing a Firebase Studio project, run two separate passes: one for logic, one for authorization. Gemini’s API expertise earns high trust on the first pass; it earns no presumed credit on the second.

How this differs from similar tools

Lovable.dev (#27) and Firebase Studio are both full-stack vibe coding platforms that generate complete apps from a description. The key structural difference is the infrastructure layer. Lovable targets Supabase for its database and auth — where security is enforced via Postgres Row Level Security policies that are separate from the client code but live in SQL. Firebase Studio targets the Firebase ecosystem — where security is enforced via a domain-specific rules language that is separate from both the client code and standard SQL. Both create the same template-security-as-actual-security trap; the specific rules layer to audit is different.

Bolt.new (#12) generates full-stack apps from a browser with no local environment, creating the same “it just works” experience as Firebase Studio. Bolt.new apps typically deploy to Netlify with a backend-as-a-service or serverless function layer; the security model is different from Firebase’s rules-based approach. The common trap in both is that the cloud preview environment has more permissive defaults than production — in Bolt.new via development mode API keys and relaxed CORS, in Firebase Studio via emulator test-mode rules.

Replit Agent (#13) is the closest structural match to Firebase Studio: a cloud IDE where an AI agent builds the entire app in a sandboxed environment, with a live preview you can share, and a one-click deploy. The emulator-as-production-parity trap is present in both, but Replit Agent’s sandbox uses different isolation mechanisms (container-level) compared to Firebase Studio’s Firebase Emulator Suite. The Firebase-specific security rules layer is unique to Firebase Studio; Replit apps don’t have an equivalent separate-file rules system to audit.

Devin AI (#25) is also an autonomous agent that builds full applications, but operates in a different context: it has access to your actual codebase, runs in a cloud VM with real terminal access, and can push to your real repository. Firebase Studio operates in a purpose-built Google-managed environment that abstracts away the infrastructure entirely. The scope of what gets generated is similar; the environment trust model is different.

What Firebase Studio gets right

Firebase Studio eliminates the environment setup phase of building a Firebase app almost entirely. No local Node.js version conflicts, no Firebase CLI installation steps, no emulator port conflicts, no project initialization ceremony. You describe what you want and the environment is ready. For building standard Firebase application patterns — user auth with per-user data isolation, real-time document listeners, basic CRUD with Cloud Functions — Gemini generates working, conventionally correct code faster than most developers can scaffold it manually.

The review traps above are not about Gemini getting Firebase wrong. They are about a workflow where the entire stack is generated in one session creating an implicit completeness signal — “the whole app was made, including the security parts.” The fix in each case is a deliberate separation: review the logic pass and the authorization pass independently, treat the emulator preview as a development environment not a security proof, and audit Firestore rules coverage separately from client code correctness. Those three separations let you use Firebase Studio’s speed advantage without inheriting its coverage assumptions.