28.07.2026

AI-Driven Development (AIDD)

Общее

Появление в 2022–2023 годах коммерческих больших языковых моделей (LLM), способных генерировать связный и зачастую работающий код, изменило базовую экономику написания ПО. Сначала AI использовался точечно — автодополнение строк, ответы на вопросы в чате, объяснение незнакомого фрагмента. Затем появились AI-редакторы (Cursor, Windsurf, Zed), автономные CLI-агенты (Claude Code, Gemini CLI, OpenAI Codex CLI, OpenCode) и языки управления промптами (SudoLang). Инструментальный слой быстро обогнал методологический: стало ясно, что «просто дать разработчику AI» даёт прирост скорости, но одновременно размывает ответственность, плодит дублирование кода и снижает стабильность.

Эту проблему и решает AI-Driven Development (AIDD) — методология разработки, в которой AI-модели берут на себя основную ответственность (primary responsibility) за производство исходного кода, тестов и документации, а человек перемещается на уровень спецификаций, архитектуры и валидации результата. Ключевой тезис AIDD: AI — это не надстройка над привычным процессом, а самостоятельный производитель кода, а значит вокруг него нужно выстроить ровно ту же инженерную дисциплину, что и вокруг любого другого источника кода — спецификации, тесты, контроль версий, ревью и валидацию.

AIDD — зонтичный термин. Под ним в индустрии понимают родственный, но не тождественный набор подходов:

  • AIDD как методология (общее значение) — смена ответственности «человек пишет код → AI пишет код, человек валидирует».
  • AI-DLC (AI-Driven Development Life Cycle) — операционная методология от AWS: три фазы (Inception → Construction → Operations), короткие циклы «bolts» вместо спринтов.
  • AIDD Framework — конкретный open-source фреймворк от Parallel Drive (Эрик Эллиотт): CLI, agent runtime, навыки (skills), промпт-язык SudoLang.
  • Spec-Driven Development (SDD) — подметодология, в которой Markdown-спецификации объявляются единым источником истины для AI-агентов.

Статья рассматривает AIDD в первом, методологическом смысле, опираясь на все перечисленные источники как на конкретные практики.

Историческая справка. Термин AIDD в современном значении начал активно использоваться с 2023 года — одна из ранних формулировок принадлежит Dawid Dahl (март 2023): AIDD как «футуристическое расширение TDD», цикл Red-Green-Refactor, где реализацию генерирует AI. С 2024–2025 годов методология была формализована: Эрик Эллиотт опубликовал AIDD Glossary и фреймворк; AWS представил AI-DLC; команда Panaversity сформулировала «девять столпов» AIDD. К 2026 году AIDD — устоявшийся термин с устоявшимся же набором артефактов и практик, которые и систематизированы ниже.

AIAD vs AIDD vs Vibe Coding

Три режима применения AI при разработке часто смешивают, хотя они различаются фундаментально — по тому, кто несёт основную ответственность за результат и какая инженерная дисциплина surrounds AI. Разведение этих режимов — отправная точка для понимания AIDD.

AIAD (AI-Assisted Development). Основную ответственность за код несёт человек. AI выполняет поддерживающую роль: автодополнение (Copilot), чат-вопросы (ChatGPT в браузере), объяснение фрагментов, генерация отдельных методов по запросу. Классическая IDE остаётся центром workflow, AI — надстройкой. Это привычный сегодня режим для большинства разработчиков.

AIDD (AI-Driven Development). Основную ответственность за генерацию кода, тестов и документации несёт AI. Человек пишет спецификации (что строить, какие стандарты качества соблюдать), организует контекст (правила, конвенции, история решений), валидирует вывод и принимает архитектурные решения. AI-редактор или CLI-агент становится центром workflow, а не надстройкой.

Vibe Coding. Термин, популяризованный Андреем Карпатым (февраль 2025): разработка, при которой человек ведёт с AI свободный диалог, принимает сгенерированное «на вайбе», не выстраивает ни спецификаций, ни тестового покрытия, ни систематической валидации. Код пишется быстро, но его сопровождаемость, безопасность и связность с остальной системой не контролируются.

Ось сравнения AIAD (AI-Assisted) AIDD (AI-Driven) Vibe Coding
Кто primary producer кода Человек AI AI (без контроля)
Спецификации до кода Опционально Обязательны (vision, conventions, tasks) Нет
Контроль качества Ручное ревью Автоматический quality-gate (тесты, линтеры, ADR) Нет / «на глаз»
Роль человека Автор строк Архитектор спецификаций, валидатор, decision maker Оператор чата
Тесты После или параллельно До реализации (TDD-стиль) Обычно нет
Контроль версий артеактов Код Код + спеки + тесты + ADR + правила Код (часто «как есть»)
Production-ready Да Да, с первого дня Нет (прототип/одноразовое)
Главный риск Медленнее, чем могло бы быть Затраты на контекст, зависимость от модели Хрупкость, техдолг, дублирование

Практический вывод: AIDD = AIAD по мощности генерации + дисциплина спецификаций/тестов/валидации. Vibe coding — это AI-генерация без этой дисциплины, и именно его AIDD противопоставляет себе как главный антипаттерн.

Отдельно отметим эмпирические данные о рисках бездисциплинарного AI-кодинга. GitClear, отследив 211 миллионов строк кода за 2020–2024 годы, зафиксировал восьмикратный рост дублирования кода по мере внедрения AI. Отчёт Google DORA связывает массовое внедрение AI с +9% к уровню дефектов и снижением стабильности (DORA — ежегодный отраслевой отчёт о производительности инженерных команд). Эти цифры — не аргумент против AI, а аргумент за методологию: генерация без quality-gate систематически деградирует в техдолг.

