SDLC для AI-агентов

Как перестроить процесс разработки: от передачи задач между людьми к spec-driven workflow

1 апреля 2026

Классический SDLC построен вокруг передачи задачи между ролями: аналитик формулирует требования, разработчик пишет код, QA проверяет результат. Каждый handoff - потеря контекста и время ожидания. AI-агенты инвертируют эту модель: агент ведёт задачу от спецификации до готового кода, а инженеры подключаются на контрольных точках. Но попытка вставить агента в существующий пайплайн "вместо разработчика" не работает - нужен другой процесс. Статья описывает как его построить, какие фреймворки существуют, и как внедрить это в организацию с уже выстроенным SDLC.

Историческая рамка: как менялся SDLC и почему агентам нужен новый Почему классический SDLC не работает с агентами Инвертированная модель: агенты работают, люди проверяют Истоки spec-driven подхода: от Мейера до Karpathy Spec-driven development как фундамент BMAD Method OpenSpec Spec Kit (GitHub) cc-sdd SPECTRE IDD (Intent-Driven Development) Сравнение и выбор Выбор фреймворка по размеру команды и зрелости Анатомия AI-driven задачи: от идеи до merge Инфраструктура контекста Управление задачами и контекстом снаружи Роли в новом SDLC Шесть режимов провала при внедрении spec-driven SDLC Внедрение в существующую организацию Метрики Риски и ограничения Практический пример: Hublix + OpenSpec Источники и смежные статьи

Историческая рамка: как менялся SDLC и почему агентам нужен новый

Прежде чем разбирать, что меняется с появлением агентов, полезно зафиксировать, откуда взялся сам SDLC и какие проблемы каждое следующее поколение пыталось решить. Без этой рамки spec-driven подход выглядит как очередной хайп, а не как закономерный шаг.

Waterfall (Royce, 1970): handoff как явление

Канонический waterfall обычно приписывают Уинстону Ройсу и его статье «Managing the Development of Large Software Systems» (Proceedings of IEEE WESCON, август 1970). Парадокс: Royce показал классическую последовательную диаграмму (requirements → design → implementation → verification → maintenance) именно как пример того, что не работает на крупных системах. Дальше в той же статье он описывает итеративные улучшения с обратной связью между фазами. Но запомнили только первую диаграмму, и в течение 1970-1980-х она стала контрактной моделью для DoD, NASA и крупного ентерпрайза. Передача артефакта между фазами (requirements → design document → code → test report) - первое формализованное появление handoff как явления в SDLC.

Spiral и iterative (Boehm, 1986)

Барри Боэм в статье «A Spiral Model of Software Development and Enhancement» (ACM SIGSOFT Software Engineering Notes, август 1986; переиздана в IEEE Computer, май 1988) предложил спиральную модель: вместо одного прохода по фазам - несколько итераций с risk assessment в начале каждой. Это первый широко принятый отказ от waterfall в пользу итераций. Боэм же в книге «Software Engineering Economics» (Prentice-Hall, 1981) количественно показал, что стоимость исправления дефекта растёт экспоненциально по мере продвижения вниз по фазам - аргумент, который до сих пор используется в защиту раннего проектирования.

Agile Manifesto (2001): отказ от тяжёлых артефактов

В феврале 2001 семнадцать практиков (включая Kent Beck, Martin Fowler, Ward Cunningham, Jeff Sutherland, Ken Schwaber) подписали Agile Manifesto. Четыре ценности явно противопоставили работающий софт исчерпывающей документации, сотрудничество с заказчиком - переговорам по контракту, реагирование на изменения - следованию плану. Это не отменяло handoff как таковой, но сильно сократило тяжесть передаваемых артефактов. Scrum (Schwaber/Sutherland, формализован к 2002) и Extreme Programming (Beck, «Extreme Programming Explained», 1999) стали двумя главными операционализациями.

Параллельно Kent Beck в той же XP-волне канонизировал Test-Driven Development («Test-Driven Development: By Example», Addison-Wesley, 2002): тест перед кодом как способ зафиксировать спецификацию поведения. Дэн Норт в «Introducing BDD» (Better Software, март 2006) вынес эту идею с уровня юнита на уровень сценария поведения. Подробнее об этой родословной - в статье о Spec Kit.

DevOps и continuous delivery (2009-2015)

Появление DevOps (термин закрепился после первой DevOpsDays в Генте в октябре 2009, организованной Patrick Debois) и continuous delivery («Continuous Delivery» Jez Humble и David Farley, Addison-Wesley, 2010) убрало последний крупный handoff внутри инженерии - между разработкой и operations. Идея: deployment - не отдельная фаза, а часть pipeline; инфраструктура - код; конвейер от commit до production автоматизирован и проходится за минуты. Это сократило цикл feedback с недель до часов и сделало возможным реальный CD в продуктовых компаниях.

«Software 2.0» (Karpathy, 2017): первый сигнал смены парадигмы

Андрей Карпати в эссе «Software 2.0» (Medium, ноябрь 2017) предложил рамку: классический софт пишется людьми на конкретных языках программирования (Software 1.0); ML-системы пишутся в форме датасетов и весов модели, а компилятором является градиентный спуск (Software 2.0). Эссе не про агентов, но это первая широко обсуждаемая попытка сказать вслух: SDLC, выстроенный вокруг человеческого автора кода, - не единственный возможный. С точки зрения 2026 года Karpathy недооценил третью волну: агентов, которые пишут Software 1.0, но управляются спецификацией. По сути, это синтез - человеческий код, но с не-человеческим автором.

Агенты как исполнители (Anthropic, 2024-2025)

В декабре 2024 Anthropic опубликовали «Building Effective Agents»: рамка для проектирования LLM-агентов с явным разделением workflows (предопределённая последовательность шагов) и agents (динамическое принятие решений). В 2025 в Claude Code появилась SKILL.md-система: переиспользуемые навыки с frontmatter-метаданными, которые автоматически инжектируются в контекст по триггерам. Это перевело разговор от «как промптить модель» к «какую инфраструктуру построить вокруг агента, чтобы он работал воспроизводимо». Параллельно вышло первое большое индустриальное измерение последствий - DORA Report 2025 зафиксировал, что наивный adoption AI-инструментов даёт +9% багов и +91% времени code review при 90% использовании.

Что именно меняется в 2024-2026

Каждое предыдущее поколение SDLC оптимизировало взаимодействие между людьми. Waterfall формализовал handoff как контракт. Agile сократил тяжесть передаваемых артефактов. DevOps убрал handoff dev/ops. Но во всех этих моделях исполнителем кода оставался человек, а артефакты (документация, тесты, спецификации) обслуживали этого человека. С появлением способных агентов исполнителем становится не-человек, и артефакты начинают обслуживать его. Это смещение и заставляет пересобирать SDLC заново.

SDD не отменяет ни waterfall, ни Agile, ни DevOps. Он добавляет ещё один контур: спецификация как контракт между человеком и агентом. Все предыдущие практики (CI/CD, тесты до кода, code review, infrastructure as code) остаются обязательными - без них агент производит больше плохого кода быстрее.

Почему классический SDLC не работает с агентами

Стандартный процесс разработки - это конвейер с передачей ответственности:

Этап Роль Артефакт Время ожидания
Анализ Аналитик/PM Требования в Jira Часы-дни
Приёмочные критерии QA / Аналитик Acceptance criteria, тест-кейсы Часы-дни
Дизайн Архитектор Техническое решение Часы-дни
Разработка Разработчик Pull Request Дни-недели
Тестирование QA Тест-репорт Часы-дни
Релиз DevOps/Release manager Deployment Часы

Проблема не в самих этапах - они логичны. Проблема в handoffs. Каждая передача задачи между людьми означает: ожидание в очереди, потерю контекста при передаче, синхронизацию через митинги и комментарии. На типичной задаче 70-80% lead time - это время ожидания, а не работы.

Даже если каждый участник ускоряет свою работу с помощью AI - аналитик быстрее пишет требования, разработчик генерирует код с Copilot, QA автоматизирует тест-кейсы - это не решает системную проблему. Handoffs остаются. Очереди остаются. Задача по-прежнему ждёт в backlog разработчика, потом в очереди на review, потом в очереди QA. AI ускоряет работу внутри каждого этапа, но не устраняет ожидание между ними.

AI-агенты работают иначе. За одну сессию агент читает спецификацию, анализирует кодовую базу, пишет код, создаёт тесты, запускает линтер, исправляет ошибки и формирует PR. Время выполнения - минуты, не дни.

Но у агентов есть ограничение: они stateless. Каждая сессия начинается с нуля. Агент не помнит предыдущих решений, не знает контекст проекта, не понимает бизнес-логику - если ему это не передали явно.

