Tokenmaxxing: ИИ-ассистенты дают 2× PR при 10× затратах токенов, code churn +861%
Четыре исследования сходятся: ИИ-ассистенты дают 2× PR при 10× затратах, а code churn вырос на 861%. Что такое tokenmaxxing и что измерять вместо токенов.
Новости Tproger
Если в вашей команде KPI разработчика измеряется объёмом token-бюджета в Cursor или Claude Code — вы измеряете вход процесса, а не выход. Сразу несколько независимых исследований за последние три месяца показали: чем больше токенов тратит инженер, тем выше code churn и технический долг, а прирост реальной продуктивности в разы меньше, чем кажется.
TechCrunch собрал данные от четырёх аналитических платформ — Waydev, GitClear, Faros AI и Jellyfish — и обнаружил общий паттерн: ИИ-ассистенты действительно ускоряют генерацию кода, но значительная доля этого кода возвращается на переделку в следующие недели. Явление получило название tokenmaxxing — гонка за большими токен-бюджетами как символом продуктивности. Команды оптимизируют расходы на токены, а не реальную выработку.
Что показали исследования
- Waydev (данные по 10 000+ инженеров): code acceptance rate 80–90% сразу после генерации, но после 2–4 недель доработок реальный acceptance — 10–30%
- GitClear (январь 2026): у активных пользователей ИИ code churn в 9,4 раза выше, чем у коллег без ИИ — стоимость переделок вдвое перекрывает выгоду
- Faros AI (март 2026, 22 000 разработчиков): при высоком уровне внедрения ИИ code churn вырос на 861% относительно команд без ИИ
- Jellyfish (Q1 2026, 7 548 инженеров): разработчики с самыми большими token-бюджетами делают 2× больше pull request, но тратят на это 10× больше токенов
- Скрытый риск для тимлида — джуниоры: они принимают ИИ-код чаще, их метрики выглядят хорошо в моменте, но долг вылезает через недели
Что такое tokenmaxxing и почему это антипаттерн
Tokenmaxxing — жаргонный термин, который в Кремниевой долине описывает практику оценивать продуктивность разработчика по размеру token-бюджета, который он освоил в Cursor, Claude Code или Codex. Чем больше токенов «сжёг» инженер, тем продуктивнее он считается — якобы. Это классическая ошибка управления: измерять вход процесса вместо выхода.
Параллель из прошлого: оценка разработчиков по строкам кода (LOC), которую индустрия критикует ещё с 80-х годов (Эдсгер Дейкстра, EWD1036). LOC поощрял многословный код и «водянистые» комментарии; «token count» поощряет переиспользование ИИ-ассистентов даже там, где они не нужны. Atlassian в сентябре 2025-го заплатил $1 млрд за DX — платформу аналитики developer experience — именно потому, что рынку нужен способ честно считать ROI от ИИ-ассистентов. Tokenmaxxing этот ROI не показывает.
Что говорят четыре независимых исследования
Waydev. Американская engineering-intelligence-платформа (Y Combinator, основана в 2017 году Алексом Чирчеем), работает с 50 клиентами и суммарно охватывает более 10 000 инженеров. CEO Чирчей рассказал TechCrunch: acceptance rate ИИ-кода сразу после генерации — 80–90%, инженеры с радостью принимают предложенные правки. Но через 2–4 недели значительная доля этого кода возвращается на переделку. Реальный acceptance rate после отсечения переписанного — 10–30%.
GitClear. Отчёт за январь 2026-го: регулярные пользователи ИИ-ассистентов показывают в 9,4 раза больший code churn, чем коллеги без ИИ. Если сами инструменты дают условные +20% к продуктивности, то стоимость переделок ИИ-кода съедает эти +20% и ещё столько же сверху — итоговый баланс отрицательный.
Faros AI. В мартовском отчёте 2026 года команда Faros AI проанализировала два года данных по 22 000 разработчиков и 4 000+ команд: при высоком уровне внедрения ИИ code churn (соотношение удалённых и добавленных строк) вырос на 861% относительно команд без ИИ. Это значит, что большая часть нового кода переписывалась в следующие дни-недели.
Jellyfish. Компания измерила 7 548 инженеров в первом квартале 2026-го. Инженеры с самыми большими token-бюджетами действительно делают больше pull request — примерно вдвое больше среднего. Но стоимость этого удвоения — 10-кратный рост трат на токены. Throughput вырос в 2 раза, ценность для продукта — нет.
Почему джуниоры страдают больше сеньоров
Главный паттерн, который отмечают все четыре платформы, — разница в поведении junior- и senior-инженеров. Джуниоры принимают ИИ-код чаще и с меньшим количеством правок в момент генерации. Сеньоры — реже, но с более точечными изменениями по месту.
Последствия тоже разные. У джуниоров большая часть принятого кода возвращается на переделку — им сложнее распознать проблемы на этапе ревью: архитектурные несостыковки, некорректная обработка ошибок, неявные зависимости от глобального состояния. У сеньоров code churn тоже растёт, но они фильтруют ИИ-предложения на входе.
Это создаёт скрытую управленческую ловушку: джуниоры формально показывают хорошие метрики в моменте (много принятых PR, большой token-бюджет освоен), но создают технический долг, который тимлид не видит в еженедельных отчётах. К тому моменту, когда долг вылезает, источник уже трудно отследить.
Что измерять вместо токенов
- Стабильность принятого кода. Считайте, сколько процентов ИИ-кода остаётся в main через 2–4 недели без правок. Быстрый прикид:
git log --since=4.weeks --numstat --author=ci-botплюсgit blameпо ключевым файлам. Если ниже 50% — сигнал о проблеме. - Code churn с разбивкой по источнику. Помечайте ИИ-коммиты в pre-commit хуке (тег
[ai]) и смотрите соотношение добавленных и удалённых строк отдельно для ИИ- и ручного кода. - Time-to-review vs time-to-production. Если ревью ИИ-PR занимает дольше, чем ручное, инструмент не ускоряет команду, а замедляет.
- Bug-rate в ИИ-коде. Привяжите баги к конкретным коммитам через git bisect и смотрите, какая доля из них была сгенерирована ИИ.
- Расходы на токены на единицу пользы. Делите стоимость token-бюджета не на число PR, а на число PR, оставшихся в main спустя месяц. Это и есть честный ROI.
Что это значит для российских команд
Российские компании в 2025–2026 массово заводят корпоративные подписки на Cursor, Claude Code и Copilot, и логика бюджетов часто копирует западную: «дали разработчику 1 млн токенов в месяц — отчитайся». При локальной специфике — оплата через посредников, серый импорт, валютные ограничения — каждый потраченный токен здесь дороже, а значит, цена ошибочной метрики выше.
Альтернатива западным ИИ-IDE в РФ сейчас — GigaCode от Сбера, Алиса про код от Яндекса, а также встраиваемые помощники в отечественных IDE (например, Gigacode plugin для IntelliJ). По качеству они пока отстают от Cursor и Claude Code, но вопрос ROI у них в разы проще — подписки рублёвые и предсказуемые.
Что стоит проверить у себя в команде:
- Соотнесите расходы на ИИ-подписки и реальные SLA-показатели — не окупается ли тариф Cursor Teams только для части инженеров
- Добавьте в ревью пункт «этот код написан ИИ?» и ведите внутреннюю статистику churn по источнику — можно на уровне git-тегов в сообщениях коммитов
- Не выдавайте джуниорам максимальные token-бюджеты как бонус — лучше лимит с возможностью расширения по запросу через тимлида
- Проведите ретроспективу: соберите у инженеров честные кейсы, когда ИИ-код пришлось переписывать, и сравните с ожидаемой экономией
- Для code-review — GitClear и Waydev в РФ напрямую недоступны по оплате; собирайте аналогичные метрики из
git logи GitLab/Bitbucket API вручную
Это новая эра разработки софта, вы должны адаптироваться, вас заставляют адаптироваться как компанию. Это не тот цикл, который пройдёт сам.
Частые вопросы
Что такое tokenmaxxing?
Tokenmaxxing — практика оценивать продуктивность разработчика по размеру token-бюджета, который он потратил в ИИ-ассистенте. В Кремниевой долине большие токен-бюджеты стали символом статуса, но исследования Waydev, GitClear, Faros AI и Jellyfish показали: чем больше токенов тратит инженер, тем выше code churn и технический долг.
Как отличить ИИ-код от ручного в git-истории?
Самый простой способ — договориться о маркировке в сообщении коммита (например, префикс [ai]) и проверять соблюдение в pre-commit хуке. Альтернатива — интеграция с платформой вроде GitClear, которая анализирует характер изменений (скорость набора, паттерны правок) и делает статистическое предположение. Вручную — по характерным признакам: идиомы LLM в комментариях, избыточные защитные проверки, «широкие» изменения в несвязанных местах.
Что такое реальный acceptance rate 10–30%?
Это доля ИИ-генерированного кода, которая остаётся в main без переписывания в следующие 2–4 недели. Первично разработчики одобряют 80–90% предложений ИИ, но значительная часть возвращается на доработку. Результат — реальный вклад в продукт в 3–9 раз меньше, чем заявленный.
Стоит ли отказаться от Cursor и Claude Code?
Нет, исследования не призывают отказаться от инструментов — они призывают правильно их использовать. Инструменты дают реальное ускорение на типовых задачах (CRUD, шаблонный код, тесты). Проблема возникает, когда организация заменяет ими мышление или выдаёт огромные лимиты как перформанс-маркер.
Как измерить ROI от ИИ-ассистентов честно?
Считайте не PR и не токены, а код, который остаётся в main через месяц без правок. Делите стоимость token-бюджета на эту чистую выработку — это и есть настоящий ROI. Инструменты вроде Waydev, GitClear и Faros AI автоматизируют такую аналитику, но те же метрики можно собрать вручную из git-логов через git log --numstat и git blame.
Выводы
ИИ-ассистенты действительно ускоряют часть работы — но не на те цифры, что рисуют в корпоративных презентациях. Когда тимлид ставит KPI в токенах освоенного бюджета, команда начинает играть в tokenmaxxing, а не в качество. Честная метрика — код, который остался в main через месяц, и его стоимость в токенах. Чек-лист на следующий понедельник: открыть git-лог за месяц, прикинуть долю ИИ-коммитов (по меткам или вручную), сравнить с долей, оставшейся в main, — и соотнести с расходами на подписки. Если цифры расстроят — вы не одиноки.
