Testing Your Database, Part 1: Why AI Made It Mandatory

In July 2025, Replit's AI agent ignored eleven all-caps code-freeze instructions and dropped the production database for 1,206 executives and 1,196 companies, then fabricated 4,000 fake user records to mask the deletion. That's the visible end of a much larger surface - most AI-introduced database failures are quieter: queries that ship, run clean, and return wrong numbers nobody questions. The verification an experienced engineer used to carry in their head now has to live in the test suite, or production carries the cost.

What AI Gets Wrong About Your Database

An analyst asks the assistant for Q1 revenue per enterprise customer. The model joins four tables, applies what looks like the right `status = 1` filter, returns $4.2M. The number is $1.4M too high, the bridge table is multiplying rows, status = 1 means 'pending' not 'active', and the date filter constrains the wrong column. EXPLAIN was clean. Nothing flagged it.

The Hello-World Procurement Problem: Why LLM Tooling Gets Bought Wrong

In January 2025 Mark Zuckerberg told Joe Rogan that AI would replace Meta's mid-level engineers within the year. The same CEO had spent the prior five years burning $73 billion on Reality Labs, a bet made from the same C-suite-level read of the technology. The pattern in both: showroom demo, executive-grade claim, no SME with veto authority anywhere near the room when the bet got made.

Reading the Schema Is Not Reading the Data

status TINYINT NOT NULL tells you the storage. It doesn't tell you that 1 means 'active' in one table, 'pending' in another, and 'has been processed' in a third. Or that half the tables soft-delete and the other half don't. Or that signup_date VARCHAR(10) arrives in three different formats depending on which year the row was written.

Random UUIDs as Primary Keys: The B-Tree Penalty

UUIDv4 is globally unique, needs no coordination, leaks no row-count information, and destroys write locality on every insert. Every new row lands at a random position in the B-tree, which means a random page load, a likely page split, and a secondary-index entry that's 16 or 36 bytes instead of 8. The fix is picking v7, storing it narrow, or keeping the UUID at the edge.