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

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

1 апреля 2026

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

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

Почему классический 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 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

Как выбрать:

Анатомия 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
Трансформация ролей не означает сокращение. Она означает, что те же люди делают другую работу. Но пропускная способность команды растёт, и при найме новых людей их нужно меньше.

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

Переход на 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"). Контекст передаётся через артефакты, не через чат-историю.

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

Источники