Whitepaper Сбера про AI PDLC: правильный диагноз — узкое место не в коде, а в процессах вокруг. Но лечение направлено не туда.
Whitepaper Сбера про AI PDLC вызвал на Хабре живую дискуссию. Одни говорят «спасибо, Кэп — спецификация важнее кода, целые поколения программистов об этом не знали». Другие поднимают реальные вопросы: кто несёт ответственность за код, который написал агент? Менеджмент не может сидеть на двух стульях — или AI отвечает за прод, или люди. Третьи замечают что сам документ написан языком топ-менеджмента — стратегические тезисы, отсылки к Gartner и McKinsey, красивые схемы. Но при этом занимает 300 страниц. Ни туда ни сюда: для инженера недостаточно конкретный, для руководителя слишком длинный.
Я прочитала документ целиком. Мнение смешанное.
Автор — Кирилл Меньшов — правильно видит проблему, честно называет цифры, строит логичную методологию. Читаешь и киваешь. А потом понимаешь: всё это написано про компанию, где это не может работать. Не потому что методология плохая — а потому что лечат не ту болезнь.
Что whitepaper видит правильно
Начнём с цифры, которую все знают но мало кто учитывает при внедрении AI. По данным Bain 2025, написание и тестирование кода занимает только 25–35% рабочего времени разработчика. Остальные 65–75% — это всё вокруг: формулировка задачи, согласования, ревью, митинги, переписка, ожидание.
Большинство компаний внедряют AI именно в эти 25–35%. Copilot, Cursor, кодогенерация — всё это ускоряет написание кода. Сам whitepaper называет это антипаттерном — «Coding-Only AI», то есть использование AI только для написания кода при том, что большая часть времени уходит на всё остальное.
Там же приводится формула:
ИИ-эффект = среда работы ИИ-агентов × workflow redesign
Без переосмысления workflow ИИ-инструменты не выходят за рамки пилотов. Среда работы агента важнее самой модели. Это правда.
И ещё один момент, который документ честно признаёт: если разработчик стал писать код быстрее, но никто не решил что он делает с освободившимся временем — он просто дольше сидит в Slack или берётся за менее важные задачи. Скорость выросла, результат для бизнеса не изменился. Bain 2025 называет это прямо: сэкономленное время само по себе не превращается в деньги.
Всё верно. И вот здесь начинается проблема.
Что whitepaper делает дальше
После того как правильно назван главный bottleneck (не код, а всё вокруг него), документ посвящает 80 страниц тому, как оптимизировать... написание кода. WTF?
Specification-Driven Development. Discovery Sub-Loop. R0–R5 permission ladder для агентов. Evidence Bundle. Governance Mesh. Всё это — инструменты для ускорения инженерного цикла.
Это как купить более быструю машину, чтобы ехать быстрее — когда стоишь в пробке.
Диагноз: 65-75% времени теряется на процессы
Лечение: ускорим оставшиеся 25-35%
Инженерный цикл — это то, что компания может контролировать. Можно написать методологию для написания спецификаций. Нельзя написать методологию для того, чтобы начальник отдела безопасности перестал держать задачи по две недели.
Ещё одна проблема: документ описывает что надо делать, но почти не объясняет как. SDD (подход где спецификация важнее кода) — хорошая идея, но как внедрить её в команду из 50 человек, которая уже работает по своим процессам? Как перейти от тикетов в Jira к исполняемым спецификациям не останавливая разработку? Этого нет. Для тех, кому нужна стратегия — сойдёт. Для тех, кому это внедрять — почти бесполезно.
Настоящий bottleneck корпорации
Дайте всем в большой компании Claude с агентным режимом. Код будет писаться в пять раз быстрее. Что произойдёт дальше?
Пробка переместится. Вместо «ждём разработки» — «ждём ревью». Вместо «ждём ревью» — «ждём архитектурного комитета». Скорость системы определяется самым медленным звеном, а самое медленное звено в корпорации — не инженерное.
Логичный следующий шаг: автоматизировать и эти этапы. Пусть агенты делают ревью, проверяют безопасность, выкатывают. Это и есть то, к чему ведёт whitepaper на уровне R4–R5.
Но тут большая корпорация упирается в стену. Финансовый сектор, госструктуры, крупный enterprise — регуляторные требования, сертификации, локализация данных, службы безопасности с правом вето. Передать агенту право деплоить в прод или автономно проверять compliance — это не технический вопрос, это вопрос регулятора. Регулятор пока не готов.
И здесь whitepaper молчит о самом важном: кто отвечает, если агент что-то сломал? Документ описывает контроль — кто проверяет результат агента на каждом уровне R0–R5. Но контроль и ответственность — разные вещи. Если агент на R3 уронил прод, виноват разработчик, который писал спецификацию? Инженер, который настраивал среду? Менеджер, который дал агенту этот уровень автономии? Этого вопроса в документе нет. А без ответа на него ни одна крупная организация не даст агенту реальных полномочий.
Почему в маленьких командах это работает
Небольшая команда с AI-инструментами — это другая система. Не потому что умнее или прогрессивнее. Потому что у неё другой bottleneck.
Когда вас двадцать, согласования занимают минуты. Ревью — часы, не недели. Решение о выкатке принимает один человек. В такой среде единственное, что реально тормозит — это скорость написания кода и формулировки задач. Именно сюда AI и бьёт точно.
Мы в команде работаем с агентными инструментами больше года — и без всяких whitepaper'ов пришли к тем же выводам, что описаны в документе Сбера:
- Спецификация стала важнее кода. Когда агент пишет 60–70% кода, качество задания определяет качество результата.
- Роли перемешались. Разработчик делает часть работы QA, продакт пишет более технические спецификации.
- Ревью изменилось. Проверяем не строки кода, а то ли вообще сделано.
Это произошло само, за несколько месяцев. Без фреймворков и матриц.
| Маленькая команда | Большая компания |
|---|
| Главный bottleneck | Инженерная скорость | Управленческие процессы |
| AI решает проблему? | Да | Частично |
| Что мешает | Ничего | Регуляторы, инерция, compliance |
| Нужна ли методология | Нет — адаптируются сами | Да — но недостаточна |
Что реально стоит взять из документа
Там есть три идеи, которые работают вне зависимости от размера команды.
Среда важнее модели. Анализ реальных агентных систем показал: ~98% кодовой базы — детерминированная логика вокруг AI, и только ~2% — сама AI-логика. Конкурентное преимущество создаёт не выбор модели, а качество среды исполнения. Модели меняются каждые несколько месяцев, среда накапливает ценность годами. Поэтому инвестировать стоит в среду, а не в подписки на инструменты.
SDD — спецификация как исполняемый контракт. Specification-Driven Development — это не «пиши подробные тикеты». Это конкретная структура: гипотеза результата с метрикой и fallback-критерием, контракты с существующими модулями, acceptance criteria в формате Given-When-Then, план откатки. Задача агенту — не «сделай поиск», а документ, отвечающий на вопросы: что именно меняем, почему, с каким уровнем автономии, как проверяем что сработало. Цена ошибки в формулировке выросла — агент выполнит задачу быстро, и быстро сделает не то.
Evidence Bundle. Агент не просто пишет код — он собирает пакет завершения: diff, результаты тестов, audit trail, аттестации. Задача не закрывается пока пакета нет. Это меняет определение «готово» с «задеплоено» на «гипотеза подтверждена». Для маленьких команд — дисциплина. Для больших — аудиторский след.
Вывод
AI PDLC работает — но только если bottleneck инженерный. Тогда вы, скорее всего, небольшая команда, и вы уже движетесь в этом направлении с whitepaper'ом или без него.
Если bottleneck управленческий — AI PDLC даст вам качественный код, который будет лежать в очереди на ревью так же долго, как раньше. Только теперь этого кода будет в пять раз больше.
Сбер написал хороший документ про систему, в которой он не может работать.