Принципы AIDD

AIDD опирается на набор принципов, которые в совокупности отличают методологию от «просто кодирования с AI». Ниже — формулировка каждого принципа с пояснением, какую конкретную проблему он решает.

Specification-first. Требования, архитектура и стандарты качества фиксируются до начала генерации кода — в виде структурированных документов (vision.md, conventions.md, tasklist.md). Проблема, которую решает: LLM по умолчанию склонна к «универсальным космолётам» — генерации избыточных абстракций на все случаи жизни. Спецификации ограничивают свободу генерации и задают критерии приёмки.

AI как primary producer. AI-модель рассматривается как основной источник кода, тестов и документации, а не как помощник, который «подсказывает». Проблема: при сохранении человека как автора строк выигрыш в скорости ограничен, а ответственность размывается. Перенос ответственности за генерацию на AI (с сохранением валидации за человеком) даёт кратный прирост velocity.

Человек как orchestrator и валидатор. Роль человека — постановка задачи в виде спецификации, выбор архитектурных альтернатив, валидация вывода AI, принятие решений в точках неопределённости. Человек остаётся decision maker’ом — это принцип Human-Verified.

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

Iteratively-Refined. Работа ведётся короткими циклами «спланировал → сгенерировал → проверил → уточнил». Фидбек цикла улучшает и код, и сами спецификации (если выяснилось, что спека была неполной — она обновляется). Проблема: длинные «водопадные» проходы с AI дают непредсказуемый результат; итеративность возвращает управляемость.

Version-Controlled для всех артефактов. Под контролем версий находятся не только код и тесты, но и спецификации, ADR (Architecture Decision Records), правила для AI, onboarding-документация. Проблема: рассинхронизация «код ушёл вперёд, документация осталась» — главный источник хрупкости в AI-генерируемых проектах.

Documentation-Embedded. Документация живёт рядом с кодом и генерируется/обновляется в том же цикле, что и реализация. Onboarding для нового разработчика (или для самого AI при следующей сессии) — отдельный артефакт, который поддерживается явно.

Production-Ready с первого дня. Никаких throwaway-прототипов «для проверки идеи», которые потом превращаются в продакшен-код без переработки. Профессиональные стандарты (тесты, логирование, обработка ошибок, безопасность) применяются с первой итерации. Принцип прямо противоположен vibe coding, где production-ready откладывается «на потом».

Принципы не меню — это система. Каждый усиливает остальные: specification-first без quality-gate остаётся на бумаге; quality-gate без specification-first не знает, что проверять; iteratively-refined без version-control теряет накопленный контекст. Частичное внедрение создаёт дыры; полное — даёт преимущество.

Ментальная модель: цикл AIDD

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

Цикл состоит из шести шагов:

  1. План (Plan). AI формирует детальный план предстоящей работы: какие файлы затронуты, какие изменения внесены, в каком порядке. План строится из текущего контекста — спецификаций, правил, истории решений.
  2. Уточни контекст (Seek clarification). AI выявляет пробелы в контексте и обращается к человеку с конкретными вопросами. В отличие от генерации «как понял», здесь человек явно доопределяет требования в точках неопределённости.
  3. Валидируй план (Human validation). Человек проверяет план и ответы на уточняющие вопросы, принимает или отвергает, корректирует архитектурные выборы. До генерации кода — а не после.
  4. Реализуй (Implement). AI генерирует код строго по утверждённому плану, в рамках зафиксированных конвенций.
  5. Проверь тестами (Verify). Запускается quality-gate: тесты, линтеры, статический анализ, проверки безопасности. Если gate не пройден — возврат к шагу 4.
  6. Итеративно доработай (Refine). Человек ревьюит результат, отмечает недочёты, при необходимости корректирует спецификацию (если причина дефекта — в неполной спеке). Цикл повторяется.
        ┌─────────────────────────────────────────────────┐
        ▼                                                  │
   ┌─────────┐    ┌───────────┐   ┌──────────┐   ┌─────────┴┐
   │  План   │ →  │  Уточни   │ → │ Валидируй│ → │ Реализуй │
   │ (Plan)  │    │ контекст  │   │ (Human)  │   │(Implement)│
   └─────────┘    └───────────┘   └──────────┘   └────┬─────┘
                                                          │
                          ┌───────────────────────────────┘
                          ▼
                   ┌────────────┐        ┌────────────────┐
                   │  Проверь   │───────▶│  Доработай     │
                   │  тестами   │ FAIL   │ (Refine) ──────┼──▶ коммит
                   │  (Verify)  │        └────────────────┘
                   └─────┬──────┘
                         │ PASS
                         ▼
                    коммит + переход к следующей задаче

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

Цикл AIDD структурно близок к OODA (Observe → Orient → Decide → Act) — модели принятия решений в условиях неопределённости, разработанной для военных и адаптированной для бизнеса. Plan ≈ Observe + Orient, Seek clarification + Validate ≈ Decide, Implement + Verify ≈ Act, Refine ≈ возврат к началу. Близость не случайна: разработка с AI — это именно работа в условиях неполной определённости (поведение модели вероятностно, контекст никогда не исчерпывающ), и AIDD заимствует у OODA главное — скорость и частота циклов важнее полноты каждого прохода. Лучше десять коротких циклов с быстрым фидбеком, чем один длинный «идеально спланированный».

Отсюда следствие для организации работы: болты вместо спринтов (терминология AWS AI-DLC). Sprint — недельный/двухнедельный цикл, привычный по Scrum, плохо ложится на AI-разработку, где единица работы измеряется часами. Bolt — короткий, интенсивный рабочий цикл (часы или дни), завершающийся проверяемым результатом. AIDD-проект — это последовательность десятков болтов, каждый из которых проходит полный цикл «план → валидация → реализация → проверка».

