Agentic Agile: почему ИИ-разработка требует процессов, а не только промптов

Когда в команду приходит ИИ-агент, первый рефлекс разработчика — написать лучший промпт. Чуть позже появляется файл-спецификация, потом система «промпт + документ». Это работает. Но только пока задача помещается в один контекстное окно и не пересекается с другими.

Как только проект выходит за рамки одного модуля — начинается знакомое: агент делает «что-то похожее», но не то. Поведение дрейфует от сессии к сессии. Дефекты просачиваются в production, потому что никто не проверял на интеграции. Разработчик тратит больше времени на правки, чем сэкономил на генерации. Это не проблема модели — это проблема процесса. Именно его и решает Agentic Agile — подход, который адаптирует Agile-принципы для команд, где рядом с людьми работают ИИ-агенты.

Почему промпт не масштабируется

Prompt-driven development отлично работает на ограниченных задачах: написать функцию, отрефакторить модуль, сгенерировать тест. Это задачи с чётко ограниченным выводом. Но как только проект разрастается до нескольких модулей, внешних зависимостей и поведенческих контрактов — система ломается предсказуемым образом.

• Нет бэклога — работа обнаруживается в процессе реализации, а не планируется заранее
• Нет понятия «готово» — сессия заканчивается, когда разработчик доволен, а не когда выполнен контракт
• Нет поэтапной доставки — всё делается сразу, без возможности остановиться и переориентировать
• Нет governance — ограничения безопасности и правила валидации добавляются в конце, если добавляются вообще

Результат предсказуем: агент производит код, который работает изолированно, но ломается на интеграции. Поведение расходится между сессиями, потому что нет общего состояния, определяющего ожидаемое поведение. Более мощная модель не решает проблему — более способный агент с размытым ТЗ создаёт более изощрённый дрейф, а не меньший.

Плохая система победит хорошего человека — или агента — в любое время.

У. Эдвардс Демингтеоретик управления качеством (цитата в вольном переложении автора)

Документация как интерфейс между людьми и агентами

Agentic Agile предлагает простой ответ на вопрос «как агент узнаёт, как у вас принято»: задокументировать. Не для людей, а для агентов. Разница в том, что документы должны быть машиночитаемыми: структурированными, актуальными и привязанными к триггерам изменений.

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

			CLAUDE.md          # Правила работы для Claude (контекст, архитектура, git-процесс)
AGENTS.md          # Единый источник правил для всех AI-агентов (Claude, Copilot, Gemini и т.д.)
STYLE.md           # Кодстайл и типографические конвенции
.github/copilot-instructions.md  # Инструкции для GitHub Copilot
		

Ключевое правило: агент должен обновлять эти файлы сам, когда меняется что-то, на что они ссылаются. В CLAUDE.md или AGENTS.md прямо прописывается таблица — когда какой документ обновлять:

			| Документ     | Обновлять когда                              |
|--------------|----------------------------------------------|
| README.md    | Изменился scope проекта, setup или usage     |
| CLAUDE.md    | Изменился процесс, конвенции или структура   |
| STYLE.md     | Изменились соглашения о стиле                |
| API docs     | Добавлены, изменены или удалены endpoints    |
		

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

Агент как участник команды, а не инструмент

Большинство команд относятся к ИИ-агентам как к инструменту: выбрать модель, написать промпт, настроить параметры, получить продукт. Agentic Agile предлагает другую модель: агент — это полноправный участник команды. Каждое его действие — это действие разработки с теми же последствиями для кодовой базы, что и человеческий коммит.

Агенты создают файлы, вводят зависимости, пишут тесты. Они также могут обогащать человеческие промпты и спецификации, создавать тикеты в бэклоге, предлагать структуру эпиков. Если агент выполняет работу разработчика — он должен соблюдать дисциплину разработчика.

Та же инженерная дисциплина, которая не позволяет человеческим командам выкатывать сломанное ПО, применима и к командам «человек + агент»: структурированное планирование, чёткие acceptance criteria, инкрементальная доставка и ревью-гейты.

Microsoft Partner Tech Strategistиз статьи Agentic Agile

Команда, которая никогда не выпустила бы написанный человеком модуль без code review, не должна выпускать написанный агентом модуль без аналогичной проверки.

Тикеты со спецификацией вместо открытых промптов

Главный практический инструмент методологии — это issue в системе задач с жёсткой структурой. Не «добавь авторизацию», а полноценный контракт с несколькими обязательными секциями.

Шаблон agentic story включает:

• Summary — одно предложение: что именно доставляет эта история
• Scope — явный список файлов, которых касается история (предотвращает конфликты при параллельной работе агентов)
• Acceptance Criteria — конкретные, проверяемые условия, которые должны выполняться по завершении
• Negative Constraints — что история явно НЕ делает (предотвращает scope creep)
• File Ownership — карта владельца каждого файла в этой волне (critical для multi-agent parallelism)

Ключевая идея: агент работает против спецификации, а не открытого промпта. Условие завершения — не «хватит» или «мне нравится», а «контракт выполнен». Это устраняет «good enough» culture, которая иначе просачивается в каждую агентную сессию.

