Когда код перестаёт быть узким местом: четыре плейбука PDLC/SDLC в эпоху ИИ-агентов

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

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

Эксперимент METR показывает ту же проблему с другой стороны. В исследовании с опытными разработчиками открытых проектов применение инструментов начала 2025 года увеличило время выполнения выбранных задач в среднем на 19%. Результат описывает конкретную выборку, инструменты и тип работ. Производительность зависит от того, как команда встраивает модель в процесс.

Поэтому основной вопрос для компаний звучит уже не так: «Какой процент кода можно сгенерировать?» Важнее другое: как устроить весь PDLC/SDLC так, чтобы агентные изменения сохраняли связь с исходным намерением, проходили достаточную проверку, соблюдали ограничения и давали измеримый результат в эксплуатации?

Ответы начинают оформляться в полноценные плейбуки. В этой статье рассмотрены четыре подхода:

• AI-Native SDLC Playbook от Anthropic;
• AI-Driven Development Life Cycle от AWS;
• AI-Disrupt PDLC от Сбера;
• набор практик AI4SDLC Т‑Банка и Т‑Технологий.

Эти модели нельзя сравнивать как четыре варианта одной инструкции. Они описывают разные уровни системы. Anthropic концентрируется на прохождении конкретного изменения через цепочку артефактов. AWS проектирует адаптивный процесс совместной работы людей и ИИ. Сбер описывает корпоративную архитектуру полного продуктового цикла. Т‑Банк показывает платформенный способ внедрения множества прикладных сценариев с измерением эффекта.

Вместе они дают достаточно материала, чтобы описать устройство AI-native PDLC без привязки к отдельной модели, IDE или поставщику.

От SDLC к исполняемому продуктовому циклу

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

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

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

В минимальной форме такой цикл выглядит так:

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

Код остаётся важным артефактом, но перестаёт быть единственным центром процесса. Рядом с ним находятся спецификация, архитектурные решения, тесты, результаты проверок, политики, права агента, журнал действий и эксплуатационная обратная связь.

Четыре школы AI-native разработки

Главное различие находится не в названиях стадий. Плейбуки по-разному отвечают на пять архитектурных вопросов:

1. Где хранится источник истины?
2. Кто принимает решение о переходе к следующему этапу?
3. Как выбирается глубина процесса для конкретной задачи?
4. Какие действия агент может выполнять самостоятельно?
5. Как доказать, что изменение принесло результат, а не только создало код?

1. Anthropic: жизненный цикл как цепочка принятых артефактов

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

Центральная цепочка строится вокруг трёх файлов:

intent.md → spec.md → plan.md

Названия файлов вторичны. Важен контракт между стадиями.

intent.md: что требуется изменить и зачем

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

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

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

spec.md: каким должно быть решение

После принятия намерения агент формирует спецификацию. Она включает функциональные требования, ограничения, интерфейсы, проектные решения и критерии приёмки.

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

plan.md: как именно будет выполнено изменение

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

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

• все ли запланированные изменения выполнены;
• появились ли незаявленные изменения;
• были ли созданы требуемые тесты;
• не вышел ли агент за установленные границы.

План отделяет принятие архитектурного решения от механического исполнения. Агент может написать значительную часть кода, не получая права самостоятельно менять смысл задачи или выбранную архитектуру.

Код как исполнение плана

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

Для этого Anthropic предлагает использовать CLAUDE.md и связанные skills. В них фиксируются команды сборки, соглашения проекта, архитектурные ограничения, правила тестирования и типовые процедуры. Документация превращается из справочного текста для человека в рабочий контекст агента.

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

Проверка как отдельная агентная функция

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

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

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

Это переносит separation of duties в агентный процесс: автор и контролёр могут быть разными агентами, но право окончательного решения связано с политикой организации и закреплённой ролью участника, а не с именем агента.

Hooks и evals

Anthropic разделяет вероятностное рассуждение агента и детерминированные ограничения среды.

Hooks позволяют автоматически проверять действия до или после их выполнения. В зависимости от контекста система может разрешить операцию, запросить подтверждение или заблокировать её. Так можно запрещать изменение защищённых файлов, выполнение опасных команд, доступ к production или обход обязательных проверок.

