Назад в блогОпубликовано 2026-08-21

Вайб-кодинг и AI-DLC: где на самом деле проходит граница

Оба режима сегодня дают работающий продукт быстро, и разница между ними не в дисциплине и не в качестве кода. Разбираем, где живёт истина о системе в каждом из подходов и какие механизмы отличают машинно проверяемую разработку от проверяемой на глаз.

Авторы: slavb18

Вайб-кодинг за два года прошёл путь от мема до рабочего инструмента. Продукт, который раньше требовал команды и квартала, собирается за несколько вечеров одним человеком, и он действительно работает. Параллельно индустрия придумала на это ответ — Spec-Driven Development, Intent-Driven, AI-DLC — и объясняет, что так делать нельзя, надо иначе.

Когда спрашиваешь, в чём конкретно разница, обычно отвечают: в дисциплине. Сначала спецификация, потом код. Ревью внимательнее. Тесты обязательны.

Ответ неверный. Не потому что дисциплина не нужна, а потому что дисциплина — следствие, и на неё смотреть бесполезно. Настоящая граница проходит в другом месте, и увидеть её проще всего через один вопрос: где после работы остаётся истина о системе.

Вайб-кодинг: истина в работающем артефакте

Слово стало ругательным зря. Вайб-кодинг — режим со своими правилами, и правила эти внутренне непротиворечивы.

Единственный источник истины здесь — работающий продукт. Вы описали намерение, агент сгенерировал реализацию, вы запустили и посмотрели. Совпало с ожиданием — приняли, не совпало — переформулировали. Знание о том, почему система устроена именно так, живёт в двух местах: в голове автора и в контексте сессии.

Пока продукт делает один человек и он же принимает решения, это оптимально. Обмен «намерение → проверка» идёт с максимальной скоростью, потому что между ними нет ни одного промежуточного документа. Демо за вечер даёт именно этот режим, и никакой другой.

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

Пока проверяющий один и это вы — вопрос не возникает: вы и так знаете. Как только появляется второй — соавтор, аудитор, разработчик, который придёт через полгода, вы сами через три месяца — спрашивать становится некого. Ответ был в сессии, сессия закончилась.

AI-DLC: агент как штатный участник цикла

AI-DLC (AI-Driven Development Lifecycle) описывает жизненный цикл, в котором ИИ-агент перестаёт быть ускорителем набора текста и становится штатным участником процесса. Он предлагает план, реализацию, тесты, конфигурацию инфраструктуры. Человек проверяет и утверждает предложенное до того, как оно исполнено. Единица работы при этом сжимается с недель до часов — цикл «предложение → проверка → исполнение» стал коротким, и держать вокруг него двухнедельный ритуал больше незачем.

Разработчик в такой схеме перестаёт быть автором текста программы. Он становится тем, кто принимает решения о предложенном.

Существенное в этом описании — не переименование спринтов и не требование писать больше документации. Существенное вот что: между намерением и исполнением на каждом шаге появляется объект, который кто-то утверждает. План. Критерий. Гейт. И существует этот объект отдельно от кода и отдельно от автора.

Вот это и есть механизм. Всё остальное — его последствия.

Конкретные реализации расходятся в деталях: как называть фазы, чем мерить единицу работы, что именно человек утверждает и в какой момент. Готовой схемы, которую снимают с полки и применяют, здесь нет — есть принцип, и каждая команда собирает под него свой конвейер. Поэтому дальше разговор не про инструменты, а про механизмы, которые из этого принципа вырастают в любой реализации.

Граница: побочные продукты, которые переживают сессию

В AI-DLC каждый шаг цикла оставляет после себя артефакт, существующий отдельно от кода и отдельно от автора. План, который утвердили. Критерий приёмки, который либо доказан прогоном, либо явно не доказан. Гейт в конвейере, который либо пропустил сборку, либо остановил её.

Каждый из них проверяется машиной без участия того, кто его создал. Именно это свойство — проверяемость третьим лицом — отличает один режим от другого. Не количество документов и не строгость процесса.

	Вайб-кодинг	AI-DLC
Источник истины	работающее приложение	приложение плюс цепочка утверждённых артефактов
Где живёт «почему так»	в голове автора и в контексте сессии	в объектах, которые сессию переживают
Кто может проверить	автор, запустив и посмотрев	кто угодно, в том числе машина
Что остаётся через полгода	код и коммиты	код, требования, доказательства, история решений
Стоимость первого шага	минимальная	заметная: инфраструктуру доказательств надо построить
Скорость проверки гипотезы	максимальная	ниже
Скорость передачи другому	около нуля	штатная операция

