Как понять, что AI-assisted coding действительно эффективен?
По количеству увеличенных релизов с качеством на приемлемом уровне? Звучит логично. Но знаете ли вы, какой ценой это достигается - сколько денег было потрачено на разработку фичи, и почему, например, было потрачено $1,000 в месяц вместо $500?
И как вы понимаете, что в случаях, связанных с:
масштабируемостью, поддерживаемостью и безопасностью
race conditions, сбоями распределённых систем, взаимодействием инфраструктуры, flaky-тестами или производительностью
институциональными/трайбл знаниями
криптографией, auth flows, комплаенс-логикой, финансовыми системами и приватными данными
и при определённых условиях - дедлайнах, качестве, ресурсах - вообще нужно было использовать AI-кодинг?
Неправильное использование AI в таких областях может легко стоить $15,000 в месяц.
Tokenmaxxing и искажённые стимулы
Одновременно многие организации приняли подход tokenmaxxing, который привёл к следующим практикам:
• «Сотрудники Amazon признаются, что используют AI без необходимости, чтобы накрутить внутренние метрики - они жалуются на давление использовать AI-инструменты»
• «Сотрудники Meta использовали 60.2 триллиона AI-токенов за 30 дней; в рамках той же инициативы tokenmaxxing Microsoft также сожгла огромное количество токенов»
• Сообщение, которое получают сотрудники Salesforce: «используйте минимум $170 в месяц в токенах, иначе вы будете помечены»
Другой взгляд на проблему
В то же время другие задают более важные вопросы.
Head of Engineering в Shopify - Farhan Thawar:
«Я хочу понять, почему они потратили, например, $1,000 в месяц на кредиты Cursor. Возможно, они действительно строят что-то значимое и используют агентную модель разработки»
AI Code Pulse: измерение AI-использования в контексте
Эти проблемы решает JIRA app AI Code Pulse
Приложение связывает:
• Token input
• Token output
• Token Cache Create
• Token Cache Read
• Token Cost ($)
с произвольными вложенными иерархиями:
• AI Model (Model → Repo → File → Author → Date)
• Author (Author → Repo → File → Date)
• Repo (Repo → File → Author → Date)
• File (File (repo) → Author → Date)
• Task (Task → Repo → File → Author → Date)
• Epic (Epic → Task → Repo → File → Author → Date)
• Date (Date → Repo → File → Author)
Это позволяет анализировать использование AI не как изолированную сущность, а в контексте инженерной работы.
На скриншоте можно увидеть, как Task (Task → Repo → File → Author → Date) связан с Token Cost ($):
Подходы к анализу стоимости AI
Для анализа можно использовать:
корреляцию JIRA-задач или коммитов с затратами на AI
бенчмаркинг одинаковых классов задач или эпиков
анализ стоимости на уровне репозитория или файла
сравнение паттернов использования AI между инженерами разного уровня
Представление затрат по моделям выглядит следующим образом:
Tokenmaxxing-адепты могут группировать данные по “Authors”, чтобы увидеть общие затраты токенов (или выбрать метрику Total tokens, чтобы увидеть общее потребление токенов авторами).
Однако экономика токенов сама по себе не отвечает на следующий инженерный вопрос.
Даже если токены расходуются эффективно на уровне отдельной задачи - как понять, учитывает ли реализация архитектуру системы и дизайн?
Даже в организациях с сильной инженерной культурой PRы часто становятся перегруженными из-за их плотности или большого количества.
В менее зрелых компаниях ситуация ещё острее: из-за скорости внедрения AI инженеры начинают меньше задумываться о том, как их код влияет на систему в целом и на будущую поддерживаемость.
Многие перестают нормально тестировать, чрезмерно доверяют AI, становятся менее внимательными или просто вынуждены работать в таком режиме, т.к. пушат менеджеры. Сейчас даже появился термин feature factory.
Если убрать SDLC-практики, за что выступает немало людей, очень легко получить технический долг, который придётся оплачивать позже - как это всегда и происходило в инженерии.
Так какой же критерий должен быть?
Rework rate - code waste/survivability и упущенные части имплементации. Этот показатель является одним из немногих важных сигналов для измерения эффективности AI-coding. Его необходимо понимать в контексте компании, но обычно высокий показатель переделки сигнализирует о потраченных впустую токенах, потерянном времени ревьюверов и вычислительных ресурсах, а иногда и о потерянном времени команд QA, DevSecOps, SRE и других.
Даже в Meta, где рефакторинг поощряется, существуют рамки, в которых он допускается.
Высокая частота доработок также часто свидетельствует о наличии существенных ошибок и, следовательно, о репутационных рисках для компании.
Исследовательское подразделение Microsoft выявило один важный момент:
Высокая частота доработок лучше прогнозирует баги, чем многие другие complexity метрики.
Типичные сигналы:
• файлы часто изменяются
• множество разработчиков работают с одним и тем же файлом
• недавние масштабные переработки
Эти сигналы сильно коррелируют с плотностью дефектов.
Ниже представлены две метрики rework rate и PR cycle time:
Как это работает
Data Flow:
Установленный на рабочем месте разработчика трекер AI Code Pulse Tracker (npm) передает данные об AI-coding, но никогда не исходный код или текст promptов.
Детерминированные эвристические алгоритмы в AI Code Pulse связывают использование AI-coding с коммитами из GitHub или Bitbucket.
На данный момент AI Code Pulse поддерживает:
Claude Code
GitHub
Bitbucket
Jira
Если ваш набор инструментов отличается, напишите в комментариях, и я добавлю поддержку в ближайшее время.
Пробный период
Знаете ли вы, что организации теряют 7 часов в неделю на каждого члена команды из-за неэффективности, связанной с AI-coding?
Попробуйте продукт бесплатно, чтобы выявить эти и другие проблемы.