Об авторе: Антон Михайлов, директор по развитию группы продуктов SASTAV (ShiftLeft Security), участник АРПП «Отечественный софт»
ИИ не сделал разработчиков хуже. Но он сделал производство кода, в том числе плохого, очень дешёвым. «Узким местом» становится способность команды понимать, проверять и принимать ответственность за сгенерированное изменение. Для бизнеса это важнее споров о доле «кода от ИИ» в общем объёме разработки.
Вайбкодинг начинается, когда решение об изменении кода принимают, не до конца понимая, как работает приложение. Иногда владелец изменения даже не может объяснить его логику, зависимости и последствия. И в этом отличие вайбкодинга от разработки с ИИ-ассистентом, когда инженер ускоряет рутину, но при этом контролирует архитектуру и отвечает за результат.
Получается, что проблема снижения качества кода кроется не в инструменте ИИ, а в отсутствии прозрачности происхождения кода. Ведь источник кода – это не только автор, чьё имя указано в GitHub. Важно, какие требования и гипотезы легли в основу решения, какие данные видел AI-ассистент, и кто проверил результат. Иначе на свет появляется код без полноценного владельца.
Старые дефекты на новой скорости
Риски появления ошибок в коде существовали и раньше: небезопасные настройки, устаревшие зависимости, секреты в репозитории, ошибки валидации и доступа. Изменились скорость и масштаб. Теперь модель может тиражировать дефект на несколько приложений, а разработчик – принять большой объём правок, не заметив общего неверного допущения.
Типовой пример: ИИ-агенту поручают добавить в приложение возможность скачивания документа по идентификатору. Агент проверяет, что пользователь вошёл в систему, но не контролирует, что документ принадлежит его организации. Функция работает, тест проходит успешно, код выглядит аккуратно, однако пользователь получает документ от другой организации. Это не синтаксическая ошибка, а разрыв между бизнес-правилом и контролем доступа.
Другой сценарий: ИИ-агент устанавливает пакеты, меняет сборку и выполняет команды с правами разработчика. Тут ошибка затрагивает рабочую среду. Это критическая ситуация, которая напрямую влияет на пользователей и бизнес.
Конечно, запрет публичных моделей может снизить риск передачи кода внешнему провайдеру, но он не решает задачу целиком. Ведь пользователи корпоративной модели тоже могут ошибиться в авторизации, выбрать уязвимую зависимость или изменить лишний файл.
Почему привычных проверок недостаточно
В современной разработке традиционное ревью кода остаётся обязательным этапом. Однако оно не ускоряется вместе с генерацией. Большие правдоподобные изменения утомляют рецензента, а тесты нередко пишет та же модель. Успешная сборка и прохождение функциональных тестов еще не подтверждают, что нужный сценарий работает.
Хорошо ищет известные опасные конструкции и потоки данных один из элементов DevSecOps-подхода — статический анализатор кода (SAST). Динамический анализ (DAST) проверяет безопасность работающего приложения. Композиционный анализ (SCA) контролирует компоненты open-source, другие инструменты — секреты и инфраструктурный код. Но этот набор не «знает», что сотрудник может согласовать платёж только своей организации. Для этого нужен контекст ролей, данных и сценариев, а также смысловой анализ. Появляется «работа» для дополнительного семантического слоя – инструментов класса AI-SAST. При наличии необходимого контекста он может сопоставить реализацию со сценарием, проследить проверки доступа между файлами и выдвинуть гипотезу о нарушении бизнес-логики. Но AI-SAST не заменяет базовый инструментарий AppSec — SAST, SCA, DAST, моделирование угроз, негативные тесты, ограничения прав агента и человеческого владельца изменения.
Как выглядит зрелый контур
Руководствуясь опытом построения крупного конвейера безопасной разработки, можно выделить четыре уровня зрелого контура.
- Правила использования. Описываются допустимые модели и проекты, запрещённые для передачи данные, инструменты ИИ-агента и минимальные права. В критичных контурах агент не должен сам включать изменения в основную ветку, получать доступ к секретам промышленной среды или развёртывать релиз.
- Постановка задачи. Вместе с функциональным требованием фиксируются роли, защищаемые данные, негативные сценарии и ограничения. Модель не «угадает» правило, которого нет даже в документации продукта.
- Проверки в конвейере. Вносятся небольшие изменения, определяется человек – владелец, применяются инструменты SAST и SCA, выполняются поиск секретов, анализ инфраструктурного кода, негативные тесты авторизации и контекстный анализ. Глубина проверок зависит не от участия в разработке ИИ, а от критичности функции. Аутентификация, платежи и управление объектом критической информационной инфраструктуры (КИИ) требуют независимой проверки при любом авторе.
- Доказуемость. Прослеживается связь между требованием, изменением, проверками, исключениями и версией в релизе. Полезно фиксировать ИИ-инструмент и его действия, но маркировка каждой «строки от ИИ» не заменяет владельца продукта и воспроизводимую сборку.
Ответственность и выгода
Определим ответственность по ролям. Разработчик отвечает за принятое изменение («так написала модель» – не аргумент). Функция AppSec задаёт правила, настраивает качество сигнала и помогает оценивать риск. Владелец продукта формулирует правила доступа и допустимое поведение, потому что бизнес-логику нельзя восстановить по одному коду. И, наконец, бизнес определяет критичность, принимает остаточный риск и финансирует внедрение соразмерного контроля.
Для большинства компаний такой контур – вопрос инженерной зрелости и экономики. Для организаций, которые создают и развивают государственные информационные системы, та же логика закрепляется и в обязательных требованиях. Приказ ФСТЭК №117 не регулирует вайбкодинг как отдельную практику, но в пределах своего контура требует управляемого процесса безопасной разработки. Если система одновременно является значимым объектом КИИ, учитываются оба набора требований. Важен общий вектор: при самостоятельной разработке ПО оператор должен реализовать меры разделов 4 и 5 ГОСТ Р 56939-2024. И это действительно тектонический сдвиг от защиты уже готовой системы к управляемому и доказуемому процессу её создания.
Экономический эффект такого подхода очевиден. Ошибки в коде обнаруживаются, пока команда помнит изменение. Релизы реже останавливаются на финальном контроле, а затраты на возврат к закрытой задаче, аварийное исправление и разбор инцидента снижаются. В свою очередь, руководство может сравнивать продукты и подрядчиков, а доказательства для приёмки формируются в обычном процессе.
Резюме. Признаком зрелой разработки в организации является не количество строк от ИИ, а способность оперативно проверить, есть ли у изменения в приложении цель, владелец, контролируемый путь в инфраструктуру и доказательства безопасности. Вайбкодинг при этом вполне может использоваться как способ быстрого исследования решения. Однако в промышленной разработке этому подходу предстоит столкнуться с суровой реальностью классической программной инженерии. Пусть что скорость создания кода растёт, но требования к его качеству, безопасности и поддержке остаются прежними.
