Объём разработки в Сбере вырос на 70%. Что из этого применимо к команде из пяти человек

Объём разработки Сбера вырос на 70% за год. Это сравнение сентября 2026 года с сентябрём 2025-го, его 16 октября 2026 года привёл старший вице-президент банка Кирилл Меньшов на инженерном дне конференции «ГигаКонф».

Там же прозвучали ещё две цифры: ИИ используют все инженеры банка, на одного инженера приходится 220 млн токенов в месяц. Так пишет «Аргументы и факты».

После таких новостей у основателя небольшой компании появляется резонный вопрос к подрядчику: если код пишет ИИ, почему разработка стоит столько же? Вопрос честный. И ответ на него сложнее, чем «ИИ всё изменил» или «ИИ ничего не умеет».

Что именно сказал Сбер и чего он не сказал

Сбер сказал, что вырос объём разработки. Это не то же самое, что «продукты стали выходить на 70% быстрее» или «разработка подешевела на 70%». Объём показывает, сколько работы сделано. Сколько из неё дошло до пользователей и сколько потом переписали, из выступления не следует.

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

Иначе говоря, банк вложился в инфраструктуру и в новую организацию команд. Подписка на нейросеть сама по себе таких 70% не даёт.

Где ИИ правда ускоряет небольшую команду

ИИ быстро окупается в небольшой команде там, где задача типовая, а результат легко проверить.

1. Прототипы и черновые интерфейсы. Показать инвестору или первым клиентам, как будет выглядеть продукт, теперь можно заметно быстрее.
2. Типовой код: формы, справочники, простые операции с записями в базе, миграции, тесты к уже понятной логике.
3. Документация и разбор чужого кода. Новому разработчику проще войти в проект, когда ИИ объясняет, что делает модуль.
4. Внутренние инструменты, которыми пользуются три человека и где ошибка не стоит денег.

В этих задачах вайб-кодинг и ИИ-ассистенты действительно экономят время. Не на 70%, но ощутимо.

Где без инженера всё равно не обойтись

Инженер нужен везде, где результат ИИ надо проверять. А проверка стала главным узким местом. Об этом говорил и сам Меньшов, его слова приводят «Ведомости» 13 октября 2026 года: агенты генерируют код быстрее, чем его можно проверить вручную. Выход, который он предлагает, требует серьёзной подготовки: формализовать требования безопасности и аудита как правила для агентов. У команды из пяти человек таких правил обычно нет, и писать их некому.

Поэтому инженер нужен в трёх местах.

Архитектура. ИИ хорошо решает локальную задачу и плохо держит в голове всю систему. Как сервисы общаются между собой, где хранятся данные, что будет при росте нагрузки в десять раз, решает человек.

Интеграции с чужими системами. 1С, платёжные провайдеры, CRM заказчика. Код может выглядеть правильным, а ошибка всплывёт в данных. Искать её приходится руками и с пониманием того, как устроена система на другой стороне.

Проверка кода и безопасность. Код, который никто не прочитал, рано или поздно уходит в рабочую версию продукта с уязвимостью или утечкой персональных данных. Отвечает за это компания. Модель ответственности не несёт.

История из практики: где ошибка жила в данных

Команда Фортех (fortech.dev) работала с сайтом поставщика сантехники, который продаёт в 50 регионах. Задача звучала просто: ускорить сайт и наладить обмен с 1С.

Самым трудоёмким оказалось разобраться в системе. Команде пришлось найти медленные запросы, выяснить, почему обмен с 1С падает с ошибками, и исправить ранжирование фильтров по цене. Каждая из этих проблем требовала понять, как данные на самом деле ходят между системами заказчика.

В подобной задаче ИИ-ассистент может пригодиться: объяснить незнакомый модуль, предложить вариант исправления. Но на вопрос «почему цены в фильтре выстроились не в том порядке» ответит человек, который видел, откуда эти цены приходят.

У любого живого продукта таких задач много.

Что делать основателю небольшой компании

Не ждать, что ИИ сократит бюджет на разработку в разы. И не платить за то, что ИИ уже делает быстро. На практике это выглядит так.

1. Спросите подрядчика, как он использует ИИ в работе и кто проверяет написанный с ним код. Ответ покажет, понимает ли команда, где ИИ помогает, а где создаёт риск.
2. Попросите разделить оценку на типовые задачи и задачи с неопределённостью: интеграции, архитектуру, безопасность. Экономия от ИИ возможна в первой части, во второй её почти нет.
3. Требуйте, чтобы код проверял человек. Особенно если в продукте есть платежи или персональные данные.
4. Прототип собирайте быстро, хоть вайб-кодингом. Продукт, за который платят клиенты, собирайте с инженером.

Если продукт ещё на стадии MVP или первой версии, подойдёт разработка на аутсорсе под ключ: подрядчик отвечает за готовый результат целиком. В Фортех оценка проекта занимает 2–3 рабочих дня, и вопросы из списка выше можно задать уже на этом этапе.

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