Linux Foundation: 25% пул-реквестов — «ИИ-мусор». Что это значит

20 октября 2026 года Linux Foundation опубликовала исследование о том, как генеративный ИИ меняет разработку открытого ПО. Главная цифра: по оценке мейнтейнеров, 25% входящих пул-реквестов — низкокачественный код, который в отчёте называют «AI slop», «ИИ-мусор». В крупных проектах — 31%. При этом время на написание кода с ИИ сократилось в среднем на 52%. Мы разберём, что эти цифры значат для тех, кто заказывает разработку.

Что показал опрос

Исследование подготовило подразделение LF Research при поддержке Red Hat. Опрошены мейнтейнеры и контрибьюторы открытых проектов. Ключевые результаты из пресс-релиза:

Сэкономленное время, по словам респондентов, уходит на технический долг (66%), новые функции (63%) и обучение (58%). 46% мейнтейнеров считают, что ИИ увеличивает потребность в наставничестве, 32% — что уменьшает.

Почему это важно не только для open source

Открытые проекты — витрина того, что происходит в любой команде разработки. Мейнтейнер видит пул-реквесты от сотен незнакомых людей и вынужден их проверять. Заказчик, который работает с подрядчиком, получает тот же поток кода — только не видит его.

Из цифр следуют три вещи.

ИИ ускоряет написание, но не проверку. Время на код сократилось вдвое, а время на ревью — нет. Если команда не увеличила внимание к проверке, качество падает.

На сложных задачах ИИ может замедлять. Каждый пятый опрошенный тратит с ИИ больше времени на сложных задачах. Это объяснимо: генерация «правдоподобного» кода в сложной бизнес-логике порождает ошибки, которые дольше искать.

Политика нужна, но её нет у большинства. Только 35% проектов формально описали правила использования ИИ.

Что мы советуем заказчикам

1. Спросите подрядчика о правилах работы с ИИ. Какие инструменты используются, кто проверяет код, есть ли тесты. Это нормальный вопрос, как вопрос о резервных копиях.
2. Требуйте автоматические тесты на ключевые сценарии. Оплата, регистрация, обмен с 1С, отправка заявок. ИИ-код без тестов — лотерея.
3. Закладывайте время на ревью. Если подрядчик обещает «в два раза быстрее благодаря ИИ», уточните, где в плане проверка.
4. Проверяйте безопасность отдельно. ИИ охотно предлагает устаревшие библиотеки и небезопасные шаблоны — нужен аудит зависимостей и кода.
5. Не платите за объём кода. Больше строк — не больше пользы. Оценивайте результат: работает ли функция, покрыта ли тестами, понятна ли документация.

Как встроить проверку ИИ-кода в процесс

Хорошая новость: для этого не нужны новые инструменты, нужны старые практики, применённые последовательно.

• Ревью каждого изменения. Ни один пул-реквест не попадает в основную ветку без просмотра вторым человеком — неважно, писал его человек или ИИ.
• Автотесты в CI. Тесты запускаются автоматически на каждое изменение. Сгенерированный код без тестов не принимается.
• Анализ зависимостей. Автоматическая проверка библиотек на известные уязвимости и лицензии: ИИ нередко предлагает пакеты, которые давно не обновлялись.
• Маленькие изменения. ИИ легко пишет 2 000 строк за раз, но такой пул-реквест невозможно нормально проверить. Лучше десять маленьких.
• Объяснение от автора. Разработчик должен уметь объяснить каждый фрагмент, который отправляет. Если не может — фрагмент не готов.

Эти правила стоит прописать в договоре или регламенте работ с подрядчиком. Они дешевле, чем исправление ошибок после запуска.

Рекомендации самой Linux Foundation

Авторы отчёта советуют проектам:

• опубликовать понятную политику для вкладов, сделанных с помощью ИИ;
• требовать раскрытия использования ИИ;
• просить авторов тестировать и документировать такие изменения до отправки;
• стандартизировать указание авторства;
• считать управление, проверку и доверие частью инфраструктуры проекта.

Эти правила легко переносятся на коммерческую разработку: договор с подрядчиком может содержать пункт о применении ИИ и обязательном ревью.

Наше мнение

Мы используем ИИ-инструменты в разработке и считаем их полезными. Но опрос Linux Foundation подтверждает то, что мы видим на практике: выигрыш получает команда, у которой есть дисциплина проверки. Без неё ИИ просто быстрее производит код, который потом дорого исправлять. Мы советуем заказчикам оценивать не скорость подрядчика, а то, как он проверяет результат.

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