AIDD и классические практики SWE

Распространённое заблуждение: «AIDD отменяет классические практики разработки, потому что AI всё сделает сам». Наоборот — AIDD переиспользует и усиливает практики Software Engineering, переформулируя их под AI-first реальность. Без этих практик AIDD вырождается в vibe coding.

TDD (Test-Driven Development). В AIDD TDD — не один из вариантов, а обязательный quality-gate. Причина структурная: человек физически не может прочитать и осмыслить каждую AI-сгенерированную строку (объёмы генерации слишком велики), поэтому единственный масштабируемый способ верификации — автоматические тесты. Конкретно применяется классический цикл Red-Green-Refactor, но распределение ролей иное:

Шаг TDD Классический TDD AIDD
Формулировка цели (Input → Output) Человек Человек (часто с помощью AI)
Тип/интерфейс функции Человек Человек (часто с AI)
Написание тестов Человек AI генерирует, человек ревьюит
Red: запуск тестов до реализации Человек AI или CI
Реализация Человек AI
Green: запуск тестов Человек AI или CI
Рефакторинг Человек AI предлагает, человек валидирует

В AIDD тесты пишутся до реализации — это задаёт AI чёткий контракт: реализация считается готовой, когда тесты проходят. Без этого порядок обратный: код генерируется, потом под него «причёсываются» тесты, что снижает их ценность как спецификации поведения.

Spec-Driven Development (SDD). В AIDD спецификации объявляются единым источником истины (single source of truth) для всей работы. Это прямое усиление классической идеи requirements engineering, перенесённое на AI-контекст: спецификация читается и человеком, и AI-агентом, и CI. Если спецификация и код расходятся — считается правильной спецификация (а код либо исправляется, либо спека обновляется через явное решение). Конкретный артефакт SDD в AIDD — проектный «конституционный» файл (AGENTS.md, CLAUDE.md или аналог), в котором зафиксированы правила, контекст и история решений.

BDD (Behavior-Driven Development). Прямо в канон AIDD не входит, но концептуально укладывается как частный случай SDD: Gherkin-сценарии (Given / When / Then) — это исполнимые спецификации на естественном языке, которые AI читает напрямую, а тест-раннер исполняет. BDD-сценарии становятся особенно ценными в AIDD как bridges между бизнес-требованиями и тестовым покрытием.

Code Review. В AIDD ревью не исчезает, а автоматизируется и встраивается в цикл. Часть проверок выполняет сам AI (встроенные skill-ревьюеры: дублирование, нарушение конвенций, потенциальные дефекты — см. инструменты ниже), часть — человек. Принцип: человек ревьюит спецификации и архитектурные решения, AI-ревьюер — соответствие кода конвенциям и стандартам. Это разделение критично: если попытаться ревьюить человеком весь AI-сгенерированный код построчно, throughput методологии обнулится.

CI/CD. В AIDD CI становится носителем quality-gate: каждый коммит прогоняет тесты, линтеры, статический анализ, проверки безопасности. Деплой — по возможности автоматический (continuous deployment). Характерная особенность AIDD-проектов: частота коммитов и деплоев значительно выше, чем в классической разработке (десятки в день), что требует зрелого CI/CD.

ADR (Architecture Decision Records). В AIDD ADR — обязательный артефакт: каждое архитектурное решение фиксируется короткой запиской (контекст → рассматриваемые варианты → выбранное решение → последствия). Причина: AI-агент в следующей сессии должен знать почему выбрано именно это решение, иначе он начнёт «переизобретать» альтернативы. ADR хранится под контролем версий рядом с кодом и подгружается в контекст агента.

Резюме: AIDD — это не отмена, а переформулировка классического SWE под AI-first реальность. TDD становится автоматическим gate’ом; spec-driven — единым источником истины; code review — гибридным (AI + человек); CI/CD — высокочастотным; ADR — обязательным. Проект, который применяет AI без этих практик, не является AIDD — это vibe coding любой степени интенсивности.

Артефакты AIDD-проекта

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

idea.md — фиксация идеи

Самый ранний артефакт: краткая запись изначальной идеи продукта или фичи, сформулированная до какой-либо технической проработки. Цель — превратить хаотичную мысль в зафиксированную отправную точку, от которой можно вести проектирование. Часто idea.md — первый файл, который создаётся в проекте, и из него далее «вырастает» vision.md.

# Идея: <название>

## Суть
<2–3 предложения: что делаем, для кого, какую проблему решаем>

## Ключевые свойства
- <свойство 1>
- <свойство 2>
- <свойство 3>

## Что НЕ входит (out of scope)
- <явное ограничение 1>
- <явное ограничение 2>

idea.md не претендует на полноту — его задача зафиксировать направление. Подробная проработка переносится в vision.md.

vision.md — техническое видение проекта

Главный проектирующий артефакт: развёрнутое техническое видение, в котором зафиксированы все ключевые решения до начала кодогенерации. vision.md — это и техническое задание, и архитектурный документ, и источник контекста для AI-агента в каждой последующей сессии. Именно через vision.md методология противодействует склонности LLM к «универсальным космолётам»: явно фиксируется, что не нужно делать, какие принципы соблюдать (KISS, YAGNI, MVP, Fail Fast), какой стек принят.

Типовая структура vision.md:

# Vision: <название проекта>

## Обзор
Кратко: что это, для кого, primary user journey.

## Цели и не-цели (Goals / Non-Goals)
- Goals: <что проект должен достичь>
- Non-Goals: <что явно не делаем>

