«AI-Disrupt PDLC» 2.0: трансформации Сбера за два месяца

Лонгрид · июль 2026

В мае я анализировал whitepaper Сбера «AI-Disrupt PDLC», представленный на ЦИПР-2026. В том разборе я отметил, что документ обладает сильной инженерной составляющей, но недостаточно подкреплён конкретными данными.

В июне вышла версия 2.0, которую в начале июля представили на «Иннопроме». Название изменилось с «Стратегия AI-трансформации бизнеса: от кода к намерению» на «ИИ-нативная трансформация разработки ПО для зрелого корпоративного контура. Практическое руководство». Переименование точно передаёт суть обновлённого содержания.

Форматов по-прежнему два: короткая версия — PDF на 44 страницы вместо 28, полная — PDF на 175 страниц вместо .docx. Объём вырос в полтора раза, с 337 тысяч знаков до примерно 515 тысяч. Появился отдельный сайт aipdlc.ru и поддержка трёх языков. Количество разделов увеличилось с пяти до восьми.

Релиз представлен под лозунгом технологического суверенитета. Кирилл Меньшов, комментируя выход версии 2.0, отметил: «Мы хотим, чтобы агентная разработка стала стандартом, потому что это даст конкурентное преимущество всей стране. AI-Disrupt PDLC укрепит технологический суверенитет и позиции России на международных рынках». В самом документе термин «суверенитет» используется пять раз и в более узком, техническом смысле: «ИИ-суверенитет — возможность сменить базовую модель (в том числе перейти с зарубежной на отечественную) без переписывания среды работы ИИ-агентов». Это определение операционно и проверяемо.

Основные изменения

Если кратко, из vendor-манифеста документ превратился в методическое руководство.

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

Вместо этого добавлены четыре части, которых раньше не было: метрики, стратегия внедрения с конкретными бюджетами, российский регуляторный контур и отдельный жизненный цикл разработки ИИ-агентов (ADLC).

Самым значительным сюрпризом стало исчезновение трёх самых цитируемых цифр первой версии.

Куда пропали 98/2, 93% и 35–45%

В майском разборе я отмечал, что цифра «98% обвязки против 2% логики модели» — самая сильная и одновременно самая спорная мысль документа: «98 — инженерная риторика, не измеримая метрика».

В версии 2.0 формулировка изменена:

«Реверс-инжиниринг Claude Code v2.1.88 показал, что среда работы ИИ-агента составляет ~98,4% кодовой базы промышленных агентных сред. Именно она обеспечивает предсказуемость, безопасность и аудируемость исполнения — не сама модель принятия решений». (4.2)

Добавились версия продукта, метод и ссылка на препринт arXiv 2604.14228v1. Теперь измеряется не «ценность», а объём кодовой базы — именно то уточнение, о котором я просил.

Цифра «93% approvals» исчезла полностью. Вместо неё:

«Эксперимент Anthropic показал: после 20+ запросов в сессии точность подтверждений падает с 85% до 55% — пользователь одобряет механически, не читая. Решение — структурно уменьшать число запросов, а не обучать пользователя быть внимательнее». (5.1)

Особо стоит отметить разбор пары «11–25% против 35–45%», вызывавшей больше всего методологических вопросов. Цифра 35–45% удалена. Вместо бинарной системы «адаптация против перепроектирования» представлены три подхода (11–25%, 25–50%, 30–50%+), применяемых одновременно для разных задач, а не последовательно:

«Зрелая команда применяет три подхода параллельно для разных задач, а не проходит их последовательно как ступени». (1.5)

На место ушедших цифр в резюме добавлены новые опоры: разброс в 22 п. п. связан с качеством среды, тогда как разница между моделями составляет 1–3 п. п. Приведён и бенчмарк DeepSense.ai: агентный контур с циклами ревью и автотестов повысил долю корректных решений на 225 задачах с 53,8% до 81,8%, но стоимость решения выросла с $0,04 до $0,61 на задачу.

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

Однако замена не обходится без последствий. Разброс «22 п. п. от среды» подкреплён ссылкой на «данные крупнейших технологических консультантов» без имён. Показатель «53,8% → 81,8%» основан на реальном бенчмарке, но это результат одного прогона на одном наборе из 225 задач, и использование его как доказательства архитектурного тезиса — то же передёргивание, только аккуратнее оформленное. К источникам я ещё вернусь.

Экономика: главное изменение

В майском разборе я отмечал отсутствие конкретики: сколько стоит построить IDP, каким будет ROI, какой штат требуется платформенной команде. Теперь эти данные есть:

