Как я перестал вайбкодить и собрал работающий SDLC из пяти промптов

Обзор

Хочу рассказать о конфигурации AI-агента для полного цикла разработки (SDLC), которую я обкатал на паре своих pet-проектов. Суть: цепочка из пяти команд — от черновика фичи до готового к ревью кода — где каждый этап выполняет AI, а я контролирую и корректирую результат между этапами.

За вечер (3-4 часа) в таком режиме AI выкатывает фичу, ручная разработка которой “по вечерам” занимала бы неделю (15-20 часов). Никаких откровений тут нет — всё, что описывается, обсуждалось тысячи раз. Новизна в том, что из общеизвестных кубиков получилось собрать работающий конвейер, которым удобно пользоваться каждый день.

Почему “вайбкодинг” не работает

Тот, кто пробовал отдать модели задачу покрупнее, знает симптомы: переписывание работающего кода, додумывание фичей, пропуск требований, костыли вместо реализации, поломка выпиливание рабочего функционала.

Причины на стороне человека — невнятные требования и отсутствие декомпозиции. На стороне модели — ограниченный контекст (требования из начала разговора вытесняются новой информацией), отсутствие grounding (модель не знает актуального состояния кода и галлюцинирует API) и склонность интерпретировать задачу шире, чем просили.

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

Контекст: проект, задача и инструменты

Прежде чем перейти к основной части — что за проект, какая задача будет сквозным примером и какой AI-инструментарий я использую. Ниже будут отсылки к конкретным технологиям, но сам подход не привязан к стеку — его можно адаптировать под любую связку.

Пет-проект

Архитектура стандартная — облачное серверлесс веб-приложение. Стек: AWS / .NET / Angular (TypeScript). Проект разбит на четыре слоя:

• Infra layer — хостинг и деплой в AWS через CDK. Данные в DynamoDB, бинарники на S3

• Backend layer — .NET Lambda-функции с трёхслойной архитектурой Data → Domain → API и анемичной моделью

• Frontend layer — Angular SPA с UI-компонентами от Syncfusion

• E2E layer — тесты на Playwright

Архитектура

Пример фичер-реквеста

Для наглядности — задача, на которой я покажу весь процесс. В проекте есть master/detail сущности: Trade и Task. У обеих есть поле Color. Требуется:

• убрать отображение и редактирование Color из UI для Task

• автоматически выставлять цвет Task равным цвету родительского Trade (на бэкенде)

• улучшить UI: заменить пикер цветов на палитру из 256 цветов, переключить грид на выделение строк вместо ячеек

Вот как выглядит исходный черновик — тот самый draft.md, с которого всё начинается:

Need to improve a color picker for SoW.
  1. Color picker is available only for Trades.
  2. Color is shown only for Trades
  3. Tasks color:
    - not shown in UI
    - once created - color is set the same as the related Trade
    - if Trade Color is changed - it changes for all related Tasks
    - all the color manipulation - at the BE.
  4. Improve Color picker for Trades: use a custom palette with classic 256 colors
  5. Configure Trade grid to not select cells - row only

Настройка AI

В качестве AI-агента я использую Claude Code. Для работы с описанным стеком настроил следующие MCP-серверы:

Frontend:

• Syncfusion Angular Assistant — доступ к документации и примерам Syncfusion-компонентов

• Angular CLI MCP — встроенный MCP-сервер Angular CLI

AWS (все из awslabs/mcp — монорепо с 60+ серверами):

• aws-api-mcp-server — работа с AWS API

• aws-documentation-mcp-server — поиск по документации AWS

• cdk-mcp-server — помощь с CDK-конструктами

• aws-serverless-mcp-server — Lambda, API Gateway, Step Functions

• dynamodb-mcp-server — работа с DynamoDB

• code-doc-gen-mcp-server — генерация документации по коду

• iam-mcp-server — IAM-политики и роли

• cloudwatch-mcp-server — логи и метрики

• cloudtrail-mcp-server — аудит событий

• billing-cost-management-mcp-server — мониторинг затрат

E2E тестирование:

• Playwright MCP — браузерная автоматизация и E2E-тесты