Evals проверяют не только итоговый код. Они позволяют оценивать весь агентный harness: инструкции, skills, hooks, способы передачи контекста и маршруты выполнения. Anthropic предлагает собирать набор реальных задач и повторно запускать его после изменений агентной среды. Инциденты и обнаруженные ошибки должны добавляться в этот набор как регрессионные примеры.

Сопровождение замыкает цикл

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

При этом агент может выполнить подготовительную работу вплоть до production gate, но не проходит его без предусмотренного политикой разрешения. Права должны различаться по средам, а правила защиты веток и выпуска действуют независимо от способности модели убедительно объяснить своё решение.

Что даёт подход Anthropic

Сильная сторона плейбука — операционная конкретность. Его можно внедрять поэтапно внутри одного репозитория:

1. зафиксировать намерение;
2. отделить спецификацию от плана;
3. сохранить связь между планом и diff;
4. добавить независимое агентное ревью;
5. ввести hooks и evals;
6. вернуть эксплуатационную обратную связь в начало цикла.

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

2. AWS: адаптивный жизненный цикл вместо универсального конвейера

AWS AI-Driven Development Life Cycle строится вокруг повторяющегося цикла взаимодействия человека и ИИ:

ИИ формирует план
        ↓
ИИ запрашивает недостающий контекст
        ↓
люди принимают критические решения
        ↓
ИИ исполняет утверждённый план

Методология делит жизненный цикл на три крупные фазы: Inception, Construction и Operations.

Inception: совместное уточнение намерения

Фаза Inception преобразует бизнес-намерение в требования и Units of Work. AWS использует формат Mob Elaboration: продуктовые специалисты, инженеры и ИИ совместно прорабатывают задачу.

Агент фиксирует сказанное, задаёт уточняющие вопросы, обнаруживает пробелы и предлагает варианты декомпозиции. Люди принимают решения, которые определяют смысл продукта, допустимые компромиссы и границы изменения.

Units of Work заменяют крупные и долго живущие эпики. Они должны быть достаточно целостными, чтобы давать проверяемый результат, но достаточно компактными для короткого агентного цикла.

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

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

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

Operations: использование накопленного контекста

В Operations тот же контекст применяется для инфраструктуры, развёртывания и сопровождения. Идея состоит в сохранении непрерывности: требования и архитектурные решения не должны теряться при переходе от разработки к эксплуатации.

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

Главная идея AWS: маршрут должен зависеть от задачи

Позднейшее развитие AI-DLC усиливает наиболее важное отличие этого подхода. AWS отказывается от одинакового конвейера для всех изменений.

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

Поэтому workflow scaffold сначала оценивает намерение, существующий контекст, сложность и характер изменения. Затем выбирает:

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

Решение маршрутизируется адаптивно, но не становится непрозрачным. Система фиксирует выбранный путь, созданные материалы и человеческие подтверждения.

Rules и steering вместо привязки к одной модели

AWS реализует методологию через правила и steering-файлы проекта. Открытый набор workflow предназначен для разных агентных инструментов, а не только для одного ассистента.

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

Человек внутри цикла, но не внутри каждой операции

AWS сохраняет human-in-the-loop на всех значимых стадиях. Однако человек не обязан подтверждать каждую команду агента. Он проверяет решения, которые меняют смысл задачи, архитектуру, риск или границы исполнения.

Такой подход снижает две противоположные опасности:

• бесконтрольную автономность;
• approval fatigue, при которой сотрудник механически подтверждает десятки низкоуровневых действий и перестаёт выполнять реальный контроль.

Что даёт подход AWS

Главное достоинство AI-DLC — адаптивность. Процесс подстраивается под задачу, сохраняя контроль и журнал решений.

Это особенно полезно для компаний, где одна платформа обслуживает разные классы изменений:

• небольшие продуктовые улучшения;
• регуляторные доработки;
• инфраструктурные изменения;
• миграции;
• модернизацию legacy;
• устранение production-инцидентов.

