Token burn как proof of work: почему AI-метрики легко уезжают в имитацию работы (Рубрика AI4SDLC)

Все чаще я думаю про моду на token maximizing и метрики вроде "сколько токенов сжег сотрудник". В этом есть забавная, но неприятная рифма с proof of work в крипте: человек предъявляет не результат, а доказательство потраченного вычисления. Смотри, я сжег достаточно токенов — значит, работал правильно. Буквально вчера в кулуарах Highload++ обсуждал это с другими экспертами (дискутируя после своего доклада "State of AI4SDLC на HighLoad++"). Поэтому я решил написать пост со своими мыслями на эту тему.

Я понимаю почему соженные токены на сотрудника являются соблазнительной метрикой: она простая, технически собираемая и хорошо выглядит на дашборде для топ-менеджров. Еще легко посчитать лицензии, MAU, число запросов, соженные сотрудником токены — все это быстро складывается в график adoption. Одна проблема - adoption напрямую не свяан с ценностью (outcome или value, если говорить по английски). Вообще, активность — это не результат, а token burn — это не инженерная производительность.

Похожая логика уже была в старой управленческой культуре, где "мерилом работы считают усталость" как в песне Nautilus Pompilius. Кто позже ушел, тот больше старался. Кто чаще был на встречах, тот вовлеченнее. Кто отправил больше писем, тот продуктивнее. Теперь та же рамка легко переезжает в AI: кто сжег больше токенов, тот вроде бы лучше использует новую технологию.

Но сами по себе токены ничего не говорят о системе разработки. Сократился ли cycle time? Стал ли ревью быстрее и качественнее? Уменьшилась ли доля rework? Стало ли восстановление после инцидентов быстрее и уменьшилась ли сама частота инцидентов? Дошел ли результат до прода, клиентов и денег? Если на эти вопросы ответа нет, token burn превращается в корпоративный proof of work. Мы доказываем, что вычисление было потрачено. Но не доказываем, что ценность была создана.

Правильная рамка, мне кажется, другая: не proof of work, а proof of value. Не "сколько токенов сожгли", а "какую ценность получили за эту вычислительную работу". Для AI4SDLC это означает смотреть на весь контур: постановка задачи, контекст, генерация, ревью, тесты, merge, раскатка, эксплуатация, качество и стоимость результата.

И вот здесь начинается взрослая и неприятная часть. Value нужно уметь измерять.

На уровне всей компании можно посмотреть в финансовую отчетность: выручка, маржинальность, затраты, рост, удержание клиентов. Но дальше начинается атрибуция. Как честно разложить вклад на подразделения, команды, людей, платформы, фичи и изменения в SDLC? Что считать эффектом AI, что эффектом хорошего менеджмента, что сезонностью, а что просто удачным релизом?

Для этого нужны baseline до внедрения, нормальная карта процесса, ownership метрик, связка DORA/SPACE/DevEx с экономикой, качество данных и договоренность о том, какие решения мы принимаем по этим числам. Нужна управленческая зрелость, а не только новый счетчик в биллинге модели.

Именно поэтому token maximizing так привлекателен. Он дешевле организационно. Не надо договариваться, что такое value. Не надо чистить грязные данные. Не надо связывать инженерные метрики с продуктовым результатом. Не надо признавать, что эффект AI в одной команде может быть отличным, во второй нулевым, а в третьей отрицательным.

Можно просто поставить цель: увеличиваем потребление токенов на сотрудника. Авось и так прокатит.

Если подбивать итоги по моей позиции, то я считаю token burn полезен как техническая и финансовая телеметрия, но опасен как управленческая цель. Его нормально смотреть рядом с adoption, стоимостью на задачу, lead time, качеством/риском и опытом разработчиков (DevEx). Но как только сожженные токены сами становятся доказательством хорошей работы, организация начинает оптимизировать не результат, а видимость деятельности. AI-метрики становятся взрослыми только там, где компания готова отвечать на неудобный вопрос: не сколько вычисления мы потратили, а что именно стало лучше в реальной производственной системе.

P.S. Про наш подход можете почитать мой разбор выступления Анны Громовой из Т-Банка на конфе AI Dev Conf буквально месяц назад, где она рассказывала что и как мы измеряем и почему считаем это верным подходом.

#AI #AI4SDLC #Engineering #Management #Metrics #DevEx