Meça a vazão de agentes de programação por meio de dois números lidos em conjunto: pull requests mescladas (merged) e taxa de rejeição (denial rate), ou seja, a parcela de pull requests fechadas sem serem mescladas. Adicione o tempo de ciclo desde o plano até o merge e o custo por pull request mesclada, e você terá dados suficientes para saber se os agentes estão gerando trabalho aceito a um preço defensável. Pull requests abertas, a métrica que a maioria dos times relata primeiro, não basta por si só: um agente pode abrir cinquenta pull requests por dia que ninguém mescla, e esse número parecerá progresso. Este artigo define cada métrica, explica o que significa um número desfavorável e mostra como o Ivy Tendril e uma calculadora gratuita da Ivy realizam esse acompanhamento.

As métricas

Métrica	Definição	O que indica um resultado ruim
PRs abertas	Pull requests criadas no período	Por si só, nada. Alto e crescente com merges estagnados significa que os agentes produzem trabalho indesejado pelo time
PRs mescladas	Pull requests mescladas no período	Estagnadas ou em queda enquanto as aberturas sobem: a revisão é o gargalo ou a qualidade está caindo
Taxa de rejeição	PRs fechadas sem merge, divididas por todas as PRs fechadas (mescladas mais fechadas sem merge)	Alta: planos incorretos, verificação fraca ou revisores rejeitam tarde. Quase zero com baixo volume: apenas o trabalho mais seguro está sendo tentado
Tempo de ciclo	Tempo desde a criação do plano até a mesclagem	Longo: o trabalho espera em um ponto de controle humano. Descubra em qual
Custo por PR mesclada	Total de tokens ou dólares no período, dividido pelas PRs mescladas	Em alta: novas tentativas (retries), planos superdimensionados ou modelo caro onde um mais econômico passaria na verificação
Taxa de aprovação na verificação	Parcela de execuções que passam em testes, lint e build na primeira tentativa	Baixa: planos subespecificados ou o agente não possui contexto suficiente sobre o código

Duas definições exigem atenção redobrada. A taxa de rejeição utiliza PRs fechadas como denominador — não PRs abertas —, de modo que pull requests abertas ainda em revisão não contem como aceitas nem como rejeitadas. O custo por PR mesclada divide todos os gastos — incluindo o gasto com planos que foram negados ou abandonados — exclusivamente pelas pull requests mescladas. Isso é intencional: o custo do trabalho rejeitado faz parte do custo do trabalho mesclado.

Por que PRs mescladas e taxa de rejeição formam a dupla honesta

Qualquer métrica individual pode ser melhorada à custa de piorar outra.

PRs abertas sobem quando você flexibiliza o que pode ser executado. A taxa de rejeição sobe junto.
PRs mescladas sobem quando os revisores aprovam mais rápido. Os defeitos encontrados após o merge disparam, e a taxa de rejeição cai pelo motivo errado.
A taxa de rejeição cai quando você executa apenas os planos mais triviais e seguros. As PRs mescladas desabam junto.

Este é o mesmo raciocínio por trás das métricas DORA, onde vazão (throughput) e estabilidade são sempre relatadas em par, precisamente porque qualquer uma isolada pode ser manipulada sacrificando a outra. PRs mescladas e taxa de rejeição analisadas em conjunto resistem a isso. Para aumentar as mesclagens sem elevar a rejeição, você precisa produzir mais trabalho que a equipe genuinamente aceite. Para reduzir a rejeição sem diminuir as mesclagens, é preciso aprimorar os planos ou a verificação, em vez de reduzir a execução. Nenhum dos dois números melhora ignorando o outro.

A razão pela qual as PRs abertas são atraentes é que representam o primeiro resultado que um agente entrega e o mais simples de contar. Porém, uma pull request aberta é apenas uma solicitação de tempo de alguém. Contar solicitações como entrega premia os agentes por criar trabalho para os revisores. Contar merges premia-os por concluí-lo com sucesso.

A Ivy publica seus próprios dados dessa maneira. O gráfico de PRs por dia versus taxa de rejeição na página Por que a Ivy é construído a partir de 1.946 pull requests nos repositórios da Ivy entre fevereiro e abril de 2026. A Ivy relata que sua equipe passou de aproximadamente 10 para mais de 100 pull requests por dia após adotar o fluxo de planejar, executar, verificar e revisar, chamado de fábrica de software. O volume é exibido lado a lado com a taxa de rejeição porque, isolado, não provaria absolutamente nada.

Custo por PR mesclada e taxa de aprovação na verificação

Com as métricas de merge e rejeição estabelecidas, o custo por pull request mesclada revela quanto custa o trabalho aceito. Esse é o número exigido por um CTO, e precisa ser mensurado em dólares ou tokens por alteração mesclada — não por plano ou execução individual —, garantindo que reexecuções e trabalhos descartados sejam contabilizados.

O custo por pull request mesclada é também o número que torna as filas visíveis: pela lei de Little, um backlog crescente de pull requests abertas a uma taxa constante de merge significa que o tempo de ciclo está aumentando, quer alguém esteja medindo isso ou não. Três fatores influenciam o custo por PR mesclada:

