От SDLC к AI-DLC: как «bolts» пытаются заменить спринты, и что с этим делать инженерам

2025 год можно с уверенностью назвать годом ИИ-трансформации: стремительный прогресс в развитии ИИ-инструментов и помощников, улучшение качества ответов популярных генеративных моделей и, как следствие, массовая «агентизация» в ИТ-компаниях. Тем не менее, мы наблюдаем одну закономерность: код стал создаваться быстрее (IDE-ассистенты, генераторы тестов, документации, ИИ-рецензенты кода), но поставка ценности в целом ускорилась незначительно. Фокус трудозатрат сместился с написания кода на проверку, что его можно безопасно и надёжно эксплуатировать в проде. Выросли затраты на рецензирование, тестирование и отладку, рефакторинг, безопасность и проверки на соответствие требованиям регулятора, интеграцию с архитектурными стандартами и платформой, наблюдаемость и готовность к инцидентам — и именно эти стадии теперь определяют lead time, а не скорость создания кода.

В результате многие команды попадают в ситуацию, когда быстрый этап разработки с использованием ИИ-инструментов нивелируется длительностью последующих этапов, стоящих на пути к поставке ценности в промышленную среду.

На этом фоне AWS (Amazon Web Services) в 2025 году предложили подход AI-Driven Development Life Cycle (AI-DLC), суть которого заключается, не в том, чтобы «внедрить ИИ в существующий SDLC», а перестроить цикл разработки с учётом того, что ИИ теперь умеет планировать и выполнять, а человек должен контролировать и проверять.

От AI-assisted к AI-driven

Классическая модель «человек думает — машина помогает» в разработке долго выглядела примерно так:

• человек формулирует требования, проектирует решение и пишет код;

• используются вспомогательные инструменты: линтеры, тесты, статический анализ, CI;

• человек собирает изменения в релиз и выводит их в продуктовую среду.

AI‑DLC, напротив, предлагает подход, при котором ИИ берёт на себя значительную часть выполнения (планирование, реализацию, подготовку артефактов, развёртывание), а человек выступает в роли контролёра и принимает финальное решение: проверяет ключевые шаги, оценивает риски, качество и готовность результата к поставке:

• человек описывает решение;

• ИИ генерирует план, задаёт уточняющие вопросы и берёт на себя рутинное выполнение: генерирует код, тесты, документацию, шаблоны конфигураций;

• человек подтверждает ключевые результаты и границы изменений: что делаем и не делаем, какие есть риски, критерии приёмки;

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

Важное замечание: AI‑DLC — это не способ с помощью ИИ полностью избавиться от человека в цикле разработки, а способ увеличить скорость разработки и поставки ценности, при котором рутину делает ИИ, а функции проверки результатов, контроля и принятия решения остаются за человеком.

AWS описывает AI‑DLC как новый жизненный цикл и вводит терминологию, чтобы показать отличия от привычного Agile:

• «спринты» (sprints) предлагается заменить на bolts — более короткие циклы (часы/дни);

• «эпики» (epics) заменить на units of work — единица результата работы.

Три фазы AI‑DLC

AI‑DLC состоит из трёх фаз:

• Inception — намерение → постановка: Что делаем? Для чего? Какие ограничения? Какие критерии?

• Construction — постановка → решение: проектирование, реализация, контроль качества;

• Operations — установка и эксплуатация → обратная связь: релизы, мониторинг, инциденты, улучшения.

Inception: намерение и постановка

Inception отвечает за превращение исходного intent в исполняемую инженерную постановку: уточнение требований, проверка, первичный дизайн, нарезка на Units of Work (в том числе для параллельной разработки), DoD, оценка рисков и сложности. На выходе появляются артефакты контекста (планы, требования, дизайн), которые хранятся в репозитории и являются входными артефактами для следующих фаз.

Типовые выходные артефакты Inception:

• формулировка intent (что хотим получить и зачем);

• ограничения и допущения (что сейчас не делаем);

• риски и нефункциональные требования (безопасность, производительность, совместимость);

• критерии приёмки и Definition of Done;

• декомпозиция результата на автономные части.

Именно здесь особенно заметен эффект от ИИ: он быстро предлагает структуру требований, список уточняющих вопросов и черновики артефактов. Но финальные формулировки и границы — ответственность человека.

Construction: проектирование и реализация

Construction — это та часть, которую многие по привычке называют «разработка», но в AI‑DLC важно уточнение: это не просто написание кода, а доведение изменения до состояния соответствующего качества и готовности установки в продакшн. Сюда входит сама реализация (код и подготовка инфраструктуры), тестирование и прохождение quality gates.

Типовые выходные артефакты Construction:

• дизайн на нужную глубину (иногда это просто ADR на одну страницу);

• код и тесты (модульные, интеграционные и сквозные в нужной пропорции);

• обновлённые контракты (например, OpenAPI) и миграции данных;

• результаты проверок (CI, статический анализ, security scanning);

• список изменений и их причины.

Operations: эксплуатация и обратная связь