Попытка вставить агента в существующий пайплайн "вместо разработчика" - антипаттерн. Агент получает задачу из Jira, написанную для человека (с неявными допущениями, ссылками на устные договорённости, контекстом из предыдущих спринтов) - и генерирует код, который формально соответствует описанию, но не учитывает реальные constraints проекта.

DORA 2025 подтверждает: при 90% adoption AI-инструментов в команде зафиксировано +9% багов и +91% времени code review. Агенты генерируют код быстрее, но если процесс не адаптирован - качество падает, а нагрузка на review растёт.

Нужен не "тот же SDLC, но с агентом вместо разработчика", а другой процесс, спроектированный под свойства агентов.

Инвертированная модель: агенты работают, люди проверяют

В классическом SDLC человек - исполнитель, инструменты - средства. IDE подсвечивает ошибки, CI запускает тесты, Jira трекает прогресс. Но решения принимает и код пишет человек.

В AI-driven SDLC агент - исполнитель, человек - валидатор и архитектор контекста. Агент пишет код, запускает тесты, итерирует до зелёного билда. Человек определяет что делать (спецификация), обеспечивает контекст (rules, memory, knowledge base) и проверяет результат (review).

Что меняется для организации:

Раньше: 5-7 человек в команде. Аналитик пишет требования, 2-3 разработчика реализуют, QA тестирует, тимлид координирует. Пропускная способность - количество разработчиков × их скорость.

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

Инвертированная модель не означает "уволить всех и оставить одного человека с агентом". Она означает, что bottleneck смещается: раньше узкое место - скорость написания кода, теперь - качество спецификаций и скорость review.

Истоки spec-driven подхода: от Мейера до Karpathy

Spec-driven development в текущем виде - это не изобретение GitHub spec-kit и не реакция исключительно на LLM-агентов. Это пятая или шестая итерация одной идеи: спецификация - не комментарий и не отдельная документация, а первичный артефакт, из которого выводится остальное. Знание этой родословной нужно по практической причине: каждое поколение ломалось на одних и тех же антипаттернах, и у нынешнего нет иммунитета.

Дизайн как контракт (Meyer, 1988)

Бертран Мейер в книге «Object-Oriented Software Construction» (Prentice Hall, первое издание 1988, расширенное 1997) сформулировал Design by Contract: каждый метод имеет precondition, postcondition и инвариант класса; контракт встроен в синтаксис языка Eiffel и проверяется во время выполнения. Это первая инженерная попытка сделать спецификацию исполняемой в самом строгом смысле - не «документ рядом с кодом», а часть программы, которая падает при нарушении. DbC так и остался нишевым (overhead на ручное написание контрактов перевесил выгоду), но идея «спецификация - артефакт, а не комментарий» унаследована современным SDD напрямую.

Тест как спецификация поведения (Beck, 2002; North, 2006)

TDD и BDD - две родительские линии. Kent Beck в «Test-Driven Development: By Example» (Addison-Wesley, 2002) канонизировал red-green-refactor: тест перед кодом фиксирует поведение на уровне юнита. Дэн Норт в эссе «Introducing BDD» (Better Software, март 2006) сместил формат с «test_calculate_total» на «Given пустая корзина, When добавляется товар, Then total равен цене»; эту идею подхватил Cucumber (Aslak Hellesoy) и десятки других инструментов. SDD прямо использует BDD-формат в шаблонах: spec.md в Spec Kit содержит User Stories с acceptance scenarios в формате Given/When/Then, и эта связь явная.

API как первичный артефакт (Swagger, OpenAPI, Stripe)

Параллельно с BDD развивалась линия «спецификация интерфейса первична». Tony Tam опубликовал Swagger Specification в 2011, а в 2015 формат был передан Linux Foundation и переименован в OpenAPI Specification. В публикациях Brandur Leach (инженера Stripe, brandur.org) описывается, как Stripe использует OpenAPI как внутренний source of truth: код обработчиков, клиентские библиотеки и документация генерируются или сверяются со спецификацией. Это спецификация на уровне системы, не на уровне теста - но ограничена интерфейсом, не покрывает поведение и архитектурные решения.

SDD как операционализация для агентов (GitHub spec-kit, 2024-2025)

Команда GitHub spec-kit (открытый репозиторий github/spec-kit) в 2024-2025 формализовала фазы specify → plan → tasks → implement, где каждая фаза - артефакт, который человек ревьюит до перехода к следующей. Технически это синтез предшественников: User Stories и Given/When/Then из BDD, «спецификация как исполняемый артефакт» из DbC и OpenAPI, обязательность тестов до кода - из TDD (часто прописывается в constitution.md как NON-NEGOTIABLE-принцип). Новое - то, что спецификация теперь исполняется не компилятором и не тест-раннером, а LLM-агентом. Подробный разбор лестницы DbC → TDD → BDD → spec-as-API → SDD - в статье о Spec Kit.

Сдвиг автора: от человека к агенту (Karpathy, Anthropic)

Эссе «Software 2.0» Андрея Карпати (Medium, ноябрь 2017) и более позднее обсуждение «Software 3.0» в его публичных лекциях зафиксировали смещение: автор кода перестаёт быть единственно человеческим. У SDD есть прямой ответ: если кодом занимается агент, спецификация должна быть достаточно строгой, чтобы из неё выводился ожидаемый результат, и достаточно человекочитаемой, чтобы её ревьюил человек. Anthropic в декабре 2024 опубликовали «Building Effective Agents», разделив workflows и agents и формализовав паттерны (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer). В 2025 в Claude Code появилась SKILL.md-система: переиспользуемые навыки с frontmatter-метаданными, инжектируемые в контекст по триггерам. Это сдвинуло фокус с «как промптить» на «какую инфраструктуру построить вокруг агента».

Что унаследовано, что добавлено

Поколение Кто пишет спецификацию Кто исполняет Что унаследовало SDD
DbC (Meyer, 1988) Инженер Runtime/компилятор Идея исполняемой спецификации
TDD (Beck, 2002) Инженер Test runner Тесты до кода как принцип constitution
BDD (North, 2006) Инженер + продукт Cucumber-подобные runners Формат Given/When/Then в spec.md
OpenAPI (Tam, 2011; LF, 2015) Инженер API Code generators + validation Спецификация - source of truth, код выводится
SDD (GitHub spec-kit, 2024-2025) Инженер + продукт LLM-агент с human-in-the-loop Всё перечисленное + четыре фазы и review gates

Практическое следствие: если в команде уже работает какая-то spec-практика (например, OpenAPI для API-контрактов или BDD-сценарии для критичных flow) - адаптация SDD идёт быстрее, потому что культура spec-as-artifact уже есть. Если нет - сначала разворачивается базовая практика «текст до кода» на одном типе задач, и только потом подключается агент.

Spec-driven development как фундамент

Все зрелые AI-driven SDLC фреймворки сходятся в одном: спецификация до кода - обязательное условие. Причина проста: агент, получивший размытое описание, генерирует код, который формально соответствует запросу, но не решает реальную задачу.

OpenSpec формулирует это так: "AI coding assistants are powerful but unpredictable when requirements live only in chat history". SPECTRE идёт дальше: "Ambiguity is death" (SPECTRE) - чем точнее спецификация, тем дольше агент работает автономно без эскалации.

Ниже - детальный разбор шести фреймворков: что они добавляют в проект, как организованы артефакты, где стоят контрольные точки и как на основе накопленных артефактов строится экспертиза.

BMAD Method

Самый комплексный фреймворк. 12+ агентных ролей (PM, Architect, Developer, UX, QA, Scrum Master), 34+ workflows, модульная система расширений.

Что добавляется в проект

your-project/
├── _bmad/                        # Конфигурация: агенты, workflows, skills
└── _bmad-output/
    ├── planning-artifacts/
    │   ├── PRD.md                # Product Requirements Document
    │   ├── architecture.md       # Архитектурные решения
    │   └── epics/                # Эпики и user stories
    ├── implementation-artifacts/
    │   └── sprint-status.yaml    # Трекинг прогресса по спринтам
    └── project-context.md        # Общий контекст проекта

Фазы и контрольные точки

  1. Analysis (опционально) - product brief, PRFAQ, исследования. Контрольная точка: нет, фаза опциональна.
  2. Planning - PRD через workflow bmad-create-prd. Контрольная точка: PRD должен существовать до перехода к solutioning.
  3. Solutioning - architecture.md, эпики и stories. Контрольная точка: bmad-check-implementation-readiness валидирует когерентность всех документов.
  4. Implementation - sprint-status.yaml, код. Контрольная точка: sprint planning должен пройти до начала build-цикла.

Развитие артефактов

