Greptile: como limitar o loop de revisão com IA

Por que isso importa

Gerar código ficou rápido. Descobrir se ele merece entrar no projeto continua exigindo trabalho. Quando um agente implementa, outro revisa e o primeiro corrige automaticamente, surge uma possibilidade interessante: reduzir o tempo gasto transportando comentários entre ferramentas. Também surge uma armadilha: confundir a concordância entre agentes com uma entrega correta.

Micky relata que a IA escreveu cerca de 95% do código que produziu nos meses anteriores à entrevista. O Greptile entra como revisor, e uma skill chamada greploop conecta seus comentários ao agente que faz as correções. É um relato de uso; a promessa de “100x” do título não vem acompanhada de uma comparação controlada de produtividade.

Minha régua para avaliar esse fluxo seria o trabalho necessário para aceitar uma mudança e mantê-la funcionando. A porcentagem de código gerado pouco diz sobre isso. A proposta abaixo acrescenta ao vídeo um protocolo de avaliação: critérios de aceite escritos antes da implementação, testes que o ciclo não pode enfraquecer, limites de execução e uma conta de custo por PR aprovado.

Pontos principais

• 01:05 A ferramenta ao redor do modelo participa do resultado. Micky apresenta o Cursor como seu ambiente principal. Leitura de arquivos, busca e execução de comandos influenciam o que o agente consegue verificar; trocar apenas o modelo deixa essas diferenças de fora da comparação.
• 04:21 Consultar a implementação ajuda a esclarecer dependências. O recurso apresentado é o opensrc, da Vercel Labs. Seu papel no fluxo é disponibilizar código de bibliotecas para investigação, especialmente quando a integração exige entender detalhes além da interface pública.
• 08:46 O contexto precisa de seleção. A entrevista defende sessões focadas. A implicação prática é indicar arquivos e perguntas relevantes, em vez de despejar o projeto inteiro e esperar que o agente descubra sozinho a prioridade.
• 10:26 Planejar também permite cobrar a entrega. Dividir uma mudança em PRs pequenos torna mais fácil perceber quando a implementação abandonou o objetivo original ou ganhou trabalho que ninguém pediu.
• 13:13 A velocidade pode multiplicar duplicações. O exemplo de adicionar Telegram mostra como um agente pode recriar uma função existente. Uma camada de serviço pode concentrar comportamento compartilhado, desde que preserve as diferenças entre os canais.
• 16:59 A revisão entra como uma etapa própria. Micky apresenta o Greptile e suas notas de confiança. Os comentários associados à nota oferecem material concreto para investigar; o número isolado explica pouco.
• 18:07 O greploop fecha o caminho entre comentário e correção. O agente lê o feedback, altera o código e aguarda nova revisão. Essa automação reduz intervenções repetitivas, mas precisa de condições claras de parada.
• 21:25 O ciclo depende de um resultado verificável. Testes e critérios de conclusão orientam as tentativas. Se o objetivo estiver mal definido, repetir a execução pode apenas consolidar uma interpretação errada.
• 23:35 Svelte é uma escolha pessoal do entrevistado. A justificativa envolve sintaxe familiar e acesso ao código. Isso sugere avaliar a legibilidade da stack para o agente, sem transformar preferência individual em recomendação universal.
• 25:45 Configurações expressas em código ficam mais acessíveis ao agente. Micky usa Convex como exemplo e informa que trabalha na empresa. Essa relação importa ao interpretar sua recomendação do backend.
• 34:28 Lançar aproxima o projeto de problemas reais. A conversa critica o adiamento constante da estreia. Uma aplicação útil dessa ideia é abrir um piloto delimitado, com usuários capazes de relatar falhas.
• 41:36 Dependências também entram na discussão de segurança. Micky propõe esperar 14 dias antes de instalar pacotes novos. Eu trataria esse prazo como uma política possível de redução de exposição, sem presumir que idade comprova segurança.
• 48:12 Experimentar faz parte do aprendizado. A conversa termina defendendo curiosidade diante das ferramentas. Para quem desenvolve, um experimento pequeno e registrado oferece uma base melhor para decidir o próximo investimento.

Como aplicar

Greptile com critérios de aceite antes da nota