Operations в AI‑DLC — часть жизненного цикла, отвечающая за вывод в пром, запуск, эксплуатацию и мониторинг. На этом этапе делают упор на наблюдаемость и управляемость изменений (развёртывание и мониторинг), а также на сохранении сквозной трассируемости и контрольных точек с человеческим надзором.

Типовые выходные артефакты Operations:

• план rollout и rollback;

• метрики, журналы и трассы (что именно мониторим);

• оповещения и runbook (что делать, если пошло не так);

• фиксация результатов (что увидели после включения, какие улучшения нужны дальше).

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

Адаптивный процесс AI‑DLC

Фазы AI‑DLC — это каркас. Но чтобы AI‑DLC работал одинаково предсказуемо в разных командах и задачах, AWS переводят его в формат «исполняемого процесса» через адаптивные процессы (adaptive workflow) — набор рабочих сценариев, которые выбирают глубину проработки, набор артефактов и quality gates в зависимости от контекста задачи.

В чём особенность adaptive workflow? Процесс (workflow) — это описанный сценарий работы: какие шаги выполняются, какие артефакты создаются, какие проверки обязательны. А адаптивный процесс (adaptive workflow) — это процесс, который выбирает глубину и набор шагов в зависимости от типа изменения. Hotfix, новая фича, миграция данных и рефакторинг требуют разной строгости и разного набора гейтов — и процесс должен это отражать, а не «прокатывать всех по одному шаблону».

AWS выложили практические материалы в открытый репозиторий awslabs/aidlc‑workflows, где можно посмотреть структуру и артефакты и ознакомиться с идеологией «audit trail» как части процесса.

Steering rules как «конституция проекта» для людей и AI

Чтобы процесс реально работал в конкретной команде, ему нужны правила: стандарты написания кода, ограничения, требования к проверкам и структуре PR. В AI‑DLC это оформляют как steering rules (steering files): директивы, которые постоянно живут рядом с кодом и автоматически «подмешиваются» в контекст ИИ‑ассистента. AWS описывает механизм Project Rules для Amazon Q Developer как способ закрепить стандарты написания кода и лучше практики внутри проекта. Так, например, агентная среда разработки от AWS Kiro поддерживает steering-директивы и стандарт AGENTS.md, чтобы агент «понимал» правила проекта без ручных напоминаний. Смысл steering rules простой: правила рецензирования и проверки качества перестают быть «традицией в головах» и становятся частью исполняемого процесса.

От Sprints к Bolts от Epics к Units of Work

Когда у вас есть фазы (Inception, Construction, Operations) и способ следовать им через адаптивный процесс и steering rules, возникает вопрос: «Измениться ли базовая единица планирования и измерения инкремента?» Подход AI‑DLC также даёт четкий ответ:

• вместо sprints использовать bolts;

• вместо epics — Units of Work.

По AWS AI‑DLC bolts — это замена спринтам: короткие, более интенсивные циклы работы, которые измеряются часами или днями, а не неделями. Bolt — это маленький «замкнутый» цикл исполнения, в течение которого команда (и/или агент) берёт ограниченный объём, доводит до проверяемого результата и фиксирует артефакты и качество.

Вместо эпиков в терминологии AI‑DLC используют Units of Work — автономные куски результата, которые можно независимо довести до продуктовой эксплуатации пользователями.

Важно правильно понять смысл: bolts — это не дробление задач на микрозадачи, а попытка сделать маленьким сам цикл «сделал → проверил → доставил». И Units of Work — это не просто новое название для эпика, а требование к декомпозиции: каждый UoW должен быть самостоятельным и завершаемым, иначе bolts внутри него превращаются в бесконечную подготовку.

От теории к практике

Рассмотрим подход AI‑DLC на примере: «Редактирование профиля пользователя» (backend + UI + Database)

Intent

Дать пользователю экран «Профиль» и возможность редактировать display_name и timezone.

Условия:

• развёртывание без простоя;

• используем feature flag profile_edit_v1 (чтобы постепенно включать и быстро откатывать);

• качество подтверждаем гейтами (CI, тесты, рецензирование), решения фиксируем в артефактах (PR и короткий audit trail).

Unit of Work (UoW)

User Profile Edit v1 — автономная часть результата, включающая в себя изменения в API, базе данных, пользовательском интерфейсе и минимально необходимую эксплуатационную готовность (наблюдаемость, план rollout/rollback).

Bolts внутри Unit of Work

UoW реализуется серией bolts. Каждый bolt — это короткий цикл поставки, заканчивающийся проверяемым результатом, который можно безопасно доставить.

• Bolt №1: контракт и feature flag (скелет).

  • Цель: зафиксировать контракт и управляемость доработки, не внедряя бизнес-логику.

  • Результат: добавлен endpoint PATCH /api/v1/profile, обновлён OpenAPI (profile_edit_v1).

  • DoD: PR (проведено рецензирование, код одобрен), CI (успешные проверки), артефакт контракта в репозитории.

• Bolt №2: Миграция БД и модель данных.

  • Цель: подготовить хранение новых полей без изменения поведения приложения.

  • Результат: миграция добавляет display_name и timezone, backend-модель/DAO готова.

  • DoD: миграция безопасна (без простоя), есть проверка и тест миграции, CI (успешные проверки).

