It was a Saturday evening, and I was confident. A new model had just dropped, and the leaderboard said it was the best thing since window functions. I pointed it at a real migration task, reviewed the SQL briefly, and scheduled it to run at 2 AM when traffic was low. At 3:14 AM, my phone lit up with a pager alert: the orders table was locked, the replica lag had spiked, and every checkout request was timing out. The AI-generated SQL was correct in the sense that it returned the right rows. It was also catastrophically wrong in the sense that it scanned the entire table, held a write lock for eleven minutes, and brought a production service to its knees.
This is not a story about a bad model. It is a story about a bad evaluation strategy, and it is the reason I now treat every AI-generated SQL query as guilty until proven innocent.
The Mistake I Made
The query looked fine in isolation. It joined two tables, filtered on a timestamp column, and returned about four thousand rows. What I did not check was the execution plan, because the test database had a fraction of the production data volume. On a 10,000-row test table, the query planner chose an index scan and the query finished in 40 milliseconds. On a 40-million-row production table, the same query triggered a full table scan, escalated to a table-level lock, and blocked every concurrent write.
