Cobrança por assento transforma uma revisão de código de 60¢ em $4

Faça a divisão na sua conta de revisão de código com IA. Pegue o que você pagou no mês passado e divida pelo número de pull requests que a ferramenta realmente revisou. O preço de tabela é um número diferente, e é esse que você decorou. Fiz a divisão para o nosso time e cheguei a um número tão distante da página de preços que achei que tinha errado a conta.

A aritmética estava certa. Eu estava comprando o produto do jeito que ele é vendido e usando do jeito que a gente realmente trabalha, e essas duas coisas acabam sendo produtos diferentes.

Aqui está a tese, e tudo depois disso é evidência a favor dela. 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 é no espaço entre eles que o seu dinheiro vai. Separadamente, e pior, a ferramenta que estávamos pagando leu um diff com seis defeitos reais e encontrou um.

Substituímos por algo que construímos. Vou mostrar os recibos das duas 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 revisou, deixou dois comentários e seguiu em frente.

Depois, um dos nossos engenheiros passou pelo diff manualmente e fez a avaliação direito, anotando cada defeito real sem olhar qual ferramenta tinha reportado o quê. Seis defeitos. Quatro deles P1, do tipo que corrompe dados do usuário em vez de só incomodar alguém.

O autosave se rearmava para sempre depois de normalizar valores. Uma falha de salvamento tentava de novo em loop infinito. O autosave sobrescrevia o que o usuário estava digitando ativamente em outra aba. Uma promise de salvamento era descartada sem tratamento. Sair da página perdia tudo que estava pendente. O botão de salvar só aparecia 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ê. Um engenheiro sentou e leu o diff linha por linha. O revisor já tinha ido embora. Estávamos pagando por uma rede de segurança que pegou uma coisa em seis, e as cinco que ela deixou passar foram pegas exatamente pela atividade que o produto existe para reduzir.

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

Houve um sétimo achado. Ele não era real.

Nos disseram que “autosave com falha não tem retry”. O defeito naquela mesma função apontava na direção oposta: autosave com falha tentava de novo para sempre. A ferramenta tinha a direção invertida.

Pensei mais nesse do que nas cinco falhas juntas. Uma falha é silêncio, e silêncio é suportável, porque você já parte do princípio de que seu revisor não é onisciente. Uma inversão é pior que silêncio. Ela manda um engenheiro para o arquivo certo 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 relato falso gasta sua atenção, e 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 vai aprender o formato dele

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

Todo modelo de fronteira tem pontos cegos, e não existem dois modelos com os mesmos. Todo fornecedor entrega essa propriedade, porque é isso que esses sistemas são. Então, se você constrói seu processo de revisão em exatamente um modelo, você o construiu em exatamente um padrão de cegueira, e nunca vai aprender o formato desse padrão, porque o único instrumento que poderia mostrá-lo é o instrumento que é cego.

Vou explicar melhor. Compre o melhor revisor do mercado e você comprou um padrão de cegueira a preço cheio. Revisão de código funcionava, em primeiro lugar, porque uma segunda pessoa olhava o diff. Esse era o mecanismo inteiro, e nós o abandonamos na semana em que automatizamos.

Então construímos o Juror. Vários modelos de fronteira revisam o mesmo diff em paralelo, cada um através do seu próprio harness de agente nativo, cada um livre para buscar no seu repositório do jeito que o fornecedor pretendia. Os achados são consolidados, então três relatos quase duplicados de um defeito chegam no pull request como um único comentário.

Rodamos contra o mesmo commit.

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

Aqui é a parte em que perdemos

O Juror errou dois.

A Greptile pegou a promise de salvamento descartada e nós não. Nenhuma das duas ferramentas encontrou o loop infinito de retry. Junte os dois revisores e você chega a cinco de seis, o que é melhor do que qualquer um deles sozinho, e não vou enterrar isso embaixo da tabela acima.

