Whitepaper Сбера «AI-Disrupt PDLC»: разбор для тех, кто пишет код

На ЦИПР-2026 в Нижнем Новгороде, 19 мая, Сбер выкатил whitepaper с амбициозным названием — «AI-Disrupt PDLC. Стратегия AI-трансформации бизнеса: от кода к намерению». Автор — Кирилл Меньшов, СВП и глава блока «Технологии». В тот же день там же подписали меморандум о партнёрстве с red_mad_robot. То есть это был не «выложили на сайт», а вполне заготовленный релиз с витриной.

Открытых версий две. Короткая — PDF на 28 страниц, обзорная. Длинная — .docx на 337 тысяч знаков, в пять раз толще, и местами это совсем другой документ: там лежит почти всё интересное. Я прочитал обе целиком, плюс лендинг (на нём, кстати, есть пара формулировок, которых нет в PDF), плюс смежные публикации Сбера, Яндекса, Т-Технологий и red_mad_robot к этому же релизу.

Ниже — пересказ того, что в документе важно для инженера. Без пересказа цитатами и без рекламы. Где это пересказ — там пересказ. Где это моё мнение — написано «от себя».

О каком документе вообще речь

По жанру это vendor-whitepaper, в большом смысле — отраслевой манифест. Сбер прямо в первых строчках пишет: «не дожидаемся появления готовых внешних фреймворков, проводим собственную трансформацию уже сейчас, валидируем подходы на промышленной инженерной практике и готовы делиться накопленными знаниями». Перевод с дипломатического: «у нас сделано, у вас нет, ловите».

Целевая аудитория — CEO, CTO, CIO, CISO, CAIO. C-level, не инженеры. Видно по языку: «культура», «горизонты», «стратегические окна», «преимущество 2028–2030». Но за этим слоем лежит конкретная техническая архитектура, и именно её я хочу вытащить — она в разы интереснее обёртки.

Структура простая: пять разделов — видение, эволюция разработки, архитектура IDP, безопасность и роли, дорожная карта. Это в PDF. В полной .docx ещё четыре больших куска, без которых концепция читается как маркетинговая стратегия, а с которыми — как техническая спецификация будущей платформы Сбера. О них дальше.

От себя. Стоит сразу держать в голове, что за концептуальным каркасом «AI-Disrupt PDLC» стоит вполне конкретный продукт — внутренняя платформа Сбера со всеми атрибутами: Agent Runtime, Agent Marketplace, Context Supply Chain. Документ хорошо объясняет, почему такую платформу нужно строить внутри. И заодно, между строк, аргументирует, почему ставка на Cursor / Copilot / Claude Code-as-a-service в большом enterprise — плохая идея. Эту вторую функцию документа полезно видеть. Но видеть её — не значит обесценивать первую: даже если убрать всю продуктовую витрину Сбера, инженерная рамка остаётся осмысленной.

Главный тезис в одной фразе

«AI — это не очередной инструмент, а новая природа организации». Поэтому встраивать Copilot в старые процессы — стратегический тупик. Перестраивать надо весь PDLC (Product Development Life Cycle) вокруг намерения человека, а не вокруг кода.

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

Если ловить документ на повторах, то их пять: «от кода к намерению», «окружение агента важнее модели», «единственный дефицитный ресурс — намерение», Zero-Friction (скорость ограничена только качеством мысли), Vibe Working (управленческая философия эпохи AI). Первые три я готов защищать, к Vibe Working у меня большие вопросы, но о них дальше.

Двухпетлевая модель: где живёт человек, где живут агенты

Базовая модель в документе — две петли с принципиально разным тактом. Слева — Intent Loop, петля намерения. Человек, такт в днях: поставил задачу, написал спецификацию, проверил результат. Справа — Implementation Loop, петля реализации. Агенты, такт в минутах: разобрали задачу, сгенерировали код, прогнали автопроверки. А посередине, как Венский конгресс, — Integrated Development Platform, IDP. Её работа — переводить намерение в исполнение и возвращать результат на валидацию.

Жёсткое правило, на котором документ настаивает раз пять: функция человека — намерение, функция агента — исполнение. Архитектурные и продуктовые решения человеку не делегируются. Никогда.

Что физически входит в IDP, если разворачивать: мульти-агентная система с изоляцией через субагентов (mixture of experts); оператор корпоративного контекста, который подаёт его агенту just-in-time; интеграция с мастер-системами через MCP (Model Context Protocol, переданный в Linux Foundation) и A2A; Skills — сертифицированные переиспользуемые навыки с низкой стоимостью контекста; observability на всё подряд (токены, события сжатия контекста, переходы между субагентами); self-service, чтобы каждый инженер мог сам собирать себе навыки, агентов и маршруты. Это длинный список, и каждый пункт тянет за собой свою команду и свой бэклог.

Сама по себе двухпетлевая модель — не новость. То же самое в разных видах лежит в основе AWS AI-DLC и любого нормального agentic-конвейера, который сейчас строят. Что в whitepaper реально удачно — это акцент на IDP как на отдельной инженерной сущности. Большинство команд, с которыми я сталкивался, об IDP думают как о «папке со скриптами и Slack-боте». Это пройдёт. Через год-полтора такое будет архитектурно стыдно — как сегодня стыдно деплоить без CI.

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

Whitepaper плотно усыпан цифрами. Большая часть подтянута из внешних отчётов — DORA 2025, AWS, McKinsey, Anthropic, Bain; часть — внутренняя кухня Сбера. Из всего массива есть смысл вытащить пять-шесть якорей, на которых держится вся остальная аргументация.