Tentativas adicionais (Retries). Cada falha na verificação exige uma nova execução. A taxa de aprovação na verificação é o indicador antecedente; quando ela cai, o custo por PR mesclada sobe dias depois. O artigo Portões de verificação aborda o que verificar e por que o portão de plano é o mais importante.
Tamanho do plano. Planos extensos custam mais por execução e são rejeitados com mais frequência, pois o revisor encontra mais motivos para objeções. Dividir um plano grande em partes menores geralmente reduz tanto a taxa de rejeição quanto o custo por PR mesclada, ao preço de um volume maior de pull requests para revisar.
Escolha do modelo. Um modelo mais barato que passe na verificação na mesma proporção representa economia direta. A única forma de comprovar é rastrear custo e taxa de sucesso por plano, comparando modelos na mesma base de código.

Para entender a transição mais ampla da medição de esforço do desenvolvedor para a entrega aceita, consulte In the loop, out of the loop: a mudança de KPIs na engenharia com agentes.

Como o Ivy Tendril rastreia esses indicadores

O Ivy Tendril é um aplicativo desktop local-first (macOS, Windows, Linux) que gerencia agentes de código desde o plano até a pull request revisada, registrando dados de cada métrica acima como consequência direta do fluxo de trabalho. Nada precisa ser instrumentado separadamente.

Dashboard. O Dashboard exibe o status dos planos ao longo do ciclo de vida, KPIs de custo, gráficos de tendência ao longo do tempo e atividade Git dos repositórios conectados. O status do plano fornece PRs abertas, mescladas e rejeitadas; a atividade Git traz o histórico de merges.
Custo por plano e por tarefa (job). Tokens e custos são monitorados para cada plano e para cada job dentro dele. Um plano que exigiu três execuções antes de passar na verificação exibe as três, de modo que o custo por PR mesclada inclui as novas tentativas por construção. A visualização Jobs apresenta o streaming de logs e as chamadas de ferramentas de cada tarefa ao lado de seu custo.
Comparação entre agentes e modelos. O Tendril opera com Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode e qualquer outro agente CLI, permitindo escolher o agente ou modelo por plano. Custos e taxa de aprovação podem ser comparados entre modelos na mesma base de código sem alterar o fluxo.
Dados locais. Planos, logs e registros de custo permanecem na sua máquina. As únicas chamadas externas são para a API do modelo configurado e para o GitHub.

Para equipes que ainda não utilizam o Tendril, a Ivy disponibiliza uma PR Cost Calculator gratuita e de código aberto. Ela lê dados públicos do GitHub e calcula médias móveis de 14 dias para PRs mescladas e taxa de rejeição, permitindo estabelecer a linha de base antes de qualquer mudança. Execute-a hoje em seu repositório e repita a medição um mês após a introdução de agentes.

Como começar

Obtenha a linha de base. Execute a PR Cost Calculator em seu repositório principal e registre as médias móveis de 14 dias de PRs mescladas e taxa de rejeição.
Instale o Tendril: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) ou irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Documentação em instalação.
Execute planos por duas semanas e avalie o Dashboard: mescladas, rejeitadas, custo por plano e tendências.
Calcule manualmente o custo por PR mesclada uma vez, dividindo os gastos totais pelo número de mesclagens, para que a equipe concorde sobre a definição antes que ela se torne um relatório formal.

O Tendril é gratuito e com código disponível sob a Functional Source License. Recursos para times, hospedagem local (on-premise), SSO e importação de verificações de CI estão disponíveis nos planos Pro ($59 por usuário/mês) e Enterprise.

Perguntas frequentes

Qual é uma boa taxa de rejeição?

Não existe uma meta universal, e uma taxa de zero por cento geralmente significa que nenhum trabalho com risco real está sendo tentado. Acompanhe sua taxa ao longo do tempo e encare um aumento como um alerta para revisar a qualidade dos planos e da verificação, não como uma métrica a ser reduzida diminuindo execuções.

O custo por PR mesclada deve incluir o tempo de revisão humana?

Inclua se você puder mensurá-lo de forma consistente. A maioria das equipes começa com tokens ou gastos diretos com modelos por serem registrados automaticamente, e adiciona o tempo do revisor após consolidar o método. Misturar os dois sem alinhamento prévio dificulta a comparação mês a mês.

Como essas métricas se diferenciam das métricas DORA?

Elas se sobrepõem. O tempo de ciclo do plano ao merge é muito próximo do lead time for changes. A taxa de rejeição não tem equivalente direto em DORA, pois DORA presume que um desenvolvedor humano escreveu o código e pergunta se ele foi implantado. A taxa de rejeição questiona se a alteração foi sequer aceita, o que se torna a pergunta mais crítica quando agentes geram as propostas.

Primeiros passos com o Ivy Tendril

Pronto para a orquestração paralela de agentes em nível de engenharia?

Explore o código: Confira o Ivy Tendril no GitHub (Código aberto).
Consulte a documentação: Encontre guias de integração em tendril.ivy.app.
Agende uma sessão técnica: Entre em contato pelo e-mail renco@ivy.app para uma consultoria de arquitetura de 30 minutos.

Medindo a vazão de agentes de código: PRs mescladas, taxa de rejeição e custo por PR