Ограничение подхода находится на корпоративном уровне. AWS подробно объясняет взаимодействие команды и агента, но слабее формализует сквозное управление правами, аудитом и зрелостью всей организации. Эти вопросы намного подробнее раскрывает Сбер.

3. Сбер: архитектура AI-native предприятия

AI-Disrupt PDLC от Сбера — наиболее широкая из рассматриваемых моделей. Она охватывает продуктовую Discovery, инженерное исполнение, внутреннюю платформу разработки, валидацию, безопасность, управление автономностью, метрики и программу внедрения.

Методология строится вокруг четырёх взаимосвязанных элементов:

• Intent Loop — контур намерения;
• Implementation Loop — контур исполнения;
• Validation Spine — сквозной контур доказательств;
• Governance Mesh — сквозное управление правами, политиками и аудитом.

Вся система работает поверх Integrated Development Platform — внутренней платформы, которая предоставляет людям и агентам контекст, инструменты, среды, политики и телеметрию.

Intent Loop: сначала определить результат

Контур намерения включает Discovery. До постановки задачи на реализацию команда должна определить:

• какую проблему она решает;
• для кого существует проблема;
• какой результат ожидается;
• как он будет измерен;
• насколько велико изменение;
• подходит ли задача для агентного исполнения;
• существует ли уже стандартное решение.

В методологии используются такие артефакты, как формулировка проблемы, PR/FAQ и outcome hypothesis. Их назначение — связать реализацию с проверяемым продуктовым результатом.

Это расширяет агентный процесс за пределы SDLC. Агент получает не только инструкцию «что изменить», но и контекст «зачем это требуется» и «по какому наблюдаемому признаку результат будет считаться достигнутым».

Implementation Loop: две скорости исполнения

Контур реализации разделён на внутренний и внешний циклы.

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

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

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

Specification-Driven Development

Сбер придаёт спецификации более сильный статус, чем Anthropic. В SDD спецификация претендует на роль основного представления системы, а код, тесты и документация становятся связанными с ней производными.

Подобная идея развивается и в GitHub Spec Kit: спецификация и план реализации рассматриваются как исполняемые первичные артефакты, которым должен служить код.

Спецификация задаёт связи между системой, кодом и проверками. Практический смысл состоит в трёх требованиях:

1. изменение кода должно быть связано с конкретным требованием;
2. расхождение реализации и спецификации должно обнаруживаться автоматически;
3. изменение требований должно запускать пересмотр зависимых артефактов.

Для brownfield-систем это особенно сложно. Реальный код уже содержит больше фактов, чем документация. Поэтому spec-first модель должна уметь извлекать фактическое устройство системы, выявлять расхождения и постепенно восстанавливать прослеживаемость.

Validation Spine: валидация как центральная производственная функция

В традиционном SDLC проверка часто находится после реализации. Сначала создаётся изменение, затем тестировщики, специалисты безопасности и ревьюеры пытаются определить, можно ли его принять.

Validation Spine меняет порядок. Доказательства собираются по всему циклу:

• во время Discovery проверяется обоснованность гипотезы;
• при проектировании — соответствие архитектуре и политикам;
• при реализации — корректность кода и тестов;
• перед выпуском — полнота Evidence Bundle;
• после выпуска — фактический продуктовый и эксплуатационный результат.

Валидация становится общей инфраструктурой принятия решений на всём процессе.

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

Задача агента в таком процессе — предоставить достаточное доказательство приемлемости результата, включая созданный код.

Governance Mesh: три независимых вопроса

Сбер разделяет управление на три измерения:

1. Validation: выполнена ли работа правильно?
2. Permission: разрешено ли агенту выполнять это действие?
3. Audit and compliance: можно ли доказать, как было принято решение и что именно произошло?

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

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

Уровни автономности R0–R5

Вместо бинарного выбора между ручной работой и полным автоматом Сбер вводит шкалу прав агента:

• R0: чтение и анализ;
• R1: подготовка предложений;
• R2: изменения в отдельной ветке с обязательным ревью;
• R3: автоматическое объединение при прохождении заданных проверок;
• R4: выполнение длинных задач через несколько сессий и контрольных точек;
• R5: полная автономность внутри ограниченной песочницы.

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

