The Coding Agent Is the Least Informed Participant

The coding agent is the least informed participant in the change, and it is the one writing the code. It knows the schema file and it knows the ORM model. It has never seen the size of the table it is about to scan, it does not know whether the index it assumes exists still exists, and it has no idea what the query planner will decide once real cardinality is involved. It will be confident either way, because agents do not hedge. A human engineer with the same information would hedge, would go look at the table, would ask someone who has been on call for that service. The agent writes the query and moves on to the next ticket.

This matters most at the database, because of where each kind of mistake surfaces. A rendering bug shows up in review. A logic error shows up in tests. A bad query shows up at 2am, in production, under real traffic, and by then it has already cost you. The database is the part of your infrastructure where AI-written code fails quietly and expensively, and it is the part DBGorilla covers.

Three rows showing where mistakes surface: a rendering bug is caught in code review in minutes, a logic error is caught by the test suite before merge, and a bad query reaches production and is caught at 2am by the on-call engineer after it has already cost you.

None of that is a criticism of the agent or of the people using one. The agent is working with what the repository gives it, and the repository does not contain the answer. Tests prove the logic. Nothing in the repository proves the query survives your data. Your staging environment has a thousand rows and your production database has fifty million, so the query plan you validated is not the query plan you shipped. The feedback loop for a bad query is production traffic, and that loop closes on your on-call engineer.

Two columns: what the repository knows, the schema file as declared, the ORM model, passing tests, a thousand staging rows, versus what production knows, fifty million rows, which indexes are used, the plan at real cardinality, what changed since March. A dashed red gap separates them.

Drift makes it worse, and drift is the part teams underestimate. The index existed when the migration was written. Someone dropped it in March during an unrelated cleanup, for a good reason, based on the best information they had at the time. The query that depended on it now runs as a sequential scan. Nothing in the repository records that change, so nothing in code review catches it, and the agent writing the feature this week reads the same schema file and reaches the same wrong conclusion. The repository describes intent. Your database has behaviour, and behaviour changes underneath the intent.

Timeline with four points: migration written and the index exists, March when the index is dropped in an unrelated cleanup, this week when the agent reads the same schema file and assumes the index, and production where the query runs as a sequential scan.

The fix is to give the agent the missing information at the moment it is writing the code, and to check the same information again before the change merges. DBGorilla does both halves from one source of truth.

At authoring time, the DBGorilla skill interjects. The developer does not have to remember to ask, and the agent does not have to know that it is missing something. Any time Claude Code, Cursor or another agent touches the database, DBGorilla’s MCP server is consulted and returns the real picture: the shape of the tables, performance metrics, the infrastructure and resource allocation underneath, which indexes are actually used, the queries that actually run, and how all of that has changed over time. It is the shape and the behaviour of your database, never the rows. That distinction matters enough to state plainly, because most people hear “the agent needs to see the database” and reasonably assume you mean their customer data. We mean the structure and how it performs. The query side comes from pg_stat_statements, which normalizes the literals out of the query text before we read it, so what we hold is the shape of the query and never the values someone searched for.

Two panels: what DBGorilla reads, table shape, indexes, performance metrics, history and normalized query shapes, versus what it never reads, column values, customer rows and search terms, all struck through. Below, a query with a literal email is normalized to a placeholder before DBGorilla sees it.

At merge time, the CI bot compares the pull request against that same real picture. The migration that adds a column to a table with fifty million rows gets flagged as a migration against a table with fifty million rows. The query that assumes an index gets checked against the indexes that exist today, not the ones that existed when someone wrote the model. The reviewer sees the operational consequence next to the diff, at the moment they are deciding whether to approve it.

A pull request diff adding a column with a default, with a DBGorilla bot comment underneath reporting two findings: the table has tens of millions of rows in production so the change holds a long lock, and the query assumes an index that was dropped in March, with the safe alternative described.

Diagram: the coding agent in the editor asks the MCP server while it writes, and the CI bot checks the change on the pull request before it merges. Both point at the same picture of your production database, its shape and behaviour and never its rows.

Both halves read the same source, which removes the gap that usually opens between advice and verification. And the merge check is not a rubber stamp of the authoring advice: it is a fresh review with fresh context, an objective judge whose only input from the developer is the code itself. A developer who follows the guidance at authoring time does not get contradicted at merge time by a tool with a different view of the world, and a developer who ignores it finds out before production rather than after.

Notice what this does to the review conversation. Today a senior engineer reviewing an AI-written migration is asked to hold the production database in their head: how big that table is, what the traffic pattern looks like at peak, which index the planner picks, whether anything changed since the last time they looked. Some of them can do it for the two or three services they know best. Nobody can do it for every service, and the volume of database changes is going up because agents write them faster than humans ever did. Attention is the scarce resource in that room, and the answer is to put the operational facts in front of the reviewer rather than asking them to remember.

The question was how to trust the code coming from AI in production. Trust in this context is a property of the system around the model: whether the agent had the facts when it wrote the change, and whether something checked the change against those same facts before it shipped. That is what we built for the database, which is the most important part of your infrastructure and the part where being wrong costs the most.