Обе колонки — рабочие режимы. Ошибка не в том, чтобы выбрать вайб-кодинг, а в том, чтобы остаться в нём после того, как условия изменились.

Четыре механизма, в которые это превращается

Принцип «артефакты, проверяемые машиной» ничего не значит, пока не увидишь его в конкретных вещах. Механизмов, которые из него вырастают, немного — по сути четыре. Ниже каждый с примером и живыми цифрами, чтобы разговор не остался на уровне лозунга.

Требование → критерий приёмки → тест → отметка, которую ставит прогон

Самый редкий механизм и самый содержательный.

Требования раскладываются на атомарные критерии с идентификаторами. Каждый критерий живёт в описании своего функционального модуля. Тест, который его доказывает, называет этот идентификатор. Отчёт о покрытии после этого генерируется командой, а не пишется руками, и выглядит так:

Модуль	Покрыто	%
Права доступа — матрица роль×право	10/10	100%
Сервисные учётные записи и ротация секрета	30/30	100%
Шлюз — доступ к API и квоты	31/32	97%
Кабинет пользователя — интерактивный вызов	13/17	76%
Распределённая трассировка	0/11	0%
Политика аккаунта: пароли, 2FA, лок-аут	0/14	0%
Итого	314/422	74%

Строки с нулями — самое ценное, что есть в этом отчёте.

Они видны, потому что отчёт машинный. Поставить галочку из добрых побуждений невозможно: отметку ставит прогон. Система, устроенная так, знает про себя правду и не умеет её приукрашивать — и это работает не только на внешнего проверяющего, но и на команду, которая перестаёт спорить о том, сделано или нет.

Архитектурные границы как правила линтера

Договорённости об архитектуре, живущие в головах и в ревью, деградируют за квартал: каждое отдельное отступление выглядит оправданным, а сумма отступлений через полгода называется «исторически сложилось». Лечится это тем, что граница становится исполняемой — её нарушение валит сборку. Набор зависит от стека; смысл правил один и тот же:

модуль не лезет во внутренности соседнего;
доменный слой чист от ввода-вывода;
обращение к базе живёт только в слое персистентности, а не там, где оказалось удобно;
фичи не вкладываются друг в друга.

Несколько строк в конфигурации линтера делают то, чего не делает ни один регламент: превращают архитектурное решение в факт, который нельзя нарушить незаметно. Регламент можно не прочитать, договорённость — забыть; красную сборку не обойдёшь.

Проверки безопасности с объявленной политикой гейтинга

Слой	Инструмент	Гейт
Секреты	gitleaks по всей истории репозитория	жёсткий: любая находка валит сборку
Зависимости	`bun audit` + Dependabot	жёсткий: high/critical валит сборку
Статический анализ	CodeQL `security-extended` — по коду и по самим workflow CI	отчёт
Статический анализ	Semgrep: OWASP Top-10, TypeScript, React	отчёт, затем перевод в блокирующий
Инфраструктура как код	Trivy по Terraform, Dockerfile, compose	отчёт
Работающее приложение	OWASP ZAP baseline — поднимает полный стек и сканирует живьём	еженедельно и по кнопке

Две детали, которые обычно пропускают.

CodeQL сканирует сами пайплайны CI (language: actions), а не только прикладной код. Компрометация workflow даёт атакующему больше, чем уязвимость в приложении, и защищать цепочку сборки нужно тем же инструментом.

Политика «трещотки» объявлена письменно. Проверки с высоким сигналом и низким шумом — секреты и зависимости — валят сборку сразу. Широкие сканеры, которые шумят всегда, сначала работают в режиме отчёта и собирают базовую линию, а после её разбора переводятся в блокирующие. Написанное решение отличается от ненаписанного тем, что через полгода никто не отключит проверку «на время» и не забудет вернуть обратно.

Метрики процесса, которые выгружаются

DORA-метрики обычно называют по памяти, и это сразу слышно. Их можно достать выгрузкой — данные уже лежат в CI и в истории git.

Для примера — выгрузка по одному живому продукту: GitHub Actions, workflow прод-деплоя, все 336 запусков за 14.12.2025 — 18.08.2026, даты коммитов из истории репозитория.

Показатель	Значение
Частота релизов в прод	11,2 в неделю за последние 30 дней (332 успешных релиза за период)
Время от коммита до прода	медиана 0,7 ч, p85 21,2 ч, p95 90,2 ч; 86 % релизов доезжают быстрее суток
Доля неуспешных выкаток	1,2 % (4 из 336)
Восстановление после сбоя выкатки	медиана 8,3 ч — на выборке из 4 случаев
Размер релиза	медиана 3 коммита

