Faturamento por usuário transforma uma revisão de código de 60 centavos em US$ 4

Faça a divisão na sua conta de revisão de código com IA. Não o preço de tabela, a divisão real: o que você pagou no mês passado, dividido pelo número de pull requests que ela revisou. Eu fiz isso para o nosso time e o número foi tão pior do que o número na página de preços que achei que tinha cometido um erro.

Eu não tinha cometido um erro. Eu só estava comprando o produto da forma como ele foi vendido para mim, em vez da forma como o usamos.

Aqui está a tese, e tudo depois disso é evidência para ela. A revisão de código com IA é vendida por desenvolvedor e consumida por pull request. Esses dois números não têm nada a ver um com o outro, e a lacuna entre eles é para onde seu dinheiro vai. Separadamente, e pior, a ferramenta pela qual estávamos pagando leu um diff com seis defeitos reais e encontrou um.

Nós a substituímos por algo que construímos. Vou mostrar os recibos para ambas as afirmações, incluindo as partes que nos fazem parecer piores.

Seis defeitos entraram. Um saiu.

O pull request era um refactor de autosave na nossa plataforma. Comum, de tamanho médio, do tipo que é aberto numa terça-feira e ninguém perde o sono por causa dele. A Greptile o revisou, deixou dois comentários e seguiu em frente.

Depois, um dos nossos engenheiros examinou o diff manualmente e o avaliou adequadamente, anotando cada defeito genuíno sem olhar para qual ferramenta havia reportado o quê. Seis defeitos. Quatro deles P1, do tipo que corrompe dados do usuário em vez de incomodar alguém.

O autosave se rearmava para sempre após normalizar valores. Um save falhou e tentou novamente em um loop infinito. O autosave sobrescreveu o que o usuário estava digitando ativamente em outra aba. Uma promise de save foi descartada sem tratamento. Sair da página descartou tudo que estava pendente. O botão de save renderizava apenas quando o passo não podia ser salvo.

Um desses seis foi reportado.

Nenhum desses seis chegou à produção, e quero ser preciso sobre o porquê, porque a razão é o ponto central. Eles foram pegos porque um humano leu o diff. Não porque o revisor os impediu. Estávamos pagando por uma rede de segurança que pegou uma coisa em seis, e a coisa que pegou as outras cinco foi um engenheiro lendo o código linha por linha, que é exatamente a atividade que o produto existe para reduzir.

Estar confiantemente errado é pior do que não dizer nada

Houve um sétimo achado. Não era real.

Nos foi dito “autosave falhou não tem retry.” O defeito real, na mesma função, era o oposto: autosave falhou tentava para sempre. Não um bug perdido. Um invertido.

Pensei mais sobre esse do que sobre os cinco erros combinados. Um erro é silêncio, e silêncio é suportável, porque você já assume que seu revisor não é onisciente. Uma inversão é pior que silêncio. Ela envia um engenheiro para o arquivo correto procurando a coisa errada, e quando ele não encontra a coisa que nunca esteve lá, ele fecha o arquivo e marca como revisado. Um relatório falso não apenas falha em ajudar você. Ele gasta sua atenção, e a gasta exatamente no lugar onde o bug real estava escondido.

Um achado real. Um achado invertido. Seis defeitos no diff.

Um modelo significa um ponto cego, e você nunca aprenderá sua forma

Minha primeira reação foi que tínhamos comprado a ferramenta errada. Essa reação estava errada, e superá-la levou mais tempo do que gostaria de admitir.

Todo modelo de fronteira tem pontos cegos e eles não são os mesmos pontos cegos. Isso não é um defeito no produto de nenhum fornecedor em particular, é o que esses sistemas são. O que significa que se você construir seu processo de revisão em exatamente um modelo, você o construiu em exatamente um padrão de cegueira, e você nunca aprenderá a forma desse padrão, porque o único instrumento que poderia mostrá-lo a você é o instrumento que é cego.

