Эффект AI: 90% на шаге — 5% на цикле

Выпуск открывает второй сезон подкаста и начинается со знакомства: гость — директор по внедрению в компании, которая делает собственный ассистент и агентов для разработчиков, а до этого несколько лет был техническим директором в консалтинге, где ему года три назад и поручили разобраться в AI. Весь прошлый год он ездил по конференциям с докладом про инструменты на каждом этапе SDLC и обновлял его раз в месяц: новые продукты выходили быстрее, чем устаревали слайды. Александр отвечает похожей историей — год назад он популяризировал AI-разработку и отвечал за один из стримов вокруг архитектуры, а с этого года ушёл в эту роль на фултайм и занимается внедрением в Т-Банке. Он говорит, что скептики, не верившие в результат, перевелись весной; гость поправляет: скорее в конце осени, ближе к зиме, когда люди попробовали и позиция «это не работает» стала неактуальной.

Типичный провал гость описывает почти анекдотом: два увлечённых инженера идут доказывать менеджменту, что AI нужен, их спрашивают, как они померят бизнес-эффект, выдают игровой компьютер и просят написать промышленную систему. Получается «вундервафля», к которой пользователи предъявляют требования жёстче, чем к любому промышленному продукту: «Claude Code так умеет, а то, что вы написали за три месяца на коленке, почему-то нет». Системный путь начинается с пирамиды метрик: наверху CTO с P&L и ROI, внизу инженеры с DORA и юнит-тестами, посередине менеджеры, которым нужны velocity и shift left, — все смотрят на одно и то же разными глазами. Первый слой измерений — обычная телеметрия: сколько людей пользуются и сколько шлют запросов, из этого считается adoption. Второй — логи запросов и ответов, которые склеиваются в «работы» с засечками, сгружаются в ClickHouse и оттуда тянутся в собственные дашборды и Grafana.

Каждая такая работа оценивается во времени и в деньгах по средней ставке, и команда видит, во что месяц обошёлся бы, если бы всё делали руками: «сэкономили шесть миллионов, десять процентов эффективности». Александр называет это контрфактуальным анализом и спрашивает главное: откуда берётся оценка того, чего не случилось. Она выросла из более ранней истории гостя: он впилил агента, который разбирал задачу аналитика на подзадачи, ходил в код и выдавал свою оценку. Предполагалось, что люди будут её править и подкручивать коэффициенты, а на практике она угадывала с самого начала — точнее, чем майки и стори-пойнты на грумингах, потому что приходит с разбором и обоснованием. Попытка мерить трудоёмкость известной формулой по объёму кода, с коэффициентами сложности проекта и квалификации команды, оказалась менее релевантной: оценка модели, заточенной под код, совпадает с ожиданиями команды примерно в 80% случаев, и в любую метрику можно провалиться и посмотреть, кто и что делал в три часа ночи.

Из тех же логов вырастает неожиданная метрика — эмоциональная. Система оценивает, как пишет пользователь: нейтрально, агрессивно; на недельном графике виден всплеск негатива, а внутри него обнаруживается забагованная часть проекта или проблема с аналитикой. Гость замечает, что при обычной оценке задач никто не спрашивает, как человек сегодня спал, а здесь состояние инженера видно по логам. Логи же показывают, что кодом занята далеко не вся работа: сначала люди исследуют код, документацию и трекер и спрашивают про бизнес-терминологию — что такое деривативы и как с ними работают. Если с одним и тем же затрудняются десять человек, вопрос закрывается одним движением. Дальше работает шкала доверия: сперва люди берут задачи, не задевающие продакшн, и статистика смещена в исследования, а когда доверие появляется, исследовательская часть схлопывается процентов до десяти-двадцати, а основным становится кодирование и тестирование. Почему она схлопывается, гость честно говорит, что до конца не понимает.

Само внедрение держится на девяти метриках, за которыми ежедневно следят «мастера», тренирующие команды. Первая — вовлечённость: если девять человек из десяти в пилоте вчера послали по триста запросов, это хороший показатель, а отвалившегося стоит спросить, в чём проблема. Эффективность считается по шести категориям — кодинг, тестирование, ревью, документирование, онбординг и ещё одна, которая на записи вылетела у гостя из головы, — как доля времени с AI, давшая пользу. Её приходится пересчитывать на весь SDLC: если задача выполняется с первого раза, на шаге экономится процентов девяносто, а на цикле целиком остаётся процентов пять, а то и один. Сами метрики гость называет мониторами, а не инсайтами, поэтому на третьей неделе внедрения дашборды разбирают вручную: так выясняется, что одним нужен режим планирования, другим — подтягивание общих микросервисных проектов в контекст, а в какую-то часть проекта просто не пускает безопасность.

Отдельный сюжет — контрметрики. Уровень принятия кода тоже меряют, выбрасывая скобки и пробельные строки; по индустрии он около 30%, но очень высокая доля не всегда хороша: иногда она значит, что генерят не глядя и не ревьюят. Речь при этом не про автономного агента в пайплайне, а про чат рядом с кодом; автокомплит они выпилили, а «тап-тап-тап», по словам гостя, маркетинг — программист занят архитектурой, а не автодополнением. Александр добавляет данные инженеров Meta с саммита Developer Productivity конца 2025 года: пока сгенерированного кода до 30%, время подготовки дифа не сокращается, значимые десятки процентов появляются ближе к 60%, потому что когнитивная сложность разбора машинного кода съедает выигрыш. Сам он несколько лет отвечал за developer productivity там, где инженеров больше десяти тысяч, и напоминает, что кроме DORA есть SPACE и DevEx. Дальше — про роли: у «чемпионов» встаёт вопрос, какие роли оставлять, если восемьдесят процентов времени уходит на кодинг.