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

Вайб-кодинг за два года прошёл путь от мема до рабочего инструмента. Продукт, который раньше требовал команды и квартала, собирается за несколько вечеров одним человеком, и он действительно работает. Параллельно индустрия придумала на это ответ — 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 сканир