98 % против 2 %. Около двух процентов инженерной ценности агентного pipeline даёт логика принятия решений в самой модели. Остальные девяносто восемь — это детерминированная обвязка вокруг: permission gates, recovery, evals, audit, context management, tool routing, policy hooks. Самая сильная цифра документа, она же самая спорная. О ней дальше будет отдельно.

93 % approvals. В среднем 93 % запросов агента на разрешение действия человек подтверждает автоматически — не вчитываясь. Документ формулирует жёстко: ручное yes/no-одобрение не работает как основной контур безопасности, оно систематически вырождается. Подтверждается, в том числе, телеметрией Anthropic.

Потолок «AI как ассистент» и эффект «AI как новая природа». Прирост продуктивности от Copilot в IDE — 11–25 % по внешним бенчмаркам и 10–15 % по внутренним наблюдениям Сбера. Сбер называет это верхней границей отдачи: дальше эта схема не масштабируется. Если же перестроить под AI сам процесс — заявленный диапазон 35–45 %. На лендинге sbertech.ru/whitepaper атрибуция дана честно: это McKinsey. В PDF цифра 35–45 % без источника, что отдельная мелочь, но мелочь характерная.

Скрытый технический долг от Copilot-ов. Код пишется на 35 % быстрее, но содержит на 25 % больше уязвимостей. Около четверти проблем доезжают до прода. Сложность кода растёт на 40 %. Прогноз: к 2028 году 40 % предприятий, использующих агентные инструменты, удвоят расходы на AI-кодирование — из-за пробелов в управлении. Не из-за моделей. Из-за процессов.

Токеномика. Token usage объясняет 80 % дисперсии производительности агентов. Мульти-агентная архитектура съедает примерно в 15 раз больше токенов, чем chat-режим. Без системного контроля затраты на агентов могут составить 40–60 % всего IT-бюджета к 2027 году. Автоматический выбор оптимальной модели под задачу даёт экономию 60–70 % токенов. Кэширование системных инструкций — до 10× снижения стоимости input-tokens. Эти три цифры — 15× потребление, 60–70 % экономия выбором модели, 10× кэш — стоит запомнить наизусть, они работают как готовые ориентиры на FinOps-планировании.

DORA 2025. AI-инструменты уже использует около 90 % разработчиков. Но прирост неравномерен и зависит от зрелости: 45 % тратят меньше времени на код, 42 % — больше на ревью. И ключевая мысль отчёта, которую whitepaper выносит наверх: AI работает как усилитель. Сильные команды получают мультипликативный эффект, слабые — усугубление своих проблем. Идея «давайте раскатим Copilot всем — и слабые подтянутся» — не подтверждается.

От себя. Цифра 98/2 — самая сильная мысль документа. Если она хотя бы наполовину правда, она убивает популярный фрейм «дайте нам лучшую модель — и всё решится» и переводит фокус инвестиций с подписок на собственный harness. Я думаю, Сбер тут прав по сути, но к самому числу относиться буквально не надо: 98 — инженерная риторика, не измеримая метрика. Реальное соотношение сильно зависит от того, что вы считаете «обвязкой». Harness и правда доминирует по строкам кода и часам инженеров. Но модель без правильно подобранного промта и контекста никакая обвязка не вытащит — баланс не настолько одностороний. Безопаснее читать это как: «модель — не центральная переменная вашей системы». Этого хватит, чтобы поменять стратегию.

Со второй парой цифр — «11–25 % против 35–45 %» — есть подвох, который в самом whitepaper не разобран. Первая цифра меряет один процесс, в который добавили AI. Вторая — уже другой процесс, перепроектированный под AI. Это сравнение не показывает «эффект масштабирования»; оно показывает эффект перепроектирования. На таком сравнении любой консультант обоснует любую трансформацию. К чести Сбера, в полной .docx-версии этот разрыв осмыслен и назван своим именем — Discovery Gap, о нём ниже.

Discovery Gap: главный практический инсайт

В PDF этого почти нет, а в полной .docx-версии — есть, и это, на мой взгляд, самая полезная инженерная рамка во всём документе. Сбер вводит Discovery — отдельный этап петли намерения от «причины для изменения» до готовой спецификации. Смысл — переосмыслить задачу прежде, чем написана сама спецификация. До любого кода.

И вот тут — тот самый бинарный выбор: адаптация или перепроектирование. С цифрами.

Примеры в документе вполне предметные. Адаптация: банк прикрутил AI-агента для маршрутизации простых обращений о выплатах. Старый процесс воспроизведён один в один, прирост пропускной способности — 25–35 %. Перепроектирование: тот же контур, но процесс пересобран вокруг агента. Пропускная способность — 60–80 %.

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

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

От себя. Эта бинарка — «адаптация или перепроектирование» — то, что любой CTO или техлид может прикладывать к своему процессу прямо завтра. И тут же находится ответ на популярный вопрос «мы внедрили Copilot, а где, собственно, скорость?». Ответ обычно такой: код стало писать быстрее на 20 %, но релизный цикл не сдвинулся. Значит, вы в режиме адаптации, и узкие места не там, где AI работает. Они в согласованиях, в QA-конвейере, в очереди на ревью, в инфраструктурных раскатках — то есть в местах, где Copilot не помогает.

Окружение агента важнее модели

В полной .docx-версии есть отдельный раздел, в котором Сбер открыто сравнивает две референсные архитектуры — Claude Code от Anthropic и open-source-стек OpenClaw.

Claude Code: 98,4 % детерминированной инфраструктуры, ~1,6 % логики ИИ. Среда работы агента как капитальный актив. OpenClaw: акцент на шлюзе политик и multi-tenancy.

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

