Сегодня за утренним кофе наткнулся на статью «70% разработчиков считают ИИ-код дырявым, при этом 30% всех опрошенных деплоят его в прод».
Похоже, это очередной материал, написанный с помощью ИИ про ИИ, которых сейчас повсюду полно. Поэтому советовать его к прочтению не буду. Да и цифрам, которые там приводятся, я как-то не особо доверяю.
Позабавило: «C-код оказался самым дырявым». Да, C такой :) Нужны прямые руки, чтобы с ним работать — это плата за скорость и экономию памяти.
Краткая суть статьи: постепенно становится ясно, что с генеративным ИИ (GenAI) не всё так радужно. Сгенерированный код оказывается не таким качественным и безопасным. Дополнительная сложность в том, что контроль не ужесточается, а наоборот, ослабевает: кто-то из вайб-кодеров недостаточно компетентен для ревью кода и грамотного выстраивания процессов разработки; кто-то может это делать, но не чувствует ответственности за сгенерированный код (тем более его слишком много из-за простоты создания).
Ничего неожиданного для меня в этом нет. Я уже писал, что ожидания завышены, а к сгенерированному коду проявляется избыточное доверие (как и к текстам в целом).
Кстати, скоро эту тему мы затронем на вебинаре «Что скрывает код: от поверхности атаки до производительности» в новом цикле «Качество и безопасность ПО в эпоху GenAI». Приглашаю зарегистрироваться: 24.06.2026 в 15:00 по МСК, онлайн.
Неожиданно другое: проблему некачественного и ненадёжного ИИ-кода начинают обсуждать как нечто новое. Уже встречал размышления о том, как теперь строить процессы разработки, чтобы достичь нужного качества.
Эээ... Так ничего не изменилось. Проблема качества кода и проектов существовала всегда. Всё, что нужно делать, уже известно. Эта проблематика — не стоит выеденного яйца.
Нужно выстраивать процессы разработки так, как это делалось до GenAI. Если нет сил на выстраивание процессов или команда считает, что уровень качества приемлем («и так сойдёт» (C)), то GenAI тут ни при чём.
Берём ГОСТ Р 56939—2024 по разработке безопасного программного обеспечения. Забываем само слово ГОСТ, вычёркиваем слово безопасность. Перед нами чек-лист полезных практик, внедрение которых даст приемлемый уровень качества проекта.
Что там у нас? Обучение сотрудников. Если хотите, чтобы вайб-кодеры умели не только наваливать код, но и проводить его аудит, задумайтесь о том, как они будут расти. Кстати, недавно была статья на эту тему: «Поколение “Approve”: почему я заставил команду переписать проект, который уже работал».
Необходимо сформировать требования к программному обеспечению. Если требований нет, то не стоит удивляться, что в итоге получилось что-то не то. GenAI позволяет быстрее приступить к делу и быстрее сесть в лужу, например, из-за того, что выбранное архитектурное решение не масштабируется.
Всегда был нужен процесс композиционного анализа. С GenAI это лишь заиграло новыми красками в связи с атаками, построенными на галлюцинациях в названиях пакетов. Об этом хорошо рассказывают специалисты компании CodeScoring в докладах и статьях:
Галлюцинации систем ИИ (slopsquatting). Сегодня многие разработчики используют ИИ-агентов в IDE. Например, просят подсказать библиотеку или показать пример кода. Но LLM «галлюцинируют» и рекомендуют несуществующие библиотеки в 20% случаев, либо воспроизводят ряд вышеописанных рисков, в основе которых лежит мимикрия проблемных решений под легитимные. Этим пользуются злоумышленники: они создают вредоносный пакет и ожидают, что кто-то установит его, доверившись исключительно подсказке модели. Ситуацию усугубляет тот факт, что галлюцинации являются воспроизводимыми, что облегчает процесс наименования вредоносных компонентов для злоумышленников.
Галлюцинации систем ИИ (slopsquatting). Сегодня многие разработчики используют ИИ-агентов в IDE. Например, просят подсказать библиотеку или показать пример кода. Но LLM «галлюцинируют» и рекомендуют несуществующие библиотеки в 20% случаев, либо воспроизводят ряд вышеописанных рисков, в основе которых лежит мимикрия проблемных решений под легитимные. Этим пользуются злоумышленники: они создают вредоносный пакет и ожидают, что кто-то установит его, доверившись исключительно подсказке модели. Ситуацию усугубляет тот факт, что галлюцинации являются воспроизводимыми, что облегчает процесс наименования вредоносных компонентов для злоумышленников.
И так далее. Хотим качества и надёжности — просто берём и делаем :)
Для тех, кто хочет познакомиться с построением процессов разработки качественного надёжного ПО, предлагаю эту подборку материалов: Разработка безопасного программного обеспечения (РБПО) по ГОСТ Р 56939—2024.
Аллергия на слово «ГОСТ»? Хорошо, есть «AppSec Table Top: методология безопасной разработки от Positive Technologies».