Производительность ИИ-агентов кодогенерации оценивается с помощью двух показателей, которые необходимо анализировать исключительно в связке: количество влитых pull request (PRs merged) и процент отклонений (denial rate) — доля PR, закрытых без слияния в основную ветку. Добавьте к ним время цикла от составления плана до слияния и стоимость одного влитого pull request, и у вас будет исчерпывающая картина того, производят ли агенты качественный результат по экономически оправданной цене. Число открытых pull request — метрика, о которой большинство команд отчитывается в первую очередь, — сама по себе бесполезна: агент может создавать по пятьдесят PR в день, из которых ни один не попадет в кодовую базу, но на графиках это будет выглядеть как бурный прогресс. В этой статье разбирается каждая метрика, объясняются причины ухудшения показателей и показывается, как Ivy Tendril и бесплатный калькулятор от Ivy автоматизируют их сбор.

Метрики

Метрика	Определение	Что означает плохой показатель
Открытые PR	Pull request, созданные за отчетный период	Сам по себе — ничего. Высокий и растущий показатель при стагнирующем слиянии означает, что агенты производят ненужный команде код
Влитые PR	Pull request, успешно влитые (merged) за период	Не меняется или падает при росте числа открытий: код-ревью стало узким местом либо падает качество кода
Процент отклонений	Закрытые без слияния PR, деленные на все закрытые PR (влитые плюс закрытые невлитые)	Высокий: неточные планы, слабая автоматическая верификация или поздний отказ ревьюеров. Близкий к нулю при низком объеме: агентам поручают только тривиальные задачи
Время цикла	Время от генерации плана до финального слияния	Длительное: работа простаивает на ручной контрольной точке. Требуется выяснить, на какой именно
Стоимость влитого PR	Суммарные затраты токенов или долларов за период, деленные на число влитых PR	Растет: частые перезапуски (retries), чрезмерно объемные планы или применение дорогой модели там, где с верификацией справится дешевая
Процент успешных верификаций	Доля выполнений, прошедших тесты, линтинг и сборку с первой попытки	Низкий: планы недостаточно детализированы либо агенту не хватает контекста кодовой базы

Два определения требуют предельной точности. В проценте отклонений в качестве знаменателя используются закрытые PR, а не открытые. Это исключает искажения: открытые pull request, все еще находящиеся на этапе ревью, не считаются преждевременно принятыми или отклоненными. Стоимость одного влитого PR рассчитывается путем деления всех расходов за период (включая затраты на отвергнутые или отмененные планы) строго на число успешно влитых pull request. Это сделано осознанно: стоимость отклоненной работы является неотъемлемой частью стоимости принятого результата.

Почему число влитых PR и процент отклонений — честная пара метрик

Любую изолированную метрику можно искусственно улучшить, ухудшив другую.

Число открытых PR растет, если снизить требования к запуску задач. Процент отклонений закономерно растет вместе с ним.
Число влитых PR растет, если ревьюеры одобряют код поверхностно. Число дефектов после слияния резко подскакивает, а процент отклонений падает по ложной причине.
Процент отклонений падает, если отдавать агентам только примитивные и безопасные планы. Но объем влитых PR при этом стремительно обваливается.

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

Открытые PR привлекают внимание лишь потому, что это первый осязаемый артефакт работы агента, который легче всего посчитать. Однако открытый pull request — это лишь запрос на чужое рабочее время. Восприятие запросов как готового результата поощряет агентов перегружать коллег ревью. Оценка по числу слияний поощряет их доводить работу до конца.

Ivy публикует собственные метрики именно по этому стандарту. График соотношения числа PR в день и процента отклонений на странице Почему Ivy построен на основе 1 946 pull request в репозиториях Ivy за период с февраля по апрель 2026 года. Команда Ivy сообщает о переходе от примерно 10 к более чем 100 pull request в день после внедрения конвейера планирования, исполнения, верификации и ревью, получившего название фабрика ПО (software factory). Показатель объема приводится только рядом с процентом отклонений, поскольку изолированно он не доказывал бы ничего.

Стоимость влитого PR и процент успешных верификаций

После того как слияния и отказы взяты под контроль, стоимость одного влитого pull request показывает фактическую цену принятой работы. Именно этот показатель запрашивает технический директор (CTO), и он должен выражаться в долларах или токенах на одно влитое изменение, а не на один план или отдельный запуск, чтобы учитывать затраты на перезапуски и забракованные ветки.

Стоимость влитого PR также наглядно демонстрирует образование очередей: согласно закону Литтла, растущий объем незавершенных PR при фиксированной скорости слияния неминуемо ведет к росту времени цикла, измеряет его кто-то или нет. На стоимость влитого PR влияют три фактора:

