💭 #ПятничныйСтек с Иваном Поддубным, CTO «Вебпрактик»

Немного про измерение эффективности от внедрения AI в SDLC

Количество часов разговоров с коллегами в отрасли на эту тему за последний год я бы мог исчислять десятками)

Например, полгода назад тут с коллегами из Т-Банк, Яндекс и WB (FunSun) или пару недель назад на круглом столе про ФОТ. Или под Новый год на митапе smallTech.

Также много разговоров с коллегами в кулуарах Saint Highload++, TeamLeadConf, Sber Arch.Meetup и ещё многих других.

Кстати, так сложилось, что практически не обсуждали на Agentic Dev Conf, там как будто бы у людей другой вайб, сильно больше тех, кто уже обосновал для бизнеса эффективность.

Я бы разделил следующие фазы этой дискуссии.

# ФАЗА 1: А ТОЧНО ЛИ УСКОРЯЕТСЯ САМ ПРОЦЕСС РАЗРАБОТКИ?

## Лагерь сомневающихся в ускорении
Во многом коллеги ссылаются на какие-нибудь среднерыночные исследования, но берут конечно те, которые подчеркивают их картину мира, игнорируя отчеты и кейсы других компаний. Здесь, мне кажется, стоит разбирать кейсы, практический опыт и результаты конкретных компаний и потенциал воспроизводимости их опыта. Это точно полезнее средних опросов по больнице.

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

На мой взгляд, в таких случаях правильный вопрос: а стоит ли параллелить решение вопросов. Иногда можно на AI рельсах пересобрать новомодные tiny team, это как раз способ и перезагрузить проржавевшие старые процессы. А с AI-флагом сейчас можно как раньше с agile-флагом ломать многие преграды внутри корпоративных укладов.

Третий довод в том, что упираемся в когнитивные возможности человека на валидацию (многие, в т.ч. Никита в канале SE Materials, подсвечивает риск).
Я бы тут прокомментировал, что большую часть когнитивных возможностей должен решать harness. Предел, конечно же, есть, однако на мой взгляд этот предел точно х2-х3 выше, чем работа в старых парадигмах. Запуская harness в 2-3 потока с высоким уровнем автономности (работа часами с самопроверкой до результата), ты можешь поочередно решить 2-3 задачи, тогда как решал за это время условно 0,5.

Но тема большая, в т.ч. если раскрывать мультипоточность работы разработчика в новых реалиях.

## Лагерь адоптеров

Можно поделить на тех, кто нашел способ доказать ускорение на пилотах в определенных командах. Я видел разные пилоты в корпорациях за последние полгода.

1. Внедрение в greenfield-проект. Берут greenfield-проект, оценивают конвенциональными способами разработки в год (верифицируют оценку другими старыми командами). И потом эффективно делают его за пару месяцев.
Примеров видел много. Вот публичный кейс x5, доклады Александра Поломодова (Т-Банк), в т.ч. на последнем Highload++ рассказывали об успехе таких команд, много данных в кулуарах конференций. Да и в целом кажется про успехи в greenfield не рассказывал только ленивый.

2. Внедрение в brownfield-проект. Это уже интереснее, т.к. было много споров, что вот на старых-то проектах внедрить нельзя. Но пилоты у многих показали, что и тут можно добиваться значимых результатов.

На Agentic Dev Conf и грядущем TeamLead Conf Siberia коллеги из Райфа показывают такие пилоты и их успех в разных несвязанных вертикалях.
Есть и много других проектов. И мы в Вебпрактик видим ускорение в т.ч. в brownfield проектах, если правильно работать с контекстом и правильно затачивать под это harness. Причём как про микросервисную (могу говорить про десятки/сотни), так и про монолитную brownfield-архитектуру.

Т.е. в лагере адоптеров есть много кейсов, когда они доказали эффективность бизнесу через прирост производительности разработки в конкретных метриках.

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

# ФАЗА 2: ТРАССИРОВКА ЭФФЕКТОВ ОТ УСКОРЕНИЯ НА БИЗНЕС

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

И один из ключевых вопросов, который задают: а точно ли ускорение разработки даёт эффект в бизнесе?
Измеримый сквозной throuthput. В идеале, в финансах.

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

Да, есть кейсы, когда это можно трассировать прозрачно, как ускорение переработки бэклога даёт прозрачный бизнес-результат. Но померить влияние на финансы какой-нибудь команды в микросервисной архитектуре — порой весьма непростая задача)

И тогда 2 сценария:
а) У вас есть возможность доказать бизнесу, что бэклог действительно конвертируется в ценность и ускорение переработки бэклога = польза.
б) У вас идут сценарии доказывания через сохранение скорости бэклога, но сокращение ресурсов.

===
В целом, в правильном споре стоит разделять уровни, и спорить на каждом конкретно: разработчик / команда / поток доставки / бизнес
Часто в спорах идет перепрыгивание с уровня на уровень, причем неосознанное.

На мой взгляд, эффективность разработки доказана давно. Лето 2026 славится тем, что уже к этому моменту, за весну, многие корпорации откатали свои пилоты и пришли с публичными результатами, о которых могут заявлять. Сейчас все начинают думать, как масштабировать этот опыт и решать те боли, с которыми столкнулись в процессе.

Нельзя не уважить лагерь тех, кто говорит подходить аккуратнее и утверждает, что можно получить ускорение больше классическими методами поиска узких мест без AI, особенно если у вас накопился большой ворох проблем и те самые 10% написания кода происходят в результате огромного количества блокеров. Но, имхо, эти процессы нужно параллелить. Чтобы к тому моменту, когда вы разошьете старые проблемы, не оказалось, что вы в самом начале перевода производства на новые рельсы.

Вебпрактик AI | Корпоративный ИИ