«IDP является капитальным активом. Начальная стоимость разработки — 12–18 месяцев для команды из 3–5 инженеров платформы и одного менеджера платформы. После запуска операционные затраты составляют 30–50% от первоначальных вложений». (4.1)

«Каждая продуктовая команда, работающая на IDP, демонстрирует рост производительности на 30–50%. Для организации с десятью и более продуктовыми командами инвестиции окупаются за 12–24 месяца». (4.1)

Ключевой аргумент в пользу собственной разработки впервые сформулирован в деньгах:

«Без собственной IDP организация платит „налог на поставщика“ — помесячное лицензирование ИИ-инструментов по числу мест для каждого инженера. Годовая сумма для организации из 100 человек достигает $1–3 млн. За аналогичный бюджет собственная IDP обслуживает все команды без нарастающей стоимости per-seat. Разрыв между „купить“ и „построить“ начинает сходиться на горизонте 18–24 месяцев и становится устойчивым через 36 месяцев эксплуатации». (4.1)

Дополнительно указаны: 10–15% бюджета IDP на безопасность, около $3 тыс. на токены для крупной задачи, бюджеты в 50 тыс. токенов на задачу, 200 тыс. на сессию и 500 тыс. на горизонт, соотношение «один инженер платформы на 8–12 продуктовых инженеров».

В седьмой части появилась таблица, которой не хватало в мае, — рекомендации для компаний, не сопоставимых по масштабу со Сбером:

Размер компании	Инфраструктура	Срок	Инвестиции
Малые (5–15 инженеров)	Discovery-ритуалы; SDD в Markdown; review-agent через промпт в ChatGPT/Claude; Pattern Library в вики	12 мес.	Минимальные
Средние (50–100 инженеров)	Платформенная команда 3–5 человек; IDP $200–500 тыс./год; централизованный review-agent	12–24 мес.	$1–3 млн/год
Крупные (500+ инженеров)	Платформа 10–20 человек; IDP $2–5 млн/год; Federated Policy Hook Registry; ALM; Cross-domain Pattern Library	24–36 мес.	$5–10 млн+/год

Рядом приведён 90-дневный MVP: 0–14 дней — снятие baseline по DORA и запуск Discovery; 15–30 — SDD версии 0.1 и review-agent в режиме наблюдения; 31–60 — три-пять паттернов, уровень автономии R2, Evidence Bundle; 61–90 — review-agent в режиме pre-merge и метрика Reallocation Rate. Критерии успеха заданы реалистично: Reallocation Rate выше нуля, стопроцентное покрытие HITL Decision Map и Outcome Hypothesis, частота отказов не хуже базового уровня.

Первая строка таблицы — минимальные инвестиции, SDD в Markdown и review-agent через промпт — оправдывает всю седьмую часть. Она прямо указывает, что небольшой компании нужна не платформа, а дисциплина. Именно этого не хватало майской версии, где рецепт по умолчанию требовал масштабов Сбера.

Но есть и обратная сторона, которую документ не обсуждает. Из его собственной экономики следует, что при менее чем десяти продуктовых командах IDP не окупается. Что делать компании с 200 разработчиками и восемью командами — не сказано. Единственный ответ в тексте: «Это разумный путь для небольших команд без внутренней возможности построить собственную интегрированную платформу разработки, но ловушка для крупных организаций» — то есть купить у вендора. Центральный тезис документа о необходимости строить собственную среду для среднего бизнеса фактически отменяется, и сформулировано это настолько сдержанно, что легко упустить.

Валидация: почему не третья петля

Наиболее интересная архитектурная новация версии 2.0 — сквозной контур валидации, названный в резюме Validation Spine. В майской версии валидация была распределена по обеим петлям без явного выделения.

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

Далее предлагается количественное правило, применимое в работе:

«ПРИНЦИП: цикл реализации не может масштабироваться быстрее методики валидации. При инвестиции X в цикле реализации инвестируется как минимум 0,5X в методике валидации ИИ-результатов». (2.12)

Также сформулирован принцип разделения труда между стохастическими и детерминированными компонентами:

«ПРИНЦИП. LLM решает — детерминированные правила исполняют. ИИ задаёт структуру проверок; код выполняет их механически и предсказуемо, без стохастических отклонений». (2.12)

Вместо запуска модели на каждом пул-реквесте она единожды генерирует план оценок (Eval Plan) и правила политик, а детерминированный конвейер применяет их ко всем пул-реквестам.