Главная цитата для всего документа, на мой взгляд, вот эта: «Если harness будет передан наружу — компетенция уходит наружу». Звучит как заклинание, но смысл вполне прикладной — об этом дальше.

Это, кстати, и есть первый из пяти архитектурных принципов зрелой IDP: Agent Runtime / Deterministic Harness — единственный компонент, который должен быть создан внутри. Остальные четыре: Golden Path (рекомендуемый маршрут задачи через AI PDLC), self-service и расширяемость (место для bottom-up решений), observability и AgentOps, Security & Governance с моделью implicit deny — всё, что явно не разрешено, запрещено.

На лендинге, кстати, принципов переформулировано четыре: «среда работы агента важнее модели», «Discovery важнее промпта», «Validation важнее скорости поставки», «Governance в процессе важнее проверок постфактум». Четвёртый — про governance — из PDF почему-то выпал, в .docx он есть. Мелкая нестыковка между версиями, но показательная.

От себя. В .docx Сбер прямо называет Claude Code как образец и приводит ту самую метрику 98,4/1,6. Это, по сути, открытое признание: мы изучали Claude Code, сделали выводы и публикуем их как фреймворк. Здоровая позиция — несравнимо лучше, чем «мы тут всё сами изобрели». Но из неё вытекает один практический вывод, который я не видел нигде в публичном пространстве: чтобы строить свою IDP, надо сначала научиться разбирать чужие. Не «сертифицировать AI-инженеров на трёхдневных курсах», а посадить команду читать harness’ы Claude Code, Aider, OpenHands, Devin — на уровне исходников и архитектурных решений. Это не «изучение AI», это инженерное reverse engineering. И это сильно дороже, чем большинство компаний готовы признать.

Это, к слову, прямо противоречит привычному корпоративному паттерну «купим best-in-class, у нас бюджет». Whitepaper говорит честно: купить можно модель, но harness вокруг неё — это уже ваша инженерная экспертиза. И наружу её отдавать нельзя.

Context Supply Chain и Policy as Code

Раздел про контекст в whitepaper, по-моему, самый недооценённый. Сбер берёт принципы supply chain security — владелец, scope, validity, eval coverage, аналог SBOM — и переносит их на работу с контекстом. AGENTS.md, skills, политики, evals начинают жить как код. С код-ревью. С версионированием. С регрессионными тестами. С аудитом.

Против чего это работает. Во-первых, против context poisoning, когда злоумышленник правит файлы контекста, и агент незаметно начинает считать вредное поведение нормой. Во-вторых, против устаревания: описание архитектуры расходится с реальностью, агент пишет код «как было», а не «как есть» — это, кстати, главная причина «странных» ошибок агентов на больших кодовых базах. В-третьих, против конфликтов локального и глобального контекста. В-четвёртых, против prompt injection — через README, описание issue, ответ MCP-сервиса. Это не теоретическая угроза, на практике уже встречалось.

В паре с Context Supply Chain идёт Policy as Code: нормативные требования встроены в агентные микроциклы как автоматические проверки, а не как PDF на гугл-диске. Сбер чётко разводит две вещи — context-as-guidance (рекомендация, агент может учесть) и policy enforcement (обязательно к исполнению, без вариантов). На практике эта разница и есть граница между «у нас есть compliance» и «у нас compliance в runtime».

Я бы рискнул сказать, что это та часть документа, которую любая enterprise-команда может разобрать на бэклог дословно. Особенно финтех и госструктуры. В полной .docx-версии прямо назван российский корпоративный контур: 152-ФЗ, требования ЦБ к аудиторскому следу, ФСТЭК, ГОСТ Р. И предложены конкретные модули политик — локализация ПДН, хранение аудита 7 лет, изоляция критической инфраструктуры. В PDF этого нет вовсе. Это эксклюзив полной версии, и он стоит отдельных денег.

От себя. Перенос supply chain security на контекст — это операционализация того, что у большинства команд сейчас лежит в виде «папки промтов в Notion с правами на запись у всех». Те, кто построит это рано, получат основу для аудита, compliance и регрессионного тестирования AI-поведения. Это не модный buzzword, это базовая инженерная гигиена. В 2027–2028 годах она станет частью внешних аудитов, как сейчас SBOM. Я уверен в этом примерно на 90 %.

Governance Mesh: третья ось PDLC

Самая смелая архитектурная заявка во всём whitepaper — Governance Mesh. В обзорном PDF её нет вовсе; в полной .docx-версии под неё отведён целый раздел.

Сбер системно бьёт по классическому IT-governance — ITIL, ITSM, COBIT, TOGAF — за их post-hoc stage-gated модель. Цитата: «Скорость и непрозрачность AI-Native разработки делают post-hoc валидацию несоизмеримыми с темпом генерации risk-signals». Если по-русски — gate-process с проверками после каждой стадии не успевает за тем, что внутри pipeline происходит каждые 30 секунд.

Что предлагается взамен. Governance Mesh — параллельный сквозной слой управления, который пронизывает обе петли (Intent и Implementation) и удерживает три измерения сразу.

Первое — Quality dimension. Методика валидации ИИ-результатов, в одном вопросе: правильно ли сделано. Второе — Permission/Policy dimension. Право на действие: можно ли это делать и кем. Третье — Audit/Compliance dimension. Доказательность и regulatory enforcement: как мы это докажем регулятору.

Документ настаивает: «Это не последовательные стадии и не альтернативные оси — параллельные грани одного зонтика». Звучит как философия, но за этим стоит вполне технический сдвиг. Governance перестаёт быть отдельной вертикалью, к которой код «приносят на проверку», и становится compliance-runtime, идущим параллельно основному pipeline. Audit-stream — туда же, в параллель.