Один и тот же агент может иметь R3 для обновления документации, R2 для прикладного кода и R0 для production-конфигурации.

Формула human-in-the-loop требует определить решения человека, получаемые им доказательства и случаи обязательной остановки системы.

Зрелость команды L0–L5

Отдельная шкала описывает зрелость организации:

• от эпизодического использования ИИ;
• через регулярную работу с базовыми спецификациями;
• к агентным конвейерам и встроенным политикам;
• далее к guardian agents и зрелой платформе;
• до координируемой многоагентной среды.

Разделение зрелости и автономности принципиально. Команда может использовать сильные модели, но оставаться на низком уровне зрелости из-за отсутствия evals, платформы, стандартов и измерения. И наоборот, зрелая организация может сознательно ограничивать автономность в критичных доменах.

Внедрение за 90 дней

Сбер предлагает начинать с ограниченного MVP, а не с корпоративного запуска для всех разработчиков.

Первые две недели отводятся на фиксацию исходных DORA-показателей, выбор пилотных команд и построение первых продуктовых артефактов. Затем вводятся базовый SDD, карта человеческих решений и проверки в CI/CD. На следующем этапе появляются шаблоны, операции уровня R2 и первый Evidence Bundle. К концу 90 дней оцениваются метрики, агентное ревью включается до merge, а продуктовый результат сопоставляется с исходной гипотезой.

План задаёт последовательность внедрения:

базовая линия
→ ограниченный пилот
→ артефакты и правила
→ доказательства
→ измерение
→ расширение автономности

Что даёт подход Сбера

AI-Disrupt PDLC наиболее полно отвечает на вопросы крупной и регулируемой организации. Он связывает продуктовую постановку, инженерное исполнение, права, доказательства и внутреннюю платформу.

Полная модель требует сложной координации. Внедрение всей системы одним этапом способно создать новую бюрократию. Количественные эффекты в материалах относятся к оценкам и внутренним результатам автора плейбука.

Главная ценность методологии — архитектурное разделение намерения, исполнения, валидации и управления; прогнозы роста производительности здесь вторичны.

4. Т‑Банк: платформа, портфель сценариев и измерение эффекта

У Т‑Банка и Т‑Технологий нет единого публичного документа, сопоставимого по форме с плейбуками Anthropic, AWS или Сбера. Подход приходится восстанавливать из материалов о внутренних практиках, платформе, прикладных решениях и программе AI4SDLC.

Далее приведена реконструкция по корпоративным первичным источникам. Авторы описывают распределённую модель рабочих групп и несколько вариантов разбиения SDLC.

Восстановленный плейбук состоит из четырёх частей:

общая AI-платформа
        ↓
портфель сценариев по стадиям SDLC
        ↓
ограниченные пилоты с исходной линией
        ↓
масштабирование подтверждённых решений

Рабочие группы вокруг инженерных процессов

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

Идеи оцениваются и приоритизируются. Это переводит внедрение ИИ из режима свободного эксперимента в управление портфелем продуктовых инициатив.

Такой подход учитывает неоднородность SDLC. Инструмент для аналитика, агент миграции кодовой базы, генератор тестов и автоматическое ревью имеют разные источники данных, риски, критерии качества и экономику. Их нельзя оценивать одной метрикой adoption или количеством сгенерированного кода.

Единая платформенная основа

Т‑Технологии описывают общий набор компонентов:

• поиск и RAG по внутренним источникам;
• LLM proxy или API Gateway;
• доступ к внутренним и внешним моделям;
• каталог MCP-серверов и инструментов;
• централизованную наблюдаемость;
• интеграции с IDE, трекерами, wiki и инженерными платформами.

Эта инфраструктура отделяет прикладной сценарий от низкоуровневых вопросов доступа к моделям, данным, инструментам, безопасности и мониторингу.

Платформенный слой важен по трём причинам.

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

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

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

Прикладные сценарии вместо универсального агента

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

Такое устройство отражает практический этап развития технологии. Универсальный агент, который одинаково хорошо выполняет весь PDLC, остаётся слишком неопределённым объектом управления. Специализированный сценарий имеет:

