5 Things AI Cannot Do at Firebase (Yet)
AI has changed the way we build software. Give an AI assistant a
Firebase project and it can generate Firestore queries, Cloud Functions,
authentication flows, and even Security Rules in seconds.
That is useful. But there is a difference between generating code that
looks correct and understanding what that code will do with real
users, real traffic, failures, and security requirements.
Firebase makes this distinction especially important. Firestore,
Realtime Database, Cloud Functions, and Authentication hide a lot of
infrastructure complexity. Development becomes faster, but a small
architectural mistake can stay invisible until the application is under
load.
AI is good at patterns and boilerplate. The harder part is understanding
the system around those patterns.
1. AI Cannot Properly Reason About Concurrency
One of the easiest ways to create a serious Firebase bug is to write
code that works perfectly for one user.
Then 10,000 users arrive.
Consider a simple read-then-write operation:
const user = await getUser(uid);
if (user.balance >= amount) {
user.balance -= amount;
await updateUser(uid, user);
}
What happens if two requests run at almost exactly the same time?
Both can read the same balance. Both can decide there is enough money.
Both can write their result. One update may overwrite the other.
This is a classic race condition. AI sees a sequence of operations,
but it does not automatically reason about how those operations interact
when many requests happen concurrently.
Firestore provides transactions and batched writes, but choosing
between them is an architectural decision. Transactions are useful when
a write depends on current data. Batched writes are better for atomic
write-only operations.
Sometimes neither is the real solution. Imagine thousands of users
joining a queue simultaneously. A better design may be to separate event
capture from processing with Cloud Tasks, rather than trying to
solve everything with database transactions.
The same applies to query ordering. If your application needs
deterministic results, do not assume equal sort values will always
produce a stable order. Add a reliable secondary ordering when the
application depends on it.
AI can write the query.
The developer has to decide whether the query is safe under real
concurrency.
2. AI Cannot Understand the Security Context of Your Data
Firebase Security Rules are powerful, but they are easy to get wrong.
An AI assistant might generate:
allow read, write: if request.auth != null;
It works for authenticated users, but that may be far too permissive.
Being logged in does not mean a user should be able to modify another
user's document.
A more appropriate ownership check might look like:
allow write: if request.auth.uid == userId;
A particularly dangerous pattern is Broken Object Level Authorization
(BOLA). AI-generated CRUD code can accidentally allow any
authenticated user to read, update, or delete documents without checking
ownership.
There is also an important difference between Firestore and Realtime
Database Security Rules. Realtime Database permissions cascade through
the data tree, while Firestore rules do not work the same way. Copying a
rule pattern from one Firebase database to another can therefore produce
serious security problems.
AI can also treat sensitive fields as ordinary properties:
isAdmin
balance
plan
createdAt
updatedAt
But should the client be able to change them?
A request containing:
{
"isAdmin": true
}
should obviously not make somebody an administrator.
Sensitive fields need trusted server-side control. Firebase
Authentication custom claims can also be used for server-controlled
roles and authorization decisions.
The research behind this article makes the same broader point: Security
Rules should be treated as executable security code, tested and reviewed
rather than accepted as generated boilerplate.
Security is not a feature AI can safely infer from field names.
3. AI Cannot Design Reliable Event-Driven Systems by Itself
Cloud Functions are one of Firebase's biggest advantages. A database
change, signup, or upload can automatically trigger backend code.
But event-driven systems have an uncomfortable property:
A function can run more than once.
Imagine:
exports.sendWelcomeEmail = onUserCreated(async (event) => {
await sendEmail(event.data.email);
});
The email may be successfully sent, but the function could fail
immediately afterward. A retry can then send the email again.
The code is syntactically fine. The problem is that the operation is not
idempotent.
For important operations such as payments, rewards, notifications,
inventory updates, and third-party API calls, you need to think about
duplicate execution.
A simple pattern is:
if (await alreadyProcessed(eventId)) {
return;
}
await processPayment();
await markAsProcessed(eventId);
The exact implementation depends on the application, but the question is
always the same:
"What happens if this runs twice?"
AI will often generate the happy path first. Developers have to design
for retries, partial failures, timeouts, and state recovery.
For multi-step workflows, this becomes even more important. If one API
call succeeds and the next one fails, blindly replaying the entire
workflow can create duplicate side effects.
4. AI Cannot Understand Your Business Rules
This is perhaps the most important limitation.
AI knows the code you show it. It does not truly know why your business
works the way it does.
Imagine a subscription document:
plan
balance
isAdmin
createdAt
An AI can easily generate CRUD operations for all four fields.
But maybe plan can only change after payment.
Maybe balance can only be changed by a trusted backend operation.
Maybe createdAt must never change.
Maybe isAdmin requires manual approval.
Those are not JavaScript problems. They are business decisions.
This connects to a broader limitation of AI-assisted development: AI can
suggest solutions, but it cannot independently choose the correct
strategy for your specific constraints and product goals.
The problem becomes bigger as the application evolves.
Today your document might contain:
name
email
photoURL
Six months later:
internalNotes
accountStatus
billingTier
The data model changed, so the security model may need to change too.
A rule that was reasonable months ago may no longer be sufficient after
a schema change. Developers have to continuously review permissions,
validation, and business logic.
This is where human context matters most.
5. AI Cannot Manage the Production Black Box for You
Getting the application to work is only the beginning.
Once real users arrive, new questions appear:
Why did a Cloud Function become slow?
Why did costs suddenly increase?
Why are requests timing out?
Why are users receiving duplicate notifications?
AI-generated code does not automatically give you good observability.
Production systems need logs, metrics, alerts, and performance
monitoring. Without them, debugging a chain of interconnected
functions can become detective work.
Cost is another problem. Code can be functionally correct and still be
expensive.
For example, additional reads caused by certain Security Rule checks,
inefficient queries, or poorly distributed document IDs can become
expensive at scale. AI generally optimizes for plausible functionality,
not your monthly cloud budget.
The difference is simple:
AI asks: "Does this code work?"
Production engineering asks: "Does it still work efficiently with a
million users?"
Firebase AI features add another operational layer. Developers need to
consider model usage, latency, billing, and what information is stored
in monitoring or logs, especially when sensitive user data is involved.
AI can help investigate these problems, but someone still has to own the
monitoring strategy and make the final decisions.
AI Is a Tool, Not the Architect
None of this means AI is bad for Firebase development.
Quite the opposite.
AI is excellent for boilerplate, documentation, test generation, query
writing, refactoring, and explaining unfamiliar APIs. It can make one
developer dramatically faster.
The mistake is expecting it to replace engineering judgment.
The five gaps are closely connected:
- Concurrency requires reasoning about simultaneous operations.
- Security requires understanding who should access what.
- Reliability requires designing for retries and failures.
- Business logic requires understanding the product and its future.
- Operations requires understanding what happens after deployment.
These are not simply coding problems.
They are system-design problems.
So instead of asking, "Can AI build my Firebase backend?", ask:
"Which parts can AI accelerate, and which parts require me to think?"
Let AI write the repetitive parts. Let it suggest implementations and
explain documentation.
But when money, permissions, shared state, retries, or production
reliability are involved, slow down and review the design yourself.
Because in Firebase, code that looks correct is not always code that
remains correct when real users, real failures, and real traffic
arrive.
Top comments (0)