Хватит считать токены: почему KPI в эпоху ИИ превратились в фикцию

В одной продуктовой команде рейтинг разработчиков строился по количеству сожжённых токенов за день. Менеджеры выделялись зелёным, отстающие — красным. В комментариях к тикету менеджер писал: «Ваня, ты сегодня потратил всего 80 тысяч токенов, а Петя — 400. Подтянись». Ваня, если что, закрыл за день две сложные интеграции. А Петя — весь день гонял агента по кругу, пытаясь сгенерировать regex для парсинга CSV.

Метрика есть. Смысла нет.

Это не анекдот. Это «tokenmaxxing» — новая корпоративная религия, которая в 2026 году добралась и до российских команд.

Токены — это новые строки кода

Когда-то менеджеры мерили продуктивность строками кода. Потом — коммитами. Потом — количеством пул-реквестов (PR). Сейчас в тренде — токены.

Логика простая: раз мы платим за ИИ-инструменты, значит, надо следить, чтобы деньги не улетали впустую. А раз разработчик потребляет токены — значит, он работает. Чем больше жжёт, тем полезнее.

DORA (DevOps Research and Assessment) в своём июньском отчёте 2026 года прямо называет это возвращением к «vanity metrics» — метрикам тщеславия, которые легко измерить, легко накрутить и которые никак не связаны с результатом. Токены — это lines of code эпохи ИИ. Их так же просто нарисовать. Открой Cursor, запусти агента на ночь, который будет рефакторить тесты — и к утру у тебя минус бюджет и плюс «продуктивность».

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

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

Но если ты руководитель, который смотрит на дашборд и видит, как счётчик крутится, тебе плевать на проценты. Ты хочешь видеть, как люди «работают».

Личный опыт

SDD (spec-driven development) — подход, где сначала пишешь спецификацию, потом ИИ генерирует код. Я пробовал. Честно — было прикольно. Пишешь спеку, запускаешь агента, он генерирует код, тесты, документацию. Красиво.

Проблема в том, что вместо написания кода и понимания, что и где лежит, я читал — а скорее делал вид, что читал — пул-реквесты от ИИ. Просматривал диффы, кивал, мержил. Через пару дней такой работы я поймал себя на том, что не могу ответить на простой вопрос: «Почему эта функция работает именно так?» Я не знал. Агент знал. Но агент не сидит на созвонах с заказчиком и не дебажит прод в три часа ночи.

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

SDD: метрика, которая измеряет бумагу

SDD — идея здравая: спецификация становится активом, который живёт дольше, чем сгенерированный код. KDDI в своей tech-note описывает переход на SDD и рост деплой-частоты в 3.1 раза — с 4.4 до 13.8 раз в неделю.

Звучит впечатляюще. Только вот в той же заметке честно написано: «Мы до сих пор не можем измерить, насколько эффективно мы используем ИИ». DORA-метрики выросли, а вменяемого показателя ИИ-продуктивности нет. Поэтому команда предложила три новых: AI proposal acceptance rate, AI cost efficiency и Spec quality score.

Проблема в том, что «количество SDD» — такая же фикция, как и токены. Если в компании введут KPI по числу написанных спецификаций, менеджеры начнут требовать спеку на каждую правку в CSS. По наблюдениям, в некоторых командах SDD-документы писались для галочки, а потом удалялись после мержа. Метрика выполнялась. Продукт не улучшался.

Но есть и другой слой проблемы — уместность SDD и зрелость команды. SDD — это не серебряная пуля, которую можно накатить на любую команду. Опытные инженеры с сильными практиками чистого кода и архитектуры извлекают из SDD наибольшую ценность. Если команда не умеет писать внятные требования, не имеет процессов ревью и живёт в режиме «пожар каждый день», SDD превратится в бюрократический ритуал. Спецификации будут писаться ради спецификаций, а не ради результата.

Существует как минимум четыре уровня зрелости SDD: от Spec-First, где спецификация просто задаёт начальный промпт, до Spec-to-Application, где человек редактирует только спеку, а код полностью генерируется. Прыгать сразу на четвёртый уровень, не пройдя первые три, — верный способ получить чёрный ящик.

Ещё несколько странных метрик

Кроме токенов и SDD, в 2026 году индустрия придумала ещё несколько способов измерять активность вместо результата.

AI adoption rate — процент дней, когда разработчик использовал ИИ. LinearB в своём отчёте на 2.7 млн пул-реквестов показывает: в топовых командах ИИ используется в 54% PR, но только менее 5% PR — от автономных агентов. То есть «адопшен» может быть 90%, а реальный эффект — нулевым, если люди просто жмут Tab в автокомплите.

Lines of AI-generated code — количество строк, сгенерированных ИИ. Thoughtworks ещё в 2026 году предупреждал: это поверхностный индикатор, который ничего не говорит о качестве. Можно сгенерировать 10 тысяч строк мусора и получить зелёный дашборд.

PR throughput — пропускная способность пул-реквестов. Выросла? Отлично. Но рост throughput может не отражать реальную продуктивность — критичные фичи всё равно могут запаздывать.

Что измерять вместо этого

Есть один принцип, который работает: если метрика не связана с результатом, который видит пользователь, она бесполезна.

Cost per verified outcome. Не «сколько токенов сжёг», а «сколько денег ушло на одну фичу, которая дошла до прода и не сломала ничего». Faros AI прямо пишет: ключевая метрика — это эффективность трат, а не объём потребления.

Portfolio-based evaluation. Исследование AMCIS 2026 на основе опроса разработчиков показало: специалисты предпочитают оценивать не отдельные действия, а портфель результатов — скорость, качество и влияние вместе. Один разработчик может сжечь мало токенов, но закрыть сложнейшую задачу. Другой — много токенов и ноль результата.

DORA в связке с новыми метриками. Частота деплоя, lead time, change failure rate, MTTR (mean time to recovery) — всё ещё работают. Но к ним нужно добавлять то, что ИИ реально меняет: время, сэкономленное на рутине, и объём верификационной работы. Потому что ИИ смещает центр тяжести с написания кода на его проверку и интеграцию.

Если продакт не может сказать, что изменилось для пользователя, ты не измерил ничего.

Вывод

Если вы руководитель и вводите KPI на токены или количество SDD — остановитесь. Вы получите не продуктивность, а имитацию. Люди будут жечь бюджет и рисовать отчёты. Аутсорсинговые компании с KPI по строкам кода уже прошли этот путь — и это не тот опыт, который стоит повторять.

Что делать вместо этого: измеряйте cost per verified outcome. Считайте не токены, а фичи, которые пережили неделю в проде. И не превращайте инструмент в цель — иначе получите ровно то, что заслужили: зелёный дашборд и красный P&L (отчёт о прибылях и убытках) .

А теперь откройте дашборд и спросите: какая фича из тех, что мы сожгли в токенах, дошла до пользователя и не сломалась?