AI coding agents break databases because they guess. An agent writing Firestore or Supabase code cannot see your actual schema, so it invents the most statistically likely field names: users.name when your field is displayName, orders.total when yours is amountCents. The code looks right, compiles, and fails quietly in production, because the agent was completing a pattern, not reading your database.
Why the agent cannot just look
Your schema does not live in your code. In document databases like Firestore and in AI-built Supabase projects, the real schema is whatever the documents actually contain, which drifts with every migration, every experiment, and every previous AI session that wrote in a hurry. The agent sees the code that once wrote the data, not the data itself. Two years of drift later, those are different things.
The failure loop most teams are living
1. You ask the agent for a feature that touches the database.
2. It guesses a field name or a rules pattern. Slightly wrong.
3. The bug is silent: an empty result, an undefined, a write to a new field that now exists alongside the old one.
4. You ask the agent to fix it. It guesses again, and often widens a security rule to make the error go away.
5. Your schema is now more inconsistent than before, which makes the next guess worse.
This loop is why an AI-assisted codebase gets harder to work on over time even as it grows faster. The agent is not getting dumber. Its picture of your database is getting more wrong.
The symbiosis: what the engineer has that the agent needs
A senior engineer holds two kinds of knowledge: how to build, and what is actually there. Coding agents have absorbed most of the first kind. They have none of the second, because what is actually there is private to your project: the real field names, which fields are always present and which are legacy, which collections are hot, what the security rules actually permit.
The engineer and agent relationship works when each side supplies what the other lacks. The agent brings speed and breadth. The engineer brings judgment and ground truth. Every failure story about AI code, hallucinated fields, loosened rules, silent drift, is a case where the agent was forced to guess at ground truth it should have been handed.
What handing over ground truth looks like
Before the agent writes database code, it should be able to check reality:
- The exact field names and types in each collection, from the live data, not from stale interfaces
- Presence rates: is this field on 100 percent of documents or 3 percent
- What the security rules currently allow, versus what the code assumes
- What past scans flagged, so the same drift is not reintroduced
With that context in the window, the agent stops inventing and starts referencing. In practice the difference is immediate: queries that match reality on the first try, migrations that account for the 2 percent of documents where the field is a string, rules changes made knowingly instead of accidentally.
We built LintBase because we were tired of living the failure loop ourselves. It connects to Firestore or MongoDB, reads the live schema, and hands your agent ground truth, as an exported context file or live over MCP for Claude, Cursor, and Windsurf. The engineer stays the auditor and decision maker. The agent finally works from facts. That is the symbiosis working as it should.