От себя. Это серьёзная заявка, и она будет резонировать в audit/compliance-кругах. Если Mesh реально взлетит (а у Сбера для этого больше всего шансов — просто в силу опыта работы под ЦБ), это будет тихий конец классического change advisory board в его нынешнем виде. CAB останется. Как ритуал. Но контуром принятия решений он быть перестанет — реальные решения уйдут в Policy as Code и в evals. И это, на мой взгляд, скорее хорошо: с CAB у меня личных счётов на пару лет работы.

Безопасность: лестница автономии, approval fatigue и Pre-trust window

Раздел безопасности — один из самых конкретных в документе. Главная мысль простая: при том количестве агентских действий, которое генерирует современный pipeline, ручное подтверждение «yes/no» перестаёт работать в принципе. Уже знакомая цифра 93 % approvals — это не аномалия, это статистический факт. От него и предлагается отстраивать архитектуру.

Первое и самое заметное — адаптивная лестница автономии R0–R5. В PDF она ещё «просто адаптивная лестница», в полной версии появляется уровневый код и адаптация по трём факторам сразу: класс риска × чувствительность данных × горизонт влияния.

Логика грубо такая: чем выше класс риска — тем больше явных human-проверок. На момент публикации сам Сбер находится на уровне R2 (Supervised automation): AI-агентам отдали работу с минорными дефектами — от отслеживания до code review. Инженер только принимает результат. Целевое состояние, R5 (Zero-Friction), звучит амбициозно. Но и тут в whitepaper честно сказано: прыгать через ступени нельзя. «Перепрыгивание уровней автономии» — отдельная позиция в списке антипаттернов.

Дальше — то, что я считаю лучшей технической находкой во всём документе. Pre-trust initialization window. Это про первые миллисекунды сессии агента — до того момента, когда загрузились policy hooks. В этом окне агент уже жив, но ещё не под контролем политик. Митигация: deny-first default, подписанные init-payload, валидация CLAUDE.md перед загрузкой. Пример атаки — инсайдер правит CLAUDE.md до старта сессии, агент стартует уже «отравленным». Очень похоже на классический bootstrap attack, только перенесённый на контекст агента. И, кстати, ровно та категория проблем, про которую обычные security-команды ещё не научились думать.

С approval fatigue Сбер предлагает уйти от per-action approvals к двум вещам: пакетным одобрениям и доверительным окнам (trust windows). Идея — агент получает доверие не на действие, а на класс действий в заданном временном окне. Человек подтверждает не каждое движение мышки, а сами окна и их параметры. Логика та же, что в OAuth-скоупах, только применённая к runtime агента.

Дополнительно появляются Guardian Agents — отдельный класс агентов, которые надсматривают за другими агентами. Версия 2.0 у Сбера сформулирована как «от мониторинга к автоисправлению». По сути это runtime-supervisor для агентов, прямой аналог intrusion detection в сетевой безопасности, только переписанный под агентские действия. И финальный штрих — Unlearning & Anti-Entrenchment: механизмы «забывания», чтобы агент не укоренялся в устаревших паттернах. На уровне практики это значит: периодическое освежение skills, инвалидация кэша контекста по расписанию, повторные evals на новых эталонных задачах.

От себя. Та самая цифра 93 % — это приговор большинству corporate AI pipeline-ов. Если ваша «безопасность» агентов держится на формальном human-in-the-loop с кнопкой Approve — по факту вы строите театр. Я знаю минимум два больших проекта (один в финтехе, один в телекоме), где security-команды отчитываются «у нас human approval на каждое действие агента». Открываешь логи — там 99 % approvals, нажатых меньше чем за секунду. Это не контроль, это галочка. И я лично подозреваю, что таких проектов в России сейчас не два, а двести.

Pre-trust window и trust windows — самая работоспособная пара концепций в этой части whitepaper. Не уверен, что Сбер их сам придумал — что-то похожее уже мелькало в публикациях Anthropic, — но собрано всё в одном месте, и любой, кто строит security-обвязку для агентов, может разобрать раздел на чек-лист.

Token economics и FinOps: то, о чём редко говорят вслух

В комментариях к AI-постам на Хабре про деньги обычно вспоминают одной фразой — «а сколько это всё стоит?» — после чего разговор тонет. Whitepaper Сбера в этом смысле редкий: экономика агентов выделена в отдельный раздел, и там сказано то, что в маркетинговых презентациях обычно тщательно прячут.

Якорные цифры уже мелькали выше. Token usage объясняет 80 % дисперсии производительности агентов. Мульти-агентная архитектура жрёт примерно в 15 раз больше токенов, чем chat-режим. Без системного контроля затраты на агентов могут дойти до 40–60 % всего IT-бюджета к 2027 году. Это, если что, не прогноз катастрофы, а вполне реальный сценарий для компании, которая раскатает агентов без FinOps-обвязки.

Что Сбер предлагает делать. Главная метрика — Cost-to-Outcome, не «токены за час» и не «токены за коммит», а «токены за подтверждённый бизнес-результат». Это тонкое смещение, но оно радикально меняет, что вы измеряете. Дальше — dynamic compute allocation: мониторинг токенов в реальном времени по командам, проектам, задачам, моделям. Бюджет токенов на задачу с автоматической эскалацией при превышении. Подбор оптимальной модели под задачу — это сразу экономия 60–70 % токенов. Кэширование системных инструкций — до 10× снижения стоимости input-tokens на повторных запросах. И наконец, cost circuit breakers — защита от зацикливания агентов. Классический риск, который редко проговаривается: агент не сломался, он работает «корректно», просто очень аккуратно, многократно превышая бюджет. Без circuit breaker вы про это узнаёте от провайдера API.

