28% рекомендаций ИИ ведут к несуществующим пакетам: искусственный интеллект в разработке на Java

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

Компания Sonatype, известная в Java-сообществе как оператор репозитория Maven Central, опубликовала отчёт о качестве кода, который генерируют большие языковые модели (LLM, модели вроде GitHub Copilot и ChatGPT, способные писать и редактировать программный код). Результат оказался тревожным: из почти 37 тысяч рекомендаций по обновлению программных библиотек больше четверти указывали на версии, которых попросту нет в реальных репозиториях.

Параллельно исследователи Университета Карнеги-Меллона установили, что языковые модели выдумывают от 69% до 88% ответов, при этом сохраняя уверенный, «экспертный» тон. Именно эта уверенность и создаёт ловушку: код выглядит профессионально, компилируется, но содержит ошибки, которые сложно заметить даже опытному специалисту.

Галлюцинации в коде опаснее галлюцинаций в тексте

Галлюцинация (когда модель уверенно выдаёт информацию, которой не существует) в обычном тексте раздражает. В программном коде она может сломать продукт или открыть дверь злоумышленнику.

В Java-экосистеме проблема особенно острая по трём причинам.

Правдоподобные, но вымышленные библиотеки. Maven Central содержит огромное количество пакетов с регулярной системой именования. Модель легко «угадывает» координаты, которые выглядят настоящими. Например, путает org.apache.commons:commons-csv с org.apache.commons:commons-text или предлагает несуществующий commons-utils. Именно на этом построена атака slopsquatting: злоумышленник регистрирует пакет с именем, которое модели часто выдумывают, и ждёт, пока разработчик скопирует его из ответа ИИ.

Скрытые цепочки зависимостей. В файле проекта могут быть указаны десятки библиотек, но система сборки Maven фактически подтягивает сотни так называемых транзитивных зависимостей (библиотек, которые нужны вашим библиотекам). Модель не видит это дерево целиком. Отчёт описывает конкретный случай: обновление Spring Cloud OpenFeign с версии 4.3.1 до 4.3.2 незаметно меняло версию commons-fileupload, закрывая уязвимость CVE-2025-48976. Одна строчка в конфигурации, а за ней целая цепочка последствий, которую ИИ не отслеживает.

Код, который компилируется, но работает неверно. Java-проекты полны шаблонного кода: аннотации, конфигурации безопасности, маппинг данных. Модель воспроизводит шаблон почти идеально, но может поставить аннотацию @Transactional не на тот метод или оставить конечную точку API (endpoint, адрес, по которому приложение принимает запросы) без защиты. Ошибка не в синтаксисе, а в смысле, и компилятор её не поймает.

Почему мозг не помогает?

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

Мозг распознаёт привычный шаблон и предлагает не тратить время на проверку. Хорошее оформление при этом ничего не говорит о корректности кода.

Уверенность человека слабо связана с его реальной компетентностью. Люди часто доверяют тому, кто говорит первым и звучит убедительно, даже если более тихий участник обсуждения лучше понимает проблему. : Томас Чаморро-Премузик, организационный психолог

Что делать прямо сейчас, по ролям

Java-разработчику. Относитесь к коду от ИИ как к pull request от незнакомого стажёра: проверяйте каждую зависимость командой mvn dependency:tree -Dverbose, запускайте в CI сканер уязвимостей (OWASP dependency-check-maven, Snyk или Sonatype Lifecycle). Фиксируйте транзитивные версии через <dependencyManagement> в Maven. Если модель предлагает библиотеку, которую вы не знаете, проверьте её существование в Maven Central вручную, прежде чем добавлять в проект.

Автору контента на Дзене, пишущему о технологиях. Тема галлюцинаций ИИ в коде даёт сильный повод для материала: цифра «каждая четвёртая рекомендация ведёт в пустоту» конкретна и понятна даже нетехнической аудитории. Но не пересказывайте без проверки: сами данные Sonatype относятся к Java-экосистеме, экстраполировать их на Python или JavaScript без источника некорректно.

Руководителю или заказчику разработки в РФ. Если ваша команда использует GitHub Copilot или аналоги для ускорения работы, уточните, есть ли в процессе этап ручной проверки зависимостей и сканирования уязвимостей. Из инструментов, доступных в России: SCA-сканер (Software Composition Analysis, анализ состава программного обеспечения) от Positive Technologies, а для языковых моделей как помощников в коде можно рассматривать GigaCode от Сбера.

Данные Sonatype про 28% вымышленных зависимостей не повод отказываться от ИИ-ассистентов, но повод перестать принимать их ответы без перепроверки. Код от модели заслуживает ровно такого же скепсиса, как пятничное обещание руководителя мигрировать фреймворк за выходные.