Escolha uma mudança pequena em um projeto que você conhece. Um exemplo: receber pedidos por webhook sem criar registros duplicados quando o mesmo evento chega novamente. Evite começar com uma migração inteira ou uma reorganização geral do backend.

Antes de pedir código, escreva comportamentos observáveis:

• Um evento válido cria exatamente um pedido.
• Reenviar o identificador do evento preserva o pedido existente.
• Uma credencial da conta A não permite gravar pedidos na conta B.
• Uma entrada inválida deixa o banco sem alterações.
• Uma falha temporária permite nova tentativa sem duplicação.

Esses critérios precisam existir antes da revisão automática. Assim, você consegue avaliar algo além da capacidade do agente de satisfazer os comentários do revisor.

Dê referências que correspondam ao projeto

Indique o handler atual, a função de persistência, os testes próximos e a versão da biblioteca envolvida. Se houver dúvida sobre o comportamento de uma dependência, consulte sua implementação e a documentação correspondente à versão instalada. O opensrc oficial permite obter fontes de pacotes e repositórios; confira as instruções atuais, pois o funcionamento pode mudar em relação à demonstração.

Código-fonte ajuda a descobrir o que uma implementação faz. A documentação continua útil para entender contratos públicos e usos suportados. Se os dois parecerem discordar, peça ao agente que identifique a divergência com arquivos e versões, antes de criar uma solução alternativa.

Estabeleça um orçamento para o ciclo

O greploop oficial busca uma revisão com confiança 5/5 e nenhum comentário pendente. A versão consultada já estabelece um máximo de cinco iterações. Veja a definição da skill.

Para um primeiro piloto, eu acrescentaria um limite de tempo e um teto de gasto. Três rodadas ou vinte minutos podem servir como parâmetros iniciais de experimento, ajustados à tarefa. Ao atingir qualquer limite, o agente deve apresentar o que corrigiu, quais verificações executou e o que permanece sem solução.

Também interrompa quando duas rodadas repetirem o mesmo problema, quando o agente precisar alterar o critério de aceite ou quando uma correção ampliar o escopo. A parada permite investigar a causa antes de consumir mais tentativas.

Proteja os testes da conveniência do agente

Peça evidência reproduzível para cada defeito relevante: entrada, resultado observado, resultado esperado e teste correspondente. Confira se o teste falha na versão anterior à correção e passa depois, quando isso for viável.

Leia especialmente mudanças que removem asserções, substituem integrações por mocks ou deixam de executar cenários existentes. Um teste pode ficar verde porque deixou de verificar o comportamento importante.

No exemplo do webhook, teste uma repetição sequencial e duas entregas simultâneas. São situações diferentes. Faça também uma conferência manual do resultado persistido usando dados sintéticos. Isso acrescenta uma verificação fora da explicação produzida pelo agente.

Refatore onde houver duplicação demonstrável

Se a mesma regra estiver no webhook e em outro canal, peça ao agente que mostre os trechos e proponha uma função compartilhada. Mantenha autenticação, tradução de entradas e regras específicas dos canais nos lugares apropriados.

Eu separaria essa refatoração em outro PR quando ela aumentasse muito a mudança. Uma revisão focada precisa continuar compreensível para a pessoa que assumirá sua manutenção.

Meça o trabalho até a aprovação

Registre uma pequena amostra de PRs semelhantes, com e sem o ciclo automático. Anote tempo total até a aprovação, minutos de atenção humana, rodadas, gasto adicional, comentários confirmados como defeitos e regressões percebidas depois. A comparação será indicativa: tarefas diferentes não formam um benchmark controlado.

Para uma equipe brasileira, converta os gastos internacionais pelo valor efetivamente cobrado e rateie as assinaturas pelo período do piloto. Uma conta útil é:

custo por PR aprovado = (assinaturas rateadas + cobranças adicionais + custo do tempo humano) ÷ PRs aprovados

Eu continuaria usando o fluxo se ele reduzisse a atenção humana necessária sem aumentar regressões ou dificultar a leitura das mudanças. A aprovação final precisa considerar os critérios de aceite, os testes e o comportamento observado. A nota do Greptile entra nessa decisão como mais uma evidência.