Deixe-me explicar isso. O problema não é que seu revisor é ruim. O problema é que seu revisor é singular. Uma segunda opinião nunca foi um luxo na revisão de código, era o mecanismo inteiro pelo qual a revisão de código funcionava, e nós silenciosamente a descartamos no momento em que a automatizamos.

Então construímos o Juror. Vários modelos de fronteira revisam o mesmo diff em paralelo, cada um através de seu próprio harness de agente nativo, cada um livre para pesquisar seu repositório da forma que seu fornecedor pretendia. Seus achados colapsam, então três relatórios quase duplicados de um defeito se tornam um achado em vez de três, e o que chega no pull request é um único comentário.

Executamos contra o mesmo commit.

Revisor	Encontrados	Precisão	Custo	Tempo
Greptile	1 de 6	50%	não divulgado	não divulgado
Juror	4 de 6	100%	$1,08	8m22s

Aqui está a parte onde perdemos

O Juror perdeu dois.

A Greptile pegou a promise de save descartada e nós não. Nenhuma ferramenta encontrou o loop infinito de retry. Juntando ambos os revisores, você obtém cinco de seis, o que é melhor do que qualquer um conseguiu sozinho, e não vou enterrar isso debaixo da tabela acima.

Eu poderia ter cortado esta seção. Estou mantendo porque ela é o argumento. Modelos diferentes pegam coisas diferentes. Isso não é uma ressalva estranha grampeada ao nosso pitch, é o pitch, e o modelo de um concorrente encontrar algo que o nosso perdeu é a demonstração mais clara disponível de que executar um único revisor é o erro. O dia em que isso parar de acontecer é o dia em que começarei a me preocupar que nosso júri colapsou em uma única opinião usando quatro chapéus.

Você não está pagando por revisões. Você está pagando por cadeiras.

Agora a conta, que é onde isso para de ser sobre um pull request.

O plano Pro da Greptile é $30 por assento por mês, a partir de agosto de 2026. Isso inclui 50 créditos por assento, onde um crédito compra uma revisão padrão e três compram uma mais profunda, e créditos adicionais são $1 cada.

Por revisão, isso é barato. Cerca de sessenta centavos, se você usar todos os créditos que recebe. Quero ser totalmente justo aqui: numa base por unidade, isso é mais baixo do que o custo da nossa própria ferramenta na pull request acima. Uma equipe pequena que consome totalmente sua cota deve comprar as licenças, e não vou fingir o contrário.

Ninguém consome totalmente sua cota.

Você é cobrado por desenvolvedor. Você consome revisões por pull request. Esses dois números deixam de se alinhar no momento em que o número de funcionários cresce mais rápido que a taxa de merge, ou seja, imediatamente, em toda organização de engenharia que já existiu. Vinte engenheiros no Pro custam $600 por mês e mil créditos. Se essa equipe faz merge de 150 pull requests, um mês completamente normal, você pagou $4 por revisão e deixou 850 créditos expirarem.

O preço de tabela nunca mudou. Sua utilização mudou. Sessenta centavos se tornaram quatro dólares e ninguém te enviou um e-mail sobre isso.

Chame isso de imposto da licença: dinheiro gasto em uma licença por desenvolvedor para um produto consumido por artefato. É invisível na página de preços, escala com contratações em vez de uso, e é o maior item de custo no que você realmente paga.

Posso te dizer quanto isso custou porque imprimimos o recibo

Juror não tem licenças. Ele roda no seu próprio runner do GitHub Actions, chama as APIs dos modelos com suas próprias chaves, e a conta é a inferência e nada mais. Aquela revisão da PR de autosave, quatro defeitos reais e nenhum falso positivo, custou $1.08 e levou oito minutos e vinte e dois segundos.

