AI‑ассистенты для разработки уже стали рабочим стандартом: Copilot, Cursor, Claude Code и десятки других ускоряют команды и снимают часть рутины. Но вместе со скоростью растет и другая величина — объем кода, который попадает в прод без глубокого понимания и проверки. История DeFi‑протокола Moonwell показала, что это уже не абстрактный риск, а вполне осязаемые потери в миллионы долларов.
Кейс Moonwell: формула на $1,78 млн
В феврале 2026 года протокол кредитования Moonwell, работающий в сетях Base и Optimism, оказался с примерно $1,78 млн «плохого долга» из‑за ошибки в ценовом оракуле для токена cbETH.
Что произошло на уровне логики:
- Оракул отвечал за оценку cbETH в долларах, чтобы считать корректные коэффициенты залога.
- В обновлeнной версии логики использовались курсы cbETH/ETH без дальнейшего пересчета в ETH/USD, то есть система жила в «этерном», а не в денежном мире.
- В результате cbETH оказался оценен примерно в $1–1,12 вместо ~ $2200, что дало около 99% расхождения с реальной ценой.
Кредитная модель Moonwell опиралась на эти значения: из‑за неверной цены залог требовался формально, но почти ничего не стоил. Ликвидаторы и боты смогли гасить позиции по цене около $1 за cbETH и забирать высоколиквидные активы из пулов, пока ошибка не была обнаружена. В итоге протокол остался с примерно $1,78 млн дефицита на балансах пулов.
Где здесь ИИ и при чем тут «вайбкодинг»
В публичных разборах Moonwell подчеркивается, что уязвимая часть логики оракула была сгенерирована при участии модели Claude Opus 4.6, а соответствующие коммиты помечены как Co‑Authored‑By: Claude Opus 4.6. Технический отчeт связывает неправильный масштабный коэффициент цены именно с AI‑сгенерированным обновлением конфигурации оракула, использующим cbETH/ETH вместо полной цепочки cbETH → ETH → USD
Связка выглядит так:
- команда использовала AI‑ассистента для разработки части финансово‑критичной логики;
- обновление прошло ревью и попало в прод без того уровня проверки, который обычно ожидается для кода, влияющего на устойчивость пула;
- одна некорректная формула транслировалась в прямой финансовый ущерб для протокола и его пользователей.crypto+1
Формально корневой причиной остаётся не сам факт использования ИИ, а отсутствие должного процесса вокруг AI‑кода. Но Moonwell стал одним из первых ярких кейсов, где цепочка «AI‑генерация → уязвимая бизнес‑логика → реальные потери» зафиксирована достаточно явно.mexc+1
«Тихий кризис» AI‑кода: это не один кейс
Кейс Moonwell лег на уже оформляющийся тренд: скорость AI‑разработки растёт быстрее, чем зрелость процессов проверки и безопасности.
AI‑ассистенты ускоряют разработку — и производство уязвимостей
Аналитика по AI‑коду в 2025 году показывает тревожную картину: по оценкам исследователей, до половины фрагментов, сгенерированных AI‑ассистентами, содержат потенциальные уязвимости или рискованные паттерны, тогда как в традиционном коде этот показатель оценивается на уровне 15–20%.
Причины сводятся к нескольким повторяющимся факторам:
- отсутствие полноценного peer‑review именно для AI‑кода в быстрых пайплайнах;
- рекомендации сложных или устаревших фреймворков, которые команда понимает поверхностно;
- неполное покрытие тестами, особенно негативными сценариями;
- ложное ощущение безопасности: код выглядит аккуратно, проходит базовые проверки IDE и воспринимается как «достаточно хороший».
Отдельные обзоры подчеркивают, что с распространением AI‑ассистентов разработчики делают больше изменений и крупнее коммиты, что усложняет ревью и повышает шанс пропустить опасный фрагмент.
Практические тесты ассистентов по безопасности
Сообщество разработчиков регулярно проверяет ассистентов на прикладных security‑сценариях. В одном из таких тестов автор сравнивал GitHub Copilot, Cursor и Claude Code на задаче реализации безопасного endpoint’а для сброса пароля.
Результаты выглядели так: Copilot сгенерировал рабочий endpoint, но без rate limiting, без истечения срока действия токена и с предсказуемым способом его генерации.
- Cursor предложил более структурное решение, но добавлял многие защиты только после явных подсказок.
- Claude Code чаще сразу учитывал rate limiting и истечение токена, но и это решение требовало ручного пересмотра.
Общий вывод тестов: ни один из ассистентов не дает гарантированно безопасной реализации по умолчанию, если разработчик не задаёт четких требований и не проводит ревью.
Уязвимости в самих AI‑инструментах
Дополнительный пласт рисков связан уже не с генерируемым кодом, а с AI‑инструментами как частью инфраструктуры разработки. Публикации за 2025 год фиксируют случаи:
- использования уязвимостей в AI‑расширениях для IDE и конструкторов агентов (например, Langflow AI) для внедрения вредоносного кода и кражи учётных данных;
- prompt‑injection атак, когда злоумышленник подсовывает ассистенту инструкции, заставляющие его утекать данные или модифицировать код нежелательным образом;
- компрометации пакетов и расширений, маскирующихся под легитимные AI‑инструменты (в одном из кейсов разработчик лишился крипто‑активов после установки поддельного расширения popularного ассистента).
Таким образом, AI‑кодинг создаeт новый слой в threat‑модели: уязвимости могут появляться как в приложении, так и в самой цепочке инструментов, которые с этим приложением работают.
Что делать команде прямо сейчас
Хорошая новость в том, что для повышения безопасности AI‑кодинга не всегда нужны радикальные перестройки процессов. Ниже — шаги, которые можно начать внедрять уже сейчас.
1. Определить, где AI‑код допустим, а где нет
- На уровне команды зафиксировать: AI‑ассистент используется для утилитарного кода, тестов, миграций, вспомогательных скриптов, документации.
- Области, которые влияют на деньги клиентов, доступы, регуляторные требования и ключевые бизнес‑инварианты, проектируются вручную и проходят полный цикл ревью и тестирования.
Такая сегментация превращает AI‑ассистента из «универсального генератора всего» в контролируемый инструмент для понятных задач, что снижает риск появления критичных ошибок в ядре системы.
2. Помечать AI‑изменения и сохранять контекст
- Ввести простое правило: каждый PR, где активно использовался ассистент, помечается тегом или типовым блоком в описании.
- Для ключевых задач фиксировать краткий фрагмент промпта/ответа, который привёл к решению — это существенно ускоряет расследование инцидентов и дебаг сложных регрессий.
Инструменты уровня Veai могут помогать здесь как слой прозрачности: сохранять историю запросов и AI‑изменений с привязкой к коммитам и PR, чтобы всегда было видно, где и как был задействован ассистент.
3. Усилить ревью для критичных участков, а не по всему коду
- Вместо попытки контролировать все AI‑фрагменты одинаково жёстко, выделить 10–20% зон повышенного внимания: финансовые модули, авторизация, интеграции с внешними системами.
- Для них завести короткий чек‑лист ревью: проверка инвариантов, крайних кейсов, модели злоумышленника, наличия негативных тестов.
Здесь полезен подход, когда инструмент не заменяет ревью, а напоминает ревьюеру о нужных вопросах, подсовывая связанный чек‑лист для конкретного типа изменения.
4. Сместить обучение с «как промптить» на «как проверять»
- Обучающие сессии по AI‑ассистентам должны включать не только «технику промптов», но и практику критического анализа ответов.
- Хороший формат — внутренние «разборы полётов»: взять AI‑сгенерированный код, прогнать через SAST и тесты, показать, где именно ассистент допустил ошибки и почему они неочевидны на первый взгляд.
Такие упражнения формируют у разработчиков привычку воспринимать AI‑ответ как предложение, а не истину, и развивают мышление «security by design».
5. Управлять, а не игнорировать
- Если в команде уже используют разные ассистенты и расширения, их лучше не запрещать «разом», а провести инвентаризацию и выделить минимальный набор одобренных инструментов.
- Для этого набора настроить понятные правила: где хранятся логи, какие разрешения выдаются, как обновляются версии и кто отвечает за мониторинг инцидентов.
Такой подход снижает вероятность того, что в цепочку разработки незаметно попадут уязвимые или вредоносные AI‑тулы, и делает использование ИИ частью управляемого процесса, а не личных экспериментов отдельных разработчиков.
AI‑ассистенты останутся с нами надолго: они реально ускоряют разработку и снимают часть операционной нагрузки. Но кейсы вроде Moonwell и первые публичные эксплойты AI‑инструментов показывают, что без явной дисциплины вокруг AI‑кодинга мы не просто ускоряем разработку — мы ускоряем путь к следующему инциденту.
Безопасный AI‑кодинг — это не один «правильный ассистент», а сочетание управляемых инструментов, осознанных процессов и команды, которая умеет смотреть на AI‑код так же критично, как на любой другой.