PRD обновляется при изменении scope. Architecture.md дополняется при архитектурных решениях в ходе реализации. Sprint-status.yaml - живой документ, отражающий текущее состояние. Scale-adaptive intelligence автоматически регулирует глубину каждого артефакта: для bug fix - минимальный набор, для enterprise feature - полный цикл.

Экспертиза по артефактам

Накопленные PRD и architecture.md формируют историю product decisions. Sprint-status.yaml даёт данные о velocity и паттернах. Party Mode позволяет запустить несколько агентных ролей в одной сессии для кросс-функциональной ревизии артефактов.

Несколько команд и sustainability

43K+ stars, активная ежедневная разработка, за фреймворком стоит BMad Code, LLC. Модульная система (BMM, TEA, BMGD, CIS) позволяет разным командам использовать разные модули. Party Mode и Cross Platform Agent Team поддерживают кросс-командное взаимодействие. Однако явной поддержки monorepo с team-level конфигурацией нет - каждая команда работает со своим набором агентов и workflows.

Когда выбирать: организация с несколькими командами, которая хочет полный lifecycle из коробки. Высокий порог входа, но максимальная структурированность.

OpenSpec

Философия: "fluid not rigid, iterative not waterfall, built for brownfield not just greenfield". Минимальная церемония, максимальная итеративность.

Что добавляется в проект

your-project/
└── openspec/
    ├── config.yml                # Конфигурация, профиль
    └── changes/
        ├── add-dark-mode/        # Папка на каждое изменение
        │   ├── proposal.md       # Зачем делаем, что меняется
        │   ├── specs/            # Требования и сценарии
        │   ├── design.md         # Техническое решение
        │   └── tasks.md          # Чеклист реализации
        └── archive/
            └── 2026-03-15-add-dark-mode/  # Завершённые изменения

Фазы и контрольные точки

  1. Propose (/opsx:propose) - AI генерирует proposal.md, specs/, design.md, tasks.md за один проход. Контрольная точка: человек ревьюит и правит артефакты до перехода к реализации. Нет rigid gates - любой артефакт можно обновить в любой момент.
  2. Apply (/opsx:apply) - агент реализует tasks последовательно. Контрольная точка: каждый task отмечается как выполненный.
  3. Archive (/opsx:archive) - завершённая работа перемещается в archive/ с датой.

Расширенный workflow добавляет: /opsx:new (новая фича), /opsx:continue (продолжить прерванную работу), /opsx:verify (валидация), /opsx:sync (синхронизация артефактов с кодом).

Развитие артефактов

Ключевое отличие OpenSpec - "update any artifact anytime, no rigid phase gates". Proposal обновляется если scope изменился в ходе реализации. Design.md правится если реальность разошлась с планом. Specs дополняются новыми сценариями. После завершения - archive сохраняет финальное состояние для будущей референции.

Экспертиза по артефактам

Archive формирует историю всех изменений с контекстом (proposal = зачем, specs = что именно, design = как). Можно анализировать паттерны: какие типы изменений проходят гладко, где чаще расходятся plan и реальность, какие домены требуют больше итераций.

Несколько команд и sustainability

36K+ stars, за фреймворком Fission AI (организация с коммерческим Teams-предложением). Есть /opsx:onboard для onboarding новых участников. Команды поддерживаются через отдельный Slack-канал. Однако team-level конфигурация в monorepo не документирована - каждый проект получает свою директорию openspec/.

Когда выбирать: быстрый старт, brownfield-проект. Минимальный overhead, итеративность, низкий порог входа.

Spec Kit (GitHub)

Слоган Spec Kit: «specifications become executable - code serves specifications, not the other way around». Python CLI (Specify), 25+ поддерживаемых AI-агентов, расширяемая экосистема с 40+ community extensions.

Несмотря на принадлежность GitHub, Spec Kit - tool-agnostic. Поддерживает Claude Code, Cursor, Gemini CLI, Codex CLI, GitHub Copilot, Windsurf, Kiro CLI, Qwen Code, OpenCode, Amp, Roo Code и другие. Установка через specify init . --ai claude (или любой другой агент). Для неподдерживаемых агентов есть --ai generic.

Что добавляется в проект

your-project/
├── constitution.md                   # Принципы и стандарты проекта
└── specs/
    └── 003-chat-system/              # Автонумерация + semantic name
        ├── spec.md                   # Спецификация (что и зачем)
        ├── plan.md                   # Технический план (как)
        ├── tasks.md                  # Декомпозированные задачи
        ├── data-model.md             # Схема данных
        ├── contracts/                # API контракты
        ├── research.md               # Исследование: библиотеки, бенчмарки
        └── quickstart.md             # Ключевые сценарии валидации

Фазы и контрольные точки

  1. Constitution (/speckit.constitution) - принципы проекта: quality standards, performance requirements, UX consistency, архитектурные ограничения. Constitution - "законы", которым подчиняются все последующие артефакты. Обновляется редко.
  2. Specification (/speckit.specify) - описание что и зачем, без деталей реализации. Шаблон явно запрещает агенту писать про технический стек: "Focus on WHAT users need and WHY, avoid HOW to implement". Неопределённости маркируются [NEEDS CLARIFICATION] вместо угадывания. Автоматически создаётся feature branch и директория. Контрольная точка: spec.md ревьюится человеком, все [NEEDS CLARIFICATION] должны быть разрешены.
  3. Planning (/speckit.plan) - технический план: стек, архитектура, ключевые решения. Генерирует дополнительные артефакты: data-model.md, contracts/, research.md, quickstart.md. Каждый технический выбор ссылается на конкретное требование из spec. Контрольная точка: plan.md может быть заблокирован через extension Plan Review Gate - требует PR/MR approval до перехода к tasks.
  4. Task Breakdown (/speckit.tasks) - анализирует plan.md, data-model.md и contracts/ для генерации задач. Независимые задачи маркируются [P] (параллелизуемые). Контрольная точка: tasks.md ревьюится.
  5. Implementation (/speckit.implement) - агент реализует задачи. Контрольная точка: extensions для post-implementation review (Verify, Staff Review, QA Testing).

Как артефакты эволюционируют

Spec Kit рассматривает спецификации как "living documents", а код - как "continuously regenerated output":

Экспертиза по артефактам

Самая развитая экосистема для аналитики:

Extension Категория Что делает
Understanding docs 31 метрика качества спецификаций по IEEE/ISO + energy-based ambiguity detection
Spec Critique docs Двойной анализ: product strategy + engineering risk
V-Model docs Парная генерация: dev spec → test spec с полной traceability
Verify Tasks code Обнаружение "phantom completions": задачи [X], но реализации нет
Staff Review code Staff-engineer-level review: spec compliance, security, performance
MAQA process Multi-Agent QA: параллельная реализация через worktree + автоматический QA
Fleet Orchestrator process Full lifecycle orchestration с human-in-the-loop gates
Jira / Linear / GitHub Projects integration Синхронизация спецификаций с task trackers

Несколько команд и sustainability