Про методику стоит сказать отдельно, потому что именно в ней прячется вся разница между честной цифрой и красивой.

Время от коммита до прода мы считаем от самого раннего коммита, вошедшего в релиз — от границы с предыдущей успешной выкаткой. Если считать от последнего коммита, получится 0,1 часа. Только это будет длительность пайплайна, а не время доставки изменения. Разница между 0,1 и 0,7 — ровно та величина, на которой ловят отчёт, написанный для впечатления.

Вторая оговорка: выборка по времени восстановления мала — четыре неуспешных выкатки за восемь месяцев. Медиана по четырём случаям статистически слаба. Содержательно она означает другое: неуспешная выкатка не оставляет прод сломанным, предыдущая версия продолжает работать, поэтому починка идёт в рабочем режиме, а не аварийном.

И строго говоря, это метрика доставки, а не инцидентов. Полноценное «время восстановления сервиса» требует журнала инцидентов, и подменять одно другим некорректно.

Где вайб-кодинг честно лучше

Разговор был бы нечестным без обратной стороны.

Непроверенная гипотеза. Пока непонятно, нужен ли продукт вообще, критерии приёмки на него — выброшенные деньги. Половина написанного будет удалена вместе с фичами, которые не подтвердились. Вайб-кодинг здесь строго сильнее.

Инфраструктура доказательств стоит дороже, чем кажется. Реестр критериев, генератор отчёта, гейты, стенд — это недели, которые окупаются на дистанции в месяцы. Ставить их ради двухнедельной работы бессмысленно.

Одиночная разработка без горизонта передачи. Внутренний инструмент, который автор написал себе и будет сопровождать сам, не нуждается в проверяемости третьим лицом: третьего лица нет.

Чужие интеграции цикл не ускоряет. Там, где скорость определяется чужой службой эксплуатации и чужими согласованиями, наведение порядка на своей стороне выигрывает единицы процентов.

Сигналы, что режим пора менять

Переключение обычно происходит поздно — когда уже больно. Ранние признаки выглядят так:

в продукте появилась функция, про которую никто не может сказать, работает ли она сейчас, без ручной проверки;
вы дважды за месяц чинили одно и то же, потому что первая починка не была ничем закреплена;
в команде второй человек, и он задаёт вопросы, ответ на которые есть только у первого;
выкатка делается вручную и её умеет делать один;
на вопрос «что у нас с безопасностью» ответ формулируется словами, а не выводом инструмента;
продукт кому-то передают: заказчику, партнёру, новой команде.

Любой один пункт — повод начать. Три и больше — вы уже платите за отсутствие артефактов, просто не видите строку расхода.

С чего начать, если решили

Ни один из шагов не требует переписывать продукт.

Снимите базовую линию. Собирается ли проект с нуля на чистой машине и за сколько. Сколько тестов и сколько из них нестабильны. Сколько секретов найдёт gitleaks по всей истории. Сколько зависимостей с уязвимостями high и critical. Сколько ручных шагов до прода. Запишите команды, которыми получили каждое число — иначе сравнивать будет не с чем.
Выгрузите свои DORA-метрики. Данные уже есть, их надо только достать.
Возьмите пять главных сценариев и напишите на каждый один проверяемый критерий приёмки. Не сто, а пять. Дальше станет видно, как выглядит сотня.
Проверьте восстановление из резервной копии на практике. Погасите стенд, поднимите из копии, засеките время. Если этого не делал никто, вы не знаете, есть ли у вас бэкап — вы знаете только, что настроено копирование.

Первые три закрываются за день. Четвёртый — за день, если копия рабочая, и обнаруживает интересное, если нет.

Итог

Вайб-кодинг и AI-DLC отличаются не скоростью и не качеством кода. Оба режима сегодня дают работающий продукт быстро.

Отличаются они тем, что остаётся после работы. Вайб-кодинг оставляет приложение и знание в голове автора. AI-DLC оставляет ещё и цепочку, по которой это знание можно восстановить без автора: требование связано с критерием, критерий доказан прогоном, решение зафиксировано гейтом, метрика достаётся одной командой.

Пока систему делает и оценивает один человек, первого достаточно, и платить за второе не нужно. Как только появляется кто-то ещё — соавтор, преемник, партнёр, проверяющий — цена отсутствующих артефактов начинает начисляться, и начисляется она задним числом.

Мы занимаемся как раз этим переходом: берём работающую вайбкод-версию и доводим её до состояния, в котором про систему можно доказать, а не рассказать. Если у вас на руках прототип и впереди разговор, где спросят подробности, — напишите нам.