Качественное исследование показало, как разработчики воспринимают и критикуют низкокачественный ИИ-контент, который они называют AI slop, в разработке ПО. Авторы описывают ситуацию как «трагедию общих ресурсов»: отдельные сотрудники и компании получают выигрыш в скорости, а издержки ложатся на ревьюеров, мейнтейнеров и open-source-сообщество.
Исследование провели учёные из Гейдельбергского университета, Университета Мельбурна и Сингапурского университета менеджмента. Себастьян Бальтес, Марк Чеонг и Кристоф Тройде проанализировали 1154 публикации из 15 дискуссий на Reddit и Hacker News.
Авторы специально отбирали треды с выражением «AI slop». Поэтому выборка изначально смещена в сторону разработчиков, которые уже относятся к такому контенту отрицательно. Позитивные и нейтральные оценки инструментов генерации кода в исследование почти не вошли, так что его выводы не отражают мнение всего сообщества разработчиков об ИИ-инструментах.
На основе этих данных исследователи составили кодовую схему из 15 категорий, объединённых в три тематические группы: Review Friction, Quality Degradation и Forces and Consequences.
В материале отмечается, что сторонники ИИ-разработки могли бы возразить на эту критику, заявив: по мере улучшения моделей оценка качества кода человеком будет значить меньше. В пример приводится сотрудник OpenAI, который предположил, что код, созданный ИИ, скоро перестанут проверять вручную, из-за чего возникнут «сбои систем, которые будет труднее отлаживать, чем большинство других», но со временем такие проблемы всё равно будут устранять.
Также упоминается разработчик в сфере ИИ Андрей Карпати, который ранее называл человека узким местом в исследованиях с ИИ. Из этой логики следует, что по мере улучшения моделей ручная проверка каждой строки кода будет считаться всё менее нужной, а человек останется в роли общего контролёра процесса.
Однако главный вывод исследования иной. Критически настроенные разработчики считают, что AI slop создаёт общий ущерб: кодовые базы накапливают технический долг, базы знаний засоряются, ревьюеры выгорают, а доверие, на котором держится совместная разработка, снижается.
Особенно заметно это в open-source-проектах, где общие ресурсы поддерживают добровольцы. Авторы приводят реальные примеры: проект curl закрыл программу bug bounty после того, как созданные ИИ отчёты об уязвимостях начали отнимать время у мейнтейнеров и при этом не давали корректных результатов. О похожих проблемах сообщали Apache Log4j 2 и Godot.
Разработчики также рассказывали, что ИИ-процессы им навязывало руководство. В одном случае топ-менеджеры вставляли ответы ИИ напрямую в ответ на каждую техническую проблему, с которой сталкивалась команда.
Одной из главных тем стал рост нагрузки на тех, кто проверяет код. Один из разработчиков сказал: «Время разработки сократилось, но теперь команде нужно тратить больше времени на ревью. Не похоже, что от этого есть польза».
Одна команда сообщила о 30 pull request в день при наличии всего шести ревьюеров. По словам участников обсуждений, это заметно увеличивает нагрузку и мешает нормальной проверке изменений.
Ревьюеры описывали своё состояние так, будто они «первый человек, который вообще увидел этот код». Ещё один участник обсуждения пожаловался, что их фактически превращают в бесплатных prompt-инженеров: «Они буквально используют вас, чтобы вы делали их работу, то есть критически оценивали и понимали их AI slop и давали следующий промпт».
Разработчики также выработали собственные признаки, по которым пытаются распознать код, созданный ИИ. Почти верным маркером они считают эмодзи в комментариях к коду. Также упоминались пошаговые шаблоны комментариев, раздутый стиль и артефакты Unicode.
Доверие к совместной работе тоже снижается. Один разработчик так описал pull request, созданный ИИ-агентом: «Я не понимаю, как этому вообще можно доверять в какой-то момент. Нет реального понимания того, что он делает, он просто угадывает».
По сообщениям участников, ИИ-агенты показывали и более тревожное поведение. Исследование описывает «циклы смерти», когда агент многократно вносил заведомо неверные исправления, а также случаи, когда он менял тесты так, чтобы сломанный код проходил проверку, вместо исправления самой ошибки.
В одном эпизоде ИИ-агент «выдумал внешние сервисы, а затем создал моки для этих же выдуманных сервисов», в результате чего получилась внутренняя логичная, но полностью фиктивная интеграция.
Проблема, по словам разработчиков, затрагивает и внешние источники знаний. Один из участников обсуждения написал: «Я начинаю видеть документацию и туториалы, в которых не хватает ключевой информации и примеров кода, нужных для реализации. Или там просто всё неверно, либо используется класс, которого не существует».
Авторы также зафиксировали опасения по поводу общей деградации навыков. Один комментатор на Hacker News описал ситуацию как ловушку: если для эффективной работы с ИИ уже нужен опытный инженер, а этот опыт раньше получали без ИИ, то остаётся вопрос, как появятся новые опытные инженеры.
В исследовании перечислены и меры, которые разработчики уже предлагают или применяют на практике:
- ограничение размера pull request с ИИ-кодом, например менее 500 строк на один PR;
- обязательное самостоятельное ревью перед отправкой коллегам;
- синхронные разборы кода;
- двойное ревью с участием внешних команд;
- привязка ответственности за качество изменений к оценке работы сотрудников.
Для разработчиков инструментов авторы рекомендуют сместить акцент с генерации кода на проверку и ревью. В качестве примеров названы индикаторы неопределённости, данные о происхождении фрагментов кода, а также поддержка небольших пошаговых изменений и более удобной структуры вывода для проверки.
Руководителям команд исследователи советуют пересмотреть критерии оценки, в которых поощряется объём выпущенного кода, и учитывать последующие издержки, включая нагрузку на ревью и частоту ошибок. Авторы также подчёркивают, что разработчики должны сами сохранять контроль над тем, когда и как использовать ИИ-инструменты.
Командам рекомендуют требовать от участников понимания и объяснения собственных изменений. Для этого предлагаются лимиты на размер PR и совместные разборы кода.
Для учебных заведений авторы предлагают использовать устные экзамены и live coding, а на ранних этапах обучения ограничивать использование ИИ-инструментов, чтобы студенты сначала получали базовые навыки. По мнению исследователей, сам по себе работающий результат не доказывает компетентность.
Источник: The Decoder.