К этой же группе решений относятся Evidence Bundle как контракт завершения задачи (восемь обязательных элементов, включая расход токенов и «журнал сессии в формате „только добавление“») и Session Handoff Protocol — четыре артефакта передачи между сессиями агента: init.sh, progress.md, feature-list.json и указатель на Evidence Bundle. Оба названы обязательными компонентами платформы.

Пропорция 0,5X на валидацию к каждому X в реализации выглядит наиболее полезной цифрой новой версии. В отличие от разброса в 22 п. п., она ничего не доказывает, а задаёт бюджетное соотношение. Такие ориентиры хорошо переносят контакт с реальностью: с ними можно спорить, но их можно применять на практике. Session Handoff Protocol — пример того, как авторы явно опирались на собственный опыт: четыре конкретных файла с конкретными именами не возникают в результате стратегической сессии.

Джуны: наиболее честный раздел документа

В майском разборе я отметил, что whitepaper обходит «парадокс джунов», а позиция по занятости («роли расщепляются, а не исчезают») выглядит социально удобной, но не честной. Раздел 3.5 новой версии — прямая противоположность.

«В традиционных командах соотношение junior: senior составляет 3:1 и выше. Агентная автоматизация берёт на себя большую часть задач junior-уровня… По данным Wobo Software Hiring Report 2026, ведущие технологические компании размещают в среднем 14 senior-позиций на каждую junior: Netflix — 47:1, Anthropic — 24:1, OpenAI — 19:1». (3.5)

«В AI-native командах 2026 года доля junior не превышает 10–15% от состава против 40%+ в командах до 2023 года».

«Организации, продолжающие строить пирамиду 3:1, накапливают избыточный junior-слой, который агент уже замещает, и одновременно не инвестируют в senior-компетенции, от которых зависит качество поставки. Рациональная стратегия — нанимать меньше junior и вкладывать в наставничество каждого».

Тезис «ИИ не приведёт к сокращению занятости» исчез. Вместо него приведена цифра, говорящая о том же без эвфемизмов: «организация сокращает затраты на численность команды на 40–60%».

Сам «парадокс джунов» решён структурно, и решение удачное: младший инженер выведен из-под ревью ИИ-кода. Формальная проверка передана агенту-ревьюеру, который «закрывает 80%+ формальных проверок», а junior работает в паре с senior над постановкой задачи и участвует в eval-сессиях как наблюдатель. Новая точка входа в профессию описана ясно: написание SDD, разработка evals, ревью Evidence Bundle, курирование библиотеки паттернов. Отдельно стоит отметить формулировку:

«Университеты, продолжающие готовить junior software engineer как человека, пишущего функции по тикетам, выпускают неконкурентоспособных специалистов». (3.5)

Появилось и то, чего я не ожидал, — признание, что часть сильных инженеров в новую модель не перейдёт:

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

Новая версия заметно честнее предыдущей. Однако в конструкции есть пробел, который документ не учитывает. Джуниоров нанимают значительно реже; senior, согласно тексту, формируется через «практическое наставничество — год под руководством senior-инженера»; при этом девятым пунктом в списке препятствий к переходу на Tiny Teams указано, что «нехватка senior engineers ограничивает темп перехода». Складывая эти утверждения: воронка сужена в разы, срок подготовки senior измеряется годами, а самих senior уже не хватает. Откуда возьмётся следующее поколение — не говорится ни слова. Это не критика формулировки, а дефект модели: она устойчива на горизонте пяти лет, но не определена на горизонте пятнадцати.

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

Часть 8: российский регуляторный контур

Моя майская претензия заключалась в отсутствии глубокого анализа регуляторного контекста для финансового сектора: 152-ФЗ и требования ЦБ были упомянуты списком без деталей.

В версии 2.0 теме посвящена целая часть из девяти разделов. Логика заявлена сразу: собственная среда исполнения в России — не архитектурное предпочтение, а регуляторная необходимость.

Шесть норм распределены по архитектурным слоям, на которые они влияют: 152-ФЗ (локализация персональных данных — инференс, конвейер данных, журнал аудита, выбор модели), требования ЦБ 683-П и 757-П (обязательный аудит систем в операционно значимых процессах — Policy Hooks и Audit Trail), приказы ФСТЭК 17, 21 и 239, Указ № 166, Указ № 250, а также ФЗ-187 с подключением к ГосСОПКА.

Ключевой элемент — библиотека политик «RU Compliance Core» из восьми модулей, для каждого из которых указаны норма, тип хука и механизм применения: PII-Localization Guard (152-ФЗ, ст. 18.1, pre-action hook с блокировкой), Data Retention Policy, Processing Purpose Declaration, Immutable Audit Trail (JSONL с добавлением только новых записей, срок хранения 5 лет), Domestic Inference Gate (жёсткая блокировка), Sanctioned Entity Check, Privileged Access Control и Incident Reporting Hook. Основная идея: «Инженер не должен помнить о 152-ФЗ — Policy Hook напомнит сам». (8.3)