Волновое планирование для параллельной работы

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

Каждая волна — это набор историй, которые можно безопасно выполнять параллельно (нет конфликтов по файлам и контрактам). Между волнами — ревью-гейт: интеграция результатов, запуск CI, проверка инвариантов. Только после прохождения гейта запускается следующая волна.

В секции File Ownership тикета явно прописано: этот файл принадлежит данной истории в данной волне. Никакая другая история в той же волне не должна его касаться. Это не договорённость — это часть спецификации.

Governance с первого дня, а не в конце

Самая дорогостоящая ошибка при agentic-разработке — отложить governance на потом. Governance в этом контексте — это система контрольных гейтов: ограничения безопасности, правила валидации, обязательные ревью и автотесты. «Сначала поймём, что строим, потом добавим гардрейлы» — в человеческой разработке это спорно, в агентной — катастрофично. Агенты принимают решения на скорости выполнения, и без явных ограничений они успевают нарушить архитектурные инварианты или создать уязвимости задолго до того, как человек это заметит. Microsoft столкнулась с этим в собственном проекте: CI-пайплайн не был первой историей в бэклоге, и к моменту его добавления уже накопились проблемы, основанные на допущениях, которые никто не проверял. Это потребовало вернуться и переделать несколько фич.

Правило Agentic Agile: если архитектурные нарушения обнаруживаются на финальном ревью, а не во время выполнения историй — governance настроен слишком поздно. Перенесите его раньше.

Правило Agentic Agile: если архитектурные нарушения обнаруживаются на финальном ревью, а не при выполнении историй — governance слишком поздний. Перенесите его раньше.

• Ограничения безопасности — это acceptance criteria в тикетах, не отдельная фаза
• Ревью-гейты стоят между волнами выполнения, не в конце проекта
• CI/CD, линтер и автотесты — первая история, которую реализует команда
• Ревью «найди всё плохое» (adversarial code review) на каждой волне — агент специально проверяет свой код на уязвимости и несоответствие контрактам, а не просто убеждается, что «всё работает»

Ретроспектива с агентом

После нескольких волн разработки команда Microsoft ввела ретроспективный процесс: агент анализирует файлы сессий, git-логи, PR-комментарии и другие данные, ищет паттерны сбоев и формулирует конкретные рекомендации по процессу. Например: «в волне 3 у нас было 4 конфликта по файлу X — в следующей волне разбить его на два отдельных владельца» или «acceptance criteria в 6 историях не были проверяемы автотестами — нужен шаблон с обязательным полем test_coverage».

Это замыкает петлю: агент не только выполняет работу, но и участвует в анализе качества процесса. Закрытые тикеты и PR-комментарии становятся исторической базой для последующих итераций — что было сделано и почему. Новые требования фиксируются в новых тикетах с явными связями parent-child, а паттерны улучшений переходят в обновлённые context-файлы (CLAUDE.md, AGENTS.md), которые агент читает на следующей сессии.

Как начать: пошаговый план

Методология переносима: Microsoft проверила её на нескольких несвязанных проектах разных доменов. Паттерны (spec-first бэклог, поэтапное планирование, context-файлы для агентов) работают без привязки к конкретному стеку или модели.

1. Скопируйте agentic-agile-template — там готовые шаблоны тикетов, context-файлы и стартовая структура бэклога
2. Создайте context-файлы для агентов: CLAUDE.md / AGENTS.md / copilot-instructions.md с описанием проекта, стиля кода и процесса
3. Составьте высокоуровневые тикеты для основных capabilities проекта — включая отдельный тикет на CI/CD и автотесты
4. Попросите агента отсортировать и сгруппировать тикеты по волнам, учитывая зависимости и конфликты файлов
5. Возьмите первый тикет, уточните его structure по шаблону agentic story (scope, acceptance criteria, negative constraints)
6. Запустите агента с явной инструкцией: работать только по спецификации в тикете, никакой работы без associated issue
7. После каждой волны — ревью-гейт: интеграция, CI, проверка инвариантов
8. После нескольких волн — ретроспектива: попросите агента найти паттерны сбоев в логах

Выводы

Идея Agentic Agile не нова по сути — это фундаментальное наблюдение Agile, применённое к новой модели коллаборации. Что Agile обнаружил для человеческих команд, Agentic Agile обнаруживает для команд «человек + агент»: итерация, контракты и рефлексия предотвращают одни и те же классы проблем.

Сдвиг принципиальный: вместо «пусть агент разберётся» — «определи контракт, ограничь выполнение, валидируй результат». Это не ограничение агента, а уважение к скорости, с которой он принимает решения.

Методология проверена Microsoft на нескольких разных проектах и оказалась по-настоящему переносимой — работает без привязки к конкретному стеку, модели или домену. Это и есть настоящий тест: методология, работающая только там, где она была изобретена, — это не методология.

Полный манифест, шаблоны тикетов и context-файлы для агентов: microsoft/agentic-agile-template на GitHub. Оригинальная статья: Agentic Agile: Why Agent Development Needs Agile, Not Just Prompts.