На GitHub опубликован pg-dry-run — npm-библиотека для Postgres, которая позволяет сначала увидеть эффект INSERT, UPDATE и DELETE, а уже потом применять изменения. Проект был замечен через Show HN, но ключевые факты следуют из описания репозитория: инструмент превращает записи, сгенерированные агентом или другой системой, в построчные JSON-предложения для проверки.
Что выпущено
pg-dry-run позиционируется как механизм безопасности для сценариев, где AI-агенты не только читают схему и данные, но и генерируют SQL для реальных приложений. Чтение обычно можно ограничить read-only ролью. С записями сложнее: корректный SQL может затронуть не те строки, которые ожидал оператор.
В README приводится типичный пример: UPDATE по домену email выглядит разумно, но в живой базе может изменить не один аккаунт, а четырнадцать. Статическая проверка запроса и обычный code review видят текст SQL, но не его фактический эффект на текущем состоянии базы.
Как это работает
pg-dry-run предлагает поток:
agent-generated SQL → read-only preview → policy or approval → guarded apply
На практике разработчик создаёт runner через createDryRunner, передаёт SQL и параметры в propose(), а на выходе получает plain JSON. В этом JSON есть, в частности, число затронутых строк и изменения по строкам. Такой результат можно показать в терминале, админке, approval-интерфейсе или передать в собственную политику проверки.
После ручного или автоматического одобрения вызывается apply(). По описанию проекта, применение выполняется в одной транзакции и записывает только те строки, которые были предварительно показаны в proposal. Если существующая строка изменилась между предпросмотром и применением, вся операция отклоняется. В названии проекта и описании упоминаются xmin checks — то есть подход опирается на проверку версии строки в Postgres, чтобы не применить устаревший предпросмотр.
Почему это важно для AI-агентов
Практическая ценность здесь не в «ещё одном guardrail» поверх промпта, а в переносе проверки ближе к базе данных. LLM может сгенерировать синтаксически правильный запрос, но не знать всех текущих данных, дефолтов, триггеров и связей. pg-dry-run пытается ответить на более полезный вопрос: не «выглядит ли SQL разумно», а «какие строки изменятся и как именно».
Это особенно релевантно для внутренних агентских инструментов: поддержки, CRM-операций, админских workflow, миграций малых данных, полуавтоматических исправлений. Вместо немедленного UPDATE агент может предложить изменение, а человек или policy-layer проверит конкретный diff.
Ограничения
Важно: pg-dry-run не запускает AI-модель, не предлагает готовую approval-систему и не заменяет права доступа, аудит или бизнес-валидацию. Это библиотека и механизм работы с Postgres, на котором можно построить CLI, агентский инструмент или админский экран.
Также сам проект предупреждает, что триггеры могут изменить фактически записываемые значения. В примере README proposal выводит warning о BEFORE UPDATE trigger touch_updated_at. Поэтому предпросмотр нужно воспринимать как сильное, но не абсолютное средство контроля: финальная архитектура всё равно должна учитывать триггеры, внешние эффекты, политики доступа и доменные ограничения.
Вывод
pg-dry-run закрывает конкретную боль практических AI-агентов: безопасно перейти от «агент написал SQL» к «мы видим построчный эффект и можем применить только его». Заявления о зрелости, производительности или production-адопшене в доступном описании не приводятся, поэтому пока это стоит рассматривать как полезный строительный блок для разработчиков, экспериментирующих с агентскими операциями над Postgres.
Источники