## Технологический стек
- Язык/ runtime: ...
- Фреймворк: ...
- Хранилище: ...
- Инфраструктура: ...

## Принципы разработки
- KISS, YAGNI, MVP, Fail Fast, итеративная разработка
- Явный запрет на оверинжиниринг

## Архитектура
- Слои приложения, диаграмма (текстовая / mermaid)
- Поток данных

## Модель данных
- Ключевые сущности, их поля и связи

## Работа с внешними зависимостями
- LLM-провайдер, интерфейс доступа (например, OpenAI client)
- Внешние API

## Мониторинг и логирование
- Что логируем, в каком формате, куда
- Метрики и алерты

## Сценарии работы
- Основные use cases (последовательно)

## Деплой
- Окружения (dev / prod)
- Способ развёртывания (Docker, serverless, ...)

## Конфигурирование
- Где хранятся настройки, формат, секреты

Критически важно: vision.md не пишется одним заходом. В AIDD он создаётся итеративно — совместно с AI раздел за разделом, с уточняющими вопросами и согласованием каждого блока. Параллельно с проектированием выбранные архитектурные решения фиксируются как ADR (см. ниже).

conventions.md — соглашения по разработке

Файл, в котором зафиксированы правила написания кода и организации проекта — «контракт» между командой и AI. conventions.md ссылается на vision.md и не дублирует его содержание: vision описывает что строим, conventions — как пишем код. Включает не только желаемое поведение, но и явные запреты («что категорически нельзя»).

# Conventions

## Ссылка на контекст
- Техническое видение: @vision.md

## Структура проекта
- <правила организации директорий>

## Стиль кода
- <языковые конвенции, linter-конфиг>
- Именование, форматирование

## Обязательные практики
- TDD: тесты до реализации
- Обработка ошибок: <паттерн>
- Логирование: <формат>

## Явные запреты
- Не добавлять зависимости без явного согласования
- Не писать «универсальные» абстракции без потребности
- Не нарушать KISS / YAGNI
- Не коммитить секреты

## Работа с AI
- Перед генерацией — план
- После генерации — тесты и ревью
- Обновлять прогресс в tasklist

tasklist.md — план работы

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

# Tasklist

## Прогресс
| Итерация | Статус | Дата |
|---|---|---|
| 1. Эхо-бот | ✅ Done | 2026-07-28 |
| 2. Интеграция с LLM | 🔄 In progress | — |
| 3. Память диалога | ⬜ Todo | — |
| ... | ... | ... |

## Итерация 1: Эхо-бот
- [x] Скелет проекта, конфиг
- [x] Telegram-обработчик
- [x] Эхо-ответ
- [x] Тесты
- [x] Коммит

## Итерация 2: Интеграция с LLM
- [ ] OpenAI client-обёртка
- [ ] Обработчик сообщения → LLM → ответ
- [ ] Тесты с mock-провайдером
- [ ] Коммит

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

workflow.md — соглашение о процессе работы

Если conventions.md фиксирует правила кодирования, то workflow.md фиксирует правила процесса: в каком порядке работать, когда AI должен спрашивать разрешения, когда действует самостоятельно, как переходить между итерациями. По сути — это та самая ментальная модель цикла AIDD (см. выше), переведённая в конкретный контракт.

# Workflow

## Принципы
- Сначала планируем, потом делаем
- Каждая итерация завершается тестами и ревью
- Обязательное подтверждение перед переходом к следующему этапу

## Порядок работы
1. Прочитать @vision.md и @tasklist.md
2. Выбрать следующую невыполненную задачу
3. Предложить план реализации (файлы, подход) — остановиться
4. После согласования — реализовать
5. Запустить тесты, обновить прогресс в tasklist
6. Сделать коммит
7. Запросить переход к следующей итерации

Rules — проектные правила для AI-среды