От себя. Cost circuit breakers — самая недооценённая идея в этом разделе. Это, по сути, тот же паттерн, что в Hystrix-стиле для распределённых систем, только применённый не к латентности, а к стоимости. И, кстати, ровно одно из мест, где agentic-инфра реально нуждается в инженерах с опытом распределённых систем. Если у вас в команде нет человека, который понимает, что такое каскадные сбои и backpressure, зацикливание агента вы поймаете постфактум — по выставленному счёту. И это будет очень неприятная встреча.

Tiny Teams и роли: где правда, где маркетинг

Раздел про команды — один из самых «расходящихся» в дискуссиях. Сбер делает четыре прогноза на 2030 год, и каждый из них стоит обдумать отдельно. Первое: более половины традиционных рабочих мест разработчиков заместит роль Product Engineer. Второе: 80 % организаций перейдут от больших инженерных команд к компактным AI-усиленным. Третье: вместо классической two-pizza-team в 10–15 человек норма — Tiny Team в 4–5. Четвёртое: время согласований падает с дней-недель до часов.

В полной .docx-версии есть операционная картина, которой в PDF не было совсем. Стартовая позиция enterprise — команды по 15–20 человек, разделённые по функциям: Dev, QA, SRE, Security. Переход — 6–12 месяцев практического наставничества. Функциональные специалисты постепенно становятся product engineers. Tiny Team в финальной форме устроена примерно так: 3–6 человек, из них как минимум двое senior product engineers, ещё один-два mid и один junior в наставничестве. У команды своя двухквартальная дорожная карта и своя опорная метрика — Outcome Validation Rate. И отдельно — целевая пропорция: платформенная команда 3–5 человек поддерживает 10+ продуктовых команд через IDP. Эта пропорция, по сути, и есть архитектурный ответ на вопрос «а сколько вообще нужно платформенщиков».

Список новых ролей, которые в этой модели появляются, длинный. Product Engineer. Platform Engineer. AI Engineer / AI Architect. Forward-Deployed Engineer. Плюс отдельная enterprise-инфраструктурная линия: инженеры политик и контролирующих агентов, runtime-инженеры, владелец Context Supply Chain, AgentOps-инженер. Шесть ключевых компетенций для всей этой обоймы перечислены явно: формулирование намерений (prompt engineering), архитектура контекста, системное мышление, AI-грамотность, верификация и ревью, бизнес-ориентация.

От себя. Tiny Teams в 4–5 человек звучат модно. Но это не «команда меньше». Это «команда дороже». Каждый член такой команды должен быть full-stack, уметь работать с агентами, знать платформу и понимать продукт. Это премиум-инженер, и рынок таких ещё не готов. Большинство компаний сделают «two-pizza с Copilot» и назовут это Tiny Team — и это будет ошибкой, причём дорогой.

К чести Сбера, документ это, в общем-то, признаёт, когда расписывает состав: минимум двое senior, один-два mid, один junior. Это 80 % сеньоров от состава. На сегодняшнем рынке собрать десять таких команд — задача для очень крупной и очень богатой компании. Сбер себе это может позволить. Большинство — нет.

Отдельный, неудобный вопрос — про занятость. В документе аккуратно сформулировано: «AI не приведёт к сокращению занятости, роли расщепятся, а не исчезнут», вакансии разработчика заместит Product Engineer. Это удобная и социально мягкая позиция для крупного работодателя, и я понимаю, почему она там есть. Но если честно — формула «50 % мест разработчиков заместит Product Engineer» означает, что тех же должностей в прежнем виде станет меньше. Реальные сокращения уже идут, это видно по открытым данным любого крупного игрока. Whitepaper подаёт это как естественную эволюцию. В этом он, в общем-то, прав. Но социальный эффект здесь — отдельная и неприятная тема, и я бы хотел увидеть её честный разбор хотя бы в одном продолжении этого whitepaper.

Антипаттерны внедрения — фактически готовый чек-лист

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

«Зоопарк ИИ-инструментов» — много инструментов без оркестрации. Каждая команда выбрала свою связку. Через год при попытке что-то унифицировать обнаруживается, что у вас не «AI-стратегия», а пятнадцать несвязанных AI-платформ — и каждая со своим бюджетом.

«Культурный балласт» — формально включены, по факту работают по-старому. Copilot куплен всем, лицензии висят, в commit history его не видно. Знакомо до боли по любой большой компании, где CTO считает успехом «количество выданных лицензий».

«ИИ только в кодировании» — применяется в 25–35 % рабочего времени разработчика, а не во всех фазах PDLC. Логика тут жёсткая: кодинг — это треть инженерной работы, ещё 10–30 % уходит на поиск информации, остальное — проектирование, ревью, согласования. AI в кодинге даст вам потолок 30 % прироста в кодинге, то есть 10 % на полную работу инженера. И всё. Дальше — упёрлись.

«Инерционный вендор-лок» — зависимость от одного поставщика модели или инструмента. Сбер тут, кстати, немного двусмыслен: они против лока, но при этом строят свой стек. Что не отменяет правильности самой мысли.

«Пилоты не масштабируются» — классика: пилот команды из 5 человек удался, попытка повторить на 50 — провалилась. Обычно вскрывается через полгода после того, как руководство уже отчиталось об успехе.

«Гонка за объёмом без бизнес-эффекта» — высокий объём кода при стагнирующей доле подтверждённых бизнес-результатов. Лекарство в документе названо прямо: Outcome Validation Rate как опорная метрика вместо «строк кода» и «количества коммитов».

