{
  "id": 8048486,
  "title": "Deterministic checks for AI-written migrations",
  "url": "https://urgent.news/2026/09/17/deterministic-checks-for-ai-written-migrations",
  "topic": "ai",
  "section": "AI",
  "published": "2026-09-17T15:30:44.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/bolvrk/deterministic-checks-for-ai-written-migrations-3m9h"
  },
  "original_language": "en",
  "account": "Coding agents can quickly add a status column to orders using SQL. However, they often generate versions that either fail on a table with existing rows or hold an exclusive lock for the entire rewrite. This occurs because the dangerous and safe forms look nearly identical, with the difference only significant at production scale. The AGI model sometimes identifies this as BV002, one of the most common migration errors, but may overlook it based on factors like the prompt, context window, and day. The obvious solution is to have another model review the AI-generated migration. However, this approach has three limitations: it is not repeatable, cannot explain what it checked, and lacks verifiable rule corpora. Therefore, the solution lies in deterministic checks to determine if the migration is safe. These checks should be placed inside the agent's loop, in the terminal, and on the pull request to ensure consistent results. The rule corpus should focus on common issues like BV002, ADD COLUMN … NOT NULL without a default, BV003, an index created without CONCURRENTLY, BV034, a lock taken without lock_timeout, and BV030, a DROP COLUMN with dependent code still deployed. These rules should provide a clear explanation of the findings and the safe alternative pattern. This approach does not replace judgment, as it cannot account for business-specific constraints, but it streamlines the process by addressing easily identifiable mistakes, allowing human teams to focus on more complex issues.",
  "summary": "A coding agent asked to \"add a status column to orders \" will do it in seconds. It will also, more often than not, write the version that fails on a table with rows in it, or the version that takes an exclusive lock and holds it for the whole rewrite. Not because the model is bad at SQL, because the dangerous form and the safe form look almost identical, and the difference only matters at…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}