Почему миграции БД от ИИ-агентов требуют отдельного уровня защиты

Coding agents эффективно справляются с рутинными задачами: от протяжки полей до генерации миграций. Однако изменения схемы базы данных обладают специфической асимметрией: небольшой фрагмент кода может иметь колоссальный «blast radius». В отличие от ошибки в бизнес-логике, неудачный ALTER TABLE способен заблокировать запись во всю таблицу, исчерпать пул соединений и превратить локальную правку в отказ всего сервиса. Поскольку генерация таких изменений стала почти бесплатной, а стоимость их проверки осталась высокой, миграции следует рассматривать как привилегированный артефакт, требующий особого контроля.

Проблема заключается в том, что обычный code review часто недостаточен. Агент видит статический снимок репозитория и не обладает данными о текущем состоянии продакшена: количестве строк, уровне RPS, наличии длинных транзакций или задержках репликации. Например, добавление индекса через стандартный CREATE INDEX блокирует записи, тогда как CREATE INDEX CONCURRENTLY позволяет продолжать работу, но требует отказа от атомарности транзакции. Безопасность операции определяется не размером SQL-запроса, а тем, с какими блокировками и трафиком она столкнется в живой системе.

Для решения этой проблемы автор предлагает концепцию «файрвола» — границы в CI, через которую миграция проходит по строгим правилам. Первый слой включает статический анализ: автоматическое блокирование опасных операций, таких как удаление колонок или использование RunSQL, без ручной классификации риска. Второй слой требует извлечения реального SQL-кода (например, через sqlmigrate в Django) для проверки конкретных команд, которые выполнит PostgreSQL, а не абстрактных ORM-операций.

Третий уровень предполагает прогон миграций на копии схемы с реалистичным объемом синтетических данных. Это позволяет выявить проблемы масштаба, например, массовые обновления данных, которые выглядят безобидно на тестовой базе, но становятся тяжелыми batch-задачами на миллионах строк. Четвертый слой — это архитектурная стратегия expand-migrate-contract, которая заменяет рискованные one-shot изменения на последовательность совместимых шагов для rolling deploy.

Последняя линия защиты находится в самой базе данных: использование lock_timeout. Это гарантирует, что миграция упадет, если не сможет получить блокировку вовремя, вместо того чтобы бесконечно ждать и накапливать очередь запросов. Отказ миграции всегда дешевле, чем отказ пользовательского трафика. Важно отметить, что AI-агенты здесь играют вспомогательную роль: они могут объяснить риск или предложить стратегию, но доказательство безопасности должно давать воспроизводимые инструменты — парсеры, тесты и policy engine.

Метрика успеха в таком подходе — не количество сгенерированных миграций, а число инцидентов, предотвращенных CI, и стабильность latency при деплое. ИИ меняет стоимость производства кода, но не физику PostgreSQL. Блокировки не становятся мягче от того, что их написал агент. Ценность смещается в сторону проверки: пять строк кода, изменяющих схему, заслуживают больше контроля, чем пятьсот строк бизнес-логики.