conventions.md и workflow.md — документы для человека. Чтобы AI-среда (Cursor, Claude Code, Copilot, OpenCode) автоматически учитывала их при каждом обращении, существуют механизмы проектных правил. Они различаются по названию у разных инструментов, но идея одна: текст инструкций, который подмешивается в контекст модели на каждом вызове.

  • Cursor Rules (.cursor/rules/*.mdc) — файлы правил Cursor с указанием режима применения: Always (всегда в контексте), Manual (по явному обращению), Specific files (при работе с определёнными путями), Intelligent (AI сам решает).
  • AGENTS.md в корне репозитория — де-факто стандарт для CLI-агентов (Claude Code, OpenCode, Codex и др.): инструкции по навигации по проекту, работе с контекстом, уважению к vision-документу.
  • CLAUDE.md — специфичный для Claude Code «конституционный» файл: правила, контекст, история решений, на которые агент обязан опираться.
  • custom instructions / system prompt overrides — в большинстве AI-IDE есть возможность задать глобальные или проектные инструкции.

Принцип общий: правила всегда в контексте, поэтому их делают лаконичными (следуют KISS) и не дублируют vision.md — они ссылаются на него.

ADR — архитектурные решения

Architecture Decision Records — короткие записи (по одному файлу на решение), фиксирующие: контекст, рассмотренные альтернативы, выбранное решение и его последствия. В AIDD ADR играют двойную роль: и средство коммуникации в команде, и контекст для AI в будущих сессиях. Без ADR агент, столкнувшись с архитектурным выбором, будет заново «переизобретать» альтернативы, уже рассмотренные и отвергнутые.

# ADR-001: Выбор LLM-провайдера через OpenRouter

## Контекст
Нужен единый интерфейс доступа к нескольким LLM (OpenAI, Anthropic, open-source)
с возможностью переключения без переработки кода.

## Рассмотренные варианты
1. Прямая интеграция с каждым вендором — много кода, сложность поддержки.
2. OpenRouter с доступом через OpenAI client — единый интерфейс, переключение моделей.

## Решение
Вариант 2: OpenRouter + OpenAI client.

## Последствия
- + Единый интерфейс, лёгкое переключение моделей.
- − Дополнительный сетевой хоп, зависимость от OpenRouter.

Тесты — quality-gate

В AIDD тесты — не отдельный артефакт «после кода», а часть цикла: они пишутся до реализации (TDD-стиль) и являются единственным масштабируемым способом верификации AI-сгенерированного кода. Покрытие формируется по тестовой пирамиде: быстрые unit-тесты в основании, интеграционные в середине, E2E на вершине. Unit-тесты должны быть молниеносными — без обращения к внешнему состоянию, через dependency injection и моки.

intro.md — onboarding-документация

Артефакт, который создаётся после реализации (или итеративно в ходе неё): техническое описание проекта для быстрого ознакомления нового разработчика — или того же AI в новой сессии. Включает архитектурную диаграмму, описание потоков данных, инструкции по развёртыванию, ссылки на ключевые файлы. В AIDD onboarding-документация часто генерируется самим AI по уже готовому коду, что решает классическую проблему «доки устарели».

Все артефакты — под контролем версий, в одном репозитории с кодом. Это не пожелание, а требование: без version-controlled спецификаций и ADR AI теряет контекст между сессиями и методология перестаёт работать.

Жизненный цикл (AI-DLC)

Операционная конкретика AIDD формализована AWS как AI-Driven Development Life Cycle (AI-DLC) — методология, в которой AI встроен в ткань SDLC, а не добавлен как надстройка. AI-DLC опирается на два измерения:

  • AI Powered Execution with Human Oversight. AI систематически создаёт детальные планы работ, активно ищет уточнения и руководство, а критические решения делегирует человеку. Только человек обладает контекстным пониманием бизнес-требований, нужным для информированных выборов.
  • Dynamic Team Collaboration. Поскольку AI берёт на себя рутину, команда объединяется в пространстве совместного решения задач: реалтайм-проблемсолвинг, креативное мышление, быстрые решения. Сдвиг от изолированной работы к высокоэнергетичной командной работе ускоряет инновации.

Жизненный цикл состоит из трёх фаз, каждая из которых обогащает контекст для следующей:

Inception (Начало). AI преобразует бизнес-замысел в детальные требования, истории и единицы работы через «Mob Elaboration» — активную валидацию вопросов и предложений AI всей командой. Результат фазы — зафиксированные требования и декомпозиция на единицы работы.

Construction (Построение). На основе валидированного контекста из Inception AI предлагает логическую архитектуру, доменные модели, кодовое решение и тесты через «Mob Construction» — команда в реальном времени даёт уточнения по техническим решениям и архитектурным выборам. Результат фазы — реализованная и протестированная функциональность.

Operations (Эксплуатация). AI применяет накопленный в предыдущих фазах контекст для управления infrastructure-as-code и развёртываниями под контролем команды. Результат фазы — развёрнутое и поддерживаемое решение.

   Inception              Construction            Operations
 ┌───────────┐         ┌──────────────┐       ┌──────────────┐
 │ Замысел   │ ──▶     │ Архитектура, │ ──▶   │ IaC, деплой, │
 │ → требова-│         │ модель, код, │       │ мониторинг   │
 │   ния,    │         │ тесты        │       │              │
 │   единицы │         │ (Mob         │       │ (под контролем
 │   работы  │         │  Construction)│      │   команды)   │
 │ (Mob      │         └──────────────┘       └──────────────┘
 │  Elabor.) │               ▲                       ▲
 └───────────┘               │                       │
        │            контекст фазы           контекст фаз
        └───────────◀────────┴──────────────◀────────┘
                  persistent context в репозитории

Ключевые терминологические сдвиги AI-DLC по сравнению с классическим Agile:

  • Спринты → bolts. Bolt — короткий, интенсивный рабочий цикл, измеряемый часами или днями, а не неделями. Подчёркивает скорость и непрерывность доставки.
  • Эпики → units of work (единицы работы). Единица работы — самодостаточный, валидируемый фрагмент функциональности, проходящий полный цикл AIDD.
  • Остальная Agile-лексика переосмысляется аналогично: Standup → синхронизация по AI-плану, Retrospective → корректировка правил и спецификаций.

Важное свойство AI-DLC — persistent context across sessions. AI сохраняет и поддерживает контекст между фазами, складывая планы, требования и артефакты дизайна в репозиторий проекта. Это обеспечивает бесшовное продолжение работы между многими сессиями — без необходимости каждый раз «с нуля» погружать агента в проект.

Роли: человек и AI

В AIDD распределение ответственности между человеком и AI перестраивается радикально — но не в пользу устранения человека, а в пользу его перехода на более высокий уровень абстракции. Модель «оркестратор + исполнитель».

Роль AI (primary producer):

  • Генерация кода по спецификации и в рамках конвенций.
  • Написание тестов (по утверждённому плану и типам).
  • Генерация документации и onboarding-материалов.
  • Ревью кода на соответствие конвенциям (встроенный ревьюер).
  • Поиск и устранение дефектов по фидбеку.
  • Управление инфраструктурой как кодом (IaC).
  • Ответы на уточняющие вопросы и выявление пробелов в контексте.

Роль человека (orchestrator и decision maker):

  • Постановка задачи в виде спецификаций (vision.md, conventions.md, task-декомпозиция).
  • Принятие архитектурных решений и их фиксация как ADR.
  • Валидация вывода AI: соответствие спецификации, качество, безопасность.
  • Принятие решений в точках неопределённости (когда AI обращается с вопросом).
  • Ревью спецификаций и архитектурных выборов (не построчное ревью кода — это делает AI-ревьюер).
  • Поддержание «конституционного» файла правил (AGENTS.md / CLAUDE.md).
  • Обучение и калибровка правил по мере развития проекта.

Принцип Human-Verified: человек остаётся decision maker’ом. AI может действовать автономно в рамках зафиксированных конвенций, но выход за эти рамки (новая архитектура, изменение принципов, рискованные решения) требует явного человеческого подтверждения. Это не «ручной контроль ради контроля», а разделение по типу решений: рутинные и механические — AI, принципиальные и контекстозависимые — человек.

Профиль разработчика: M-Shaped

Сдвиг ролей меняет оптимальный профиль разработчика. В традиционной разработке доминировали два идеала:

  • I-shaped (специалист) — глубокая экспертиза в одном домене, остальное — на поверхностном уровне. Хорошо для крупных команд с узким разделением.
  • T-shaped — глубоко в одном домене + широкая база по смежным. Классический full-stack-идеал 2010-х.

AIDD делает практически достижимым третий профиль — M-shaped: глубокая экспертиза в 2–4 комплементарных доменах одновременно (например, backend + DevOps + ML + продуктовая аналитика). До AI такой профиль был практически невозможен: времени жизни не хватало, чтобы набрать глубину в нескольких областях. В AIDD рутинная реализация делегируется AI, и человек фокусируется на архитектуре и валидации — что делает глубину в нескольких доменов реалистичной.

Профиль Форма Глубина Историческая достижимость
Specialist I 1 домен Норма для больших команд
Generalist плоско мелко во многих Хорош для прототипов
T-shaped T 1 глубокий + широкая база Full-stack-идеал 2010-х
M-shaped M 2–4 глубоких комплементарных Достижим в AIDD

Важные оговорки по M-shaped-профилю:

  • Глубина домена всё ещё имеет значение — M-shaped не означает «поверхностно везде».
  • Домены должны быть комплементарны (frontend + backend + DevOps — синергичны; ML research + legal compliance — трудно совместить).
  • AI не заменяет многолетнюю специализированную экспертизу в критичных областях — безопасность, regulatory compliance, safety-critical системы, продвинутый research по-прежнему требуют глубокой «заработанной» экспертизы.
  • M-shaped — это capability multiplier, not a magic solution: организационный контекст (структура, культура, риск-аппетит крупного enterprise) может требовать формальных handoffs и specialist-verification.

Инструментарий AIDD

Инструментальный слой AIDD быстро развивается. Ниже — карта по категориям; конкретные инструменты упомянуты как ориентиры, а не как рекомендации (рынок меняется за месяцы).

AI-IDE (редакторы с AI в ядре)

Редакторы, в которых AI — основа workflow, а не надстройка: встроенный чат, inline-редактирование, агентский режим, управление правилами проекта.

  • Cursor — AI-first форк VS Code с режимами Composer/Agent, системой Cursor Rules (.mdc), таб-комплецией.
  • Windsurf (Codeium) — AI-IDE с агентским режимом Cascade.
  • Zed — высокопроизводительный редактор с multiplayer-режимом и AI-интеграциями.
  • VS Code + AI-расширения (Copilot, Cline, Continue) — переходный вариант: AI как расширение классического редактора.
  • Kiro (Amazon) — IDE со встроенным spec-driven процессом: спецификации генерируются и валидируются внутри редактора.
  • Qoder (Alibaba) — помимо spec-driven, включает автогенерацию Repo Wiki.

AI-CLI и автономные агенты

CLI-инструменты, работающие из терминала: читают кодовую базу целиком, выполняют многошаговые задачи, коммитят. Это «напарник в терминале», снимающий изоляцию соло-разработчика.

  • Claude Code (Anthropic) — агент для терминала с поддержкой CLAUDE.md, subagents, системы Tasks; один из наиболее цитируемых в AIDD-материалах инструментов.
  • Gemini CLI / Gemini Code Assist (Google) — CLI и IDE-интеграция.
  • GitHub Copilot CLI — CLI-расширение экосистемы Copilot.
  • OpenAI Codex CLI — агент от OpenAI.
  • OpenCode, Aider, Cline — open-source и сторонние агенты с похожим функционалом.

MCP (Model Context Protocol)

MCP — открытый протокол (предложен Anthropic) для подключения AI-агентов к произвольным инструментам, базам данных и сервисам. Неофициальное название — «USB для AI»: единый интерфейс, через который агент получает доступ к файлам, репозиториям, БД, API, системам мониторинга. В архитектуре AIDD MCP снимает главную боль интеграций — раньше для каждого внешнего ресурса нужен был свой специализированный код; теперь любой MCP-совместимый сервер доступен любому MCP-совместимому агенту.

Фреймворки AIDD

Готовые наборы практики, объединяющие CLI, агентов, навыки и промпт-шаблоны:

  • AIDD Framework (Parallel Drive, Эрик Эллиотт) — open-source: AIDD CLI для бутстрапа проекта, agent runtime (workflow от product discovery до коммита и релиза), библиотека skills, серверный фреймворк (лёгкая альтернатива Express), утилиты. Включает встроенные команды: /discover, /task, /execute, /review, /log, /commit, /user-test.
  • Специализированные skill-системы — каталоги переиспользуемых модулей предметной экспертизы (custom instruction files, контекстные фреймворки), которые агенты подгружают по необходимости.

Промпт-языки

Для простых промптов естественный язык оптимален, но для сложной оркестрации (сохранение состояния, явный control flow, типизация) используются псевдокодовые языки:

  • SudoLang (Эрик Эллиотт) — декларативный, constraint-based, interface-oriented псевдокод для промптинга LLM. По утверждению автора, экономит 20–30% токенов по сравнению с естественным языком за счёт структурных шаблонов и типизации.

Системы правил и навигации по проекту

  • .cursor/rules, AGENTS.md, CLAUDE.md — описаны в разделе артефактов.
  • index.md в поддиректориях — практика, при которой каждая папка AI-системы содержит индексный файл, позволяющий агенту понять содержимое без чтения всех файлов (progressive discovery).

Инструментарий — быстро меняющийся слой; методология — устойчивый. AIDD как методология не зависит от конкретного инструмента: практики спецификаций, тестов и валидации переносятся между Cursor, Claude Code, Windsurf и любым будущим инструментом.

Промпт-инжиниринг в AIDD

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

Preamble (преамбула). Секция промпта, задающая контекст, роли, задачу и ключевые термины перед основным запросом. В AIDD преамбула часто выносится в project rules и подмешивается автоматически — чтобы не повторять контекст в каждом обращении.

Role-Based Prompting. Явное задание AI роли или персоны («senior backend engineer», «security reviewer», «product manager»). Активирует семантические кластеры темы, углубляет связность и релевантность вывода. В multi-agent системах каждый агент имеет свою постоянную роль.

Constraint-Based Prompting. Формулировка требований в виде явных ограничений: положительных («включить X», «использовать Y») и отрицательных («избегать Z», «не добавлять зависимости без согласования»). Производная от constraint-based programming (Иван Сазерленд, 1960-е). Особенно полезна для направления генерации под стандарты проекта — по сути, это и есть программная форма conventions.md.

Few-Shot и Zero-Shot Prompting. Few-shot — 2–5 примеров желаемого вывода в промпте; zero-shot — без примеров, полагается на способность модели к генерализации. В AIDD few-shot применяется для задач со строгим форматом (JSON-вывод, код по шаблону). Предостережение: примеры могут «утечь» в вывод — иногда лучше template-строки или явные constraints.

Chain-of-Thought (CoT). Пошаговое рассуждение модели перед финальным ответом. Улучшает точность на сложных задачах (математика, логика, архитектурный выбор). В AIDD CoT часто неявно встроен в цикл: шаг «План» с требованием развернуть рассуждение перед генерацией.

Prompt Chaining. Связывание промптов, где вывод одного — вход следующего. Помогает управлять контекстом в длинных взаимодействиях и декомпозировать сложную задачу. На уровне проекта prompt chaining превращается в agent orchestration (см. ниже).

Iterative Refinement. Постепенное улучшение ответа серией follow-up-промптов. Главная связка с другими техниками: iterative refinement + constraint-based prompting через метапрограмму (см. ниже) — сохранённый workflow, который можно переиспользовать. Особенно полезно для сложных и творческих задач, где один проход не даёт приемлемого качества.

Metaprogramming. Программы (метапрограммы), порождающие или манипулирующие другими программами. В AIDD метапрограмма — это промпт-шаблон, кодифицирующий практики проекта (стек, инструменты, конвенции), превращающий разовое взаимодействие в переиспользуемый процесс. Типовые применения: автоматизация feature-planning, story mapping, генерация state-management слоя, UI-компонентов, документации, unit-тестов — с соблюдением практик конкретного стека. Метапрограмма становится «записью» всех итеративных уточнений, накопленных при решении задачи.

RAG (Retrieval Augmented Generation). Подключение внешнего знания к генерации: существующие кодовые базы, документация, best practices, корпоративные стандарты. В AIDD RAG критичен: без него AI опирается только на свои обучающие данные и текущий промпт; с RAG — на актуальное состояние проекта и признанные практики. Подробнее про RAG как технику построения AI-приложений — за рамками этой статьи.

Multi-Agent Systems и AI Orchestration. Система из нескольких специализированных агентов, ведущих разные фазы lifecycle’а: product discovery → project management → code generation → documentation → testing → review → deployment. AI Orchestration — координация нескольких моделей/инструментов/агентов в сложных workflow так, чтобы они работали согласованно. В зрелом AIDD-проекте orchestration — не ручное связывание промптов, а системная функция (через MCP, фреймворки, skill-системы).

Automatic Prompt Optimization. Автонастройка промптов методами ML (генетические алгоритмы, RL). Пока нишевая, но перспективная техника: промпты перестают быть ручным артефактом и становятся оптимизируемым параметром. Качество промптов измеряется через метрики LLM (см. Метрики LLM).

Главный сдвиг AIDD-промпт-инжиниринга относительно «обычного»: промпт — не одноразовый запрос, а производственный актив, который версонируется, ревьюится и улучшается итеративно, как код.

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

AIDD — не универсальный ответ. Эффективность методологии сильно зависит от типа задачи, зрелости проекта и характера принимаемых решений. Ниже — карта по режимам применимости.

Где AIDD работает хорошо:

  • Greenfield-проекты. Новые проекты без легаси — идеальная среда: спецификации пишутся с нуля, нет сопротивления существующего кода.
  • MVP и прототипы production-качества. AIDD позволяет за дни, а не месяцы, получить работающий продукт с тестами и документацией — при условии соблюдения принципов (без этого вырождается в vibe coding).
  • Рутинная функциональность (CRUD, интеграции, boilerplate). Задачи с предсказуемой структурой — самая сильная сторона AI-генерации.
  • Рефакторинг и миграции. Переписывание модуля с сохранением поведения, миграции между версиями фреймворков — AI хорошо справляется при наличии тестового покрытия как oracle.
  • Документация и onboarding. Генерация технической документации по готовому коду — практически «бесплатный» выигрыш AIDD.
  • Покрытие тестами. Генерация unit-тестов по существующему коду или спецификациям.

Где применять с осторожностью:

  • Legacy-код без тестов. AIDD требует тестов как quality-gate; в проекте без покрытия gate не работает, и генерация становится рискованной. Сначала вводится тестовое покрытие, потом — AIDD.
  • Крупные enterprise-системы со сложными интеграциями. Здесь persistent context и orchestration критичны, но организационная структура (формальные handoffs, specialist-verification, риск-аппетит) может требовать классического разделения ответственности.
  • Домены с регулируемым комплаенсом. Финтех, медицина, оборонка — там, где требуется формальная верификация и аудитируемость, человеческая экспертиза и формальные процедуры не заменяются AI.

Где AIDD не заменяет человека:

  • Безопасность (security). AI-ревьюер находит типовые уязвимости (XSS, SQL injection, NPE), но тонкие архитектурные дыры безопасности требуют специализированной экспертизы. AIDD — это первый фильтр, не последний.
  • Safety-critical системы. Авиация, медицина, автомобилестроение — там, где ошибка стоит жизней, формальная верификация и сертификация остаются прерогативой человека.
  • Продвинутый research. novel-алгоритмы, фундаментальные ML-исследования — области, где AI генерирует по известным паттернам, а не создаёт принципиально новое.
  • Стратегические архитектурные решения в крупных системах. Решения с долгосрочными последствиями (выбор базы данных на десятилетие, стратегия микросервисного разрезания) требуют человеческого контекста, которого у AI нет.

Практическое правило: чем выше цена ошибки и чем меньше формализуема задача — тем больше решений остаётся за человеком. AIDD не отменяет этого правила, а делает границу явной через ADR и принцип Human-Verified.

Преимущества и риски

Методология — всегда компромисс. Ниже сбалансированная карта преимуществ и рисков AIDD.

Преимущества:

  • Velocity. Прирост скорости разработки — основной и самый заметный эффект. Задачи, ранее занимавшие недели, выполняются за дни или часы. Источник ускорения — не «быстрее печатает код», а делегирование рутины + итеративный цикл с быстрым фидбеком.
  • Качество через дисциплину. Парадоксальный на первый взгляд эффект: при правильном применении AIDD повышает качество, а не снижает его. Причина — обязательный quality-gate (тесты, линтеры, ревью) применяется систематически, а не «когда есть время». Сгенерированный код, прошедший gate, часто более единообразен, чем написанный человеком в спешке.
  • DX (Developer Experience). Сдвиг фокуса с рутинной реализации на архитектуру и решения повышает удовлетворённость разработчика и снижает когнитивную нагрузку.
  • Рыночная адаптивность. Короткие циклы (bolts) и непрерывная валидация позволяют быстро реагировать на изменения требований и фидбек пользователей.
  • Прослеживаемость. При version-controlled спецификациях и ADR каждое решение имеет объяснение — улучшается онбординг и аудируемость.
  • Доступность M-shaped-профиля. Один разработчик с AI покрывает функционал, ранее требовавший нескольких силосных специалистов.

Риски:

  • Зависимость от модели и вендора. Качество генерации напрямую зависит от используемой LLM; смена модели или версии может потребовать перенастройки промптов и правил. Подробнее — Бенчмарки LLM и Параметры LLM.
  • Стоимость. Активная AI-генерация стоит денег (токены коммерческих моделей) и времени (latency reasoning-моделей). Экономика складывается из тарифа вендора и параметров инференса — не учитывать её значит получить неожиданный счёт.
  • Галлюцинации. LLM уверенно генерирует правдоподобный, но неверный код (несуществующие API, выдуманные параметры библиотек). Quality-gate перехватывает часть, но не все — критично для production-кода.
  • Дублирование кода. Эмпирический факт: GitClear зафиксировал 8× рост дублирования с внедрением AI. Без явных skill-ревьюеров и enforcement DRY дублирование накапливается.
  • Рост дефектов при отсутствии дисциплины. DORA связывает AI-внедрение с +9% дефектов и снижением стабильности — именно в тех проектах, где AI добавлен без методологии (vibe coding).
  • «AI theater». Формальное применение AIDD без понимания принципов: спецификации пишутся «для галочки», тесты не запускаются, ADR не ведётся. Внешне похоже на AIDD, по эффекту — vibe coding с дополнительными накладными расходами.
  • Размывание экспертизы команды. При чрезмерной делегировании рутины команда может терять глубокое понимание кодовой базы — что становится критичным в точках, где AI ошибается и нужно ручное вмешательство.
  • Безопасность и утечки. Загрузка проприетарного кода или контекста в коммерческие модели — риск утечки интеллектуальной собственности; требуется политика использования моделей и приватность данных.

Сбалансированный вывод: AIDD даёт значительный выигрыш в скорости и — при дисциплине — в качестве, но не бесплатен. Стоимость — методологические накладные расходы (спецификации, тесты, ADR, правила) + инструментальная зависимость. Проект, не готовый нести эти накладные, получит vibe coding под вывеской AIDD со всеми его рисками.

Источники и материалы

Первоисточники и ключевые публикации

Связанные материалы базы знаний

  • Метрики LLM — как системно оценивать качество моделей, контролировать деградацию и принимать решения о выборе. База для quality-gate и оценки AI-генерации.
  • Параметры LLM — настройки инференса (temperature, top_p, max_tokens, seed и др.), определяющие характер генерации. Влияют на поведение AI в каждой точке цикла AIDD.
  • Бенчмарки LLM — стандартизированные тесты моделей; основа для выбора модели под AIDD-проект и оценки зависимости от вендора.