«Перепрыгивание уровней автономии» — особенно частая ошибка для команд, которые сразу хотят на Горизонт 3. Из R1 в R4 не прыгают; точнее — прыгают, но потом откатываются с потерями.

И ещё два, которые мне нравятся за честность. Антипаттерн №19 — «управление, прикрученное сбоку». Governance не как Mesh, а как отдельная стадия после релиза. И антипаттерн №20 — «статичная лестница автономии»: фиксированный уровень автономии для всех задач, независимо от риска, типа данных и горизонта влияния. Оба — про то, как «как бы» делать правильно, не делая правильно по сути.

И ещё одна важная мысль из этого раздела, которую почему-то редко выносят наверх: антипаттерны Горизонта 3, обнаруженные в команде Горизонта 1, — это ложные тревоги. Мониторинг должен подстраиваться под уровень зрелости. Простой пример: ругать команду пилота за «зоопарк инструментов» — то же самое, что ругать стартап за отсутствие SOC 2. Не время.

Цифры из реальной практики: GigaCode, Яндекс, Т-Технологии, red_mad_robot

В самом whitepaper конкретики о результатах в Сбере, к сожалению, мало. Зато к ЦИПР-2026 та же команда выпустила пачку смежных материалов — интервью, презентации, расшифровки панелей, — и из них уже можно собрать вполне честную картину. Это уже не whitepaper, но контекст к нему важный.

GigaCode (Сбер) на момент ЦИПР-2026. Около 14 000 разработчиков используют GigaCode. Из них примерно 80 % работают с инструментом ежедневно — а не «попробовали и забыли», что для корпоративных раскаток редкость. Доля принятого AI-кода за 2025 год: 45 % → 69 %, прирост в 24 процентных пункта. И ещё один любопытный эпизод: в декабре 2025 GigaCode впервые закрыл полноценный релиз продукта без единой ручной строки. Пять крупных задач плюс дефекты — агенты сделали всё, команда приняла. Это, на минуточку, R3 в чистом виде.

GigaIDE PRO. Сбер перевёл всех разработчиков с JetBrains на собственную IDE. Заменили примерно 25 фреймворков и инструментальных цепочек. Внутри — 7 AI-агентов: документация, журналирование, модульность, транзакционность, автотесты, анализ тестовых моделей, командная аналитика. Разработчики принимают больше половины предложений агентов. 165 000 скачиваний, продукт в Реестре российского ПО. По меркам IDE — невероятно быстрая раскатка.

Метрики DX (Developer Experience). Время выхода нового разработчика на полную продуктивность сократилось с 71 дня в 2024 до 36 дней в 2026. Мировой бенчмарк по 135 тыс. разработчиков из 435 компаний — с 91 до 49. То есть Сбер сокращает на 13 дней быстрее тренда. По числу PR с AI-ассистентом: мир +60 %, Сбер +62 %. Это почти бенчмарк — но именно «почти», без чудес.

Яндекс (Дмитрий Иванов, SourceCraft). Около 70 % разработчиков Яндекса регулярно используют AI-ассистентов и делают на 10–20 % больше коммитов. Любопытная деталь: активные пользователи AI-чата заходят на внутренние wiki вдвое реже — получают ответ от чата быстрее, чем успевают открыть браузер. DeepAgent с режимом рассуждения для сложных задач даёт, по их оценке, 10× ускорение на исследовании больших кодовых баз. Цифра звучит фантастически, но в контексте исследования кода — поверю.

Т-Технологии (Александр Краснов, CTO T-Insurance). Доля разработчиков, регулярно использующих AI: 17 % → 85 % за 10 месяцев. Еженедельных пользователей — с 2 000 до 12 000. Через 4 недели после первого использования 80 % продолжают в IDE, 75 % — в веб-интерфейсе. И самое интересное: они работают по фреймворку SPACE — Satisfaction, Performance, Activity, Communication, Efficiency — и принципиально отказались от метрик «строки кода / коммиты / длительность ревью» как опорных. Опорные у них — фокус-время, цикломатическая сложность, размер MR, скорость первой рецензии, доля нестабильных тестов. Этот подход — самый трезвый среди всех, что прозвучали на ЦИПР.

red_mad_robot (Валерий Ковальский, Head of AI). Самые громкие цифры релиза. Проект «Автономный завод»: за 48 часов собрали прототипы на трёх платформах (React, iOS Swift, Android Kotlin) силами одного AI-инженера. Около 80 000 строк кода и 208 коммитов за 3 дня. Сокращение длительности в 60× (с 3–4 месяцев до 48 часов); сокращение команды в 200× (с 6 специалистов за 4 месяца — до одного AI-инженера за 2 суток). Стоимость API-запроса к Kimi K2 — $0.01. Себестоимость прототипа — около $27 плюс инфраструктура. Базируются на open-source OpenClaw (300K+ звёзд на GitHub). После аудита Cisco в нём нашли 512 уязвимостей, включая критическую CVE-2026-25253 (RCE через WebSocket). Пересобрали под enterprise: многопользовательский режим, seccomp-профили, gVisor-изоляция, on-premise, 152-ФЗ, поддержка Kimi K2 и Qwen3. Экономика проекта: 1,5 млн ₽ → 50 тыс. ₽.

От себя. Цифры GigaCode — 14 000 пользователей, 80 % daily, 69 % принятого кода — это, на мой взгляд, самые сильные эмпирические данные всей истории. Они весят больше, чем абстрактные «35–45 %» из отраслевых отчётов. Конкретная организация, конкретный год, конкретные числа.

