Сбер выкатили AI-Disrupt PDLC (сайт aipdlc.ru) — авторства Кирилла Меньшова, CIO Сбера. Это новая стратегия AI-трансформации разработки программного обеспечения. Если запомнить только три вещи, то:
- Человек — про намерение, агент — про исполнение. Главный актив — спецификация, а не код.
- Среда решает больше, чем модель. Стройте платформу, а модель подберёте под неё.
- Контроль — внутри процесса, а не в конце. Иначе выигрыш в скорости уйдёт на разбор её же последствий.
Поскольку документы, представленные на том сайте читаются довольно тяжело, то ниже:
- ИИ-выжимка в более облегченном варианте поонимания.
- Мнение модели Fable 5 "без цензуры".
Суть в одном предложении
Это не «прикрутить ИИ-помощника (Copilot) к старому процессу», а перестроить весь жизненный цикл создания продукта (PDLC) вокруг развилки: человек отвечает за замысел, ИИ-агент — за исполнение, а между ними стоит платформа-среда, превращающая капризную нейросеть в предсказуемый инструмент. «Ломающая» приставка (Disrupt) значит, что ИИ не ускоряет привычные стадии, а меняет у каждой исполнителя, скорость и нужные навыки.
Модель задаёт минимум результата. Среда вокруг модели — максимум. Модели меняются каждые пару месяцев, среда строится годами и копит знания о компании.
Одна метафора, чтобы понять всё: Формула-1
Гонка показывает, как четыре вещи работают одновременно, не мешая друг другу:
| На трассе | В методологии | Вопрос |
|---|---|---|
| Бокс строит стратегию (резина, дозаправка) | Петля намерения (Intent Loop) — человек | Что и зачем строим? |
| Пилот ведёт болид, решает в каждом повороте | Петля реализации (Implementation Loop) — агент | Как это сделать? |
| Телеметрия в реальном времени | Хребет валидации (Validation Spine) | Правильно ли едем? |
| Стены, регламент FIA, чёрный ящик | Сквозной контур управления (Governance Mesh) | По правилам ли едем? |
Соль: пилот не теряет ни секунды оттого, что телеметрия и регламент работают параллельно. Без них он либо разобьётся, либо получит дисквалификацию. Так и здесь — контроль не тормозит разработку, если встроен внутрь, а не навешан в конце.
Сердце методологии: две петли
- Петля намерения (Intent Loop) — человеческая, дни–недели. Люди исследуют задачу (Discovery), ставят гипотезу, пишут спецификацию, принимают результат. Право на архитектурные решения агенту не передаётся.
- Петля реализации (Implementation Loop) — агентная, часы–минуты. Система сама пишет код по спецификации в цикле «правка → тест → прогон → исправление».
- Между ними — платформа разработки (IDP), которая переводит намерение в код и возвращает результат человеку.
Главный сдвиг: код перестаёт быть главным активом. Его место занимает спецификация — точное описание того, что и как должна делать система (подход SDD, Specification-Driven Development). Агент, в отличие от человека, не додумывает — расплывчатое ТЗ даёт лотерею.
Почему «среда важнее модели» — не лозунг, а цифры
- Один и тот же разработчик с одной и той же моделью даёт разброс результата до 22 процентных пунктов — всё решает качество среды. А разрыв между лучшей и худшей топ-моделью — всего 1–3 пункта. Гоняться за «правильной моделью» почти бессмысленно.
- В реальных промышленных агентных системах ~98% кода приходится на саму среду (обвязку вокруг модели) и лишь ~2% — на «мыслящий» цикл нейросети. Почти вся инженерия — в среде.
- После одного цикла самокоррекции доля верных ответов агента растёт с 53,8% до 81,8%.
- К 2028 году доля ручного кода упадёт с 50% до 25% (не из-за увольнений, а из-за смены роли инженера). У команд со зрелой средой — −60% дефектов после выкатки.
Четыре принципа
- Среда важнее модели. Вложения в среду копятся с каждым поколением моделей; подписки на конкретную модель обесцениваются каждые пару месяцев.
- Исследование перед генерацией. Спецификация без Discovery = старый процесс на новой технологии.
- Валидация встроена, а не добавлена. Отдельная стадия ревью убивает бесшовность.
- Управление — третья ось. Контроль работает в реальном времени, а не постфактум.
Fable 5: Моё мнение: что это значит для рядового программиста
Мантра документа — «ИИ не заменяет, а усиливает человека». Но тот же текст говорит: команда из 10–15 ужимается до 3–6, ручного кода станет вдвое меньше, один продуктовый инженер (Product Engineer) закрывает работу 3–5 прежних разработчиков. Это и есть сокращение, просто названное «трансформацией».
- Ценность уходит от «пишу код» к «ставлю задачу и проверяю». Скорость печати больше не капитал; понимание бизнес-задачи — да.
- Больнее всего джунам и «руками-кодерам». Рутину (шаблонный код (boilerplate), тесты к легаси, обновление зависимостей) забирает агент. Нижняя ступень карьерной лестницы автоматизируется первой — а как расти в сеньоры без неё, документ не отвечает.
- Работа меняет вкус: меньше глубокого потока в коде, больше ревью машинного вывода и «нажми ОК». Многие сильные инженеры это возненавидят — и документ сам это признаёт: «не каждый хочет или может стать оркестратором».
- Ответственность без контроля: за результат агента отвечаешь ты, а вникаешь всё меньше (усталость от подтверждений, Approval fatigue). Штампуешь одобрения — и сам же на крючке.
Не всё чёрно: барьер «сделать что-то» падает — если у тебя есть идеи и знание предметной области, ты становишься сильнее, а не слабее. И это не завтра: горизонты перехода — 0–6, 6–18, 18–36 месяцев, время переобуться есть.
Что делать уже сейчас: перестать мерить себя строками и стори-поинтами; учиться писать спецификации и критерии приёмки; критически проверять агента, а не поддакивать ему; лезть ближе к клиенту и продукту. Документ сам называет единственный неисчезающий дефицит — намерение, «способность понять суть клиента». Вот туда и надо.
Вывод без цензуры: профессия не умирает, но «программист = тот, кто пишет код» — умирает. Остаётся «программист = тот, кто понимает задачу и управляет её решением». Кто успеет переобуться — выиграет; кто держится за среду разработки (IDE) и объём кода — окажется догоняющим.
Комментарии (146)