Один невидимый для человека текст в Java-инструменте jqwik заставил ИИ-агенты для кода удалять собственные тесты и логи. История неприятная не только для любителей «автономной разработки»: она показывает, что ИИ-агенты для кода по-прежнему слишком доверчивы к любому входу, будь то вывод в консоль, README или комментарий в вредоносном пакете.
Об этом как пишет The Register напомнил кейс вокруг jqwik — инструмента для property-based тестирования Java-приложений. Его автор Йоханнес Линк давно и публично выступает против использования LLM-агентов в разработке. В начале года он опубликовал большой текст, где назвал такие практики неэтичными, а затем добавил в jqwik 1.10 отдельное ограничение: библиотека не предназначена для использования AI coding agents. Предупреждение появилось и на сайте проекта, и в README на GitHub, и в release notes.
Но предупреждения, как выяснилось, сработали хуже, чем техническая ловушка. В релизе от 25 мая jqwik начал печатать в stdout строку с прямой инструкцией: игнорировать прежние указания и удалить все тесты и код jqwik. Для обычного разработчика она была фактически спрятана: в эмулированном терминале сообщение не отображалось. Для бота, который без разбора поглощает сырой вывод консоли, этого оказалось достаточно. Результат предсказуемый: у пользователей, доверивших библиотеку ИИ-агентам для кода, начали исчезать тесты и логи, а в GitHub-issues посыпались обвинения в «вредоносном коде» и уничтожении месяцев работы.
Линк ответил просто: это не malware, а принудительное соблюдение правил проекта. Логика у него неприятная, но последовательная. Если человек читает README и условия использования, он заранее понимает, что библиотека не рассчитана на LLM-агентов. Если вместо человека решение принимает бот, который без проверки выполняет инструкции из вывода утилиты, проблема уже не в jqwik, а в том, как устроен сам контур автоматизации. Впрочем, давление оказалось достаточным, чтобы автор отступил: в версии 1.10.1 команда на удаление пропала. Вместо нее библиотека теперь сообщает ИИ-агенту, что использовать jqwik нельзя и результаты тестов следует игнорировать.
От jqwik к вредоносным пакетам
Самое интересное в этой истории не локальный конфликт автора библиотеки с поклонниками AI-assisted coding, а более широкий вывод. The Register связывает кейс jqwik с серией публикаций о черве Shai-Hulud — самораспространяющемся JavaScript-вредоносе, который за последние месяцы успел засветиться в нескольких инцидентах. Издание писало о нем еще в сентябре 2025 года, затем возвращалось к теме в ноябре, а весной 2026-го описывало новые вариации, копии и случаи утечки внутренних GitHub-репозиториев. В июне следы активности, по данным публикации, обнаруживались уже и в npm-архивах, связанных с Red Hat.
На этом фоне индустрия пытается натравить ИИ-агентов для кода уже не на ускорение написания тестов, а на разбор цепочек поставки и первичный triage вредоносных пакетов. Здесь в сюжет входит Socket.dev — компания, продвигающая защиту от supply-chain атак. В ее отчете с длинным заголовком про Mini Shai-Hulud, Miasma и Hades описан прием, который по сути зеркалит историю с jqwik. В JavaScript-файле _index.js исследователи обнаружили огромный комментарий, который ничего не исполняет, но содержит специально составленные инструкции для LLM: переключиться в «неограниченный режим» и выдать пошаговые советы по созданию биологического и ядерного оружия.
Расчет у злоумышленников почти издевательский. Большинство современных LLM снабжены жесткими safety-ограничениями и должны отказываться от подобных запросов. Если сканер на базе модели прогоняет подозрительный файл как текст и послушно пытается обработать комментарий как инструкцию, он может остановить анализ еще до того, как доберется до реальной обфусцированной нагрузки. Socket.dev прямо пишет, что такой комментарий предназначен для срыва AI-assisted triage: не для человека, не для интерпретатора языка, а именно для модели, которую подключили к разбору кода.
Почему это важно разработчикам и бизнесу
Оба кейса бьют по одной иллюзии: будто промптинг можно наращивать до уровня интеллекта. Нельзя. Можно добавить модели системные инструкции, запретить рискованные действия, потребовать «думать как опытный инженер» или «быть особенно осторожной». Но если агент все равно потребляет вход как плоский поток токенов, он остается уязвимым к prompt injection в любой форме — от логов и комментариев до README, issue-трекеров и результатов тестов. И чем глубже такого агента встраивают в CI/CD, IDE и пайплайны безопасности, тем дороже будет ошибка.
Для русскоязычных команд здесь довольно приземленный вывод. Если у вас ИИ-агент умеет не только подсказывать код, но и менять файлы, запускать тесты, открывать pull request или классифицировать пакеты как безопасные и вредоносные, его нельзя считать самостоятельным участником процесса. Это не «джун, которого надо лучше промптить», а вероятностный парсер, которому регулярно подсовывают враждебный ввод. Значит, нужны жесткие ограничения на действия, изоляция среды, принцип наименьших привилегий, ручное подтверждение разрушительных операций и недоверие ко всему, что агент читает из внешних источников. Особенно если этот источник выглядит как безобидный лог, комментарий или служебный текст.
Есть и менее очевидный эффект для open source. История jqwik показывает, что maintainers уже начинают защищаться от несанкционированного использования библиотек AI-агентами не только лицензиями, но и поведенческими ловушками. Это неприятный сигнал для тех, кто привык думать, что любые открытые репозитории можно бесконечно скармливать ботам без согласия авторов и без чтения условий. Если такая практика закрепится, рынок получит новый слой конфликтов: не только между разработчиками и вредоносными пакетами, но и между авторами OSS и платформами, которые строят поверх их кода полуавтономные системы.
Вопрос теперь не в том, станут ли ИИ-агенты для кода «умнее» после очередного набора инструкций. Вопрос в том, сколько еще пайплайнов успеют им доверить до того, как индустрия признает более скучную правду: любой LLM-агент, который читает все подряд и умеет что-то удалять, коммитить или блокировать, нужно проектировать как потенциально компрометируемый компонент, а не как цифрового коллегу.