И плагины Claude Code (полный каталог доступен в реестре плагинов и на GitHub):

Разработка и качество кода:

• code-review, code-simplifier, commit-commands, feature-dev, pr-review-toolkit, security-guidance

Языковые серверы и документация:

• typescript-lsp, csharp-lsp, microsoft-docs

Инфраструктура и деплой:

• aws-serverless, databases-on-aws, deploy-on-aws

Frontend и тестирование:

• frontend-design, chrome-devtools-mcp

Утилиты и оркестрация:

• github, ralph-loop, atomic-agents, hookify, claude-code-setup, superpowers, explanatory-output-style, coderabbit

Если обобщить — собрал всё стандартное и бесплатное для используемых технологий.

Помимо этого я написал несколько пользовательских команд (/command), которые оркестрируют работу Claude. Это и есть ядро подхода — давайте к нему.

Конвейер: пять команд от черновика до мержа

Цель — построить SDLC-процесс, где каждый этап выполняет AI, а я сохраняю контроль и возможность коррекции между этапами. Вот что получилось:

SDLC

Clarify — из черновика в спецификацию

На вход подаётся уже упомянутый draft.md — описание фичи в свободном тексте (тот самый черновик из примера выше). Команда /clarify анализирует его, собирает контекст из кодовой базы и выдаёт стандартизированную спецификацию.

Что здесь важно. Команда работает в несколько фаз:

1. Сбор контекста — читает черновик и CLAUDE.md файлы проекта (архитектура, конвенции, стек)

2. Анализ и уточнение — задаёт вопросы, если что-то неоднозначно, и фиксирует допущения

3. Генерация спеки — формирует документ по шаблону

В шаблоне критически важны две вещи:

• Список требований — конкретных и тестируемых. Каждое требование должно быть достаточно точным, чтобы следующая команда (/design) могла построить план без дополнительных вопросов

• Список юзкейсов — конкретных сценариев, которые можно напрямую превратить в E2E-тесты на Playwright

Спеку на выходе можно (и нужно!) просмотреть глазами, поправить руками и сохранить в репозиторий. Вот что получилось из нашего черновика:

Design — из спецификации в план имплементации

Команда /design берёт спецификацию и генерирует из неё детальный пошаговый план. На этом этапе активно подключаются MCP-серверы и плагины — Claude исследует кодовую базу, сверяется с документацией библиотек и проектирует решение.

Что здесь важно:

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

• Контракты прорабатываются отдельно — как REST API (эндпоинты, DTO, статус-коды), так и внутренние (интерфейсы сервисов, схема данных). Это критично для независимой имплементации слоёв

• Self-review перед выдачей. Команда включает чеклист: все ли требования покрыты, нет ли лишнего, нет ли переусложнения. Если что-то не сходится — план ревизируется до показа

На выходе — пошаговый план имплементации, включающий юнит-тесты, E2E-тесты, инфраструктуру и схему данных. Вот план для нашего примера:

Implement — пишем код

Команда /implement берёт план и реализует его.

Можно имплементировать всё сразу, а можно послойно — контракты мы проработали на предыдущем этапе, поэтому слои независимы.

Ключевые принципы:

• Red-green-refactor. Сначала пишем тесты — они падают (red). Пишем минимальный код, чтобы тесты прошли (green). Рефакторим при необходимости. Это не пожелание, а жёсткое требование команды

• Предсказание результатов. После каждого значимого изменения Claude должен предсказать, какие тесты пройдут, а какие сломаются, запустить тесты и сравнить ожидание с реальностью. Несовпадение — сигнал остановиться и разобраться

• MCP-серверы как справочники. При работе с API библиотек Claude обращается к документации через MCP: Syncfusion, Angular, .NET SDK — вместо того чтобы галлюцинировать сигнатуры по памяти

• Конвенции из CLAUDE.md. Команда явно запрещает изобретать паттерны — только следовать существующим в проекте

В результате получаем простыню. Казалось бы, код написан и тесты зелёные — можно мержить? Не совсем.

Verify — проверяем результат

Команда /verify запускает многоуровневое ревью реализации.

Что здесь ключевое:

1. Билд и тесты — сборка без предупреждений, все юнит- и E2E-тесты зелёные

