Безопасный вайбкодинг: от автопилота к пилоту
Почему AI-агенты, пишущие код, требуют тех же принципов безопасности, что и автопилоты в авиации. И почему «вайблёрнинг» – это не опция, а необходимость.
Александр Серов
Начальник отдела безопасности технологий искусственного интеллекта, Департамент кибербезопасности
Почему AI-агенты, пишущие код, требуют тех же принципов безопасности, что и автопилоты в авиации. И почему «вайблёрнинг» – это не опция, а необходимость.
Представьте, что вы руководитель разработки в финтехе. Ваша команда внедряет систему противодействия отмыванию денег FinCrime. Требования жёсткие: каждая транзакция проходит через цепочку правил, доля ложных срабатываний должна быть ниже 2%, а пропуск подозрительной транзакции это штраф регулятора и уголовное дело.
Сценарий дальше собирательный, не история конкретного банка и не про нас. Но паттерн воспроизводится везде, где код генерируется быстрее, чем его успевают осмыслить.
Разработчик использует AI-агент для генерации модуля скоринга. Агент пишет 400 строк кода за 15 минут. Код выглядит правильно. Тесты проходят. Разработчик не вникает в логику. Через три месяца аудит обнаруживает, что модуль скоринга содержит состояние гонки при параллельной обработке транзакций. При высокой нагрузке две транзакции от одного клиента обрабатываются одновременно, и вторая не видит результат первой. Суммарный оборот клиента занижается. Подозрительные паттерны не детектируются.
Что пошло не так? Агент написал код, который выглядел правильным. Но никто не понял этот код: разработчик не разобрался в модели параллелизма, ревью провёл другой агент с теми же слепыми зонами. CI проверил синтаксис и покрытие, но не бизнес-логику. А тестировщики и безопасники? Классический QA ловит то, что ловил всегда: синтаксис, покрытие, регрессии на happy-path. Race condition под нагрузкой не виден unit-тестами, его ловит либо специальный concurrent-сценарий, либо инженер, который понимает модель параллелизма и видит дефект при ревью. Раньше это закрывалось побочно: автор кода вынужден был держать модель выполнения в голове. Агент этот побочный продукт не производит.
Этот паттерн повторяется каждый раз, когда скорость генерации кода обгоняет скорость понимания.
Kaggle и иллюзия продуктивности
Другой пример – из мира ML-соревнований. На Kaggle появились «агентные» подходы к решению задач: участник запускает Claude или GPT в цикле, агент генерирует модели, обучает, отправляет решение, анализирует таблицу лидеров, генерирует следующую итерацию.
Проект KaggleClaw показал характерный паттерн: агент, оставленный без контроля, совершает бесполезные повторные циклы. Он не строит архитектуру решения – он перебирает вариации. Увеличить скорость обучения. Уменьшить скорость обучения. Добавить слой. Убрать слой. Каждая итерация потребляет вычислительные ресурсы, но не приближает к пониманию задачи.
Участник, который не вникает в данные и не строит ментальную модель задачи, проигрывает участнику, который потратил время на разведочный анализ данных вручную и понял структуру, и только потом подключил агента для ускорения проверенных гипотез.
Паттерн один и тот же: агент ускоряет выполнение, но не заменяет понимание. Без понимания скорость превращается в дорогостоящее блуждание.
Сформулируем проблему
Вайбкодинг — парадигма разработки, при которой AI-агент пишет код по описанию на естественном языке: разработчик формулирует намерение, а агент реализует.
Но возникает фундаментальный риск: чем больше кода пишет агент, тем меньше разработчик понимает кодовую базу. Возникает разрыв между ответственностью (человек отвечает за production) и компетенцией (агент писал код, человек его не понимает).
Например, в ходе усиления безопасности пет-проекта (FastAPI + React + Kubernetes) мы наблюдали этот разрыв в действии:
• AI‑агент добавил 21 задачу в CI/CD‑пайплайн, но 8 из них оказались бесполезными — они лишь создавали видимость усиленной безопасности, не принося реальной пользы.
• Агент трижды сломал CI нерабочими командами, каждый раз будучи уверенным в корректности.
• Но ни разу не сказал «я не уверен» – даже когда использовал несуществующий API.
• Пять параллельных агентов-ревьюеров не поймали ошибки друг друга, потому что у них слепые зоны одинаковы.
Это не проблема конкретного агента, а системная проблема парадигмы. «Вайбкодинг» превращает разработчика из архитектора в оператора, который вынужден верить на слово системе, превосходящей его в скорости, но уступающей в осознанности.
Может показаться, что перед нами новая нерешаемая проблема. Но…
Авиация уже решала эту задачу
Авиационная индустрия потратила 40 лет на решение точно такой же проблемы: как внедрить автоматизацию, не потеряв навыки операторов и не создав новые категории катастроф?
Ответы, найденные ценой человеческих жизней, напрямую применимы к вайбкодингу.
Потеря навыков при автоматизации
3 июня 2009 года. Рейс Air France 447, Airbus A330, Атлантический океан. Самолёт входит в зону турбулентности. Трубки Пито (датчики скорости) обледеневают и дают противоречивые показания. Автопилот отключается — он не может работать без достоверных данных о скорости.
Пилоты растеряны. Они привыкли, что автопилот ведёт самолёт. За три с половиной минуты они не смогли диагностировать ситуацию и самолёт упал в океан. 228 человек погибли.
Расследование BEA установило: пилоты утратили навыки ручного пилотирования из-за чрезмерной зависимости от автоматизации. Они не практиковали ручной полёт, потому что автопилот «и так справлялся».
В вайбкодинге это выглядит аналогично: разработчик привыкает, что агент пишет код, а когда в production возникает баг, который агент не может диагностировать (так как не помнит контекст предыдущих сессий), то разработчик не может найти проблему, потому что никогда и не понимал этот код…
После катастрофы AF447 авиакомпании ввели обязательные ручные полёты («hand-flying»). Это регулярные полеты, во время которых пилот самостоятельно контролирует траекторию полета, скорость и положение самолета в пространстве с помощью штурвала, педалей и рычагов без автопилота, чтобы не терять навыки.
Для вайбкодинга ручные полёты — это вайблёрнинг: регулярное чтение и понимание кода, сгенерированного агентом. Не для поиска багов, а для поддержания компетенции.
Как экипаж научился говорить о проблемах
28 декабря 1978 года. Рейс United Airlines 173, DC-8, Портленд. У самолёта не выпускается шасси. Капитан зацикливается на этой проблеме, игнорируя показания топлива. Бортинженер дважды говорит «у нас заканчивается топливо» – капитан не реагирует. Самолёт падает в 10 км от аэропорта. Погибли 10 человек. Топливо закончилось.
После этой катастрофы NASA разработала CRM (Crew Resource Management) – методологию взаимодействия экипажа, при которой любой член обязан озвучивать сомнения, а командир обязан их слышать.
В вайбкодинге агент никогда не скажет «я не уверен», ведь у него нет сомнений — он всегда выдаёт ответ с одинаковой уверенностью, будь это проверенный паттерн или галлюцинация. Роль бортинженера, который сигнализирует о проблеме, должен брать на себя человек или автоматизированные проверки в CI.
Защитные ограничения и CI/CD
Современные самолёты Airbus (A320 и новее) имеют систему защиты режима полёта – она не позволяет пилоту выйти за безопасные параметры. Даже если пилот полностью берёт управление на себя – самолёт не позволит превысить критический угол атаки.
В вайбкодинге CI/CD-пайплайн — это такая же система ограничений для кода.
Уровни 1–5 ловят технические ошибки. Уровень 0 – единственный, который ловит логические и бизнес-ошибки. Без уровня 0 все остальные уровни — это автопилот без пилота.
Режим концентрации при опасных изменениях
В авиации существует правило «стерильной кабины» (FAR 121.542): ниже 10 000 футов запрещены любые разговоры и действия, не относящиеся к полёту. Взлёт и посадка — самые опасные фазы.
При изменениях, затрагивающих безопасность (аутентификация, валидация ввода, криптография, работа с секретами, инфраструктура), нужна такая же концентрация:
• Никаких «быстро добавим и потом разберёмся».
• Каждое изменение безопасности проходит полный цикл: реализация – локальное тестирование – ревью – проверка.
• Агент объясняет каждое решение, разработчик подтверждает понимание.
Чеклист перед коммитом
Предполётный чек-лист — обязательная процедура. И даже пилот с 30 000 часами налёта не пропускает чек-лист. Но не потому что не помнит, а потому, что человеческая память ненадёжна, а цена ошибки слишком высока.
В вайбкодинге перед каждым коммитом нужен такой же обязательный цикл:
Блокирующие проверки в CI
В авиации существует TCAS (Traffic Collision Avoidance System) — система предупреждения столкновений. Это «последний рубеж» защиты в авиации. Если диспетчеры на земле и пилоты в небе что-то упустили и два самолета сближаются, именно эта система предотвращает катастрофу — даёт команду «набирай высоту» или «снижайся». Пилот обязан подчиниться, даже если диспетчер говорит иное. TCAS имеет абсолютный приоритет.
Если пилот не слушает TCAS, то случаются катастрофы. 1 июля 2002 года над Юберлингеном столкнулись Boeing 757 и Ту-154. TCAS дал Boeing команду снижаться, а Ту-154 набирать высоту. Но диспетчер, не знавший, какие указания выдал TCAS, велел Ту-154 снижаться. Пилот послушал диспетчера вместо системы. Оба самолёта пошли вниз и столкнулись. 71 человек погиб.
Проверки безопасности в CI работают по тому же принципу:
Если задача в CI не блокирует деплой — она бесполезна. Как система предупреждения, которая «рекомендует, но не настаивает».
Git как бортовой самописец
Чёрные ящики записывают каждое действие пилота, каждый параметр полёта, каждое слово в кабине, а после инцидента проводится полная реконструкция событий для выявления причин аварии.
В вайбкодинге git-история и логи CI — это такие же чёрные ящики. Сообщения к коммитам должны фиксировать не только «что изменилось», но «почему» и «какие альтернативы были отвергнуты». Модель угроз — это задокументированные решения о принятых рисках.
Регулярные тренировки без автопилота
Пилоты проходят тренировки каждые шесть месяцев – включая отработку аварийных ситуаций в симуляторе. Даже если за 20 лет ни разу не было отказа двигателя – пилот регулярно тренируется на этот сценарий.
Вайблёрнинг — это такие же регулярные тренировки для разработчика:
Вайблёрнинг: определение
Вайблёрнинг — парадигма, при которой процесс разработки с AI-агентом одновременно является процессом обучения разработчика. Агент не просто делает — он объясняет. Разработчик не просто принимает — он понимает.
Как это выглядит на практике
Без вайблёрнинга:
С вайблёрнингом:
Разница: во втором случае разработчик узнал про проблему обратного прокси. В следующем проекте он спросит про это сам, даже без агента.
Ошибки агента — это учебный материал
Когда агент ломает CI нерабочей командой, то это не провал, а урок:
За одну сессию разработки проекта, который упоминался ранее, мы зафиксировали 8 таких ошибок. Каждая – урок, каждая – правило в чеклисте.
Модель зрелости
Уровень 0: Слепой вайбкодинг
Агент пишет, разработчик принимает, деплой. Максимальный риск. Как автопилот без пилота.
Уровень 1: Вайбкодинг с проверками CI
Агент пишет, CI проверяет, деплой при зелёных проверках. Технические ошибки ловятся. Логические – нет.
Уровень 2: Вайбкодинг с ревью
Агент пишет и объясняет, агент-ревьюер проверяет, разработчик подтверждает. Лучше, но агент-ревьюер – это эхо-камера с теми же слепыми зонами.
Уровень 3: Вайблёрнинг
Агент пишет, объясняет, учит; CI-проверки; человеческое ревью; разработчик может объяснить каждую строку. Минимальный риск. Разработчик растёт в компетенции.
Заключение
Дискуссия об AI в разработке часто сводится к двум полюсам: «AI заменит разработчиков» или «AI бесполезен». Оба ошибочны.
Авиация нашла ответ 40 лет назад: автопилот не заменяет пилота и не бесполезен. Автопилот усиливает пилота: берёт рутину, снижает нагрузку, повышает точность. Но пилот остаётся: он понимает систему, следит за автопилотом, принимает решения и готов взять управление.
Вайбкодинг — это автопилот для разработки. Он мощный, полезный, но опасный без пилота.
Вайблёрнинг — это методология, при которой пилот не теряет навыки из-за автопилота, а наоборот — наращивает их. Агент объясняет, разработчик учится. Ошибки агента становятся учебным материалом. Чеклисты превращают хаос в процесс. Проверки безопасности не позволяют ошибкам дойти до production.
Формула:
Цель – не отказ от агентов и не слепая вера в них. Цель – процесс, при котором каждый участник (человек, агент, CI) делает то, что умеет лучше всего. Как в хорошем авиационном экипаже: пилот и автопилот работают вместе, каждый усиливая другого.
Посты кончились :(Вернитесь позже, мы обязательно выпустим новые