Posso te dizer isso ao centavo porque toda revisão do Juror termina com uma tabela: cada modelo, seus tokens de entrada, seus tokens em cache, seus tokens de saída, seus dólares. Cada valor é rotulado como reported quando o provedor o calculou, ou estimated quando derivamos dos preços de tabela publicados. Quando um harness não nos dá nenhum dos dois, ele imprime unknown e o total é marcado como um limite inferior. Não chutamos e não arredondamos a nosso favor.

Agora olhe novamente para as duas células naquela tabela que dizem “não divulgado”. Isso não é uma lacuna na minha pesquisa. A ferramenta não te diz quanto uma revisão custou, porque não precisa. Você comprou uma licença. A economia unitária é problema do fornecedor, e o fornecedor prefere que você continue fazendo a multiplicação do jeito deles.

Essa era a coisa que eu realmente queria e não consegui comprar por nenhum preço. Não um revisor mais barato. Um revisor que me dissesse o que gastou.

O que não vou fazer é chamar isso de benchmark

Esta é uma pull request. Nosso próprio protocolo de benchmarking diz que uma decisão de substituição precisa de 20 a 30 PRs julgadas abrangendo frontend, backend, migrações, concorrência, código sensível à segurança, e diffs pequenos e grandes. Temos uma. Ela está no repositório com um aviso anexado dizendo que não deve ser apresentada como evidência estatisticamente suficiente de que qualquer revisor pode substituir o outro, e não vou violar nosso próprio aviso dentro de um post de blog sobre o quão cuidadosamente reportamos números.

Quatro de seis contra um de seis não é um resultado de benchmark. É um caso julgado que me fez ficar disposto a executar ambos lado a lado. Uma pull request diferente, uma que dependa fortemente de contexto do repositório onde um revisor indexado deve se sair bem, poderia plausivelmente inverter isso. Se acontecer, esse caso também entra no corpus.

O que não é uma amostra de um é a aritmética. Trinta dólares por licença vezes vinte engenheiros são $600, quer eu goste ou não, e 150 revisões contra mil créditos são 15% de utilização em qualquer mês que você queira medir. Mudamos com base na estrutura de preços, que posso defender com divisão, e em um caso promissor. Não com base em uma alegação de desempenho que ainda não conquistamos.

Venha nos medir

Não acredite na minha palavra para nada disso. Tenho um interesse comercial na sua conclusão e você deve ponderar tudo acima de acordo.

Coloque ambos os revisores em modo shadow no seu próprio repositório. Deixe-os rodar por algumas semanas sem que nenhum bloqueie um merge. Então pegue cada descoberta, remova os rótulos para que ninguém saiba qual ferramenta disse o quê, e peça a um engenheiro sênior para julgá-los a frio contra o código. Conte o que cada um pegou. Conte o que cada um inventou.

Enviamos as ferramentas exatamente para isso, porque nós mesmos precisávamos:

npx juror-ai benchmark --file your-corpus.json

Ele reporta recall, precisão, taxa de duplicatas, custo e latência para cada revisor que você alimenta, e lista cada erro pelo nome. O nosso incluído.

Não acho que o modelo de licenças sobreviva ao contato com alguém que faça a divisão. Ele sobrevive agora porque a divisão é levemente irritante e a página de preços é organizada para que você não se incomode. Alguém na sua organização faz esse cálculo eventualmente. Quando fizer, a resposta não será sessenta centavos.

Aquela pull request de autosave foi mergeada esta manhã, aliás. Foram necessários mais dois commits para chegar lá, um para tornar os saves de navegação single-flight e outro para fazer o autosave convergir e deixar o builder em paz. Bons commits. Nada pegando fogo.

Ninguém jamais saberá que eles foram necessários, porque bugs pegos antes do merge não deixam rastro e não geram relatório de incidente. Essa é a parte disso que deveria te incomodar. O revisor que perdeu cinco deles custa o mesmo quer encontre seis ou zero, e nunca te dirá por qual desses dois meses você acabou de pagar.

---

Juror é open source e licenciado sob MIT: github.com/juror-ai/juror. Preços do Greptile citados de greptile.com/pricing em agosto de 2026.