2. Мёртвый код — поиск неиспользуемых импортов, зависимостей и экспортов

3. Параллельное ревью агентами — шесть независимых ревьюеров одновременно: code review, поиск проглоченных ошибок, анализ покрытия тестами, ревью типов, проверка комментариев, и внешний ревью от CodeRabbit

4. Сверка с требованиями — самая важная часть. Реализация сравнивается со спецификацией: все ли требования покрыты, нет ли лишнего scope, консистентны ли контракты между фронтендом и бэкендом, для каждого юзкейса есть E2E-тест

5. Безопасность — IAM, аутентификация, инъекции, CORS

6. Дрифт документации — какие CLAUDE.md файлы устарели после изменений

На выходе — структурированный отчёт:

Document — обновляем документацию

Финальная команда в цепочке. Обновляет CLAUDE.md файлы проекта. Это критически важный шаг: если вы обратили внимание, все предыдущие команды загружают контекст проекта именно из этих файлов. Устаревшая документация = деградация качества всего конвейера. Тем самым мы подготовили почву для новой итерации.

После /document фича готова к финальному ревью глазами и мержу в мастер.

Границы применимости

Изменение должно быть гранулярным и с хорошим запасом влезать в окно контекста. Упомянутый пример использовал около 15% контекста в пике. Рост нелинейный, но если окно контекста занято на 50+ процентов, то это уже флажок, что что-то может пойти не так. Сжатие контекста — уже красный флаг, скорее всего напортачит. Однако разбиение процесса на этапы (вплоть до имплементации по слоям) с возможностью очистки контекста между ними успешно упрощает задачу.

Само собой, проект должен иметь сколько-нибудь стабильную архитектуру. AI-агенты отлично умеют работать «сделай по образцу» (даже если их специально об этом не попросят). Если образец — bullshit, то и результат — bullshit. Поэтому старые кодовые базы с десятилетиями исторических наслоений, скорее всего, будут проблемными.

Аналогично, новые библиотеки/фреймворки потребуют обновления команд.

Не уверен, что такой подход подойдёт для крупных команд со сложным SDLC-процессом.

А что используют другие?

Описанный подход — не единственный способ структурировать AI-разработку. Вот пять альтернатив разного калибра.

BMAD Method

BMAD (Breakthrough Method for Agile AI-Driven Development) — open-source фреймворк (43k+ звёзд на GitHub), который симулирует полноценную agile-команду через специализированные AI-персоны: Analyst, Product Manager, Architect, Developer, QA и другие — всего 12+ ролей и 34+ воркфлоу.

Процесс: Analysis → Planning → Solutioning → Implementation. На каждой фазе работает свой “специалист” со своим системным промптом. На выходе — PRD, юзер-стори с acceptance criteria, архитектурный дизайн и код с тестами.

Плюсы: наиболее полное покрытие SDLC из всех альтернатив. Ролевая модель создаёт структурированную ответственность. Фронтлоадинг планирования снижает количество переделок. Активное сообщество. Минусы: высокий порог входа (~2 месяца на освоение). Значительное потребление токенов (~31k на воркфлоу). Жёсткая методология — плохо подходит для мелких задач и экспериментов. Если один агент выдал некачественный артефакт, ошибка каскадирует в следующие фазы.

OpenSpec

OpenSpec — лёгкий open-source фреймворк для spec-driven development (36k+ звёзд, бэкинг от Y Combinator). Ключевая идея: спецификации живут в репозитории как markdown-файлы и являются “контрактом” между разработчиком и AI.

Процесс: три команды — /opsx:propose (генерирует proposal, спеки, дизайн и таски), /opsx:apply (реализует) и /opsx:archive (архивирует завершённое и обновляет библиотеку спецификаций). Работает с 30+ AI-инструментами: Claude Code, Cursor, Copilot, Windsurf и др.

Плюсы: минимальный порог входа (5 минут на настройку). Тул-агностик — не привязан к конкретному AI. Заточен под brownfield (эволюция существующей кодовой базы). Спеки в git — переживают смену разработчика и AI-инструмента. Минусы: нет отдельного этапа верификации — apply сразу пишет код. Спецификации статичны после создания — не эволюционируют в процессе имплементации. Если забыть /archive, библиотека спецификаций устаревает. Для простых задач формальный процесс может быть избыточным.