Eu poderia ter cortado esta seção. Estou mantendo porque ela é o argumento. Modelos diferentes pegam coisas diferentes, e um modelo concorrente encontrar algo que o nosso errou é a demonstração mais limpa disponível de que rodar um único revisor é o erro. O dia em que isso parar de acontecer é o dia em que começo a me preocupar que nosso júri virou uma opinião só usando quatro chapéus.

Sua fatura acompanha o headcount. Suas revisões acompanham merges.

Agora a fatura, que é onde isso deixa de ser sobre um pull request.

O plano Pro da Greptile custa US$ 30 por assento por mês, em 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 custam US$ 1 cada.

Por review, isso é barato. Aproximadamente sessenta centavos, se você usar todos os créditos que recebe. Quero ser totalmente justo aqui: por unidade, isso é mais barato do que nossa própria ferramenta custou no pull request acima. Um time pequeno que consome totalmente sua cota deveria comprar os assentos, e não vou fingir o contrário.

Ninguém consome totalmente sua cota.

Você é cobrado por desenvolvedor. Você consome reviews por pull request. Esses dois números param de acompanhar um ao outro no momento em que o headcount 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 esse time faz merge de 150 pull requests, um mês completamente normal, você pagou $4 por review e deixou 850 créditos expirarem.

Sua utilização mudou e o preço de tabela não, então sessenta centavos viraram quatro dólares e ninguém te mandou um e-mail sobre isso.

Chame de imposto do assento: 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 dizer quanto isso custa porque imprimimos o recibo

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

Posso dizer isso ao centavo porque todo review 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 de preços de tabela publicados. Quando um harness não nos dá nenhum dos dois, ele imprime unknown e o total é marcado como limite inferior. Não adivinhamos e não arredondamos a nosso favor.

Agora olhe de novo para as duas células naquela tabela que dizem “not disclosed.” Fui procurar esses números e eles não estão publicados em lugar nenhum. A ferramenta não te diz quanto um review custou porque não precisa. Você comprou um assento. A economia unitária é assunto do fornecedor, e o fornecedor prefere que você continue fazendo a multiplicação do jeito deles.

Um reviewer que imprime sua própria conta é a coisa que eu queria e não conseguia comprar por nenhum preço.

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

Este é um pull request.

Nosso próprio protocolo de benchmarking diz que uma decisão de substituição precisa de 20 a 30 PRs adjudicados cobrindo frontend, backend, migrações, concorrência, código sensível a segurança, e diffs pequenos e grandes. Temos um. Ele está no repositório com um aviso anexado dizendo que não deve ser apresentado como evidência estatisticamente suficiente de que qualquer um dos reviewers pode substituir o outro, e não vou violar nosso próprio aviso dentro de um post de blog sobre como reportamos números com cuidado.

Quatro de seis contra um de seis é um caso adjudicado. Isso me deixou disposto a rodar ambos os reviewers lado a lado, e esse é todo o peso que pode carregar. Um pull request diferente, um que dependa fortemente de contexto do repositório inteiro onde um reviewer indexado deveria se sair bem, poderia plausivelmente inverter o resultado. Se acontecer, esse caso entra no corpus também.

A aritmética é a parte que sobrevive a uma amostra de um. Trinta dólares por assento vezes vinte engenheiros é $600, goste eu ou não, e 150 reviews contra mil créditos é 15% de utilização em qualquer mês que você queira medir. Mudamos a estrutura de preços, o que posso defender com divisão, e um caso promissor. A afirmação de desempenho é a que ainda não conquistamos, então não vou fazê-la.

Vá nos medir

Não acredite em mim por nada disso. Tenho interesse comercial na sua conclusão e você deve ponderar tudo acima de acordo.

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

Enviamos a ferramenta exatamente para isso, porque precisávamos dela nós mesmos:

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

Ela reporta recall, precisão, taxa de duplicatas, custo e latência para cada reviewer que você alimentar, e lista cada erro pelo nome. Os nossos incluídos.

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

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

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

---

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