В конце 2025 года AWS опубликовала open-source методологию AI-DLC — набор markdown-файлов, описывающих 30+ этапов разработки с ИИ, сгруппированных в 5 фаз. Идея простая: кладёшь файлы в репозиторий — получаешь структурированный процесс работы coding agents. Но за этой простотой скрывается проблема, которую Valeria Viana Gusmao описывает прямо:
The cons are that it is essentially an automated waterfall (4 out of 5 phases produce documentation) with quality being defined by how thorough and knowledgeable the reviewers are.
Минус в том, что по сути это автоматизированный waterfall (4 из 5 фаз производят документацию), а качество зависит от того, насколько тщательны и компетентны ревьюеры.
Команда из 5 человек может прочитать документ, сгенерированный ИИ. Команда из 50 — нет. А если нужно масштабировать AI-процессы на всю организацию, mob-review каждого артефакта становится узким местом. ValeriaVG предлагает альтернативу — Agile AI-DLC, где вместо human review стоят автоматические проверки, а вместо документации — прототипы.
Что такое AI-DLC и почему его мало
AI-DLC от AWS — это попытка дать командам готовый процесс работы с ИИ-агентами. Методология описывает 5 фаз:
- Initialization — настройка окружения и инструментов.
- Ideation — генерация и валидация идей.
- Inception — планирование, архитектура, документация.
- Construction — написание кода агентами.
- Operation — деплой и поддержка.
Каждый этап требует mob-review артефактов, сгенерированных ИИ. По замыслу AWS, это гарантирует качество. На практике — создаёт бутылочное горлышко.
Два других популярных подхода в той же нише:
- Compound Engineering / Superpowers — наборы skill-файлов в markdown, которые дают агентам контекст и инструкции. Зависят от human-in-the-loop review.
- Platform Engineering — не изобретение нового, а эволюция существующих процессов. Spotify назвал это Golden Paths, Netflix — «paved roads». CNCF выпустила White Paper по платформенным командам.
Суть Agile AI-DLC: два отличия
Agile AI-DLC — это гибрид, который занимает пространство между AWS AI-DLC и платформенным подходом. Два ключевых отличия от AWS AI-DLC:
1. Продукт — прототипы, а не документация. Каждый этап цикла выдаёт рабочий прототип (или его эволюцию), а не README на 50 страниц. Это значит, что проверить результат можно запуском и тестированием, а не чтением.
2. Качество обеспечивают детерминированные проверки, а не люди. Линтеры, типизированные системы, scorecards, CI/CD-пайплайны — всё, что можно запустить автоматически. Human review остаётся только там, где автоматизация невозможна или нецелесообразна.
Шесть церемоний Agile AI-DLC
ValeriaVG описывает процесс как итеративный цикл из шести этапов. Не каждый цикл проходит все шесть — стартовая точка зависит от зрелости проекта и состава команды.
1. Proof of Concept
Быстрый, исследовательский прототип. Команда collaborative изучает проблемное пространство и проверяет жизнеспособность решения. Paved path (маршрут разработки) определяется типом проблемы и составом команды.
Результат: решение — продолжать или остановиться. Domain-эксперты участвуют активно.
На практике это выглядит так: дизайнер делает макет в Figma и запускает билд интерактивного прототипа. Продуктовый менеджер через Slack-бота добавляет к прототипу full-stack возможности. Инженер берёт внутреннюю платформу и доводит до production, используя существующие компоненты.
2. Prototype
Валидированный PoC эволюционирует в прототип. Маршрут зависит от состава команды — design-first, API-first, database-first. Domain-эксперты привлекаются реже.
Результат: scope и требования для MVP.
3. Executable Specification
Ключевой этап, на котором Agile AI-DLC расходится с AWS AI-DLC. Требования, собранные на предыдущих этапах, превращаются в executable specifications — unit-тесты, integration-тесты, контракты API, визуальные regression-тесты, строгие машинные правила. Всё, что можно проверить автоматически — проверяется автоматически.
Extreme Programming (XP) is often remembered for its rituals: pair programming, test-driven development (TDD) and small batch delivery. Its core insight was far more fundamental: correctness is established continuously during creation rather than inspected after the fact.
XP часто вспоминают за ритуалы: pair programming, TDD и доставку маленькими батчами. Но ключевая идея была глубже: корректность устанавливается непрерывно в процессе создания, а не проверяется постфактум.
— Agentic XP: Moving Rigour Left in the Age of AI, Wandoo Systems
Требования, которые невозможно автоматизировать, документируются — но документация хранится в формате, доступном и людям, и агентам.
Результат: набор тестов и executable specifications.
4. Implementation Loop
Агенты берут прототип и одну задачу за другой доводят его до рабочей реализации. Каждое изменение проходит через автоматические проверки — CI/CD, линтеры, тесты. Если проверки не проходят — агент итерирует, пока не исправит.
Результат: рабочая реализация, в которой все автоматические проверки пройдены.
5. Evaluation
Рабочая реализация проверяется на более широком наборе требований — включая ручные проверки, если необходимо. Демо стейкхолдерам. Domain-эксперты привлекаются по запросу.
Результат: список дополнительных требований для следующей итерации.
6. Retrospection
Команда анализирует процесс и корректирует paths, процессы и требования. Time spent — минимум 20% от времени проекта на рефлексию и улучшение ежедневной работы.
Результат: набор обязательств, запускающих следующий цикл.
Executable Specification: почему это load-bearing концепция
Термин «executable specification» заслуживает отдельного внимания, потому что он держит на себе всю архитектуру методологии.
Человек терпит неопределённость. Читая README с описанием «система должна быть быстрой», разработчик интерпретирует это по-своему — и обычно достаточно правильно. Агенты ИИ не терпят неопределённости. Если в spec написано «быстро» — агент может интерпретировать это как миллисекунды или секунды, и оба варианта будут «корректны».
Agile AI-DLC предлагает решать эту проблему через предсказуемость. Один правильный способ делать одно и то же — для людей и агентов:
| Инструмент | Что обеспечивает |
|---|---|
| Строгие компиляторы (Rust, Haskell) | Код компилируется или нет — нет серой зоны |
| Типизация (TypeScript strict, mypy) | Интерфейсы зафиксированы, агент не угадывает |
| Линтеры (ESLint, Ruff) | Один стиль, проверяемый автоматически |
| Design system | UI-компоненты стандартизированы, нет вариативности |
| API catalogs и контракты | Структура данных зафиксирована |
| Scorecards в CI/CD | Все проверки в одном месте |
ValeriaVG формулирует принцип «More Power — More Guardrails» (чем больше прав агенту, тем жёстче ограничения). Для brainstorming или одноразового прототипа можно ограничиться skills.md. Для продакшена — paths с бетонными стенками.
Russian Reality: что из этого работает в РФ
Методология Agile AI-DLC — это не конкретный продукт, а набор процессов и инструментов. Большинство из них доступно в России:
- CI/CD: GitLab (gitlab.com заблокирован, но self-hosted работает), GitHub (через VPN), Gitea/Forgejo — полностью доступны.
- Линтеры и компиляторы: TypeScript, ESLint, Ruff, Rust — все open-source, работают локально, без API.
- Тестирование: pytest, Playwright, Jest — open-source, локально.
- Платформенные инструменты: Backstage (Spotify) — open-source, self-hosted.
- AI-агенты: Claude Code (API через VPN или прокси), OpenCode с DeepSeek/Qwen (без VPN), Codex CLI (API OpenAI через VPN).
Ключевой момент: сама методология не зависит от конкретного AI-провайдера. Paved paths, executable specifications, CI/CD-пайплайны — это инфраструктурные решения, которые работают без облака и без VPN. AI-агент — это компонент в пайплайне, а не основа процесса.
Русскоязычного контента по Agile AI-DLC практически нет — тема свежая (август 2026), и ValeriaVG — автор с dev.to-аудиторией, а не из рунета.
Как это выглядит на практике: пример paved path
Допустим, команда добавляет новый API-endpoint. Без Agile AI-DLC процесс выглядит так: инженер пишет код, коммитит, открывает PR, ждёт ревью. Ревьюер читает, предлагает правки. Инженер правит. Через 2–3 раунда PR мержится. На это уходит 1–3 дня.
С Agile AI-DLC paved path для нового endpoint:
- Инженер (или AI-агент) создаёт файл с описанием endpoint: метод, путь, тело запроса/ответа, ошибки.
- Из описания автоматически генерируются: OpenAPI-контракт, type-определения, моки для тестов.
- Агент реализует endpoint, ориентируясь на контракт и типы — не на свободное описание.
- CI-пайплайн запускает: type-check, линтеры, unit-тесты, integration-тесты (сгенерированные из контракта), contract-тесты.
- Все проверки зелёные → PR автоматически одобрен (если paths mature). Жёлтые → агент исправляет и повторяет.
Человек в этом процессе делает три вещи: определяет что нужно (контракт), проверяет как (на demo), решает зачем (приоритизирует). Всё остальное — автоматизация.
Для другого paved path — добавление нового UI-компонента — логика та же, но вместо contract-тестов: visual regression tests (Playwright), accessibility checks (axe-core), проверка соответствия design system.
Метрики: что измерять
Agile AI-DLC предлагает считать не только стандартные DORA и SPACE, но и специфические для paved paths метрики:
| Метрика | Что считает | Как использовать |
|---|---|---|
| Path Adoption Rate | Сколько уникальных пользователей используют путь в день / неделю / месяц | Низкий adoption → path неудобен или команда о нём не знает |
| Path Error Rate | Доля неудачных запусков пути от общего числа | Высокий error rate → path нуждается в доработке |
| Path Re-run Rate | Доля запусков с повторным запросом от числа уникальных запросов | Высокий re-run → агент не понимает путь с первого раза |
Плюс: у каждого пути должен быть cost budget и алерты по стоимости. Токены — это деньги, и при масштабировании на организацию этот расход становится заметным.
На практике метрики выглядят так: если новый paved path для добавления API-endpoint использует 10 инженеров в неделю, а его error rate — 30%, это сигнал. Возможно, specification написана слишком абстрактно, или линтеры не покрывают частые ошибки. Re-run rate выше 20% — значит агенту не хватает контекста, и path нужно дополнить примерами или stricter constraints.
Команда: Platform Team + Stream-Aligned Team
Agile AI-DLC не меняет организационную структуру — она опирается на Team Topologies:
Platform Teams — отвечают за поддержку paved paths и развитие платформенных возможностей. Могут быть организованы вокруг кластера путей, домена или технологии. Поглощают сложность платформы. В контексте AI — это те, кто пишет линтеры, настраивает CI/CD-пайплайны, поддерживает design system и API catalogs.
Stream-Aligned Teams — отвечают за конкретный бизнес-поток (набор целей или revenue stream). Фокусируются на решении бизнес-задач, избавляясь от сложности. Используют paved paths как чёрный ящик: описывают задачу → получают результат → проверяют на demo.
Важно: обе стороны должны чувствовать ownership. Platform Team прислушиваются к нуждам Stream-Aligned и proactively строят нужные возможности. Stream-Aligned предлагают улучшения платформы, которая им нужна или скоро понадобится.
Domain-эксперты могут быть частью Platform Teams или существовать как independent satellite teams, которых подключают по необходимости. В небольших командах (до 10 человек) roles совмещаются — и это нормально.
С чего начать
Методология Agile AI-DLC adopts не требует революции. Первый шаг — заменить один процесс:
- Выберите один recurring workflow в команде (например, добавление нового endpoint’а или верстка нового компонента).
- Создайте paved path для этого workflow — пайплайн из скриптов, линтеров и тестов, который запускается автоматически.
- Напишите executable specification для этого path — что проверяется, какие тесты запускаются, какие линтеры проверяют код.
- Подключите AI-агента к этому path — агент выполняет задачу, автоматические проверки гарантируют качество.
- Измеряйте adoption rate, error rate, re-run rate. Корректируйте path на ретроспективе.
Компания считает методологию adopted в момент, когда первый path заработал. Зрелость растёт с числом активно используемых paths.
Ограничения
- Начальный барьер. Agile AI-DLC предполагает зрелый CI/CD и culture автоматизации. Если тестов нет — первый шаг будет самым тяжёлым.
- Domain-эксперты. На PoC и Evaluation их присутствие необходимо. Методология упрощает процессы, но не отменяет потребность в экспертизе.
- Измеримость. Paths, которые невозможно измерить, невозможно улучшить. Не все виды работы хорошо ложатся на метрики adoption/error/re-run.
- Не замена архитектурным решениям. Агент силён в реализации, слаб в проектировании. Agile AI-DLC облегчает исполнение, но не снимает с человека ответственность за дизайн системы.
- Стоимость. Детерминированные проверки (тесты, линтеры, CI/CD) — бесплатно. AI-агенты в пайплайне — нет. При масштабировании cost budgets становятся обязательными.
Вывод
Agile AI-DLC — не новая религия, а practical компромисс. Вместо автоматизированного waterfall от AWS (много документации, ручной review) — прототипы и автоматические проверки. Вместо платформенного подхода «сделайте golden path» — конкретные церемонии и метрики.
Идея, которая стоит запомнить: ИИ-агент работает лучше, когда у него один правильный путь, а не десять вариантов на выбор. Executable specification — это не про тесты, а про устранение неопределённости, которая агентам противопоказана.
Agile AI-DLC не требует революции. Первый шаг — взять один повторяющийся workflow в команде, автоматизировать его проверки и подключить к нему AI-агента. Всё остальное — итерации. Свободное время, высвобожденное автоматизацией, тратится на улучшение процессов, а не на масштабирование объёма работы.
Если ваша команда уже использует CI/CD и тесты — Agile AI-DLC можно начать внедрять завтра. Если нет — первый шаг будет про инженерную зрелость, а не про ИИ. И это нормально.
