Сегодня за утренним кофе прочитал статью “70% разработчиков считают ИИ-код дырявым, при этом 30% всех опрошенных деплоят его в прод”.

Кажется, это ещё одна из статей, написанных с помощью ИИ про ИИ, которые всё заполонили. Поэтому рекомендовать её к прочтению не стану. Да и приведённым там числам я что-то не очень верю.

Позабавило: “C-код оказался самым дырявым”. Да, C такой :) Надо иметь прямые руки, чтобы им пользоваться — плата за скорость и экономный расход памяти.

Краткая суть статьи: постепенно начинает выясняться, что с генеративным ИИ (GenAI) не всё так волшебно. Сгенерированный код оказывается не таким уж качественным и безопасным. Дополнительная проблематика заключается в том, что вместо ужесточения контроля он, наоборот, снижается: кто-то из вайб-кодеров некомпетентен, чтобы проводить обзоры кода и грамотно выстраивать процессы разработки; кто-то может, но не чувствует свою ответственность за сгенерированный код (тем более его слишком много в силу простоты создания).

Внезапного для меня в этом нет. Я уже писал, что ожидания завышены, а к сгенерированному коду есть избыточное доверие (как и к текстам в целом).

Кстати, скоро эту тематику мы затронем в вебинаре “Что скрывает код: от поверхности атаки до производительности” в новом цикле “Качество и безопасность ПО в эпоху GenAI”. Приглашаю зарегистрироваться: 24.06.2026 в 15:00 по МСК, онлайн.

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

Эээ... Так ничего не изменилось. Проблема качества кода и проектов была всегда. Уже известно всё, что надо делать. Проблематика не стоит выеденного яйца.

Нужно выстраивать процессы разработки так, как это делалось до GenAI. Если же нет сил на выстраивание процессов или команда считает, что уровень качество приемлем (“и так сойдёт” (C)), то GenAI тут ни при чём.

Берём ГОСТ Р 56939—2024 по разработке безопасного программного обеспечения. Забываем само слово ГОСТ, вычеркиваем слово безопасность. Перед нами чек-лист полезных практик, внедрение которых даст приемлемый уровень качества проекта.

Что там у нас? Обучение сотрудников. Если хотите, чтобы вайб-кодеры умели не только наваливать код, но и уметь проводить его аудит, задумайтесь о том, как они будут расти. Кстати, вот недавно статья на эту тему была: “Поколение “Approve”: почему я заставил команду переписать проект, который уже работал”.

Необходимо сформировать требования к программному обеспечению. Если нет требований, то не стоит удивляться, что в итоге получилось что-то не то. GenAI позволяет быстрее приступить к делу и быстрее сесть в калошу, например, из-за того, что выбранное архитектурное решение не масштабируется.

Всегда был нужен процесс композиционного анализа. С GenAI это лишь заиграло новыми красками в связи с атаками, построенными на галлюцинациях в названиях пакетов. Про это хорошо рассказывают специалисты компании CodeScoring в докладах и статьях:

Галлюцинации систем ИИ (slopsquatting). Сегодня многие разработчики используют ИИ-агентов в IDE. Например, просят подсказать библиотеку или показать пример кода. Но LLM “галлюцинируют” и рекомендуют несуществующие библиотеки в 20% случаях, либо воспроизводят ряд вышеописанных рисков, в основе которых лежит мимикрия проблемных решений под легитимные. Этим пользуются злоумышленники: они создают вредоносный пакет и ожидают, что кто-то установит его, доверившись исключительно подсказке модели. Ситуацию усугубляет тот факт, что галлюцинации являются воспроизводимыми, что облегчает процесс наименования вредоносных компонентов для злоумышленников.

И так далее. Хотим качества и надёжности — просто берём и делаем :)

Для тех, кто хочет познакомиться с построением процессов разработки качественного надёжного ПО, предлагаю эту подборку материалов: Разработка безопасного программного обеспечения (РБПО) по ГОСТ Р 56939—2024.

Аллергия на слово “ГОСТ”? Хорошо, есть “AppSec Table Top: методология безопасной разработки от Positive Technologies”.