• конкретный вход;
• ограниченный набор инструментов;
• понятный результат;
• собственный eval-набор;
• измеримый участок процесса;
• определённую группу пользователей.

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

Пилот, базовая линия, масштабирование

Публичная схема внедрения включает четыре шага:

1. выбрать один-два сценария;
2. провести пилот на ограниченной команде в течение двух-четырёх недель;
3. зафиксировать исходные и итоговые значения Time-to-Market, Lead Time, дефектов и adoption;
4. масштабировать решение после подтверждения эффекта и продолжать его улучшение.

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

Команда как единица измерения

Исследовательская программа AI4SDLC разделяет индивидуальный, командный и организационный эффекты. Это существенное отличие от большинства отчётов об ИИ, которые измеряют скорость выполнения отдельного задания или субъективно сэкономленное время.

Инженер может писать код быстрее, а Lead Time команды останется прежним из-за очереди на ревью, нестабильных тестов или длительного выпуска. Число созданных pull request может вырасти, одновременно увеличив нагрузку на проверяющих и объём переработки.

В программе 2026 года дополнительно исследуются глубина делегирования, длительность автономной работы, доступные агенту права и число параллельных потоков. Кодовый объём и число PR не рассматриваются как самостоятельное доказательство производительности.

Что даёт подход Т‑Банка

Сильная сторона реконструированного плейбука — реалистичная модель внедрения:

• сначала общие платформенные возможности;
• затем ограниченные сценарии;
• затем измерение на уровне команды;
• затем масштабирование.

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

Ограничение — отсутствие единой публичной формальной модели прослеживаемости. В материалах нет такой же явной цепочки артефактов, как у Anthropic, адаптивной карты процесса AWS или шкалы прав Сбера. Поэтому Т‑Банк лучше отвечает на вопрос «как организовать программу внедрения», чем на вопрос «каким должен быть нормативный AI-native PDLC».

Что объединяет четыре плейбука

Различия между моделями значительны, но их общий фундамент уже различим.

1. Намерение становится отдельным артефактом

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

Anthropic фиксирует это в intent.md. AWS начинает с business intent и Mob Elaboration. Сбер использует Discovery, PR/FAQ и outcome hypothesis. Т‑Банк начинает с отбора и приоритизации сценария.

Чем выше автономность исполнения, тем строже требования к качеству намерения.

2. Контекст становится производственной инфраструктурой

Контекст больше нельзя собирать вручную для каждой сессии. Он включает:

• код и зависимости;
• архитектуру;
• API и модели данных;
• стандарты;
• требования безопасности;
• историю решений;
• сведения о пользователях и продукте;
• инструменты выполнения действий;
• текущее состояние сред.

Anthropic размещает значительную часть контекста в репозитории и skills. AWS использует persistent project context и steering rules. Сбер передаёт контекст через IDP. Т‑Банк создаёт общий поиск, RAG, gateway и каталог инструментов.

Поэтому качество агентной системы зависит от модели, доступных и актуальных знаний, а также разрешённых действий.

3. Спецификация и план отделяются от реализации

Все четыре подхода пытаются предотвратить смешение двух решений:

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

Разделение снижает вероятность скрытого изменения требований во время генерации кода. Оно также позволяет использовать разные модели или агентов для проектирования, исполнения и проверки.

4. Валидация должна масштабироваться вместе с генерацией

Если объём изменений растёт в два раза, а ревью и тестирование остаются прежними, ускорение превращается в новую очередь.

Поэтому появляются:

• continuous evals;
• verifier agents;
• AI review;
• guardian agents;
• автоматическое сопоставление кода со спецификацией;
• Evidence Bundle;
• детерминированные hooks;
• риск-зависимые release gates.

Исследования METR дополнительно показывают, что функционально корректное решение агента может не быть готовым к включению в реальный проект из-за качества тестов, форматирования и других требований сопровождаемости. Успешное прохождение benchmark нельзя приравнивать к production readiness.

5. Политики превращаются в исполняемые ограничения

Регламент в wiki не обеспечивает соблюдение правила агентом. Политика должна влиять на доступные действия:

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

