Сбер перестроил весь цикл AI разработки вокруг агентов: 6 уровней автономии вместо автодополнения

До сих пор большинство команд использовали ИИ точечно: автодополнение кода, генерация тестов, черновики документации. Сам процесс разработки при этом оставался прежним. AI Disrupt PDLC (Product Development Life Cycle, жизненный цикл разработки продукта) ставит задачу иначе: ИИ-агент (программа, которая сама выполняет цепочку действий для достижения цели) работает с бизнес-задачей, спецификациями, кодом, тестами и инфраструктурой, а человек ставит цель, принимает ключевые решения и контролирует результат. Разбор руководства показывает, что многие отдельные элементы AI Disrupt имеют предшественников, но Сбер собрал их в связанную систему и адаптировал под собственную архитектуру.

Что собрано внутри AI Disrupt?

• Два связанных цикла разработки. Intent Loop (цикл намерения) превращает бизнес-задачу в формальное описание результата, ограничений и критериев проверки. Implementation Loop (цикл реализации) превращает это описание в работающий продукт.

• Спецификация как контракт между человеком и агентом. Specification-Driven Development (разработка от спецификации) делает техническое задание не просто документом для людей, а машинно-читаемым контрактом: агент получает из него задачу и ограничения. Подход не изобретён Сбером, в 2025 году похожие реализации представили Kiro и GitHub Spec Kit, но здесь он встроен в общую архитектуру.

• Принцип «среда важнее модели» (Environment > Model). Агенту мало хорошей языковой модели и качественного промпта (текстовой инструкции для ИИ). Ему нужны доступ к репозиториям, документации, тестовым средам, CI/CD (автоматическая сборка и доставка кода). Для этого в архитектуре появляются IDP (внутренняя платформа разработчика) и Golden Paths (проверенные маршруты выполнения задач).

• Validation Spine, сквозной контур проверки. Когда агент работает быстрее человека, ручная проверка каждого шага становится узким местом. Validation Spine (позвоночник валидации) автоматически сопровождает результат от спецификации до работающей системы. Вместе с кодом формируется Evidence Bundle, набор доказательств того, что результат соответствует требованиям.

• Governance Mesh, управление полномочиями. Агент, который только предлагает фрагмент кода в редакторе, и агент, который сам меняет репозиторий и запускает инструменты, представляют разные классы риска. Governance Mesh (сетка управления) включает Policy as Code (политики в виде кода), управление разрешениями, контроль действий и Guardian Agents (агенты-надзиратели).

• Шкала автономии R0–R5. Шесть уровней описывают, насколько самостоятельно агент может действовать: от R0 (человек делает всё сам, ИИ только подсказывает) до R5 (агент действует автономно в заданных рамках). По данным руководства, в шкале смешиваются не только автономность, но и разрешения, риск, длительность выполнения и свойства среды.

Откуда растут корни?

Сбер не скрывает, что отдельные элементы AI Disrupt существовали до него. Работа от будущего результата и формат PR/FAQ пришли из практики Amazon Working Backwards. IDP и Golden Paths сформировались в сообществе platform engineering. Policy as Code появился в DevOps-культуре задолго до ИИ-агентов.

31 июля 2025 года, буквально за несколько дней до публикации Сбера, AWS представила AI-Driven Development Life Cycle (AI-DLC), собственный подход к жизненному циклу разработки с ИИ в центре. AWS тоже противопоставляет его простому добавлению ассистента в существующий процесс: ИИ становится центральным участником, формирует планы, запрашивает уточнения и выполняет реализацию, а критические решения остаются за человеком.

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

Как попробовать?

1. Найдите руководство AI Disrupt PDLC на ресурсах Сбера. На момент публикации документ доступен, но конкретный URL и условия доступа могут измениться.
2. Оцените текущий уровень автономии ИИ в вашей команде по шкале R0–R5. Большинство команд, использующих автодополнение кода, находятся на уровне R0–R1.
3. Начните со Specification-Driven Development: переведите одну задачу из текстового описания в формализованную спецификацию, которую может прочитать и агент, и человек.
4. Внедряйте Governance Mesh до повышения автономии агента, а не после: сначала определите, что агенту разрешено, потом расширяйте его полномочия.

Сравнение с зарубежным аналогом: AWS AI-DLC

Для команд из РФ и СНГ AI Disrupt имеет практическое преимущество: руководство написано с учётом отечественной инфраструктуры и не зависит от доступности зарубежных облачных сервисов, часть которых ограничена для российских пользователей.

Частые вопросы

AI Disrupt подходит только крупным компаниям?

Руководство описывает архитектуру, рассчитанную на организации с выстроенными процессами разработки. Но отдельные элементы, Specification-Driven Development, шкала автономии, принцип «среда важнее модели», применимы в командах любого размера. Маленькая студия может взять шкалу R0–R5 как ориентир, не внедряя Governance Mesh целиком.

Чем это отличается от простого использования Copilot или GigaChat в коде?

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

Можно ли применить идеи AI Disrupt вне разработки ПО?

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

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