84K+ stars - крупнейший фреймворк в категории. Принадлежит GitHub (Microsoft), ежедневная активная разработка. Самая богатая экосистема для multi-team: MAQA для параллельной реализации, Fleet Orchestrator для lifecycle, интеграции с пятью task trackers. Enterprise/air-gapped installation. Brownfield walkthroughs документированы: ASP.NET CMS (307K строк C#), Jakarta EE runtime (420K строк Java), Go/React dashboard. Де-факто стандарт в пространстве spec-driven development.

Когда выбирать: команда или организация, которая хочет расширяемую платформу. Core минимален, 40+ extensions добавляют capabilities по потребности. Tool-agnostic: работает с любым AI-агентом, не привязан к GitHub. Подходит для организаций, где разные команды используют разные наборы extensions.

cc-sdd

Kiro-inspired workflow с явным brownfield path. 8 AI-агентов, 13 языков, кастомизируемые шаблоны.

Что добавляется в проект

your-project/
└── .kiro/
    ├── settings/
    │   ├── templates/            # Кастомизируемые шаблоны
    │   │   ├── requirements.md   # Шаблон требований
    │   │   ├── design.md         # Шаблон дизайна
    │   │   └── tasks.md          # Шаблон задач
    │   └── rules/                # Правила генерации для AI
    ├── steering.md               # Контекст проекта (brownfield)
    ├── memory.md                 # Память между сессиями
    └── specs/
        └── photo-albums-en/
            ├── requirements.md   # EARS-format требования
            ├── design.md         # Архитектура + Mermaid-диаграммы
            └── tasks.md          # Задачи с зависимостями

Фазы и контрольные точки

Greenfield path:

  1. spec-init - создать скелет спецификации
  2. spec-requirements - сгенерировать требования в EARS-формате (Exceptional, Alternative, Real world, Specification)
  3. spec-design - архитектура с Mermaid-диаграммами
  4. spec-tasks - декомпозиция с dependency tracking
  5. spec-impl - реализация

Brownfield path (ключевое отличие):

  1. steering - описать существующий проект, стек, conventions
  2. spec-init - создать спецификацию изменения
  3. validate-gap - агент анализирует gap между текущим состоянием и требованиями. Контрольная точка: результат валидации ревьюится человеком.
  4. spec-design - дизайн с учётом существующей архитектуры
  5. validate-design - агент проверяет что дизайн не ломает существующий код. Контрольная точка: результат ревьюится.
  6. spec-tasks - задачи
  7. spec-impl - реализация

Развитие артефактов

Шаблоны в templates/ кастомизируются под процессы команды один раз - дальше все агенты генерируют артефакты в едином формате. Memory.md накапливает контекст между сессиями: архитектурные решения, паттерны, стандарты. Steering.md обновляется при значительных изменениях в проекте.

Экспертиза по артефактам

EARS-формат требований (стандарт из automotive/aerospace) делает требования формально проверяемыми. Mermaid-диаграммы в design.md дают визуальную архитектуру. Dependency tracking в tasks.md показывает критический путь. Кастомизация шаблонов позволяет встроить специфичные для команды чеклисты и критерии.

Несколько команд и sustainability

3K stars, за фреймворком gotalab (японский разработчик, автор книги на Amazon). Явная поддержка команд: "Team-aligned templates - customize once, all agents output docs that fit your approval process." Шаблоны в .kiro/settings/templates/ кастомизируются под процесс команды. 8 AI-агентов с единым workflow. Последняя активность - март 2026. Совместим с Kiro IDE спецификациями (миграция между инструментами).

Когда выбирать: brownfield-проект с legacy, где важно не сломать существующий код. Validation checkpoints между фазами - страховка. Также хорош для мультиязычных команд (13 языков из коробки).

SPECTRE

Семь фаз по акрониму. Философия: "Great Inputs → Great Outputs" и "Ambiguity is Death". Создан за 12+ месяцев ежедневного использования Claude Code. Протестирован на кодовых базах до 250K строк.

Что добавляется в проект

your-project/
├── .spectre/
│   └── manifest.json
├── docs/tasks/
│   └── rate-limiting/            # Папка на каждую фичу
│       ├── specs/
│       │   ├── scope.md          # Что делаем и что НЕ делаем
│       │   ├── ux.md             # User flows и компоненты
│       │   ├── plan.md           # Технический дизайн
│       │   ├── tasks.md          # Задачи для исполнения
│       │   ├── code_review.md    # Результаты code review
│       │   └── gaps.md           # Обнаруженные пробелы
│       └── session_logs/         # Логи сессий (handoff)
│           ├── 2026-04-01_01.md
│           └── 2026-04-01_02.md
└── .claude/skills/
    └── rate-limiting/
        └── skill.md              # Captured knowledge для будущих сессий

Фазы и контрольные точки

Фаза Команда Что делает Контрольная точка
Scope /spectre:scope Интерактивный скоупинг: что строим, что НЕ строим, constraints scope.md ревьюится человеком
Plan /spectre:plan Исследование кодовой базы, технический дизайн plan.md ревьюится, /spectre:handoff для чистого контекста
Execute /spectre:execute Параллельная реализация через субагентов (wave-based delivery) /spectre:validate верифицирует каждую задачу
Clean /spectre:clean Deep cleanup: dead code, дубликаты, lint, logical commits Все изменения коммитятся
Test /spectre:test Risk-aware тестирование, субагенты пишут тесты Test coverage
Rebase /spectre:rebase Подготовка к merge с обработкой конфликтов Clean merge
Evaluate /spectre:evaluate Архитектурный review + knowledge capture skill.md создан и зарегистрирован

Развитие артефактов

Session logs - ключевой механизм. /spectre:handoff сохраняет snapshot текущей сессии. Субагент @spectre:sync объединяет последние 3 session logs в единую memory. При /clear новая сессия автоматически получает контекст предыдущих.

Skills - кумулятивная экспертиза. /spectre:evaluate после каждой фичи генерирует skill.md с gotchas, decisions, patterns, procedures. SessionStart hook при каждом запуске проверяет registry и инжектирует релевантные skills в контекст. Каждая следующая сессия умнее предыдущей.

Экспертиза по артефактам

Пять категорий captured knowledge:

/spectre:recall auth находит и загружает всё, что известно про auth. Gaps.md после validate - явный список того, что агент пропустил. Это данные для улучшения scope и спецификаций.

Несколько команд и sustainability

119 stars, автор - ex-Meta/Amazon PM, проект создавался как личный daily driver. Не рассчитан на multi-team из коробки: session logs и skills привязаны к одному пользователю. Однако skills в .claude/skills/ коммитятся в git и доступны всей команде. Session memory - индивидуальная. Для команды потребуется адаптация: shared skills + индивидуальные session logs.

Когда выбирать: solo operator или малая команда, которая строит product. SPECTRE заточен под ежедневный workflow одного человека с агентом. Сильная сторона - session memory и knowledge capture: чем дольше используешь, тем лучше работает.

IDD (Intent-Driven Development)

Не инструмент, а процессный фреймворк. Заменяет Agile-артефакты (Epic/Story/Task) на четырёхуровневую иерархию, оптимизированную для AI-агентов.

Что добавляется в проект (концептуально)

your-project/
└── specs/
    ├── products/
    │   └── payment-system.md     # Product (заменяет Epic)
    ├── intentions/
    │   └── add-rate-limiting.md  # Intention (заменяет Feature)
    ├── expectations/
    │   └── rate-limit-429.md     # Expectation (заменяет Acceptance Criteria)
    └── specs/
        └── impl-rate-limit.md    # Spec (заменяет Story+Tasks, AI-ready)

Четыре уровня "chain of context"

Уровень IDD Заменяет в Agile Назначение Частота обновления
Product Epic Описание продукта/подсистемы на бизнес-языке Редко
Intention Feature Что хотим изменить и зачем (intent, не реализация) При новой фиче
Expectation Acceptance Criteria Конкретные ожидания с edge cases, testable утверждения По мере обнаружения edge cases
Spec Story + Tasks AI-ready инструкция с явными Boundaries (что агент НЕ должен делать) Одноразовый: написал → реализовал → закрыл

Развитие артефактов

Products и Intentions - стабильные документы, обновляются при стратегических изменениях. Expectations дополняются по мере обнаружения edge cases (в том числе по результатам агентных сессий). Specs - одноразовые: написал → агент реализовал → spec закрыт. Но накопленные specs формируют базу знаний о том, как устроен каждый домен.

Экспертиза по артефактам

Spec quality - основная метрика производительности. Не velocity, не story points, а качество спецификаций. Измеряется: процент specs, выполненных агентом без эскалации; количество iterations до merge; частота boundary violations. Вводится continuous flow вместо спринтов, WIP limits вместо sprint capacity.

Несколько команд и sustainability

3 stars - концептуальный фреймворк, а не популярный инструмент. IDD не требует установки: это набор принципов и формат артефактов. Именно поэтому он легко масштабируется на несколько команд - каждая команда адаптирует четырёхуровневую иерархию под свой домен. Риск: автор может перестать поддерживать. Но поскольку IDD - процесс, а не код, зависимость от репозитория минимальна.

Когда выбирать: организация, которая хочет трансформировать процесс, а не добавить инструмент. IDD накладывается на любой стек. Особенно полезен для перехода от Agile к AI-driven: знакомые концепции (Epic → Product, Story → Spec), но с фокусом на AI-readability.

Сравнение и выбор

Фреймворк Порог входа Brownfield Артефакты Контрольные точки Knowledge capture
BMAD Method Высокий Scale detection _bmad/, _bmad-output/ Implementation readiness check Party Mode, project-context.md
OpenSpec Низкий Явная поддержка openspec/changes/ Нет rigid gates, human review Archive с полным контекстом
Spec Kit Средний Через extensions constitution.md, specs/ Extension-based gates 40+ extensions для аналитики
cc-sdd Средний validate-gap, validate-design .kiro/specs/ Validation checkpoints memory.md, steering.md
SPECTRE Средний Codebase research docs/tasks/, skills/ validate + code_review Skills auto-loading, session logs
IDD Низкий Overlay specs/ (4 уровня) Spec quality Накопленные specs

Как выбрать:

Выбор фреймворка по размеру команды и зрелости

Разбор шести фреймворков выше отвечает на вопрос «что они умеют». Этот раздел отвечает на вопрос «что брать в моей конкретной ситуации». Главные оси выбора - размер команды, доля greenfield/brownfield-кода и зрелость существующего SDLC.

Solo operator или малая команда (1-3 человека, MVP/стартап)

Главный риск - утонуть в инструментарии вместо того, чтобы доставлять. Нужен фреймворк с минимальным overhead, без отдельной фазы tooling-onboarding.

Растущий стартап с несколькими командами (10-50 инженеров, 2-5 команд)

Главный риск - расхождение стилей между командами и отсутствие governance над общими rules. Нужен фреймворк, который поддерживает несколько проектов в одном репозитории и даёт точки входа для общих стандартов.

Enterprise или регулируемая отрасль (50+ инженеров, compliance-требования)

Главный риск - конфликт между быстрыми итерациями spec-driven процесса и тяжёлыми требованиями к traceability, аудиту, согласованиям. Нужны явные approval-gates, integration с task-trackers и enterprise-installation.

Ось зрелости существующего SDLC

Размер команды - не единственный фактор. Не менее важна зрелость процесса до внедрения spec-driven подхода.

Состояние SDLC до внедрения Что брать сначала Чего избегать
Нет регулярных code review, нет CI, тесты редкие Базовая инфраструктура (CI, тесты, review) до любого фреймворка Любой фреймворк - усилит хаос, а не уберёт его
Есть CI и review, но нет письменных спецификаций OpenSpec или Spec Kit core, минимум extensions BMAD - слишком тяжеловесно для команды без культуры spec
Есть acceptance criteria и/или OpenAPI-спецификации Spec Kit с extensions для V-Model и Verify Tasks; IDD как процессный overlay Игнорировать существующие spec-форматы и переписывать всё в новом формате
Есть PMO, формальный SDLC, регулярные аудиты BMAD Method или Spec Kit с Fleet Orchestrator + Jira-интеграцией Лёгкие фреймворки без явных gates - компания всё равно их добавит сверху, но менее консистентно

Стилизованный пример решения по выбору

Это стилизованный пример на основе типичных паттернов, не описание конкретной компании. B2B SaaS, 80 инженеров, 8 продуктовых команд, средний стек (Go + React + Postgres), CI/CD есть, formal compliance отсутствует. Решение: Spec Kit как платформа во всех командах, core + extension Plan Review Gate для двух наиболее критичных команд (платежи, identity), интеграция с Linear (где уже живут задачи), constitution.md на уровне организации с обязательными принципами (test-first, security review для auth-кода) и слой принципов на уровне каждой команды. Через 2 квартала - оценка по spec quality score и lead time, по результатам решение - расширять extensions или остановиться на текущем наборе.

Главное правило выбора: фреймворк должен быть на полступени тяжелее, чем текущая зрелость команды. На две ступени тяжелее - команда не освоит и откатится. На полступени легче - ничего не изменится.

Анатомия AI-driven задачи: от идеи до merge

Разберём полный жизненный цикл продуктовой задачи. Пример: в Rails-приложении с парольной аутентификацией нужно добавить вход по passkey (WebAuthn). Задача нетривиальная: криптография, клиентский JavaScript, серверная валидация, миграции, обратная совместимость с существующими пользователями. Подробнее о самой технологии - в статье о passkey-аутентификации.

Шаг 1: Спецификация (Spec Author)

Spec Author создаёт структурированную спецификацию по шаблону фреймворка: 

Feature: Passkey Authentication (WebAuthn)
Issue: PROJ-892

## What
Добавить вход по passkey как альтернативу паролю.
Регистрация passkey в настройках профиля, вход через
биометрию или PIN. Существующий парольный вход остаётся.
Fallback: если браузер не поддерживает WebAuthn или
пользователь потерял устройство - одноразовый код на email.

## Why
Фишинг-атаки на пользователей участились. Passkey устраняет
фишинг как вектор: приватный ключ привязан к домену и
не передаётся по сети.

## Constraints
- Аутентификация через собственный session controller
  (без Devise, без Warden)
- PostgreSQL для хранения credentials
- Stimulus для клиентского JS (не React)
- Поддержка: Chrome, Safari, Firefox (последние 2 версии)
- Email-отправка через ActionMailer + существующий SMTP

## Acceptance Criteria
- Пользователь регистрирует passkey в профиле
- Вход по passkey с биометрией/PIN
- Парольный вход продолжает работать
- Один пользователь - несколько passkeys (ноутбук + телефон)
- Удаление passkey из профиля
- Fallback: кнопка "Войти по email" отправляет одноразовый
  код (6 цифр, TTL 10 минут, одноразовый)
- Если у пользователя нет passkey - показывать только
  пароль + email fallback

## Boundaries
- НЕ удалять парольную аутентификацию
- НЕ менять существующую модель User (добавить связанные)
- НЕ добавлять OAuth
- НЕ использовать Devise/Warden
- Только серверная валидация, НЕ полагаться на клиентские проверки

Спецификация сохраняется как файл в репозитории. Это источник правды для агента. Boundaries критичны: без них агент может "улучшить" существующий auth flow, сломав его для текущих пользователей.

Шаг 2: Валидация спецификации (Context Engineer)

Context Engineer проверяет готовность контекста:

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

Шаг 3: Агентная сессия (Agent)

Агент получает спецификацию и работает автономно. Вот что он реально делает на каждом этапе:

Анализ существующего кода:

Миграции и модели:

Серверная логика:

Клиентская часть:

Тесты:

Финализация:

Точка эскалации: агент спросил, нужно ли отправлять email через Sidekiq (async) или inline. Спецификация не описывала это. Context Engineer ответил: Sidekiq, как все остальные email в проекте. Это пробел в контексте - после задачи в rules добавили "email отправляется через deliver_later".

Шаг 4: Review (Reviewer)

Reviewer фокусируется на том, что агент не может оценить сам:

AI-driven разработка требует высокой культуры детерминированных проверок. Агент пишет структурно корректный код, но пропускает нюансы. Линтеры, статический анализ, security scanning, обязательные CI checks - всё это должно быть настроено до начала работы с агентами. Чем больше проверок автоматизировано, тем меньше нагрузка на человеческий review. Минимальный набор: RuboCop (стиль + паттерны), Brakeman (security), SimpleCov (coverage threshold), обязательный green CI для merge. Без этого агент генерирует код, который "работает", но постепенно накапливает технический долг.

Шаг 5: Merge и обновление контекста

После merge в knowledge base добавляется: паттерн интеграции WebAuthn, структура Stimulus-контроллера для browser API, правило "email через deliver_later". Следующая задача с криптографией или browser APIs пройдёт быстрее - агент уже знает паттерны проекта.

Инфраструктура контекста: что нужно агенту для работы

Агент не помнит ничего между сессиями. Без подготовленного контекста он каждый раз начинает с нуля: не знает архитектуру, не знает conventions, не знает ограничения. Инфраструктура контекста - это набор файлов в репозитории, которые загружаются в контекстное окно агента при каждой сессии. Подробнее - в статье об инфраструктуре контекста и context engineering.

Минимальный пример на Claude Code (аналогичные механизмы есть в Cursor, Windsurf и других): 

your-project/
├── CLAUDE.md                      # Конституция (загружается всегда)
└── .claude/
    └── rules/
        ├── api-conventions.md     # Загружается при работе с app/controllers/api/
        ├── migration-rules.md     # Загружается при работе с db/migrate/
        └── testing-patterns.md    # Загружается при работе с spec/

Конституция: CLAUDE.md

Загружается в контекст каждой сессии. Содержит только то, что агент не может вывести из кода самостоятельно: 

# Project

Ruby 3.1.2, Rails 7.0.4+, PostgreSQL 15, Redis 7.
Puma + Nginx. Docker Compose для деплоя.

## Architecture
- Controllers: `Web::` (HTML), `Api::V1::` (JSON), `Telegram::` (bot)
- Auth: собственный session controller, bcrypt, без Devise
- JS: Stimulus + Turbo, importmap (не webpack)
- Background jobs: Sidekiq

## Commands
```
bundle exec rspec          # тесты
bundle exec rubocop        # стиль
bundle exec rubocop -A     # автофикс
bin/rails server           # dev server
```

## Critical constraints
- SimpleCov requires 100% line coverage
- RuboCop max AbcSize is 17
- Email отправляется через deliver_later (Sidekiq)
- Не использовать raw SQL в контроллерах

Это ~30 строк. Правило: чем меньше конституция, тем больше места для рабочего контекста задачи. Если инструкцию можно вывести из кода (gem-версии, структура директорий) - не дублируй.

Rules: доменные правила

Загружаются автоматически, когда агент открывает файл в соответствующей директории. Пример .claude/rules/api-conventions.md: 

---
paths:
  - app/controllers/api/**
---

# API Conventions

- Namespace: `Api::V1::`
- Inherit from `Api::V1::BaseController`
- Response: JSON, camelCase keys
- Auth: API key в header `X-Api-Key`
- Errors: `{ error: "message" }`, HTTP status codes
- Pagination: Kaminari, `page` и `per_page` params
- Тесты: request specs в `spec/requests/api/v1/`

Когда агент работает с файлом в app/controllers/api/, harness автоматически инжектирует это правило в контекст. Агент не знает о существовании правила до момента инжекции - и не может его проигнорировать.

Несколько команд в одной кодовой базе

Если в организации уже работает domain ownership, инфраструктура контекста повторяет существующую структуру: 

monorepo/
├── CLAUDE.md                      # Platform conventions (стек, CI/CD)
├── .claude/rules/
│   └── shared-conventions.md      # Общие правила
├── payments/
│   ├── CLAUDE.md                  # Team conventions payments-команды
│   └── .claude/rules/
│       └── payment-rules.md       # Правила домена
├── notifications/
│   ├── CLAUDE.md                  # Team conventions notifications-команды
│   └── .claude/rules/
│       └── notification-rules.md
└── shared/
    └── .claude/rules/
        └── shared-code-rules.md   # Правила для кода без владельца

Агент, работающий в payments/, видит: корневой CLAUDE.md + payments/CLAUDE.md + payment-rules.md. Правила notifications-команды он не видит. Это те же границы, в которых работают люди - просто формализованные в файлах.

Управление задачами и контекстом снаружи

Инфраструктура контекста живёт в репозитории. Но задачи живут снаружи - в Jira, Linear, GitHub Issues. Разрыв между внешним backlog и spec-driven workflow - главная нерешённая проблема большинства фреймворков.

Текущее состояние

Большинство spec-driven фреймворков игнорируют внешние системы управления задачами. OpenSpec, SPECTRE, cc-sdd работают с артефактами в репозитории. Backlog management - "вне скоупа". На практике это создаёт две системы правды: менеджмент смотрит в Jira, агент работает со спецификациями в репозитории.

Исключение - Spec Kit: extensions для интеграции с Jira, Azure DevOps, GitHub Projects, Linear, Trello. Но даже они решают задачу синхронизации статусов, а не полной интеграции workflow.

Что предлагают task trackers

Трекеры задач двигаются навстречу AI-driven разработке:

Visibility для менеджмента

Ключевая проблема: менеджмент привык видеть прогресс через статусы задач в трекере. В AI-driven процессе задача может перейти из "To Do" в "Done" за час. Привычные сигналы прогресса (daily updates, sprint burndown) перестают работать.

Что работает вместо них:

Паттерн интеграции

  1. Issue в трекере - описание задачи на бизнес-языке, приоритет, привязка к эпику. Для менеджмента и планирования.
  2. Spec в репозитории - техническая спецификация, созданная по шаблону фреймворка. Ссылка на issue. Для агента.
  3. Агентная сессия - агент работает со спецификацией, формирует PR.
  4. PR - ссылка на issue и на spec. Review происходит здесь.
  5. Обновление issue - статус, время, метрики. Автоматизируется через CI/CD hooks.
Issue в трекере - для людей, spec в репозитории - для агента. Не пытайся сделать Jira-тикет пригодным для агента и наоборот.

Что автоматизируется

Что остаётся ручным

Роли в новом SDLC

AI-driven SDLC не отменяет роли - он трансформирует их. Масштаб трансформации зависит от размера организации.

Solo Operator (1 человек)

Один инженер совмещает все роли: пишет спецификации, поддерживает инфраструктуру контекста, запускает агентов, ревьюит результат. Подходит для side-проектов, внутренних инструментов, MVP. Фреймворки SPECTRE и OpenSpec спроектированы именно под эту модель.

Ограничение: при росте сложности solo operator становится bottleneck на review и спецификациях. Один человек не может качественно ревьюить 10+ PR в день и одновременно писать спецификации для следующих задач.

Minimal Team (2 человека)

PM/Spec Author + Engineer/Operator. PM формулирует что делать и пишет бизнес-часть спецификации. Engineer дополняет технической частью, поддерживает контекст, ревьюит.

IDD Framework построен вокруг этой модели: Spec Author пишет Intentions и Expectations, Engineer переводит их в Specs с Boundaries и запускает агента.

Scaled Team (3-5 человек)

Spec Authors + Context Engineers + Reviewers. Каждый Context Engineer управляет несколькими агентными сессиями параллельно. Модель OpenAgentsControl: "Propose → Approve → Execute" с чёткими approval gates.

Enterprise (существующая оргструктура)

Существующие роли трансформируются:

Классическая роль Новая роль Что меняется
Бизнес-аналитик Spec Author Структурированные спецификации вместо описаний в свободной форме
Разработчик Context Engineer + Reviewer Поддержка инфраструктуры контекста, review кода агента
Senior Developer Context Architect Проектирование rules, skills, knowledge base
QA Acceptance Criteria Author + Validator Testable criteria до реализации, валидация результата после
Tech Lead Operator Управление агентными сессиями, мониторинг метрик
DevOps Без изменений CI/CD + автоматизация spec → PR pipeline
Трансформация ролей не означает сокращение. Она означает, что те же люди делают другую работу. Но пропускная способность команды растёт, и при найме новых людей их нужно меньше.

Шесть режимов провала при внедрении spec-driven SDLC

Spec-driven подход кажется очевидным улучшением: записали что хотим, агент сделал, проверили. На практике большинство команд, которые быстро объявили о переходе на spec-driven, через 2-3 квартала откатываются обратно к чату с агентом или вовсе к ручному коду. Причины повторяются. Ниже - шесть наиболее частых режимов провала и узнаваемые сигналы каждого.

1. Spec drift: спецификация и код расходятся

Самый распространённый паттерн. Spec написан, агент реализовал, через две недели в код внесены ручные правки или новый агентный прогон без обновления spec. Через месяц spec.md описывает один интерфейс, код реализует другой, тесты проходят на третьем. На этом этапе spec из контракта превращается в устаревшую документацию, и все начинают читать только код.

Сигналы. «Не верь spec, смотри код» в комментариях к PR. Агентные сессии завершаются «расхождениями со spec», но никто их не разрешает. Архив изменений (например, OpenSpec archive) пустой или давно не пополнялся. Антидот. Drift detection (Spec Kit Reconcile, аналогичные practices в OpenSpec через ручной audit), правило «изменение spec обязательно при любом изменении контракта», обязательная фаза archive после merge.

2. Documentation theater: spec есть, но никто его не использует

Команда внедрила spec-driven фреймворк, потому что «так делают». Spec пишется ради процесса, а не для агента. Шаблоны заполнены, контрольные точки пройдены, но реальная работа всё равно идёт через чат с агентом, где задача формулируется заново в свободной форме. Spec становится отчётным артефактом, который читают только при ретроспективах.

Сигналы. Spec.md содержит общие фразы вроде «реализовать функциональность согласно бизнес-требованиям». PR не ссылаются на spec, или ссылка формальная. Агент работает в IDE-чате, а не через команды фреймворка (/speckit.implement, /opsx:apply и аналоги). Антидот. Audit реальных PR за две недели: процент с явной ссылкой на spec и пройденными фазами фреймворка. Если ниже 70%, spec используется как театр.

3. Over-specification: spec тяжелее кода

Обратная крайность. Spec пишется так подробно, что время на написание спецификации превышает время реализации. Команда тратит дни на обсуждение формулировок acceptance criteria для двухдневной задачи. Возникает соблазн «давайте просто напишем код, а spec потом» - и это начинает работать чаще, чем нет.

Сигналы. Spec на типовую CRUD-задачу занимает 5+ страниц. На spec-фазу уходит больше времени, чем на implement. Команда жалуется, что «процесс задушил скорость». Антидот. Scale-adaptive подход (BMAD scale detection, минимальные шаблоны OpenSpec для bug fix), правило «spec не должен повторять boilerplate, который агент выведет из rules», обязательный лимит времени на фазу specify (например, 20% от ожидаемого implement-времени).

4. No validation gates: spec написан, но никто не ревьюит

Spec пишет один человек (часто автор задачи или Spec Author) и сразу запускает агента. Никто не проверяет полноту спецификации до того, как агент потратит токены и время. Половина агентных сессий заканчивается «нужны уточнения», что в корне противоречит идее автономной работы.

Сигналы. Метрика Agent Autonomy Rate ниже 50%. Эскалации от агента случаются на каждой второй задаче. Один и тот же тип неопределённостей всплывает снова и снова (например, «как обрабатывать ошибки»). Антидот. Обязательный peer review на фазе specify. Чек-лист готовности spec: все ли [NEEDS CLARIFICATION] разрешены, описаны ли error handling и edge cases, явно ли указаны Boundaries.

5. Tooling without process: spec-фреймворк без культуры использования

Команда установила Spec Kit, OpenSpec или другой фреймворк по инициативе одного энтузиаста. Файлы появились в репозитории, но нет договорённости когда их использовать. Часть команды работает по-старому, часть - по-новому. Spec-файлы накапливаются хаотично, часть - устаревшие, часть - дубли. Через квартал кто-то предлагает «удалить эту папку, всё равно никто не понимает что там».

Сигналы. Папка specs/ или openspec/ содержит файлы без обновлений за месяц+. Новые сотрудники не получают инструкции по использованию фреймворка во время онбординга. Нет owner-а у фреймворка - никто не отвечает за rules, шаблоны, обновления. Антидот. Назначить явного owner-а инфраструктуры контекста на старте. Включить spec-driven-процесс в onboarding и в Definition of Done. Обзор и чистка spec-структуры каждый квартал.

6. Single-author spec: спецификация одного человека

Все spec пишет один senior-инженер или Spec Author. Остальная команда работает «исполнителями» - запускает агентов и ревьюит код. Бутылочное горлышко смещается с написания кода (где раньше была проблема) на написание спецификаций. Single-author spec ещё и не получает peer-review, потому что автор - самый компетентный человек в команде по этому домену.

Сигналы. 80%+ spec-файлов в репозитории - от одного автора. Время от создания issue до начала агентной сессии растёт. Spec Author жалуется на перегрузку, остальная команда - на скуку. Антидот. Постепенное расширение круга авторов через парные сессии (опытный Spec Author + новичок). Шаблоны и чек-листы, которые делают первый spec безопасным для новичка. Метрика - доля spec-файлов от non-primary автора.

Связь между режимами провала

Эти шесть паттернов часто появляются вместе. Single-author spec приводит к over-specification (потому что автор перестраховывается). Over-specification приводит к documentation theater (потому что команда устаёт читать длинные spec). Theater приводит к no validation gates (зачем ревьюить то, что никто не использует). Без gates растёт spec drift, и через квартал команда говорит «spec-driven у нас не работает».

Большинство команд, объявивших о провале spec-driven подхода, на деле провалились на одном из этих шести режимов, а не на самой идее. Откат к чату с агентом убирает симптом, но не решает проблему: те же дефекты вернутся в виде «code drift» (код и реальное поведение расходятся), «implicit specification» (требования живут в голове) и «single-author code».

Внедрение в существующую организацию

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

Шаг 1: Аудит текущего SDLC

Зафиксировать текущий процесс и найти точку входа:

На этом этапе важно договориться о базовых метриках: lead time, change failure rate, время review. Они понадобятся для сравнения "до" и "после".

Шаг 2: Инфраструктура контекста

До первой агентной задачи должна быть базовая инфраструктура:

Обсудить с командой: какие conventions не зафиксированы в коде и существуют только в головах? Именно они должны попасть в rules первыми.

Шаг 3: Пилот на одном типе задач

Выбрать категорию задач с двумя свойствами: повторяемость и чёткие boundaries. Примеры: CRUD-эндпоинты, стандартные миграции, bug fixes с воспроизводимым сценарием, добавление валидаций или бизнес-правил.

Один-два инженера работают по новому процессу, остальная команда - по старому. Фиксировать: lead time каждой задачи, количество эскалаций от агента, время review, количество итераций до merge, причины каждой эскалации (пробел в контексте? неточная спецификация? ограничение агента?).

Шаг 4: Расширение scope

По результатам пилота провести ретроспективу:

На основе ретроспективы: расширять scope задач, дополнять инфраструктуру контекста, формализовать шаблоны спецификаций для новых типов задач.

Шаг 5: Масштабирование на организацию

Когда процесс стабилен на одной команде и метрики подтверждают эффект:

Барьеры внедрения и как с ними работать

Потеря прозрачности. Менеджмент привык видеть прогресс через Jira-статусы и standup-отчёты. Когда агент делает работу за минуты вместо дней, привычные сигналы прогресса исчезают. PR появляется "из ниоткуда", и непонятно что за ним стоит - час работы или пять минут.

Как работать: spec-driven workflow создаёт более прозрачный audit trail, чем классический процесс. Каждая задача имеет спецификацию (что делаем и зачем), PR с diff (что сделано), и метрики (время, эскалации). Dashboard с этими данными даёт менеджменту больше visibility, чем Jira-статусы.

Страх потери контроля над кодом. Код пишет агент, а не человек. Кто отвечает за качество? Кто понимает что в нём происходит? Если агент сгенерировал 500 строк - кто-то вообще их читал?

Как работать: в spec-driven процессе review - обязательный gate. Но review AI-generated кода отличается от review человеческого. Код структурно чистый (агент следует rules), проблемы - в логике и edge cases. Это другой навык review, и его нужно развивать. Автоматизированные проверки (тесты, линтер, security scanning) закрывают механические аспекты. Человек фокусируется на том, что автоматизация не ловит: архитектурная корректность, бизнес-логика, security implications.

Неопределённость ролей. "Я senior developer, теперь я Context Engineer - это повышение или понижение? Что конкретно я делаю каждый день?" Без ответа на этот вопрос люди саботируют процесс или уходят.

Как работать: начинать с пилота, где 1-2 инженера пробуют новую модель добровольно. Они становятся internal champions и показывают команде как это выглядит на практике. Явно описать ежедневные задачи для каждой роли: Context Engineer утром проверяет очередь спецификаций, запускает агентные сессии, ревьюит результаты, дополняет knowledge base. Это не абстрактная трансформация - это конкретный рабочий день.

Compliance и security concerns. В регулируемых отраслях (финтех, медтех) код должен проходить аудит. AI-generated код вызывает вопросы: можно ли его сертифицировать? Кто несёт ответственность за уязвимости?

Как работать: spec-driven процесс упрощает аудит, а не усложняет. Каждый фрагмент кода имеет спецификацию (требования), PR (review), тесты (верификация). Traceability от требования до реализации полнее, чем в классическом SDLC. Security scanning в CI ловит типовые уязвимости. Permission system ограничивает что агент может делать (нет доступа к production, нет push без approval).

Сопротивление "это не мой код". Инженеры, которые гордятся craftsmanship, воспринимают AI-generated код как чужеродный. "Я бы написал это иначе" - частая реакция на review.

Как работать: правила в rules и constitution определяют стиль кода. Если команда хочет определённые паттерны - они описываются в rules, и агент им следует. Код становится "кодом команды, написанным по правилам команды" - просто написанным быстрее. Review - момент, где инженер влияет на результат.

Метрики: как понять, что работает

DORA в контексте AI-driven SDLC

Четыре метрики DORA остаются релевантными, но их интерпретация меняется:

Специфичные метрики AI-driven SDLC

Метрика Что измеряет Целевой показатель
Spec Quality Score Процент агентных сессий без эскалации 70-80% (100% = задачи слишком простые)
Agent Autonomy Rate Соотношение автономной работы к общему времени Растёт по мере улучшения контекста
Context Coverage Процент кодовой базы, покрытый rules и knowledge base Покрывать частые домены, не стремиться к 100%
Cost per Task Токены + инженерное время vs. классический SDLC Ниже полной стоимости задачи без агентов

Риски и ограничения

Что агенты не умеют

Security

Агент имеет доступ к кодовой базе и может выполнять команды. Это attack surface: prompt injection через данные, которые агент читает (issue descriptions, API responses); случайное включение секретов в commits; генерация кода с уязвимостями (SQL injection, XSS).

Минимизация: permission system (агент не может push без approval), security-focused rules в инфраструктуре контекста, automated security scanning в CI.

"Чёрный ящик": код, который никто не понимает

Через несколько месяцев активной генерации кода агентами команда может обнаружить, что никто не понимает, как работают отдельные модули. AI генерирует код, который проходит тесты и review, но при отладке оказывается сложнее, чем написанный человеком: неочевидные зависимости, неявные контракты между компонентами, пропущенные edge cases.

Spec-driven подход снижает этот риск: спецификация документирует зачем код написан, boundaries определяют scope, review фокусируется на логике. Но риск остаётся, особенно если review формальный. Практика: после merge сложных фич обновлять knowledge base с описанием архитектурных решений и нетривиальных паттернов.

Стоимость при масштабе

Агентная сессия на крупной задаче - тысячи вызовов API, миллионы токенов. При команде из 10 context engineers, каждый из которых запускает 5-10 сессий в день, счёт за API измеряется тысячами долларов в месяц. Это дешевле зарплат, но требует бюджетирования и мониторинга.

Качество кода при масштабном adoption

Данные из индустрии за 2025-2026:

Эти цифры - следствие плохого процесса, а не агентов как таковых. Команды, которые «просто включили Copilot» без spec-driven workflow, получили больше кода и больше проблем. Spec-driven подход работает в обратную сторону: спецификация ограничивает scope, rules обеспечивают conventions, тесты и линтер ловят механические ошибки.

Практический пример

Hublix - платформа процессных AI-агентов в Telegram. Python-монорепозиторий с OpenSpec. Разберём как выглядит реальная задача в spec-driven процессе.

Инфраструктура проекта

hublix/
├── CLAUDE.md                          # Конституция: стек, архитектура, trigger tables
├── .claude/agents/                    # Специализированные агенты по доменам
│   ├── orchestration-specialist.md
│   ├── identity-specialist.md
│   ├── state-engine-specialist.md
│   ├── frontend-specialist.md
│   ├── infra-specialist.md
│   └── pr-reviewer.md
├── .claude/rules/
│   ├── testing.md                     # 100% coverage, pytest conventions
│   ├── design.md                      # OpenSpec proposal до кода
│   └── security.md                    # 152-ФЗ, валидация, секреты
├── openspec/
│   ├── specs/                         # Tier 3: холодная память по подсистемам
│   │   ├── auth-flows/
│   │   ├── orchestration-pipeline/
│   │   ├── tenant-isolation/
│   │   └── ...
│   └── changes/                       # Активные и архивные изменения
│       ├── yookassa-payments/         # В работе
│       └── archive/
│           └── 2026-04-01-tenant-balance-credits/
├── services/                          # 4 микросервиса
│   ├── identity/                      # Auth, tenants, balance
│   ├── messaging/                     # Webhook gateway
│   ├── orchestration/                 # FSM + LLM
│   └── scheduler/                     # Cron jobs
├── libs/                              # Shared code
│   ├── db/                            # SQLAlchemy, Alembic, repos
│   └── shared/                        # Pydantic types
└── apps/                              # React UI
    ├── admin/                         # Tenant admin
    └── backstage/                     # Platform admin

Конституция (CLAUDE.md) содержит trigger tables - автоматическую маршрутизацию агентов: при изменении файлов в services/orchestration/ подключается orchestration-specialist, при работе с services/identity/ - identity-specialist. Правило #9: "Use OpenSpec for planning - /opsx:propose before implementing non-trivial changes".

Реальная задача: Tenant Balance & Credits

Задача: добавить систему баланса в рублях, чтобы контролировать расход LLM-токенов по тенантам. Каждый вызов YandexGPT стоит денег, и тенанты должны работать только пока баланс положительный.

1. Proposal (/opsx:propose)

OpenSpec сгенерировал proposal.md с ключевыми решениями:

Proposal также определил scope (11 пунктов) и out of scope (YooKassa, per-tool pricing, analytics - будущие фазы). Это те самые boundaries, которые не дают агенту "улучшить" задачу.

2. Design

Агент сгенерировал design.md с полной технической спецификацией. Ключевые артефакты:

Схема данных - две таблицы в identity schema:

balance_transactions (append-only ledger)
───────────────────────────────────────────
id              UUID PK
tenant_id       UUID FK → tenants.id
type            VARCHAR(20)    -- initial_grant | topup | usage | adjustment
amount          INTEGER        -- копейки: положительное = credit, отрицательное = debit
reference_type  VARCHAR(50)    -- turn | manual | system
reference_id    VARCHAR(255)   -- turn_id, admin user_id, etc.
memo            TEXT           -- "Ручное пополнение", "LLM usage: 347 tokens"
created_at      TIMESTAMPTZ

tenant_balances (materialized cache)
───────────────────────────────────────────
tenant_id       UUID PK FK → tenants.id
balance         INTEGER DEFAULT 0    -- копейки
updated_at      TIMESTAMPTZ
CHECK (balance >= 0)                 -- предотвращает овердрафт на уровне БД

API контракты - два уровня доступа:

Internal (без JWT, K8s network trust):
  POST /internal/balance/check   {tenant_id, estimated_kopecks: 40}
                                 → {allowed: true, balance: 48500}
  POST /internal/balance/deduct  {tenant_id, amount_kopecks: 28, turn_id}
                                 → {balance: 48472}

Backstage (JWT required):
  GET  /backstage/tenants/{id}/balance       → {balance_rub: "484.72", ...}
  POST /backstage/tenants/{id}/topup         {amount_rub: "100.00", memo: "..."}
  GET  /backstage/tenants/{id}/transactions  → paginated list

Sequence diagram - агент создал docs/diagrams/balance-credit-flow.puml с четырьмя сценариями:

Сценарий 2: Входящее сообщение - balance check + deduct

User → Telegram → Messaging → Orchestration Worker → Identity Service → PostgreSQL

1. User отправляет "Привет" в Telegram
2. Webhook → Messaging → ARQ job → Orchestration Worker
3. Worker → Identity: POST /internal/balance/check {estimated_kopecks: 40}
4. Identity → DB: SELECT balance FROM tenant_balances
5. Identity → Worker: {allowed: true, balance: 48000}
6. Worker: FSM + LLM processing (tokens_used = 347)
7. Worker → Identity: POST /internal/balance/deduct {amount_kopecks: 28, turn_id}
8. Identity → DB: INSERT balance_transaction (-28) + UPDATE tenant_balances
9. Worker → Telegram: ответ пользователю

Сценарий 3: Баланс исчерпан
  ...шаги 1-4...
5. Identity → Worker: {allowed: false, balance: 0}
6. Worker → Telegram: "Баланс исчерпан" (LLM не вызывается)

Design также описал error handling (fail-open при недоступности Identity), конфигурацию (4 env variables) и future extensibility (YooKassa, per-tool pricing, analytics - без изменения схемы).

3. Tasks (/opsx:apply)

tasks.md - 11 задач. Каждая - атомарная единица работы для одной агентной сессии. Порядок определён зависимостями: 

- [x] 1. ORM-модели BalanceTransaction + TenantBalance + Alembic-миграция
         (включая initial_grant для существующих тенантов) + тесты
- [x] 2. BalanceTransactionRepository + TenantBalanceRepository
         + wire в BackstageUnitOfWork и APIUnitOfWork + тесты
- [x] 3. BalanceService: get_balance, get_balance_summary, create_initial_grant,
         topup (₽ string → копейки), record_usage, list_transactions + тесты
- [x] 4. Internal API: POST /internal/balance/check, POST /internal/balance/deduct
         (копейки, без JWT) + тесты
- [x] 5. Backstage API: GET balance (₽), POST topup (₽ input → копейки),
         GET transactions (paginated) + тесты
- [x] 6. Wire initial_grant в tenant creation flow (auth_service +
         backstage_auth_service) + IdentityConfig + тесты
- [x] 7. BalanceChecker protocol + HttpBalanceChecker в Orchestration +
         balance gate в IncomingMessageProcessor (pre-check + post-deduct,
         token → копейки conversion) + config + тесты
- [x] 8. Backstage UI: баланс в ₽ на tenant detail, topup modal,
         transaction history tab
- [x] 9. PlantUML sequence diagram: docs/diagrams/balance-credit-flow.puml
- [x] 10. Update ERD: docs/diagrams/erd-data-model.puml
- [x] 11. Full quality gates: ruff check + ruff format + pytest --cov-fail-under=100

Агент выполнял задачи последовательно. Задачи 1-3 - фундамент (модели, репозитории, сервис). Задачи 4-6 - API слой. Задача 7 - интеграция между сервисами (Orchestration вызывает Identity). Задача 8 - UI. Задачи 9-11 - документация и quality gates.

В процессе выполнения задачи 7 агент обнаружил, что IncomingMessageProcessor не имел injection point для внешних зависимостей. Агент добавил BalanceChecker protocol и HttpBalanceChecker implementation, следуя dependency injection паттерну, который уже использовался в проекте для других internal clients. Это решение не требовало эскалации - агент нашёл паттерн в кодовой базе самостоятельно.

4. Результат и архивация

После completion - /opsx:archive: 

openspec/changes/archive/2026-04-01-tenant-balance-credits/
├── proposal.md    # Зачем, scope, out of scope, key decisions, future phases
├── design.md      # Схема данных, API контракты, sequence diagram, config
└── tasks.md       # 11 задач, все [x]

Артефакты сохранены для будущей референции. Когда через месяц нужно понять почему баланс в копейках, а не рублях - ответ в proposal.md, ключевое решение #1: "Rubles, not credits - no abstract unit conversion. Tenants see real money."

Следующая задача в pipeline - YooKassa payments - уже в openspec/changes/yookassa-payments/. Её proposal ссылается на Phase 2 из balance proposal. Design использует balance_transactions с reference_type='yookassa' - расширение, которое было заложено в design предыдущей задачи (раздел "Future Extensibility"). Контекст передаётся через артефакты, не через чат-историю.

Что показывает этот пример

Источники и смежные статьи

Историческая рамка SDLC

Spec-driven родословная

Эпоха агентов

Spec-driven фреймворки

Качество AI-generated кода и метрики

Смежные статьи блога