Референс-архитектура из десяти компонентов представлена с конкретными названиями: GigaIDE Pro и Community, GigaCode, GigaCode CLI, GigaChat, GigaView, SourceCraft CLI, GitVerse, Yandex Tracker, Kaiten, YandexGPT, SberCloud, Allure TestOps, Qase, PT Application Inspector, Solar appScreener, Monq, wiSLA, Qdrant, Milvus, а из открытых решений — Aider и OpenHands. Зоны разрыва обозначены откровенно: про GigaIDE сказано, что он уступает Cursor на сложных задачах, а его сильные стороны — Java, Kotlin и 1С; отечественные CLI-агенты, по формулировке документа, пока догоняют Claude Code и Codex CLI; в части governance отмечено, что отечественного решения уровня Harness не существует. Отдельно оценивается ситуация с Guardian Agents: «Зрелых отечественных поставщиков Guardian Agent на уровнях T3–T5 практически нет». (8.6)

Вывод: собственная разработка обязательна, и это наиболее затратная статья дорожной карты локализации. Первые 0–6 месяцев отводятся на Policy Hook Framework и RU Compliance Core версии 1.0 под 152-ФЗ, где стоимость первой версии политик оценена в 4–8 недель работы одной платформенной команды; следующие 6–18 месяцев — на требования ЦБ и ФСТЭК; 18–36 месяцев — на Guardian Agents уровней T3–T5.

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

Однако для банка этого недостаточно, и проблема сосредоточена в одном месте: в документе не упоминается ГОСТ Р 57580 — ни часть 57580.1, ни 57580.2. Это стандарт, по которому Банк России фактически оценивает уровень защиты информации в финансовых организациях, и для темы ИИ-агентов в банке он ключевой. Положения 683-П и 757-П приведены одной строкой, без разбора пунктов и без разграничения кредитных и некредитных финансовых организаций. Нет упоминания 115-ФЗ, 161-ФЗ и ЕБС, не приведено ни одного примера реального предписания.

Самый существенный пробел в другом: нигде не рассматривается, кто несёт ответственность за решения, принятые агентом. Для регулятора это первый вопрос, а не пятый. В результате восьмая часть получилась архитектурно-комплаенсной, а не юридически-надзорной: руководителю разработки её достаточно, для CISO банка это стартовая точка, но не готовый документ.

Чего по-прежнему нет

Главная претензия к версии 1.0 стояла на первом месте: отсутствие показателей продуктивности от внедрения самого AI-Disrupt PDLC в Сбере. В версии 2.0 их стало ещё меньше.

GigaCode, GigaIDE и GigaChat встречаются только в восьмой части — в обзоре отечественного ландшафта и в таблице референс-архитектуры. Ни количества пользователей, ни acceptance rate, ни метрик developer experience.

Исчезла и самооценка уровня зрелости. В майском релизе было прямо указано, что Сбер находится на уровне R2 (Supervised automation) при целевом R5, и я называл это лучшим калибратором документа. В версии 2.0 лестница R0–R5 развёрнута значительно подробнее — восемь факторов эскалации, формула эффективного уровня автономии, три профиля песочниц, фиксированные российские смещения (АБС R5→R4, клиентский кабинет R3→R1, AML-конвейер R2→R0), — но собственной позиции Сбера на этой лестнице нет. Оставить подробнейшую шкалу и убрать точку отсчёта — значит превратить калибратор в абстракцию.

Само слово «Сбер» встречается в 175-страничном документе шесть раз, и лишь однажды к нему привязан числовой ориентир:

«Бюджеты (калибровочные значения по внутренним наблюдениям Сбера, настраиваются под организацию): 50K токенов на задачу, 200K на сессию, 500K на горизонт». (5.2)

Даже таблица объёма кода в месяц (2 000 строк без ИИ, 3 000 с базовым ассистентом, 5 000–8 000 при разработке через спецификацию, 15 000–25 000 у команды агентов уровня L5) атрибутирована мягко — «внутренние наблюдения Сбера и публичные вендорские бенчмарки» — и тут же оговорена: «количество строк здесь — грубая оценка масштаба сдвига, а не целевая метрика». Более того, показатель 10–15%, который в прошлом релизе подавался как внутренние данные Сбера, теперь приписан GitHub Copilot.