Переезд с JetBrains — отдельное и сильно недооценённое событие. Замена IDE с 20-летней историей на собственный продукт — это не «решили попробовать», это сжигание мостов. И заявка на платформенный суверенитет, заодно. Через 3–4 года этот опыт либо войдёт в курс «как надо», либо в курс «как не надо». Сейчас непонятно, какой из вариантов выстрелит.

Цифры red_mad_robot — то место, где я бы поставил большой и жирный дисклеймер. «60× быстрее и 200× меньше людей» — это про прототип, не про production-продукт. Прототип на 80K строк за 48 часов — это, по сути, новый класс артефактов, что-то среднее между mockup и MVP. Бизнес-моделирование на этих цифрах легко превращается в маркетинг: продают «сократили команду в 200 раз», получают «сделали красивую демку». Это не одно и то же, и я бы хотел, чтобы это писали крупным шрифтом. Сама технология при этом — рабочая, кейс — реальный, к самим ребятам у меня вопросов нет. Вопросы — к тем, кто будет линейно переносить эти цифры на свой production. Не делайте так.

Подход Т-Технологий — самый зрелый и неэффектный одновременно. Отказ от «строк кода» как опорной метрики и переход к фокус-времени, цикломатической сложности и доле нестабильных тестов — это то, что должны были сделать ещё в 2018 году, до всякого AI. Зато сейчас эта база отлично ложится на agentic-разработку, и это, по сути, контр-аргумент к «гонке за объёмом» из антипаттернов whitepaper.

Шкала AI-зрелости PDLC: где сейчас сам Сбер

В сопутствующей Хабр-статье Сбера упомянута шестиуровневая шкала зрелости AI-разработки, по которой они себя оценивают. На нуле AI в разработке отсутствует. На уровнях 1–2 — точечные ассистенты, что-то вроде Copilot для отдельных энтузиастов. Уровень 3 — Supervised automation, и именно здесь Сбер находится сегодня: AI встроен в большинство этапов, разработчик постоянно с ним взаимодействует, но финальное решение всегда за человеком. Уровень 4 — агентная разработка: AI сам формулирует подзадачи, запускает тесты, реагирует на ошибки. Уровень 5 — Zero-Friction PDLC, целевой: человек формулирует задачу, AI её реализует, проверяет и возвращает результат целиком. Целевая пропорция самого Сбера, сформулированная для пятого уровня: «90 % реализации делает ИИ, а 90 % управления замыслом остаётся за людьми».

От себя. «Сбер на уровне 3 из 5» — это, по сути, признание, что и они сами ещё не там. Документ продаёт горизонт 5, а реальность — Supervised automation. Полезный калибратор для любого, кто читает whitepaper как готовую инструкцию: даже автор фреймворка живёт сегодня в R2 / уровне 3. Если до пятого уровня не добрался Сбер с его масштабами, GigaChat-ом, AIRI и СберУниверситетом — стоит хорошо подумать, на каких ресурсах туда соберётся ваша команда из шести человек.

Чего в документе нет

Прежде чем хвалить или ругать, полезно проговорить, чего в whitepaper попросту нет. Это, в общем, тоже информативно.

Во-первых, нет цифр продуктивности от самого AI-Disrupt PDLC в Сбере. Только обещание «принципиально иного порядка» и общие отраслевые ориентиры. Сравнения «Сбер с AI-Disrupt PDLC против Сбера без AI-Disrupt PDLC» — нет. И это, согласитесь, для документа от Сбера странновато.

Во-вторых, нет конкретики по экономике. Сколько стоит построить такую IDP, какой ROI, какой штат платформенной команды — за исключением единственной формулы «3–5 человек поддерживают 10+ продуктовых команд». На какие модели идут токены и сколько это в рублях в месяц — тоже нет. Понятно, что часть этого — внутренняя кухня. Но любому, кто будет защищать бюджет на «свою IDP», без этих цифр будет тяжко.

В-третьих, нет ответа на вопрос, что делать организациям, которые не Сбер. Без GigaChat, без AIRI, без СберУниверситета, без десятков тысяч разработчиков. Документ адресован «top execs», но рецепт, если его честно прочитать, требует масштабов Сбера. Для компании на 200 разработчиков большая часть рецептов либо неприменима, либо требует существенной адаптации, о которой в whitepaper ни слова.

В-четвёртых, нет глубокого разбора провалов и уроков. Только success story. Хочется хотя бы пары кейсов в духе «вот тут мы попробовали и обожглись, делайте по-другому». Без них документ читается слишком гладко.

И, наконец, нет глубокого регуляторного среза для финансового сектора, хотя у Сбера тут самый интересный опыт в стране. 152-ФЗ и ЦБ упомянуты, но в виде списка, без деталей. Очень жалко.

Курпатовская часть: единственное «risk to humans», а не к процессам

Отдельно стоит сказать про лабораторию нейронаук Сбера (которой руководит Курпатов). В самом whitepaper её результатов почти нет, зато в смежных материалах опубликована серия глубинных интервью с разработчиками. И там вскрылись эффекты, которые в маркетинговом нарративе обычно прячут.

Первое — страх потери профессиональной идентичности. Переход «творец → оператор нейросети» воспринимается как понижение статуса. И не только воспринимается, а во многих случаях именно им и является.

Второе — парадокс джунов. Они оказываются в роли эксперта, не накопив опыта: должны проверять AI-код, который они сами писать ещё не умеют. Это как студента-первокурсника назначить рецензентом научной статьи. Технически возможно. Содержательно — катастрофа.

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

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

От себя. Это единственная часть всей истории, где звучит risk to humans, not just to processes. Whitepaper про роли — оптимистичен. Интервью лаборатории — тревожны. И именно эта тревожная часть, на мой взгляд, требует от инженерных руководителей самого серьёзного отношения. Серьёзнее, чем все архитектурные диаграммы вместе взятые.

