Разбор · Опубликовали 08.10.2026
Галлюцинации нейросетей в коде ловят проверкой существования библиотеки, API и нужной версии
Что требовать от агента до приёмки правки: источник зависимости, документацию версии и результат настоящего вызова.
Машина агентов под надзором Евгения Шилова · факты проверены 8 октября 2026
Галлюцинация в коде выглядит как готовое решение, пока инженер не проверит, существуют ли предложенные библиотека и API в версии вашего проекта.
Ни уверенный ответ, ни зелёный тест с подменой вызова этого не доказывают: ниже процедура, по которой правку можно принять или вернуть на доработку.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Выдумку ищут в трёх проверяемых местах.
Галлюцинацией в коде называют выдуманную деталь решения. Агент ссылается на пакет, метод или параметр, которого в действительности нет.
Учебный пример: агент предлагает выгрузку заявок через exportAll(). Имя здесь намеренно вымышленное; своего клиентского случая выдуманного API у нас нет.
В исследовании USENIX Security 2025 нашли выдуманные пакеты. Исследователи проверили 576 000 примеров кода от 16 моделей; это исторический эксперимент, не замер вашего агента.
У каждого обещания агента есть своя проверка.
Источник: USENIX Security 2025; документация npm view. Проверено 08.10.2026. Таблица приёмки составлена редакцией.
Установить найденный пакет сразу тоже рано. В USENIX описан риск: посторонний публикует пакет под выдуманным именем, и следующая рекомендация уже ведёт к настоящему скачиванию.
2. Документацию читают для версии клиента.
Настоящий API тоже бывает непригоден для проекта. На странице последнего выпуска метод есть, а у клиента установлена версия, в которой его ещё не было.
Возьмём исторический пример из Node.js. В документации 16.14.2 встроенного глобального fetch нет, а в 18.0.0 он есть и ещё помечен экспериментальным.
Поэтому ответ «fetch существует» неполон. Надо проверить, где исполняется код, какая версия запущена и не добавляет ли само приложение этот вызов через библиотеку.
Один API по-разному доступен в разных выпусках.
Источник: официальные документы этих выпусков Node.js, проверено 08.10.2026. Это демонстрация различий версий, не рекомендация запускать проект на старой среде.
Версию берут из проекта, не из ответа агента. Файл фиксации зависимостей показывает выбранный выпуск; список установленных пакетов и среда запуска подтверждают, что он используется.
3. Зелёный тест с подменой API не доказывает реальный вызов.
Тест способен пройти без существующего метода. Если инженер подменил exportAll() готовым ответом, он проверил обработку ответа, а не возможность выгрузить заявки.
Такая подмена полезна для проверки своей логики. Но ей нужна отдельная проверка настоящего вызова: запрос на тестовых данных и сверка полученного результата.
Требование записывают при постановке задачи агенту. «Выгрузка готова» означает, что заявка попала в файл, а ошибка доступа показана пользователю.
Подмена ответа и настоящий вызов проверяют разные вещи.
Источник: редакционная процедура приёмки; документация GitHub о проверке сгенерированного кода, прочитана 08.10.2026. Различия проверок объяснены на учебном примере.
4. Наши ошибки фактов закрепили проверку по первоисточнику.
У нашей машины агентов зафиксированы выдумки фактов при подготовке материалов. Инженер ведёт машину на vibecoding.ru; эти записи не являются клиентскими случаями ошибок API.
Самостоятельный пересказ источника уже давал ошибку. Поэтому проверяющий получает исходную страницу и буквальное утверждение, которое должен подтвердить.
Вторую модель здесь используют как проверяющего. Вопрос «решение верно?» оставляет её в пересказе; задача найти метод в документации даёт проверяемый результат.
Проверка дрейфа модели требует повтора контрольных задач и учёта смены версии.
Ошибка факта получила правило проверки.
21.08
Писатель приписал продукту внутренний замер, которого не было в исходных данных. Приёмник вернул текст. Правило: факты сверяет отдельный проверяющий с чистым контекстом.
21.08
При чтении одной страницы разведчики принесли несовпадающие цифры. Правило: сохранять сырьё, якорную цитату ключевого числа и проводить независимую сверку.
05.09
Инструмент чтения приписал страну списку поддерживаемых; буквальный поиск по странице её не нашёл. Правило: списки читать машинно, не доверять пересказу.
Источник: редакционные журналы vibecoding.ru, записи 21.08 и 05.09.2026, сверены 08.10.2026. Первичка непубличная; здесь пересказ событий без цитат и кадров закрытых файлов.
Для кода переносится метод проверки. Если агент обещает exportAll(), инженер ищет объявление метода и запускает вызов; согласие другого чата не заменяет эти следы.
5. Приёмка требует следов проверки в репозитории.
Руководителю нужен проверяемый результат в правке. Объяснение агента остаётся предположением, пока инженер не приложил источник и результат проверки.
У пакета сверяют происхождение до установки. Ошибка доступа к частному реестру не доказывает, что пакет выдуман; её сначала разбирают с владельцем доступа.
В правила работы агентов запишите требование: новую зависимость и новый вызов принимают после проверки по этой таблице.
Шесть шагов оставляют доказательства при правке.
Источник: процедура редакции, составлена 08.10.2026 на основе документации npm, Node.js и GitHub. При выполнении используют реестр, язык и команды самого проекта.
6. Повторную выдумку ловит проверка из прошлой поломки.
После исправления полезно сохранить причину отказа. В учебном примере агент убирает вымышленный exportAll() и выбирает документированный способ выгрузки.
Тест на настоящую выгрузку остаётся с правкой. Новый агент сможет сменить реализацию, но ему придётся снова получить файл с заявкой в принятой среде.
Обновлять все библиотеки до latest ради красивого ответа не нужно. Если обновление необходимо, это отдельное изменение с проверкой совместимости.
Исправление остаётся в проекте вместе с проверкой.
Источник: учебный пример редакции, 08.10.2026. Таблица описывает требуемую приёмку, не результат работы на клиентском проекте.
Кто принимает правку и возвращает её при сбое, определяют заранее. Порядок ответственности за ошибки нужен даже тогда, когда агент нашёл существующий API.
Если инженер есть в команде, таблица становится его правилом приёмки. Если проверку некому вести, в агентной разработке по подписке её ведёт инженер до передачи правки.
Тариф «Один проект» стоит 250 000 ₽ в месяц на 08.10.2026. До заказа можно обсудить задачу с инженером.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| USENIX Security 2025 | 576 000 примеров кода от 16 моделей. Проверен официальный abstract. Выборка 2025 года не даёт частоту ошибок модели клиента. | 2026-10-08 |
| Node.js | Прочитаны официальные документы выпусков 16.14.2 и 18.0.0. Пример показывает различие наличия встроенного fetch, а не рекомендуемую среду запуска. | 2026-10-08 |
| Метаданные пакета | Документация npm view: можно читать сведения о конкретной версии. Наличие имени в реестре не удостоверяет происхождение и безопасность. | 2026-10-08 |
| Наши истории | Записи 21.08 и 05.09.2026 сверены по первичным редакционным журналам. Это ошибки фактов; своего клиентского случая выдуманного API нет. | 2026-10-08 |
| Цена подписки | Тариф «Один проект», 250 000 ₽ в месяц, прочитан на живой /services. Цена относится к месяцу работы, не к исправлению отдельной ошибки. | 2026-10-08 |
| Учебный пример | Метод exportAll() намеренно вымышленный. Таблицы описывают предложенную процедуру приёмки; замер на клиентском проекте не проводился. | 2026-10-08 |
7. Частые вопросы
Любая ошибка в коде считается галлюцинацией?+
Нет. Неверное условие в существующем методе бывает обычной ошибкой логики. Галлюцинацией здесь называем выдуманный факт о библиотеке, API, параметре или его наличии в версии.
Можно ли убрать галлюцинации правильным промптом?+
Промпт задаёт обязанность найти подтверждение и остановиться, если его нет. Существование метода он не доказывает; это подтверждают документация и исполнение.
Поиск и документация устраняют выдумки?+
Они дают источник для проверки. Если агент пересказал его неверно или прочитал другую версию, ошибка останется. Сверяют конкретный метод, параметры и результат вызова.
Если пакет нашёлся в реестре, его можно ставить?+
Наличие имени не доказывает происхождение и безопасность. Сначала сверяют автора, исходный проект и выбранную версию. Для нового неизвестного пакета нужна проверка по правилам компании.
Поможет ли другая модель?+
Ей можно поручить найти подтверждение и проверить правку. Совпадение двух ответов не является подтверждением API: нужны первоисточник и воспроизводимый результат.
Как проверить закрытый API, у которого нет публичной документации?+
Использовать доступное внутри компании описание, объявление интерфейса и разрешённый тестовый вызов. Отсутствие страницы в интернете не доказывает, что внутреннего API нет.
Источники
- USENIX Security 2025, We Have a Package for You!: первичная научная работа, август 2025. — первоисточник
- Node.js 16.14.2, глобальные объекты: официальный документ выпуска. — первоисточник
- Node.js 18.0.0, глобальные объекты: официальный документ выпуска. — первоисточник
- npm view: официальная документация метаданных пакета. — первоисточник
- GitHub, ответственное использование агентов: официальные рекомендации по проверке кода. — первоисточник
- Открытая машина vibecoding.ru: публичный контекст машины; события ленты сверены по непубличным редакционным журналам. — наш опыт
- Агентная разработка по подписке: тариф проверен 08.10.2026. — наш опыт
Запомнить
1. Переведите ответ агента в проверяемые утверждения о пакете, API и версии.
2. До установки сверьте происхождение зависимости; существование имени не удостоверяет безопасность.
3. Проверяйте документацию установленной версии и среду исполнения клиента.
4. Дополните тест с подменой ответа настоящим вызовом на тестовых данных.
5. Сохраните результат приёмки и проверку, которая поймает повторную ошибку.