Как пересобрать метрики команды после внедрения ИИ-агентов: опыт Tech Lead

Сергей Прощаев, Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce, столкнулся с типичной для 2025–2026 годов ситуацией: после внедрения ИИ-агентов в команде из 25–40 инженеров дашборд показывает рост velocity, числа пулл-реквестов и закрытых тикетов, но поставка замедлилась. Релиз, который раньше проходил за неделю, теперь занимает полторы, ревьюеры перегружены, а в проде появляются инциденты, которые сложно воспроизвести. На вопрос CTO о том, окупаются ли токены, ответить нечем: операционные цифры выросли, но доверия к ним нет.

Корень проблемы в том, что старые метрики перестали отражать реальность. DORA в отчёте ROI of ИИ-assisted Software Development описывает это как verification tax: время, сэкономленное на генерации кода, возвращается в систему в виде дополнительной проверки и аудита. По телеметрии Faros, медианное время нахождения PR в ревью выросло на 441%, размер PR — на 51,3%, а доля PR, вливающихся без ревью, — на 31%. Узкое место сместилось из «написать» в «проверить», а часть проверок молча отвалилась. Исследование Стэнфорда, на которое ссылается InfoQ, даёт прирост 35–40% на простых задачах на чистом листе и порядка 10% или меньше на сложном легаси. Если основная работа команды связана с легаси и интеграциями, ориентироваться на greenfield-эксперименты опасно: ожидания руководства сформированы первым сценарием, а живёте вы во втором.

Прощаев приводит и собственный пример ловушки: команда отчиталась за квартал ростом числа смёрженных PR, но через месяц выяснилось, что треть прироста дали PR на 40 строк с правкой конфигов, которые агент нарезал вместо одного нормального изменения. Формально рост в полтора раза, фактически та же работа, размазанная тоньше. Это иллюстрирует главное правило, которое он теперь пишет первым пунктом в любом соглашении о метриках: метрика, которая считает усилие вместо результата и становится KPI, очень быстро начинает оптимизироваться сама под себя.

История, которую стоит знать до того, как заводить дашборд, — это токенмаксинг, мода конца 2025 — начала 2026 года, когда потребление токенов стали выставлять как показатель продуктивности. В Meta сотрудник построил на внутренней платформе лидерборд Claudeonomics, ранжировавший более 85 тысяч сотрудников по расходу токенов. За 30 дней совокупный расход составил около 60,2 триллиона токенов, лидер израсходовал 281 миллиард. Через два дня после публикации лидерборд отключили — с формулировкой, что данные из него ушли наружу. Часть участников оставляла агентов работать вхолостую, чтобы поднять позиции в рейтинге. Amazon свернула дашборд KiroRank по схожей причине: метрику для онбординга начали применять для оценки людей. ИИ Impact Report 2026 приводит цифры: 58% организаций меряют эффект от ИИ через потребление токенов, и 57% считают, что это не отражает реальную ценность.

Что делать? Прощаев предлагает маршрут на четыре недели, который делается силами тимлида и одного дата-инженера на полставки, не останавливая поставку. Исходные условия: продуктовая команда 25–40 инженеров, 4–6 сервисов на Java/Kotlin, агенты доступны всей разработке, доля изменений с агентами — 40–60%. Git-хостинг с нормальным API, задачи в Jira, CI на GitLab CI или Jenkins. Бюджет на изменения — ноль, всё делается на существующем стеке. История PR, деплоев и инцидентов за 12 месяцев уже существует в Git, Jira и CI. Неделя маршрута уходит не на накопление истории, а на её нормализацию: без неё измерять эффективность ИИ-агентов рано, сравнивать не с чем.

Ключевой вывод: прежде чем внедрять новые метрики, нужно понять, что именно вы измеряете. Если метрика считает усилие (токены, число PR) вместо результата (скорость поставки, стабильность), она неизбежно начнёт искажаться. Пересборка метрик — это не просто замена дашборда, а пересмотр того, что считать ценностью для бизнеса.