Anthropic реализует это через hooks и managed settings. AWS — через правила и checkpoints. Сбер — через Governance Mesh и policy-as-code. Т‑Банк — через платформенный gateway, управление инструментами и централизованную наблюдаемость.

6. Эксплуатация возвращается в начало цикла

Инцидент, нарушение SLO, рост ошибок или отсутствие ожидаемого продуктового эффекта должны создавать новое намерение. Цикл не завершается merge или deployment.

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

• он выпущен;
• система работает в допустимых пределах;
• результат сопоставлен с исходной гипотезой;
• новые знания возвращены в контекст.

Где плейбуки расходятся

Объединить четыре подхода механически невозможно. За разницей терминов находятся реальные архитектурные альтернативы.

Фиксированные стадии или адаптивный маршрут

Anthropic сохраняет шесть узнаваемых стадий и определяет артефакты перехода между ними. AWS выбирает глубину и состав стадий в зависимости от задачи. Сбер сохраняет постоянные контуры, но адаптирует права и требования к доказательствам. Т‑Банк строит отдельные сценарии вокруг разных частей SDLC.

Практический вывод: компании требуется набор классов изменений, из которых складываются маршруты под риск.

Например:

Адаптивность опирается на формальный механизм классификации риска.

Repo-first, spec-first или platform-first

Anthropic и AWS естественно начинают с репозитория. Это позволяет внедрять процесс снизу: добавить файлы, правила, hooks и проверки внутри проекта.

Сбер движется к spec-first и IDP. Источник истины находится в системе взаимосвязанных спецификаций, политик и фактических артефактов.

Т‑Банк использует platform-first подход: общая инфраструктура предоставляет контекст, модели, инструменты и наблюдаемость прикладным решениям.

Выбор зависит от масштаба:

• одной команде проще начать с repo-first;
• продуктовой платформе нужен общий контекст и интеграции;
• регулируемому предприятию потребуется централизованное управление и аудит;
• brownfield-среде придётся одновременно учитывать код как фактическое состояние и спецификации как целевое.

Human-in-the-loop или risk-adaptive autonomy

Фраза «человек остаётся в контуре» описывает три конкретных вопроса:

• какой человек;
• на каком этапе;
• какое решение он принимает;
• какие доказательства получает;
• что произойдёт при отсутствии ответа;
• можно ли отменить действие.

AWS делает человеческие checkpoints частью каждой значимой стадии. Anthropic связывает подтверждения с артефактами и production gates. Сбер предлагает наиболее формальную риск-зависимую шкалу R0–R5. Т‑Банк контролирует автономность через специализированные сценарии и платформенные ограничения.

На практике требуется минимально достаточное участие человека при контролируемом риске; цель — управляемая автономность.

Централизованная платформа или локальные правила

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

Централизованная IDP обеспечивает общие сервисы:

• управление моделями;
• доступ к знаниям;
• каталог инструментов;
• политики;
• песочницы;
• идентификацию агентов;
• телеметрию;
• аудит;
• eval-инфраструктуру.

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

Референсная архитектура AI-native PDLC

После удаления названий продуктов и внутренних терминов остаётся следующая архитектура:

СИГНАЛЫ
обращения пользователей / стратегия / данные / инциденты
                              │
                              ▼
НАМЕРЕНИЕ
проблема / аудитория / ожидаемый результат / ограничения
                              │
                              ▼
СПЕЦИФИКАЦИЯ
требования / архитектура / интерфейсы / критерии приёмки
                              │
                              ▼
ПЛАН
декомпозиция / затрагиваемые компоненты / риски /
порядок работы / необходимые доказательства
                              │
                              ▼
ОРКЕСТРАЦИЯ
выбор маршрута / агентов / моделей / инструментов /
уровня автономности / контрольных точек
                              │
                              ▼
ИСПОЛНЕНИЕ
код / тесты / документация / конфигурация /
миграции / инфраструктура
                              │
                              ▼
ВАЛИДАЦИЯ
детерминированные тесты / evals / review agents /
безопасность / архитектурные правила / compliance
                              │
                              ▼
