Релиз PostgreSQL 19 перенесён на 19 ноября 2026 года, хотя исторически версии проекта выходили между серединой сентября и серединой октября. Коммитер PostgreSQL Robert Haas объясняет задержку тем, что LLM-ревьюеры массово находят дефекты в кодовой базе, а люди не успевают подтверждать находки и доводить исправления до мержа. На этом фоне из релиза откатаны три крупные фичи, а ресурсы команды ушли в правки стабильных веток вместо новых функций. Разбираем, что этот случай меняет в разработке open-source и что сдвиг релиза значит для тех, кто планировал миграцию.

image

Что произошло

Коммитер PostgreSQL Robert Haas опубликовал разбор, где зафиксирован новый график: RC 1 вышел 15 октября, RC 2 назначен на 12 ноября, финальная версия PostgreSQL 19 выйдет 19 ноября 2026 года. Центральный аргумент автора — измеримый рост коммитов: с 8 апреля по 25 сентября поток коммитов в master вырос с 1037 до 1443, то есть на 39 процентов, а в стабильных ветках REL_18_STABLE и REL_17_STABLE — на 61 и 74 процента соответственно. Haas интерпретирует эту динамику как следствие работы LLM-ревьюеров, которые находят баги в том числе в старом коде. Объём находок оказался настолько велик, что между 27 августа и 15 сентября 2026 года из релиза откатаны три крупные фичи — UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ) и ALTER TABLE ... MERGE/SPLIT PARTITION, — а освободившиеся ресурсы команды направлены на правки стабильных веток вместо разработки нового функционала. Об этой задержке с формулировкой «find more bugs than humans can fix» 16 октября написал и The Register.

Контекст

Чтобы оценить масштаб, важно понимать устройство проекта. PostgreSQL — зрелый open-source проект с почти сорокалетней историей кодовой базы; её качество десятилетиями держалось на человеческом ревью коммитеров-волонтёров, и часть дефектов в годами накопленном коде просто не была замечена. Машинный анализ меняет баланс: LLM-ревью поднял планку качества уже после того, как код был написан, и находит проблемы не только во вновь написанных фичах, но и в стабильных ветках, где код давно выпущен и считался проверенным. В результате узкое место разработки сместилось: обнаружение багов стало дешёвым и практически масштабируемым без ограничений, а дефицитом оказались человеческая верификация, воспроизведение ошибок и коммит исправлений. Для зрелых проектов это означает отдельную фазу, когда ресурсы уходят на «догон» — исправление ранее скрытых дефектов вместо выпуска новых возможностей. PostgreSQL стал одним из первых наглядных примеров такого сдвига на уровне production-кода.

Почему это важно для индустрии

Для индустрии это первое широкое подтверждение, что LLM-ревью на кодовой базе уровня PostgreSQL — не демонстрация, а рабочий механизм, встроенный в критический путь релиза. Экономика разработки open-source меняется: ценность смещается от задачи «найти баг» к задачам «проверить находку, написать патч и довести его до мержа», потому что поиск стал масштабируемым, а человеческая экспертиза — нет. Отсюда готовая продуктовая ниша: инструменты, которые дедуплицируют сырые находки от машинных ревьюеров, ранжируют их по серьёзности, воспроизводят ошибку и превращают репорты в проверенные патчи и тест-кейсы. Мейнтейнерская пропускная способность превращается в дефицитный ресурс, и проекты с большим накопленным кодом могут пережить период замедления инноваций, пока не выстроят автоматизированный триаж потока находок. Для команд, строящих продукты поверх этой динамики, сигнал таков: ценность не в «ещё одном LLM-ревьюере», а в слое верификации и триажа, который конвертирует машинные репорты в проверенные изменения.

Почему это важно для пользователей

Практический эффект касается в первую очередь планирования: миграцию на PostgreSQL 19 стоит закладывать от даты финального релиза из анонсов, а не от привычного осеннего окна, и сверять финальный фичесет по анонсам RC, потому что часть крупного функционала уже откатана. Если ваш продукт зависел от фич, откачанных в августе–сентябре, эти зависимости нужно снимать из планов; в релиз они не попадут. Если же вы ждали версию ради REPACK CONCURRENTLY, эта функциональность остаётся в составе PostgreSQL 19. Второй сигнал шире конкретного релиза: LLM-находки всплывают и в старом стабильном коде, значит скрытые дефекты production-софта теперь будут обнаруживаться чаще. Практический вывод — планировать более регулярные обновления на патч-релизы и воспринимать «проверенный временем» код как потенциальный источник новых багрепортов.

Что пока неизвестно / ограничения

Ключевая оговорка: связь задержки с LLM — это объяснение одного коммитера, а не проверенный вывод; рост коммитов на десятки процентов — корреляция по одному проекту, и альтернативные причины такой динамики в источниках детально не разобраны. В опубликованных материалах нет методологии: не описано, какие модели и пайплайны использовались, какая доля репортов от машинных ревьюеров подтверждалась и было ли сравнение с обычным ручным ревью. Отсутствует и базовая линия пропускной способности человеческого ревью до появления LLM-ревьюеров, поэтому точный вклад машинного анализа в задержку установить нельзя. Прогнозы о том, что описанный паттерн повторится в других больших проектах, — экстраполяция, а не подтверждённый факт.

Источники

Автор

Look at AI, редакция