Технически — AI-агенты решают задачи. Культурно — они отъедают у инженера ровно ту часть работы, ради которой он, скорее всего, и пришёл в эту профессию. Если вам интересно «как устроена сложная система и как её сделать круче», а вам выдают «принимай PR от агента» — это не профессиональный рост. Это понижение, прикрытое словом «эффективность». Документ Сбера прав по архитектуре, но в нём почти нет ответа на вопрос «а как сохранить инженерное удовольствие от работы». Я думаю, это и есть главный долгосрочный вопрос всей трансформации. И, кажется, ни у кого из индустриальных лидеров ответа на него пока нет.

Парадокс с джунами — отдельная боль. Если AI закрывает ровно те задачи, на которых джуны традиционно росли, — джунам некуда расти. Сбер обещает «новые роли» и «снижение порога входа». Реальность пока обратная: попасть на стартовую позицию в AI-зрелую команду сегодня сложнее, чем в обычную, потому что от джуна сразу требуют умения работать с агентами, evals и политиками. Это системный вопрос для индустрии, и whitepaper его, увы, обходит. По-моему — зря. Он ровно про ту демографию, которая через десять лет будет писать следующий whitepaper.

Итого: кому что читать

Whitepaper «AI-Disrupt PDLC» получился большим и очень неравномерным по плотности. Подведу итог не общим выводом, а по жанрам читателей — так практичнее.

Если вы CTO, CIO или тимлид крупной компании, полная .docx-версия — must read. Особенно разделы про Discovery Gap, Governance Mesh, Policy as Code для российского регуляторного контура и таблицу антипаттернов. Это готовый материал, который можно разбирать на собственный бэклог пересборки процессов.

Если вы инженер, читайте .docx целиком, но обращайте особое внимание на несколько мест. Двухпетлевую модель и принцип «harness важнее модели» из четвёртого раздела — это та оптика, через которую полезно посмотреть на свою архитектуру. Сравнение Claude Code и OpenClaw в §4.16 — единственный известный мне публичный документ, где это сравнение сделано системно, с цифрами и архитектурными выводами. Security-блок — лестница R0–R5, Pre-trust window, approval fatigue, Guardian Agents — стоит прочитать и обсудить с командой. Context Supply Chain и Policy as Code — это, как мне кажется, то, что попадёт в индустриальные стандарты ближайших 2–3 лет. И, наконец, антипаттерны (§7.5) — самый практический раздел документа.

Если вы пишете стратегию AI-внедрения для своей команды, берите блоки как есть. Discovery Gap, бинарка «адаптация vs перепроектирование», метрики ADLC, калибровка антипаттернов по горизонтам зрелости. Шкала AI-зрелости 0–5 — отличный калибратор для разговора с руководством: на нём очень удобно показывать, что «давайте сразу на уровень 5» — не план, а пожелание.

Если вы скептик и обычно whitepaper-ам не верите — смотрите не на whitepaper, а на цифры GigaCode и переезд с JetBrains. Это не риторика, это публично проверяемые факты. Они не доказывают, что концепция «AI-Disrupt PDLC» работает целиком и для всех. Но доказывают другое — у Сбера есть достаточно практики, чтобы концептуальный каркас держался не на воздухе.

От себя — финально. Это, в первую очередь, продуктовый whitepaper про внутреннюю IDP Сбера. Не обзорная статья, не нейтральный отраслевой документ — продуктовый whitepaper. Но при всём этом — лучший публичный документ на русском языке об agentic-разработке как о системе, а не как о «давайте к нашему процессу подключим Copilot». В этом качестве он опережает всё, что я видел в открытом доступе по-русски за последние два года.

Больше всего меня убеждает в нём не риторика «от кода к намерению» — она для C-level и звучит привычно, — а инженерная конкретика во второй половине: Pre-trust window, Cost circuit breakers, R0–R5, Guardian Agents, Context Supply Chain. Это явно написано людьми, которые реально строят такую систему и уже наступили на достаточное количество граблей, чтобы их можно было перечислить. С номерами.

Больше всего настораживают две вещи. Первая — разрыв между декларацией «горизонт 5» и реальной позицией «уровень 3». Это не критика, это калибровка: автор фреймворка сам ещё не на финише, и если кто-то берёт документ как пошаговую инструкцию, стоит понимать, куда эта инструкция ведёт. Туда, куда Сбер только идёт. Вторая — оптимизм в части занятости и ролей. Звучит социально удобно, но плохо стыкуется с уже идущей реструктуризацией IT-команд. Здесь whitepaper выбирает удобную позицию вместо честной, и это, по-моему, самая слабая часть документа.

Если совсем коротко — документ стоит того, чтобы потратить вечер. Полная .docx-версия, не PDF.

Источники

• AI-Disrupt PDLC Whitepaper (Сбер, май 2026): обзорный PDF и полная техническая концепция .docx, оба — с лендинга sbertech.ru/whitepaper.

• Хабр Сбера — расшифровка панели ЦИПР-2026 «Что происходит с разработчиками, когда ИИ берёт на себя 80 % их работы» (Сбер + Яндекс + Т-Технологии + red_mad_robot).

• Пресс-релиз ComNews от 19.05.2026 о подписании меморандума Сбер ↔ red_mad_robot.

• Интервью К. Меньшова АиФ от 21.04.2026 (АКПО-КОНФ 2026).

• DORA AI Capabilities Model 2025 (Google Cloud); AWS AI-DLC 2025; серия публикаций Anthropic 2025–2026; arXiv 2604.14228v1 «Dive into Claude Code».