Это наиболее странное изменение в документе. Он стал строже к чужим цифрам и одновременно перестал показывать собственные. Возник парадокс: версия 1.0 была вендорским whitepaper со слабо обоснованными цифрами, версия 2.0 — отраслевым руководством без каких-либо показателей внедрения. Причина понятна: если документ переписан как методология для отрасли, кейс конкретной компании выглядит рекламой. Но эффект обратный. Руководство, которое на 175 страницах объясняет, как создавать IDP, и не содержит информации о результатах автора, воспринимается как консалтинговый материал, а не как отчёт практика. В первой версии инженерная убедительность держалась именно на позиции «мы это делаем, и вот наши цифры».

Разбор неудач тоже не завершён. Примеры проблем появились, но они обезличены: «CFR вырос с 8% до 14% за три месяца», «агент проработал шесть часов и упал… потерян день продуктивности», «процесс команды A сломал промышленную среду команды B», «CFO не видит эффекта в P&L». Подробный банковский кейс в разделе 7.2 — с бюджетом «$2 млн/год (до $4 млн к третьему году)», графиком по кварталам и итогом «$10 млн суммарно к 2028 году; реализованные выгоды $30–50 млн+» — прямо обозначен как «Синтетический кейс, отражающий паттерны реальных внедрений».

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

Итог

Версия 2.0 — не дополненное издание, а другой документ. Из манифеста для высшего руководства он превратился в руководство для инженерных руководителей, и это правильное направление.

Стало лучше: появилась экономика — стоимость IDP, срок окупаемости, «налог на поставщика», таблица соответствия размера команды и объёма инвестиций, 90-дневный MVP. Изменилось обращение с цифрами: три наиболее цитируемые величины первой версии удалены или заменены на более осторожные. Раздел о рынке труда лишился социально удобного оптимизма. Валидация выделена в отдельный контур с бюджетным правилом 0,5X. Российский регуляторный контур получил восемь модулей политик и референс-архитектуру с именами вендоров.

Осталось нерешённым: ни одной цифры внедрения в Сбере — здесь ситуация даже ухудшилась, поскольку самооценка уровня R2 исчезла. Нет ГОСТ Р 57580 и ответа на вопрос об ответственности за решение агента, что критично для банковского CISO. Не освещён вопрос воспроизводства senior-инженеров, хотя из собственных данных документа следует, что это узкое место. Человеческое измерение — мотивация, профессиональная идентичность, удовлетворённость работой — остаётся за пределами текста. И нет ни одного разбора собственных неудач: все примеры проблем обезличены или синтетические.

Рекомендации по чтению. Инженерному руководителю — части 4, 5 и 7 целиком: там сосредоточена вся практика, включая финансовые оценки. Инженеру — разделы 2.10–2.12 (Session Handoff Protocol, Evidence Bundle, принципы валидации) и 4.5 о Guardian Agents уровней T1–T5. Специалистам по комплаенсу в финансовом секторе — восьмую часть, с пониманием, что это архитектурная рамка, а не юридический разбор. Тем, кто планирует внедрение в компании до ста разработчиков, — таблицу из раздела 7.1 и 90-дневный MVP.

Если коротко: в мае я отмечал, что документ стоит потраченного вечера и что читать нужно полную версию. Это остаётся в силе, хотя вечер потребуется более длинный. А вопросов к автору у меня осталось ровно два — где собственные показатели внедрения и где ГОСТ Р 57580.

Источники

• AI-Disrupt PDLC. ИИ-нативная трансформация разработки ПО для зрелого корпоративного контура. Практическое руководство. Версия 2.0, июнь 2026 (Сбер). Полная версия — 175 стр., короткая — 44 стр.
• Сайт релиза: aipdlc.ru; предыдущий лендинг — sbertech.ru/whitepaper.
• «ИИ — только исполнитель. За смыслы отвечает человек» — АиФ, 7 июля 2026 (представление версии 2.0 на «Иннопроме», комментарий К. Меньшова).
• «AI-Disrupt PDLC как основа технологического суверенитета страны» — Коммерсантъ; сообщение EastRussia о выходе обновлённого руководства.
• Предыдущий разбор: «Whitepaper Сбера „AI-Disrupt PDLC“: разбор для тех, кто пишет код», Хабр, 23 мая 2026.
• Внешние работы, на которые ссылается документ: McKinsey Developer Velocity Index (2020) и McKinsey 2025; Bain «From Pilots to Payoff» (2025); DORA AI Capabilities Model 2025; публикации Anthropic 2025–2026; бенчмарк DeepSense.ai; Wobo Software Hiring Report 2026; препринт arXiv 2604.14228v1.