Индустрия двадцать лет смеялась над метрикой «строки кода» — и пришла к консенсусу, что LOC не измеряет ценность. Когда в командах появились ИИ-инструменты, счётчики переключились на промпты на разработчика, процент ИИ-assisted коммитов и adoption rate. По сути — та же метрика активности, только в новой обёртке.
Проблема не изменилась: активность не равна результату. Команда может интенсивно использовать Copilot или аналоги и выдавать ровно те же бизнес-исходы, что и до внедрения. Дашборд при этом будет зелёным, а сквозная пропускная способность — время от идеи до того, что увидел клиент — останется на месте или просядет.
| Уровень | Что меряем | Примеры метрик | Что упускает |
|---|---|---|---|
| 1 — Активность | Использование инструмента | Лицензии, adoption rate, промпты, токены | Не связан с бизнес-результатом |
| 2 — Движение | Скорость конвейера | Cycle time, число PR, время в ревью | Локально оптимизируется, клиент не чувствует |
| 3 — Результат на затраты | Ценность на вложенный рубль | Время доставки до клиента, стоимость инцидентов, роадмап тем же составом | Требует честного baseline и воли показать «не работает» |
Механика здесь простая. Когда генерация кода дешевеет в разы, узкое место конвейера не исчезает — оно переезжает вниз по потоку. Раньше написать код было дорого, а проверить — относительно дёшево на его фоне. Теперь написать почти бесплатно, и вся стоимость переехала на ревью, QA и интеграцию. Senior-инженеры чувствуют это первыми: ревью-очередь распухает, потому что в неё валится в разы больше изменений, и каждое нужно понять, а не просто пробежать. Пропускная способность конвейера определяется самым узким его местом — теперь это место завалено дешёвым кодом, ждущим дорогого человеческого внимания.
Автор материала, работающий временным техническим директором в компаниях, которые «вложились в ИИ, а результата не видно», выделяет три уровня зрелости ИИ-отчётности. Первый — активность: лицензии, adoption, токены. Это то, что вендор отдаёт из коробки; отвечает на вопрос закупок, не инженерии. Второй — движение: cycle time, число PR, время в ревью. Уже лучше, но эти метрики локально оптимизируются и игнорируют результат — PR можно дробить, cycle time улучшать, а клиент изменений не почувствует. Третий уровень — результат на единицу затрат: сократилось ли время доставки изменения, которое видит клиент; упала ли стоимость инцидентов; выкатили ли роадмап тем же составом — и сколько каждый из этих исходов стоил в деньгах на ИИ.
Только третий уровень финдиректор понимает без перевода, потому что он в той же валюте, что и его вопрос. Парадокс в том, что именно эту метрику обходят стороной: дашборд активности умеет только расти, а дашборд результата умеет сказать «это не работает». Признать вслух, что часть ИИ-вложений пока не приносит ничего, кажется карьерным риском. На деле риск обратный: через квартал хуже всех окажется тот, чья история про adoption развалится от одного деления финдиректором столбика «потратили» на столбик «получили».
Практический тест, который автор предлагает провести без дашбордов: можно ли ответить на вопрос «что нам дал ИИ за прошлый квартал» в терминах результата за минуту, без слова «adoption»? Известно ли, куда переехало узкое место — и есть ли в команде кто-то, кто отвечает за стоимость ИИ на единицу результата? Наконец: можно ли назвать хоть один ИИ-сценарий, который сегодня отключили бы за ненадобностью? Если таких нет — у команды не портфель, которым управляют, а подписка, которую продлевают.
Рецепт, который следует из анализа, прямолинеен: снять честный baseline до внедрения, взять метрики, которые финдиректор признаёт за результат, сопоставить с затратами в тех же единицах и относиться к ИИ как к портфелю, а не к фиче, которую «внедрили». Это не позиция против ИИ-инструментов — это единственное, что сохраняет ИИ-бюджет живым после первого серьёзного разговора с финансами.
