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

Количество часов разговоров с коллегами в отрасли на эту тему за последний год я бы мог исчислить десятками)
Например пол года назад тут с коллегами из Т-Банк, Яндекс и WB (FunSun) или пару недель назад в круглом столе про ФОТ. Или под новый год на митапе smallTech.
Также много разговоров с коллегами в кулуарах Saint Haighload++, TeamLeadConf, Sber Arch.Meethup и еще многих других.
Кстати так сложилось что практически не обсуждали на 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% написания кода происходяи в результате огромного количества блокеров. Но имхо эти процессы нужно параллелить. Чтобы к тому моменту когда вы разошьете старые проблемы, не оказалось что вы с самом начале перевода производства на новые рельсы.