GitHub Copilot Workspace

Copilot Workspace — среда от GitHub, которая превращает Issue в готовый Pull Request через цепочку: спецификация → план → реализация → валидация. Всё в браузере, каждый этап можно отредактировать перед переходом к следующему.

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

Cursor (Rules + Agent Mode)

Cursor — AI-native IDE (форк VS Code) с поддержкой .cursor/rules файлов и многошагового Agent Mode. Rules-файлы задают стандарты и конвенции проекта, а Agent Mode автономно читает файлы, пишет код, запускает тесты и итерирует.

Плюсы: rules-файлы работают аналогично CLAUDE.md — сохраняют контекст проекта между сессиями. Agent Mode умеет автономно гонять билд-тест цикл. Поддержка нескольких моделей. Минусы: нет формализованных этапов — пайплайн существует только в голове разработчика. Rules-файлы — это guardrails, а не workflow. Работает только в IDE, нельзя встроить в CI/CD.

Aider

Aider — open-source CLI-инструмент для AI-парного программирования. Ключевая фича — Architect Mode: модель-“архитектор” проектирует решение, модель-“редактор” реализует изменения в коде. Каждое изменение автоматически коммитится в git.

Плюсы: open-source, модель-агностик, работает из терминала и в CI/CD. Architect Mode — встроенный двухфазный пайплайн. Отличная git-интеграция: каждый шаг — отдельный коммит. Минусы: пайплайн ограничен двумя фазами. Нет встроенных этапов для сбора требований, верификации и документирования.

Сравнение

	BMAD	OpenSpec	Copilot Workspace	Cursor + Rules	Aider	Свои /commands
Этапы	4 фазы, 12+ ролей	3 (propose/apply/archive)	4 (фикс.)	Неформализованы	2 (архитектор + редактор)	Любые
Кастомизация	Средняя (свои агенты)	Низкая	Низкая	Средняя	Средняя	Высокая
Среда	CLI	CLI	Браузер	IDE	CLI	CLI
Open-source	Да	Да	Нет	Нет	Да	Команды ваши
Тул-агностик	Частично	Да (30+ инструментов)	Нет (GitHub)	Нет (Cursor)	Да	Нет (Claude Code)
Порог входа	Высокий (~2 мес.)	Низкий (~5 мин)	Низкий	Средний	Средний	Средний (команды пишет AI)
Верификация	Adversarial Review	Нет (отдельно)	Встроенная	Нет	Нет	Да (/verify)
Стоимость токенов	Высокая	Умеренная	Непрозрачна	Непрозрачна	Умеренная	Контролируемая

Если расположить альтернативы на шкале “простота ↔ полнота”, получится: Aider → Cursor → OpenSpec → Copilot Workspace → свои /commands → BMAD. OpenSpec и свои команды занимают соседние ниши: оба используют markdown-спеки в репозитории и оба строят пайплайн из этапов. Разница в том, что OpenSpec даёт готовую структуру из коробки, а свои команды — полную свободу в определении этапов, промптов и артефактов. BMAD стоит особняком как полноценная методология с высоким порогом входа, но и с наиболее системным подходом к качеству.

Заключение

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

Переносимость. Команды не привязаны к моему стеку. Чтобы адаптировать их под другой проект, достаточно дать AI ссылку на команду и написать “адаптируй под мой проект”. Их легко расширять — например, добавить команды Investigate, Debug, Commit.

Итеративное улучшение. Не стесняйтесь спрашивать у AI-агента:

• Соответствует ли документ архитектуре и конвенциям моего проекта?

• Все ли аспекты этапа покрыты?

• Что улучшить в команде?

• Просмотри все команды целиком — все ли требования прослеживаются от Clarify до Verify?

Главное, что даёт этот подход — не скорость сама по себе, а предсказуемость. AI не “вайбкодит” — он следует процессу с чёткими входами, выходами и контрольными точками между этапами. А человек остаётся тем, кто принимает решения.