Эволюция AI SDLC: Почему вайб-кодинг и Spec-Driven подходы ломаются на масштабе и что будет дальше
За последний год ландшафт разработки ПО изменился до неузнаваемости, перейдя от простых ИИ-ассистентов к мультиагентным системам. В этой статье мы исследуем, почему популярные подходы, такие как вайб-кодинг и Spec-Driven разработка, терпят неудачу на масштабе, и предлагаем зрелую модель AI SDLC, основанную на Intent-Driven Development.
Авторы: slavb18
Эволюция AI SDLC: Почему вайб-кодинг и Spec-Driven подходы ломаются на масштабе и что будет дальше
За последний год ландшафт разработки программного обеспечения изменился до неузнаваемости. Мы незаметно перешли от простых ИИ-ассистентов в стиле «допиши строчку кода» к автономным мультиагентным системам и продвинутым ИИ-IDE. Индустрия разделилась на два лагеря, каждый из которых обещает кратный рост продуктивности.
С одной стороны - вайб-кодинг (Vibe Coding), где разработчик просто общается с моделью на естественном языке, абстрагируясь от самого кода. С другой - разработка на основе спецификаций (Spec-Driven Development, SDD), пытающаяся обуздать недетерминированность нейросетей жесткими текстовыми контрактами и инструкциями.
Однако любой технический лидер, попытавшийся развернуть эти подходы на уровне крупной инженерной команды (хотя бы от 20-30 человек), неизбежно упирается в глухую стену. Пулл-реквесты ломают конвенции коммитов, спецификации начинают «галлюцинировать» и противоречить друг другу, а экономия времени на написание кода сжирается часами археологии в Git-истории.
Почему обе концепции дают сбой на уровне энтерпрайза и как должен выглядеть зрелый ЖЦПО (SDLC) в эпоху ИИ? Давайте разбираться.
🤯 Иллюзия выбора: В чем системная ошибка текущих подходов
Главная проблема как вайб-кодинга, так и Spec-Driven подхода заключается в одном и том же архитектурном грехе - схлопывании трех принципиально разных слоев абстракции в один хаотичный массив данных.
Проектируя любую систему с помощью ИИ, мы оперируем тремя уровнями:
🎯 Намерение (Intent) - чего хочет бизнес или пользователь, в каких рамках, с какими критериями успеха и ограничениями (например: «Система должна выдерживать 100k RPS и при отсутствии товара на складе предлагать релевантную замену»).
📝 Спецификация (Specification) - измеряемый, проверяемый контракт. Это жесткие pass/fail тесты (evals). Если требование нельзя превратить в автоматический тест - это не спецификация.
🛠️ Реализация (Implementation) - конкретная архитектура, паттерны и стек (микросервисы или монолит, кэширование, структура БД).
Вот как с этими слоями обходятся современные методологии:
💬 Вайб-кодинг: Спецификации нет. Намерение и реализация перемешаны в контекстном окне чата.
📑 Spec-Driven: Один гигантский Markdown-файл, где требования бизнеса, тесты и архитектурные решения свалены в кучу.
Вайб-кодинг полностью игнорирует контрактную часть. Модель принимает решения «в моменте», не имея долгосрочной памяти и аудиторского следа. Для соло-разработчика на гринфилде это магия. Для распределенной команды - логистический кошмар, порождающий десятки неконсистентных и противоречащих друг другу ПР.
Spec-Driven Development пытается решить проблему детерминизма, заставляя человека писать детальные простыни инструкций. Но как только вы меняете один верхнеуровневый компонент (например, переносите таргет деплоя из одного облака в другое), вся цепочка downstream-задач в спецификации рушится. Архитектурные решения оказываются намертво зашиты в документ требований.
Если для исправления пятиминутного бага вашей команде приходится обновлять спецификацию, прогонять её через агента, тратить миллионы токенов на валидацию edge-кейсов, а потом вручную переписывать сообщения коммитов - ваша методология работает против вас.
✅ Решение: Разделение обязанностей (Intent-Driven Development)
Чтобы AI SDLC стал масштабируемым инженерным процессом, а не шаманством, три упомянутых слоя нужно изолировать друг от друга. Эта концепция формирует подход Intent-Driven Development (IDD).
Трехуровневая схема ИИ-разработки
| Слой абстракции | Кто управляет | Что содержит |
|---|---|---|
| Намерение (Intent) | Человек | Ограничения, условия отказа, требования к масштабируемости и бизнес-логика. |
| Спецификация (Spec) | Человек | Набор автоматических эвалов (Evals) и тестов. Строгий контракт формата «прошел/не прошел». |
| Реализация (Implementation) | ИИ-Система | Выбор конкретных паттернов, написание кода, рефакторинг под кодовую базу. |
При таком разделении человек перестает быть «кодером» или «писателем детальных инструкций для ИИ». Роль инженера смещается в сторону двух ключевых ремесел: Intent Crafting (умение формализовать бизнес-ограничения в виде строгих схем) и Spec Crafting (проектирование проверяемых тест-контрактов).
Выбор реализации - монолит или микросервис, in-memory cache или распределенный - должен оставаться за ИИ-системой, обладающей эмпирической памятью конкретно вашей организации (знанием контекста, легаси-кода и принятых в компании практик). Человеку не нужно диктовать архитектуру внутри файла требований, если система способна вывести её из контекста и ограничений по нагрузке.
🚀 Матрица зрелости AI SDLC
Куда движется индустрия автоматизации разработки? Весь стек можно разделить на 5 уровней технологической зрелости:
1. 🕺 Vibe Level
- Инструменты: Базовые ИИ-плагины для IDE, чаты.
- Субстрат: Модель + контекст текущего файла.
- Проблема: Отсутствие памяти, стандартов и контрактов. Полный хаос на уровне команды.
2. 📝 Spec-Driven Level
- Инструменты: Системы генерации кода на основе статических Markdown-описаний.
- Субстрат: Жесткие текстовые инструкции, интерпретируемые агентами.
- Проблема: Экстремальная тяжеловесность. Спецификации «дрейфуют» (спека расходится с реальным кодом), поддержка документации сжирает всю экономию времени.
3. ✨ Intent-Driven Level
- Инструменты: Оркестраторы мультиагентных систем с разделением слоев.
- Субстрат: Исполняемые плейбуки (сценарии) + корпоративная база знаний (эмпирическая память).
- Статус: Текущий технологический фронтир для продвинутых команд. Роли разделены, система сама предлагает архитектурные решения на основе контекста репозитория.
4. 🤖 Autonomous Level
- Субстрат: Общий семантический слой вместо индивидуальных сценариев.
- Особенность: Система способна самостоятельно рассуждать и перестраивать цепочки задач (plays) на ходу при изменении верхнеуровневого намерения.
5. 🏭 Fully Autonomous (Dark Factory)
- Концепция: «Темная фабрика» программного обеспечения.
- Субстрат: Непрерывный цикл компиляции бизнес-намерений в готовый продукт. Человек находится только на входе (валидация целей) и на выходе (приемка бизнес-ценности). На сегодняшний день - во многом теоретическая модель.
📋 Чек-лист для технического лидера
Если вы внедряете ИИ-агентов в процессы разработки, задайте себе один диагностический вопрос:
Не пытаемся ли мы упаковать намерения, тесты и архитектурные решения в один документ и назвать это «спецификацией»?
Если ответ «да» - вы на пороге методологического кризиса. Вы заметите, как аналитики тонут в написании текстов для ИИ, разработчики втихающую «вайбят» мимо процессов, чтобы успеть к дедлайнам, а агенты начинают игнорировать раздутые инструкции.
Что делать?
✂️ Отрежьте архитектуру от требований. Опишите в намерениях целевые метрики (нагрузку, отказоустойчивость, безопасность), но позвольте системе самой адаптировать код под эти параметры.
✅ Сделайте спецификацию проверяемой. Если строчку в требованиях нельзя покрыть автоматическим эвалом (eval) - удалите её или перенесите в слой намерений.
🧠 Инвестируйте в контекст, а не в промпты. Модели меняются каждый месяц. Промпты устаревают. Единственное, что имеет долгосрочную ценность - это эмпирическая память вашего проекта (структурированная база знаний, архитектурные гайдлайны и история контекста), к которой подключаются агенты.
Методология становится главным продуктом инженерного менеджмента. Тот, кто сможет выстроить чистый, разделенный на слои AI SDLC, получит те самые кратные иксы к скорости поставки фич. Остальные продолжат сжигать токены, пытаясь заставить агентов читать устаревшие инструкции.