Автоматический помощник может работать без усталости. Человек, которому досталась очередь его результатов, — пока нет. Три материала The Register показывают разные стороны этой проблемы. Сопоставимых голосов и оценок нет, поэтому порядок редакционный.

curl: менее опасные уязвимости отправят в публичное обсуждение

По сообщению от 20 октября, с 26 октября curl намерен принимать сообщения об уязвимостях низкой и средней опасности в публичном репозитории GitHub. Закрытая обработка останется для высокой и критической опасности. На момент публикации материала это объявленный будущий порядок, а не уже завершённый переход.

Дэниел Стенберг объясняет изменение перегрузкой ключевых сопровождающих. ИИ помогает находить в том числе необычные сочетания настроек и представлять мелкие расхождения как уязвимости. Это не означает, что все такие сообщения ложные: даже настоящий, но малозначимый дефект требует времени на разбор.

Публичное обсуждение позволит привлечь больше людей, но не сделает каждое сообщение бесплатным для проверки. Есть и обратная сторона: сведения становятся доступны атакующим раньше исправления. Проект пытается распределить работу, принимая связанный с публичностью риск.

Урок: автоматизация поиска ошибок без соразмерных ресурсов на проверку способна заставить проект менять даже привычный порядок раскрытия уязвимостей.

PostgreSQL 19: полезная проверка тоже умеет двигать сроки

The Register 16 октября сообщил о переносе PostgreSQL 19 примерно на 19 ноября и исключении восьми–десяти значимых возможностей. Разработчик Петер Айзентраут связывает часть нагрузки с улучшением проверки кода языковыми моделями: они быстрее находят длинный хвост сравнительно безобидных пограничных ошибок. Даже если исправление короткое, кто-то должен отдельно разобраться в проблеме.

Здесь важно не перепутать причины. У части отложенных возможностей были серьёзные архитектурные недостатки, поэтому сводить весь перенос к ИИ нельзя. Айзентраут также отвергает объяснение генерацией кода по запросам: большинство возможностей разрабатывалось раньше. Речь о выросшем потоке найденных проблем, а не о доказанном нашествии сгенерированного кода.

Получилась неприятная премия за хорошую работу проверяющего: ошибок обнаружили больше, чем успели спокойно обработать к сроку.

Урок: если скорость обнаружения дефектов выросла, время на их проверку и исправление нужно пересчитать — даже когда ИИ действительно полезен.

Linux Foundation: быстрее написать — ещё не значит быстрее принять

В материале от 21 октября The Register пересказывает опрос Linux Foundation. Сопровождающие оценивают долю низкокачественных предложений изменений, подготовленных с ИИ, примерно в четверть входящего потока, а в крупных проектах — в 31%. Одновременно респонденты сообщают о сокращении времени написания кода в среднем на 52%.

Это оценки участников опроса, а не независимый замер всех открытых проектов. Из этих чисел нельзя вывести универсальную долю плохого ИИ-кода или точный баланс сэкономленных и потраченных часов. Но они показывают важное расхождение интересов: отправитель быстрее готовит изменение, а получателю всё ещё приходится его понимать, проверять и принимать либо отклонять.

Конвейер разогнали, приёмную комиссию — забыли.

Урок: ответственность за тестирование и прозрачное раскрытие использования ИИ остаётся у автора изменений. Иначе сэкономленное им время просто переезжает в чужую очередь проверки.