РЕШЕНИЕ
принять / вернуть на доработку / эскалировать /
выпустить автоматически или после подтверждения
                              │
                              ▼
ЭКСПЛУАТАЦИЯ
SLO / ошибки / стоимость / продуктовые показатели /
поведение пользователей
                              │
                              └──────────────► новое намерение

Через весь цикл проходят три горизонтальных слоя.

Контекст и знания

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

Governance

Слой определяет:

• кто или что может инициировать работу;
• какие инструменты доступны;
• какие данные можно читать;
• какие компоненты разрешено менять;
• где требуется подтверждение;
• какие доказательства обязательны;
• как остановить и отменить действие.

Телеметрия и evals

Слой фиксирует:

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

Без этих трёх слоёв агент остаётся интерфейсом к модели. С ними он становится управляемым участником производственной системы.

Как меняются роли

Агенты сокращают объём ручного исполнения, но увеличивают значение постановки, проектирования и проверки.

Владелец продукта отвечает за намерение

Продуктовый менеджер должен формулировать наблюдаемое изменение поведения пользователя или бизнеса и связывать его с проверяемой outcome hypothesis. Его работа становится ближе к проверке продуктовой гипотезы.

Неясность на этом уровне больше нельзя компенсировать длительной ручной реализацией. Агент быстро материализует противоречия постановки в коде.

Инженер управляет ограничениями и доказательствами

Инженер всё меньше времени тратит на механический ввод кода и больше — на:

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

Это не отменяет знание программирования. Напротив, проверка большого объёма машинных изменений требует способности быстро распознавать архитектурные и эксплуатационные дефекты.

Платформенная команда создаёт среду для агентов

К внутренней платформе разработки добавляются новые функции:

• управление моделями;
• агентные runtime;
• MCP и другие интерфейсы инструментов;
• индексация знаний;
• песочницы;
• policy engine;
• eval-наборы;
• трассировка;
• учёт стоимости;
• идентификация и права агентов.

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

Возникает владелец политик

Архитектурные, безопасностные и регуляторные требования должны быть преобразованы в исполняемые правила. Для этого требуется совместная работа специалистов предметной области, платформенных инженеров и владельцев процессов.

Политика должна иметь:

• формальное условие применения;
• проверяемое требование;
• реакцию при нарушении;
• владельца;
• версию;
• набор тестов;
• исключения и порядок их согласования.

Ревьюер становится проектировщиком системы контроля

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

Цель состоит не в том, чтобы быстрее читать машинный код. Нужно уменьшать долю изменений, для которых человеческое чтение является единственной защитой.

Как измерять эффект

Главная ошибка программ внедрения ИИ — измерять доступную активность вместо результата.

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

Даже acceptance rate показывает только локальную пригодность предложения. Принятый фрагмент может позже потребовать переработки, усложнить сопровождение или увеличить время ревью.

Система измерения должна состоять из четырёх уровней.

1. Продуктовый результат

• изменение целевого поведения пользователя;
• рост дохода или снижение затрат;
• сокращение продуктового риска;
• достижение показателя, указанного в outcome hypothesis.

2. Поток поставки

Актуальный набор DORA включает пять показателей:

• change lead time;
• deployment frequency;
• failed deployment recovery time;
• change fail rate;
• deployment rework rate.

Их следует рассматривать вместе и сравнивать только для сопоставимых систем. Превращение одной метрики в соревновательный персональный KPI искажает поведение команды.

3. Качество и сопровождаемость

• дефекты после выпуска;
• уязвимости;
• архитектурные нарушения;
• изменение сложности;
• нестабильность тестов;
• объём повторной работы;
• время ревью;
• доля отклонённых или существенно переработанных агентных изменений.

4. Работа агентной системы

• доля задач по уровням автономности;
• средняя длительность автономной работы;
• число эскалаций;
• число повторных попыток;
• успешность eval-наборов;
• стоимость принятого изменения;
• полнота контекста;
• частота блокировок политиками;
• доля действий, потребовавших ручного подтверждения.

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

Минимально жизнеспособный плейбук на 90 дней

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

Дни 1–14: выбрать процесс и установить базовую линию

