Postgres 19 відкладено через потік багів від ШІ-рев'юерів

Реліз PostgreSQL 19 відклали, бо автоматичні ШІ-рев'юери почали знаходити баги швидше, ніж люди в команді встигають їх закривати. Черга виправлень росте, і дата виходу посунулась. Це перший широко відомий випадок, коли машинний контроль якості став вузьким місцем проєкту, а не прискорювачем.

PostgreSQL — не черговий стартап із гучним пресрелізом. Це одна з найстаріших і найсуворіших до якості коду спільнот у світі open source, де патч місяцями проходить ручні рев'ю, перш ніж потрапити в основну гілку. Якщо навіть тут ШІ-інструмент видає більше претензій, ніж команда здатна опрацювати, це говорить щось важливе про сам інструмент.

Знайти ваду — це не те саме, що її виправити

ШІ-рев'юер працює як невтомний молодший інженер, який читає кожен рядок і підсвічує все підозріле: потенційний витік пам'яті, неврахований крайній випадок, сумнівну роботу з конкурентним доступом. Швидкість тут майже нескінченна — модель не втомлюється й не пропускає файли через брак часу.

Проблема в наступному кроці. Кожну знахідку хтось живий мусить оцінити: це справжній баг чи хибне спрацювання? Яке виправлення не зламає сумісність? Чи не тягне воно за собою зміни в десятках інших місць? Ось ця частина не прискорюється. Машина генерує роботу зі швидкістю, яку людська експертиза фізично не перетравлює.

Баг знайдено за секунду. Рішення, чи це взагалі баг, забирає годину інженера, який розуміє всю систему.

Звідси й затримка. Не тому, що софт раптом став гіршим — а тому, що видимість проблем зросла швидше, ніж спроможність на них реагувати. Старі баги нікуди не поділись, їх просто раніше ніхто не бачив.

Чому це безпосередньо стосується українських команд

Половина нашого IT будує або підтримує системи, де ціна помилки висока: банківські ядра, платіжні шлюзи, реєстри в "Дії", оборонний софт. У таких проєктах спокуса підключити ШІ-рев'ю й відрапортувати про "посилення якості" особливо велика — інструмент дешевий, звіт виглядає переконливо.

Кейс Postgres показує, де пастка. ШІ-рев'ю — це додатковий детектор, а не заміна інженера, який ухвалює рішення. Якщо впровадити його без людей, здатних розгрібати потік знахідок, ви отримаєте одне з двох: або паралізований процес, як у Postgres, або — значно гірше — команду, яка масово тисне "ignore" на попередженнях, щоб встигнути до дедлайну. Другий сценарій означає, що справжні баги тонуть серед хибних спрацювань, і система стає менш безпечною, ніж була без усякого ШІ.

Що з цього практично випливає

Правильна рамка проста. ШІ-рев'юер ставлять перед людським рев'ю, щоб відсіяти очевидне й звузити фокус інженера, а не замість нього. Для критичних систем до нього додають бюджет часу на розбір знахідок — якщо такого бюджету немає, інструмент краще не вмикати взагалі.

• Міряти не кількість знайдених багів, а частку підтверджених: високий рівень хибних спрацювань убиває довіру до інструмента.
• Закладати людський ресурс на тріаж знахідок ще на старті, а не коли черга вже виросла.
• Для реєстрів і фінансових систем тримати фінальне рішення за інженером, який відповідає за архітектуру цілком.

Postgres відклали не тому, що ШІ підвів. Його відклали тому, що ШІ зробив свою роботу надто добре, а людська частина конвеєра виявилась не готова. Інструмент, який знаходить проблеми, корисний рівно настільки, наскільки у вас є кому їх вирішувати.