• Bolt №3: Backend: запись профиля (под флагом).

  • Цель: сделать реальную запись display_name и timezone через PATCH, но пока без UI.

  • Результат: PATCH /profile проверяет вход, пишет в БД, возвращает обновлённую модель, добавлены журналы и метрики.

  • DoD: модульные и интеграционные тесты, успешные проверки CI, функциональность работает при включённом флаге.

• Bolt №4: Чтение профиля и экран интерфейса (read‑only).

  • Цель: дать пользователю экран профиля и отображение данных, не включая редактирование.

  • Результат: GET /api/v1/profile отдаёт поля, поля отображаются в интерфейсе, кнопка «Edit» скрыта при отключённом флаге.

  • DoD: smoke и сквозные тесты интерфейса, успешные проверки CI.

• Bolt №5: Редактирование профиля (форма в UI и PATCH).

  • Цель: сделать форму редактирования профиля и корректную обработку ошибок.

  • Результат: форма с проверкой, отправка PATCH, обработка кодов 4xx/5xx, состояния загрузки.

  • DoD: тестирование интерфейса (модульное и компонентное), интеграционный happy path, успешные проверки CI, функциональность работает при включённом флаге.

• Bolt №6: Operations: наблюдаемость и rollout/rollback.

  • Цель: сделать управляемый выпуск и контроль качества в эксплуатации.

  • Результат: дашборды и оповещения по PATCH /profile, план rollout (1%→10%→50%→100%), план rollback.

  • DoD: runbook и инструкция закреплены, оповещения и метрики проверены.

• Bolt №7: Rollout до 100 % и уборка хвостов.

  • Цель: довести фичу до «готово для всех» и зафиксировать план удаления временных элементов.

  • Результат: флаг включён поэтапно до 100 %, метрики стабильны, создан bolt/тикет на удаление флага (если практикуется).

  • DoD: «фича в проде» с доказательствами (метрики и журналы), без критичных регрессий.

Заключение

Мы подробно рассмотрели, почему появление агентных ИИ‑инструментов меняет саму логику жизненного цикла разработки и приводит к формированию подхода AI‑Driven Development Life Cycle (AI‑DLC). Разобрали его фазы (Inception → Construction → Operations), объяснили роль адаптивных процессов и steering rules, а затем показали на практическом примере, как меняются единицы планирования и поставки: от sprints к bolts и от epics к Units of Work.

Units of Work помогают держать разработку управляемой в условиях высокой скорости изменений. Вместо расплывчатого «эпика» появляется автономная единица результата: с границами, критериями готовности и понятным маршрутом (Inception → Construction → Operations).

Bolts превращают скорость ИИ в скорость завершения цикла. Ценность измеряется уже не строками написанного кода, релизом автономной функциональности, которая прошла гейты качества и готова к поставке: контракт зафиксирован, миграции применимы, тесты и проверки пройдены, фича управляема (например, через feature flag). Такой ритм уменьшает количество незавершённых задач, снижает скрытый риск и делает обратную связь быстрее — что критично, когда изменения появляются часто и быстро.

При этом AI‑DLC не отменяет ответственности: даже если ИИ способен автономно выполнять шаги, то финальные решения (go/no‑go), границы изменений и контроль качества остаются за человеком. Именно поэтому в AI‑DLC так важны steering rules и audit trail: они удерживают поведение ИИ в рамках стандартов команды и оставляют проверяемый след решений и проверок.

Что с этим делать инженерам?

Начать пробовать! :)

• Выберите один сервис ил компонент и один тип работ для прототипа (например, исправления багов или небольшие фичи под feature flag).

• Зафиксируйте «скелет» AI‑DLC на практике: для каждого изменения заведите короткий intent, обозначьте границы и DoD, а результат фиксируйте артефактами в репозитории (PR + evidence и audit trail).

• Не превращайте всё в единый «универсальный регламент». Настройте адаптивный процесс: несколько типовых сценариев под разные классы изменений (hotfix, небольшая фича, миграция данных, рефакторинг) с разным набором обязательных шагов и quality gates. Это позволит сохранять скорость там, где риск низкий, и усиливать контроль там, где риск высокий.

• Введите минимальный bolt‑ритм: маленький объём, обязательные quality gates (CI, тесты, линтеры, сканеры).

• Оформите steering rules как код: стандарты проекта, правила PR, требования к тестам и миграциям — чтобы AI‑ассистент работал в рамках ваших договорённостей, а не «как получится».

• Поддержите это инфраструктурой доставки: быстрый CI, понятные проверки, управляемый релиз (feature flags/canary) и базовая наблюдаемость.

Чтобы оценить эффект, не нужно вводить десятки метрик KPI. Достаточно нескольких — потока и качества: lead time изменения, доля возвратов на «переделать», CFR, время восстановления после инцидента (если применимо). Если после 2–4 недель пилота вы видите уменьшение доли незавершённых задач, более короткий цикл обратной связи, уменьшение проблем интеграции и увеличение скорости поставки ценности — значит, вы на верном пути, на пути AI‑DLC.