Выбирается одна команда и один-два повторяемых сценария. Подходящий пилот должен иметь:

• достаточную частоту;
• наблюдаемый результат;
• ограниченный радиус риска;
• существующие тесты или доступный способ проверки;
• возможность сравнить процесс до и после внедрения.

До запуска фиксируются Lead Time, время активной работы, ожидание ревью, объём переработки, дефекты и субъективная нагрузка команды.

Не следует начинать с наиболее критичной системы или с задачи «автоматизировать весь SDLC».

Дни 15–30: ввести цепочку артефактов

Для пилотного сценария вводится минимальная структура:

intent → specification → plan → change → evidence → outcome

Каждый артефакт получает:

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

Необязательно использовать Markdown. Артефакты могут храниться в трекере, Git, каталоге архитектурных решений или продуктовой системе. Связи должны быть доступны агентам и пригодны для автоматической проверки.

Дни 31–45: собрать управляемый контекст

Агенту предоставляются:

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

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

Дни 46–60: разделить исполнение и проверку

Вводятся три класса контроля:

1. детерминированные тесты и статические правила;
2. независимая агентная оценка;
3. человеческое решение для критичных случаев.

Агент, создающий изменение, не должен быть единственным источником его оценки.

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

Дни 61–75: определить уровни риска и автономности

Для каждого действия задаётся допустимый режим:

Учитываются критичность среды, обратимость, покрытие тестами, доступ к данным и возможный ущерб.

Дни 76–90: оценить системный результат

Показатели сравниваются с базовой линией. Отдельно анализируются:

• локальное ускорение исполнителя;
• изменение командного Lead Time;
• нагрузка на ревью;
• количество переработок;
• качество после выпуска;
• стоимость моделей и платформы;
• фактический продуктовый результат.

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

Какой плейбук выбрать

Компании не требуется принимать одну методологию целиком.

Anthropic подходит как основа процесса внутри репозитория

Его сильные элементы:

• явные артефакты перехода;
• связь намерения, спецификации, плана и кода;
• независимое ревью;
• hooks;
• continuous evals;
• возврат эксплуатации в начало цикла.

Это наиболее быстрый способ дисциплинировать работу одного или нескольких кодовых агентов.

AWS подходит для адаптивной маршрутизации

Из него следует заимствовать:

• совместное уточнение требований;
• короткие Units of Work;
• выбор стадий под конкретную задачу;
• прозрачные checkpoints;
• независимость процесса от конкретной модели.

Подход полезен там, где одинаково строгий workflow создаёт лишние издержки.

Сбер подходит как референс корпоративной архитектуры

Наиболее ценные элементы:

• разделение Intent Loop и Implementation Loop;
• Validation Spine;
• Governance Mesh;
• уровни автономности R0–R5;
• разделение зрелости команды и прав агента;
• IDP как среда исполнения;
• 90-дневная последовательность внедрения.

Это ориентир для крупной организации, где требуются единые политики, аудит и управление риском.

Т‑Банк подходит как модель программы внедрения

Из реконструированного подхода следует взять:

• общую минимальную AI-платформу;
• портфель специализированных сценариев;
• рабочие группы вокруг инженерных процессов;
• обязательную базовую линию;
• командный уровень измерения;
• масштабирование только подтверждённых решений.

Эта модель снижает риск построить сложную методологию без реального использования.

Основной вывод

AI-native PDLC/SDLC не определяется долей кода, написанного моделью. Он определяется устройством всего производственного контура.

Зрелая система должна уметь:

• преобразовать сигнал в проверяемое намерение;
• предоставить агенту актуальный и разрешённый контекст;
• отделить спецификацию и план от исполнения;
• выбрать маршрут по сложности и риску;
• ограничить действия агента техническими политиками;
• собрать доказательства корректности;
• сохранить происхождение решений;
• связать выпуск с эксплуатационным и продуктовым результатом;
• вернуть новые данные в следующий цикл.

Узким местом становится не производство кода. Им становится способность организации точно формулировать намерение, быстро проверять результат и безопасно делегировать исполнение.

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

Что сделать дальше

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