Перезапуски (Retries). Каждая непройденная проверка влечет повторный прогон. Процент успешных верификаций выступает опережающим индикатором: при его падении стоимость влитого PR вырастает уже через несколько дней. В статье Гейты верификации подробно описано, что именно нужно проверять и почему гейт согласования плана важнее остальных.
Размер плана. Объемные планы требуют больше ресурсов на запуск и чаще бракуются, так как у ревьюера возникает больше замечаний. Разделение крупного плана на компактные подзадачи снижает как процент отказов, так и удельную стоимость PR, пусть и ценой увеличения количества проверяемых веток.
Выбор модели. Более дешевая модель, проходящая проверки с той же вероятностью, дает мгновенную экономию. Единственный способ это выяснить — фиксировать затраты и процент прохождения по каждому плану, сравнивая разные модели на одной кодовой базе.

О фундаментальном переходе от учета сырой активности разработчиков к измерению принятого кода читайте в статье In the loop, out of the loop: смена KPI в эпоху разработки с ИИ-агентами.

Как Ivy Tendril отслеживает эти метрики

Ivy Tendril — локальное десктопное приложение (macOS, Windows, Linux), управляющее циклом разработки от плана до проверенного pull request. Оно автоматически собирает статистику по каждой вышеописанной метрике прямо в ходе рабочего процесса. Никаких сторонних систем мониторинга настраивать не требуется.

Dashboard. Dashboard отображает статусы планов на всех стадиях, ключевые финансовые показатели, динамику во времени и активность Git в подключенных репозиториях. Статусы планов дают данные об открытых, влитых и отклоненных PR, а активность Git — проверенную историю слияний.
Стоимость плана и каждой задачи. Расход токенов и финансов фиксируется для каждого плана и для каждого запуска (job) внутри него. Если плану потребовалось три попытки для прохождения проверок, отображаются все три, поэтому стоимость влитого PR изначально включает все перезапуски. Вкладка Jobs показывает потоковый вывод агента и вызовы инструментов одновременно со стоимостью.
Сравнение агентов и моделей. Tendril поддерживает запуск Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode и любых других CLI-агентов, причем агент и модель выбираются индивидуально под каждый план. Это позволяет объективно сопоставлять эффективность моделей на реальном проекте без изменения процессов.
Локальное хранение. Планы, логи и история затрат не покидают компьютер разработчика. Единственные внешние сетевые вызовы направляются к настроенному API модели и к GitHub.

Для команд, которые еще не перешли на Tendril, Ivy предлагает бесплатный инструмент с открытым исходным кодом PR Cost Calculator. Он извлекает публичные данные репозитория из GitHub и вычисляет скользящее среднее за 14 дней для влитых PR и процента отказов, позволяя зафиксировать начальный уровень до старта любых оптимизаций. Запустите его на своем проекте сегодня и повторите замер через месяц после внедрения агентов.

С чего начать

Определите базовую линию: запустите PR Cost Calculator на основном репозитории и зафиксируйте скользящие средние за 14 дней для влитых PR и процента отклонений.
Установите Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) или irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Инструкция по установке доступна в документации.
Запускайте генерацию планов в течение двух недель и анализируйте Dashboard: число слияний, отказов, стоимость плана и тренды.
Рассчитайте удельную стоимость влитого PR вручную (общие расходы, деленные на количество успешных слияний), чтобы команда согласовала методику до того, как цифра войдет в регулярные отчеты.

Tendril бесплатен и доступен в исходных кодах по лицензии Functional Source License. Командные функции, локальное развертывание (on-premise), SSO и интеграция результатов CI входят в тарифы Pro ($59 за пользователя в месяц) и Enterprise.

Часто задаваемые вопросы

Какой процент отклонений считается нормальным?

Универсального ориентира нет, а нулевой показатель обычно означает, что агентам поручают только тривиальные задачи, исключающие любой риск. Отслеживайте динамику внутри своей команды: скачок отказов должен служить сигналом к пересмотру качества формулировки планов и настроек верификации, а не поводом искусственно сокращать число запусков.

Должна ли стоимость влитого PR учитывать время ручного ревью?

Учитывайте его, если можете делать это системно. Большинство команд начинают с прямых затрат на токены и вызовы API, так как они собираются автоматически, а трудозатраты инженеров добавляют позже, когда методика учета устоится. Смешивание показателей без предварительного консенсуса затрудняет сравнение от месяца к месяцу.

Чем эти метрики отличаются от DORA?

Они частично пересекаются. Время цикла от плана до слияния сопоставимо со временем внедрения изменений (Lead Time for Changes). У процента отклонений прямого аналога в DORA нет, поскольку методология DORA исходит из предпосылки, что код пишет человек, и фокусируется на успешности его доставки в прод. Процент отклонений проверяет, было ли изменение в принципе одобрено командой, — а это ключевой вопрос, когда код генерируют автономные агенты.

Начало работы с Ivy Tendril

Готовы к параллельной оркестрации агентов на профессиональном уровне?

Изучить исходный код: Посетите репозиторий Ivy Tendril на GitHub (Open Source).
Читать документацию: Ознакомьтесь с руководствами по интеграции на tendril.ivy.app.
Запланировать консультацию: Напишите на renco@ivy.app для 30-минутной архитектурной сессии.

Измерение производительности ИИ-агентов: влитые PR, процент отклонений и стоимость одного PR