Como criar um agent de revisão de código com IA — Daksh Gupta, Greptile

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How to Build an AI Code Review Agent - Daksh Gupta, Greptile · Canal: AI Engineer · 18:01 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Modelos de IA

Resumo

Daksh Gupta explica como criar um agent que revisa e testa pull requests, destacando os desafios de detectar bugs, compreender o contexto do código e controlar custos. Ele recomenda melhorar o prompt, avaliar o agent com pull requests históricos e usar um modelo diferente daquele que gerou o código. Também aborda a criação de uma base de conhecimento da codebase, o acesso a documentação e tickets e a execução de testes em sandboxes. Por fim, sugere distribuir as tarefas entre modelos de diferentes capacidades para reduzir custos sem comprometer a qualidade.

Pontos-chave

• Um protótipo básico pode receber pull requests por webhook, enviar o conteúdo a um agent em uma sandbox e publicar comentários de revisão, mas tende a deixar passar bugs e contexto importante.
• O prompt deve orientar a busca por tipos específicos de bugs relevantes para a empresa e instruir explicitamente o agent a evitar comentários excessivamente minuciosos.
• Pull requests históricos associados a incidentes ajudam a medir e ajustar a capacidade do agent de detectar bugs.
• Usar um modelo diferente para revisar o código pode ajudar a detectar falhas que o modelo gerador tende a reproduzir.
• Uma base de conhecimento indexada da codebase pode oferecer contexto mais preciso e reduzir leituras desnecessárias de arquivos.
• Documentação, tickets e informações sobre a aplicação ajudam o agent a entender a intenção por trás das mudanças.
• Testes autônomos em sandboxes podem verificar fluxos da aplicação de ponta a ponta, inclusive problemas visuais em dispositivos específicos.
• Modelos menores podem ser usados em tarefas exploratórias e de seleção de contexto, reservando modelos mais capazes para tarefas críticas.

Capítulos

Início	Capítulo	Resumo
00:01	O que faz um agent de revisão de código	Daksh Gupta apresenta a Greptile e os três aspectos que diferenciam seu produto: contexto da codebase, execução de código e alocação eficiente de inference.
03:08	Protótipo inicial e problemas comuns	O palestrante descreve uma implementação simples com sandbox e webhook e os problemas de bugs não detectados, contexto insuficiente, custo e comentários minuciosos.
06:11	Prompts e avaliação com pull requests históricos	Ele recomenda direcionar o prompt a bugs específicos e usar dados históricos para avaliar se o agent detecta falhas relevantes.
08:47	Inverter o modelo e melhorar o contexto da codebase	A palestra aborda o uso de modelos diferentes para geração e revisão e a criação de uma base de conhecimento para tornar a busca de contexto mais precisa.
11:21	Documentação, tickets e testes autônomos	O agent pode usar conhecimento da codebase, documentação e tickets para compreender a intenção, além de testar fluxos em sandboxes.
14:26	Testes de ponta a ponta	O palestrante explica como executar a aplicação em sandboxes e usar visão computacional para identificar problemas nos fluxos e na interface.
17:00	Alocação de modelos e controle de custos	Ele recomenda usar modelos menores em tarefas menos críticas e modelos mais capazes para análise de bugs, validando as escolhas com dados.

Citações

Procure tipos específicos de bugs e ignore os comentários minuciosos. — 06:11

Os tipos de bugs produzidos pelos modelos Claude e Codex são bem diferentes. — 09:17

O grep é extremamente impreciso e caro. — 11:21

Pela primeira vez, acho que o QA de ponta a ponta está quase resolvido. — 14:56

Conceitos e entidades

• Greptile (empresa): Empresa que desenvolve agents para revisar e testar pull requests com contexto da codebase.
• Daksh Gupta (pessoa): Co-fundador da Greptile e palestrante sobre a criação de agents de revisão de código.
• pull request (conceito): Proposta de alteração de código que o agent analisa e testa.
• sandbox (conceito): Ambiente isolado usado para executar código e testar a aplicação.
• OpenCode (ferramenta): Harness open source mencionado como opção para criar um agent independente de modelo.
• Pi (ferramenta): Harness open source citado como alternativa para implementar o agent.
• Claude Code (ferramenta): Ferramenta de programação mencionada como exemplo de agent que pode gerar o código revisado.
• Codex (modelo): Modelo citado como exemplo de opção para escrever ou revisar código.
• RAG (conceito): Abordagem mencionada para recuperar contexto de codebases grandes.
• Jira (ferramenta): Ferramenta de tickets cujo conteúdo pode fornecer contexto ao agent.
• Linear (ferramenta): Ferramenta de tickets citada como fonte de contexto sobre o trabalho e o roadmap.
• Confluence (ferramenta): Ferramenta de documentação citada como fonte de conhecimento para o agent.
• Notion (ferramenta): Ferramenta de documentação mencionada como fonte de contexto.

Tradução completa (pt-BR)

00:01 [música] >> Certo, meu nome é Dax. Sou um dos cofundadores de uma empresa chamada Greptile, e criamos agents que revisam e testam pull requests com todo o contexto da base de código. Ao revisar e testar esses pull requests, identificamos bugs, erros lógicos e problemas de qualidade de código, principalmente no código gerado por IA.

00:32 Para dar uma ideia da escala, milhares de empresas usam a Greptile todos os dias. Cerca de 1% de todos os pull requests no GitHub passam por nós, em uma grande variedade de bases de código, seja a base de código CUDA da Nvidia, a base de código da carteira da Coinbase ou muitas outras. De vez em quando, encontramos uma empresa para a qual não somos o produto certo de revisão ou teste de código. As necessidades dela são tão especializadas e tão esotéricas que, na verdade, é vantajoso criar uma solução própria. Quando isso acontece, costumamos ajudá-la

01:03 de graça. Há dois motivos para isso. Primeiro, temos bastante conhecimento especializado sobre como fazer isso muito, muito bem. Segundo, temos a oportunidade de aprender bastante sobre como podemos atender clientes como esses no futuro. Nesta apresentação, quero contar o que dizemos a eles: como criar por conta própria um ótimo agent de revisão de código com IA. Há, por assim dizer, três coisas de que as pessoas gostam na Greptile, e vou explicar como implementá-las por conta própria. A primeira é o contexto da base de código. Quando os clientes usam a Greptile em seus pull requests, percebem que ela realmente entende a base de código.

01:35 Na verdade, antes de sermos uma empresa de validação de código, éramos uma empresa de contexto de bases de código. Ensinávamos modelos de linguagem de 2023 a entender bases de código muito grandes e, por isso, ficamos muito bons em indexar código. A segunda coisa de que as pessoas gostam na Greptile é que ela executa seu código, no sentido de iniciar sua stack em um sandbox totalmente equipado e com muitas dependências, e navegar por ela e testar coisas usando computer use, testando os endpoints da API sob pressão, entre outras coisas. A terceira coisa é que somos muito eficientes na alocação de inference. Escolhemos o modelo certo e a quantidade certa de orçamento de inference para cada

02:06 subtask no processo de revisão e validação. Como resultado, conseguimos muito mais desempenho por dólar do que uma ferramenta interna ou qualquer concorrente. Há, por assim dizer, dois motivos para assistir a esta apresentação. O primeiro é que você quer criar seu próprio agent de revisão. O segundo, um pouco mais sutil, é que você está tentando escolher um agent de revisão ou de testes para sua empresa e quer entender o que faz um bom agent e o que faz um ótimo agent. Certo. Vamos começar. Agora,

02:37 imagine que você está começando do zero. Você faz parte da equipe de plataforma da sua empresa ou é simplesmente a pessoa da equipe obcecada por IA, e quer criar o validador de revisões da empresa. As empresas estão escrevendo muito código. As pessoas estão fazendo vibe coding. É claro que os engenheiros estão fazendo vibe coding. Algumas delas estão chegando perto demais do sol. Você também tem pessoas de marketing escrevendo código. E o novo problema é o gargalo de revisão, o gargalo de validação. É disso que você quer tratar. A primeira coisa que deve fazer é conseguir um sandbox. Há muitas, muitas empresas que

03:08 vão vender um sandbox para você. Você também pode simplesmente usar o firecracker ou algo assim. E vai querer colocar um agent nesse sandbox. O agent pode ser o Codex ou o Claude Code. Pessoalmente, recomendo não depender de um único modelo, por motivos que vou explicar, então você pode usar algo como OpenCode ou Pi como seu harness. Ambos são open source. Depois, você precisará conectar seu GitHub ou GitLab. Configure um webhook de PR para enviar o conteúdo de um pull request ao agent sempre que um pull request for aberto. O agent pode receber algum tipo de prompt que simplesmente diga: “Ei, revise isto e envie alguns comentários de volta”. Depois, você pode enviar esses comentários de volta usando as APIs de revisão do GitHub.

03:39 Muito simples. Na verdade, muita gente acha que isso é tudo o que é preciso para criar um agent de revisão. Algumas coisas vão dar errado quando você começar a usar isso. Mas o que vai acontecer é que um pull request será aberto. O conteúdo será enviado a um agent e, cerca de cinco minutos depois, você receberá alguns comentários sobre seu pull request. Mas veja o que vai dar errado durante a construção disso. A primeira coisa é que você vai deixar passar muitos bugs. Acontece que os bugs são interativamente grandes. Na verdade, vi um tuíte há pouco tempo dizendo que os bugs são

04:09 fractalmente infinitos. Portanto, você nunca vai ficar sem bugs em um trecho específico de código. Essa é a primeira coisa que vai dar errado: você vai deixar bugs passar. É claro que a principal função do seu sistema é evitar pelo menos interrupções e incidentes muito catastróficos. A segunda coisa que vai acontecer é que ele vai deixar passar o contexto e entender errado partes do funcionamento da sua base de código. Talvez não entenda para onde você está levando a base de código. Não entenda como uma parte específica dela funciona. Talvez não entenda como uma das suas bibliotecas funciona. É possível que sua empresa seja uma daquelas que nunca se recuperaram do apocalipse dos microsserviços dos anos 2010

04:39 e, por isso, simplesmente tenha milhares e milhares de repos e precise do contexto de todos eles para conseguir operar. Essa é a segunda coisa que vai dar errado. A terceira é que vai ficar muito caro. Acho que as pessoas ficam bastante surpresas com isso. Em geral, quem já tentou fazer isso percebe que gasta entre US$ 3 e até US$ 25 por pull request para revisá-lo usando coding agents. Esses tokens podem se acumular muito, muito rápido. Sem fazer alarde, os custos ficam muito altos. O quarto problema que elas encontram são os comentários excessivamente minuciosos. Isso importa mais do que você imagina. Comentários excessivamente minuciosos são comentários tecnicamente

05:09 corretos, mas pedantes demais. Há duas coisas que dão errado quando você recebe comentários excessivamente minuciosos. Se você está lendo esses comentários como uma pessoa, eles são muito irritantes. É como a história do menino que gritava “lobo”. Você vai ver muitos e muitos comentários, e vai ser meio irritante ter de lê-los e descobrir quais são apenas reclamações estilísticas menores e quais são problemas realmente catastróficos. A segunda coisa que vai dar errado é que eles vão estragar sua base de código, porque, em geral, os agents de revisão deixam comentários no GitHub, e seu coding agent os encontra e resolve. E coding agents não são criteriosos. Eles vão olhar os comentários da revisão e simplesmente resolver todos, e você acabará com um código extremamente

05:41 defensivo e doloroso, como descobrimos que os coding agents são particularmente bons em escrever. O próximo problema é que, sempre que você executar um agent de revisão no mesmo pull request, de algum jeito vai encontrar bugs novos. Ou seja, ele continuará encontrando coisas novas no pull request, de um jeito muito irritante, e você… Como eu disse, os bugs vão parecer fractalmente infinitos. Então, a primeira coisa que você deve fazer, o caminho mais fácil, é otimizar o prompt. Você começou com um prompt bem simples, algo como “revise este PR e depois apresente os

06:11 comentários no formato de schema da API do GitHub”. Em geral, há dois temas relacionados aos bugs: procurar tipos específicos de bugs e, segundo, evitar comentários excessivamente minuciosos. É nisso que você deve orientar seu prompt. Peça para procurar tipos específicos de bugs. Você pode fazer uma análise interna dos dados de interrupções e incidentes que já aconteceram na sua base de código e descobrir quais tipos de bugs ela tende mais a produzir. Crie um catálogo deles e, depois, configure o prompt para procurar esses tipos específicos de bugs. Em segundo lugar, você precisará explicar claramente o que é um comentário excessivamente minucioso e dizer para não procurar esse tipo de comentário. Esses comentários podem ser qualquer coisa, desde

06:43 perguntando por que não há três camadas de defesa nesse item específico, ou por que o tratamento de erros é feito de um jeito meio descuidado. Agora, o que você vai perceber quando mudar esses prompts é que uma pequena alteração no prompt pode ter um impacto estranhamente grande no número de comentários que seu agent escreve no seu pull request. Isso é bastante assustador, porque significa que você não sabe de verdade se ele deixou passar um bug ou não. Você não sabe o que teria acontecido no cenário alternativo. Os agents de validação — ou, na verdade, qualquer revisor ou testador — podem dizer se há bugs, mas, felizmente, não podem dizer se não há bugs. Essa é uma espécie de

07:14 limitação do formato. E o que torna isso particularmente difícil são os bugs extraordinariamente raros, que ficam cada vez mais raros a cada dia. Na verdade, de acordo com nossos dados de ciência de dados, apenas cerca de um em cada mil pull requests contém um bug geralmente catastrófico. Ou talvez um em cada mil linhas de código contenha um bug catastrófico. Então, como esses bugs são muito raros, você pode lançar uma versão do seu agent que considera muito boa, mas que, secretamente, deixa passar um bug catastrófico em um pull request, e você não vai saber disso por muito tempo, porque esses bugs não aparecem com frequência.

07:44 E isso nos leva à segunda melhoria. Você vai querer um conjunto de dados de PRs históricos. Isso é relativamente fácil se você fizer parte de uma daquelas empresas que catalogam muito bem todas as vezes que algo dá errado na base de código. Se tiver isso, terá uma lista de pull requests que causaram indisponibilidades e incidentes no passado. Você vai querer catalogá-los e, então, essencialmente, fazer com que qualquer versão do seu agent de revisão passe por eles e verificar com que frequência consegue detectar esses bugs. Isso vai permitir que você ajuste o prompt com um pouco mais de confiança. Mas, ao mesmo tempo, o interessante sobre os bugs é que, em um mundo em constante mudança, a topologia e a

08:15 ontologia dos bugs mudam com o tempo. Por isso, você vai precisar de um conjunto de dados atualizado em tempo real. E isso é complicado porque, a menos que você tenha milhões e milhões de pull requests, é difícil ter uma cobertura razoavelmente alta dos tipos de bugs. É verdade que cerca de 80% ou 90% dos seus bugs serão apenas repetições de erros anteriores, mas, à medida que os code agents ficam cada vez melhores, eles vão começar a cometer erros inéditos. Vão falhar de novas maneiras que não previmos antes. E é aí que você vai começar a encontrar limitações. Agora, uma observação rápida: é mais ou menos isso que fazemos na Greptile, só que, na verdade, temos muito código de muitas empresas diferentes e podemos testar em um corpus muito,

08:47 muito grande de pull requests e, assim, melhorar nosso agent com bastante confiança. Essa é uma das razões pelas quais conseguimos obter pequenos ganhos de desempenho nas margens, de maneiras que os agents de revisão internos não conseguem. Mas você pode chegar bem longe, especialmente na sua empresa, fazendo isso com seus dados internos. A próxima coisa que você vai querer fazer é a inversão de modelo. Então, caso alguém tenha ido à minha palestra no início deste ano, em São Francisco, no AI Engineer, falei bastante sobre as maneiras como os agents de programação falham. E, por meio dessa pesquisa, descobri um padrão interessante: os tipos de bugs produzidos pelos modelos Claude

09:17 ou pelos modelos Codex são bem diferentes entre si. E eles diferem em vários aspectos. Por exemplo, os modelos Claude têm cerca de três vezes mais chances de produzir erros isolados do que os modelos GPT. Já os modelos GPT têm uma probabilidade significativamente maior de produzir desvios de autenticação do que os modelos Claude. Pelo que entendo, tudo isso são consequências do pós-treinamento. Para evitar isso, você vai perceber que, se usar o mesmo modelo para revisar o código escrito por esse modelo, na verdade, menos bugs serão detectados, porque, durante a revisão, eles falham das mesmas maneiras que falham

09:48 durante a geração de código. Por isso, você vai querer inverter o modelo. Se usou Claude Code para escrever o código, vai querer usar um modelo GPT para revisá-lo, e assim por diante. Fazer isso é relativamente simples para chegar ao percentil 80, mas bastante complicado para os 20% restantes. Se você usa agents de programação, vai notar que eles deixam algum tipo de marca que indica qual agent de programação foi usado em um determinado pull request. Por exemplo, o Codex nomeia branches no formato codex/nome da branch. Ou o Claude escreve “co-authored by Claude” na descrição do PR e na mensagem do commit. E isso será

10:19 verdade em cerca de 80% das vezes. Nos 20% restantes, quando você cria manualmente um nome de branch ou por algum outro motivo talvez tenha sido usado um agent de programação diferente, é significativamente mais difícil descobrir qual modelo foi usado durante a geração. E você precisa desenvolver algum tipo de heurística para identificar as assinaturas dos modelos usados. Muitas vezes, você pode ter um catálogo interno em que as pessoas informam quais agents de programação estão usando atualmente, ou algum tipo de telemetria proveniente das máquinas de desenvolvimento e dos computadores dos seus engenheiros. Descobrimos que a taxa de detecção aumenta 10% quando você alterna os modelos. Isso pode parecer muito pouco, mas você precisa saber que 10%, em termos de incidentes e

10:51 indisponibilidades, é bastante coisa. Isso significa que há uma chance 10% maior de algo dar errado se você não usar a inversão de modelo, e isso pode ser catastrófico. Por isso, recomendamos muito que você use algum tipo de inversão de modelo no seu processo. A terceira melhoria é o contexto da base de código. Isso é algo com que me importo muito. Antes de trabalharmos com validação de código, trabalhávamos com contexto da base de código. Estávamos tentando descobrir maneiras melhores de fazer RAG em bases de código muito grandes. Mesmo hoje, as pessoas consideram que o grep resolveu efetivamente todos os problemas de contexto da base de código. Na verdade, acho que isso não é verdade por vários motivos.

11:21 Primeiro, o grep é extremamente impreciso. Segundo, é muito caro. Para dar uma noção da escala, uma porcentagem de um dígito do crescimento do PIB no ano passado veio de inference. Uma parcela muito grande da inference veio de agents de programação. E, se você observar o trace de um agent de programação, a grande maioria dos tokens usados por esses agents é sempre a mesma coisa: grep, leitura de arquivo, gravação em cache do conteúdo do arquivo. Isso significa que uma parcela não trivial do crescimento do PIB é grep, leitura de arquivo e gravação em cache. Isso é muito ruim. E isso acontece porque o grep é muito impreciso. Ele lê arquivos em quantidades muito grandes e, sei lá, talvez haja alguns incentivos perversos para empresas remuneradas por token encontrarem maneiras de consumir mais tokens. Mas, mesmo assim, você vai perceber que precisa usar métodos um pouco mais cirúrgicos para descobrir o que deve ler. E a maneira como fazemos isso é criando uma base de conhecimento interna em que, essencialmente, verificamos todas as partes da base de código, catalogamos tudo e depois indexamos, dizendo: “Certo, isto é autenticação. Veja como funciona. Estes são os fluxos. Aqui está um diagrama dos fluxos. Estes são todos os arquivos envolvidos.” Um exemplo de situação em que o contexto da base de código importa é quando você está tentando detectar um desvio de autenticação. Na verdade, é muito difícil descobrir se ocorreu um desvio de autenticação,

11:52 incentivos para empresas remuneradas por token encontrarem maneiras de gastar mais tokens. Mas, mesmo assim, você vai perceber que precisa usar métodos um pouco mais direcionados para descobrir onde deve ler. E fazemos isso criando uma base de conhecimento interna, na qual verificamos essencialmente todas as diferentes partes de toda a base de código, catalogamos e indexamos, dizendo: “Certo, isto é autenticação. É assim que funciona. Aqui estão os fluxos. Aqui está um diagrama dos fluxos. Aqui está cada arquivo envolvido.” Um exemplo de como o contexto da base de código importa é quando você está tentando detectar um bypass de autenticação. Na verdade, é muito difícil descobrir se ocorreu um bypass de autenticação.

12:23 porque você precisa ter um entendimento bastante concreto sobre se está ou não em um ambiente autenticado naquele trecho da base de código. E isso é muito complicado. Então, você vai perceber que precisa de algum tipo de contexto da base de código para conseguir fazer isso. Agora, tenho me concentrado bastante no conceito de bugs, mas o código pode ser muito, muito ruim mesmo sem ter bugs. Primeiro, pode ser de péssima qualidade, mas, segundo, pode simplesmente não cumprir a intenção expressa pelo autor. Recentemente, vi uma publicação dizendo que as pessoas estavam usando cada vez mais o Slack como IDE.

12:53 Agora, acho isso um pouco engraçado, mas, ao mesmo tempo, não há tanta intenção explícita em uma mensagem no Slack. Você talvez diga apenas uma ou duas frases, se tanto, pedindo a um agent que vá corrigir alguma coisa, o que significa que há muita ambiguidade na sua instrução. Como resultado, você pode descobrir que o coding agent interpretou suas instruções incorretamente ou que elas eram simplesmente ambíguas demais e ele não sabia exatamente o que fazer. Então, seu código correto ainda pode estar bastante errado. Uma das maneiras de combater isso é dar cada vez mais contexto aos agents. E descobrimos que os dois tipos de contexto que mais importam são

13:23 documentação e tickets e, claro, a base de código, fornecida pelo indexador da sua base de código ou pela base de conhecimento. Você pode avançar bastante se der ao agent acesso ao Jira e ao Linear e, depois, ao Confluence, ao Notion ou a qualquer ferramenta onde você armazene sua documentação. Você vai perceber que há muito conhecimento tácito que ajuda você, subconscientemente, a produzir código melhor. E, quando os agents fazem a mesma coisa, parece que eles simplesmente não sabem o que está acontecendo. Isso porque você subestima o quanto sabe. A maneira como a Reptile aborda esse problema é, na verdade, eliminar a intermediação entre todas essas fontes de contexto…

13:55 …com uma wiki viva. Essa wiki é, essencialmente, uma espécie de modelo do mundo de como sua empresa funciona. Ela contém tudo o que sabe sobre sua base de código, tudo o que sabe sobre sua aplicação por meio da telemetria de produção, dos logs, tudo o que sabe sobre seu roadmap com base na documentação, nos tickets do Linear e assim por diante. E usa essa wiki para fornecer contexto, tanto tornando o agent mais ciente do contexto quanto tornando suas buscas no código muito mais precisas, porque ele nunca vai ler um arquivo que não precisava ler.

14:26 A última coisa que você deveria fazer — ou talvez seja a quarta de cinco — é o próximo passo: testes autônomos. >> [limpa a garganta] >> Uma coisa em que pensamos bastante é que, por exemplo, em mudanças de UI, você pode ler vários arquivos alterados de código React e concluir que não há nada errado com o código. Mas, na verdade, quando você o renderiza, ele pode, por exemplo, ficar oculto em um iPhone. Esse é um dos problemas tecnicamente mais difíceis de resolver. A maneira como abordamos isso na Reptile é construir sandboxes com muitas dependências,

14:56 que são máquinas virtuais totalmente configuráveis. Trabalhamos com nossos clientes para, essencialmente, inicializar suas stacks nesses sandboxes. Então, o agent da Reptile usa visão computacional para testá-las de ponta a ponta. Se você não tem acompanhado, a visão computacional melhorou muito e está muito melhor nos modelos GPT e Opus desta nova geração do que nos anteriores. Acho que, pela primeira vez, o QA de ponta a ponta está quase resolvido. Mas o que você precisa fazer é documentar todos os fluxos da sua aplicação. Em segundo lugar, você precisa ter um script de build suficientemente simples para que

15:26 o agent possa inicializar sua stack nos seus ambientes. Temos uma equipe de engenheiros alocados diretamente que ajuda as empresas a fazer isso. Descobrimos que é uma das partes mais complicadas. A menos, claro, que você já tenha ambientes de desenvolvimento muito bons — nesse caso, parabéns por trabalhar na Stripe. Então, ah, este é o diagrama que vou mostrar. Mas, sim, você vai precisar de um ambiente de desenvolvimento, de dependências da branch do PR, com a aplicação em execução, e de algum tipo de mapa de fluxo que diga: “Este é o código de autenticação e este é o fluxo de cadastro”, e assim por diante. Com isso, seu agent pode testar seu código de ponta a ponta e usar modelos de visão

15:57 para dizer: “Ah, este botão aparece tecnicamente, mas na verdade fica oculto em iPhones, ou não aparece na primeira dobra da tela no iPhone Duo, etc.” Agora, se você fizer tudo isso, vai descobrir que os custos ainda são bem altos. Pode custar de três dólares até 15 ou 20 para revisar um único pull request. E o que você vai querer resolver agora é usar modelos mais baratos para algumas coisas. Para mim, de modo geral, os modelos de ponta ainda são mais capazes do que os modelos open source. Isso vem sendo verdade há algum tempo, embora a diferença esteja diminuindo. Hoje, nossa proporção é de cerca de 20%

16:29 de uso de modelos de ponta para as tarefas mais críticas. Para a longa cauda de tokens, que envolve exploração, leitura de arquivos e assim por diante, usamos uma variedade de modelos menores. Assim, você pode reduzir drasticamente o custo de executar seu agent de revisão. Este é um exemplo ilustrativo do que fazemos: usamos um modelo pequeno para encontrar contexto, um modelo leve de uso do computador para testar fluxos de usuário e um modelo de ponta para tarefas como analisar bugs, aplicar o processo de revisão e fazer o primeiro envio. Na prática, temos 20 subtarefas diferentes, e cada uma delas tem

17:00 um conjunto bem específico de modelos que usamos para ela. Temos uma pequena equipe de pesquisa que está constantemente avaliando exatamente quais modelos usamos em cada tarefa. Provavelmente dá para chegar a 70% ou 80% do caminho usando algo desse tipo, em que você simplesmente substitui tarefas muito simples por modelos muito simples. Este é outro exemplo de como ter um conjunto de dados muito grande ajuda bastante. Se você não tiver um bom conjunto de dados, talvez consiga fazer com que o trigger substitua alegremente muitos subagents diferentes por modelos menores e mais rápidos, sem perceber que esse agent agora está bem pior em detectar bugs. Você só descobriria quando ele deixasse passar algo que então

17:30 causasse uma interrupção ou um incidente. Você também vai descobrir que pode combater esse problema de leituras excessivas de arquivos usando um modelo barato que analisa todos os seus itens de contexto e determina quais realmente devem ser incluídos. Em teoria, você deveria conseguir usar um decision model para isso, algo como Java ou a Decisions API, para reclassificar com eficácia todos os itens diferentes e decidir o que deve ou não ser carregado no cache do modelo de ponta, que, de certa forma, é seu recurso mais caro e mais escasso. Se fizer tudo isso, talvez consiga avançar bastante na

18:01 criação do seu próprio agent de revisão. E, se fizer isso, me avise. Meu e-mail é daksh@prod.com. Adoraria ajudar você. E, se decidir não criar um, também pode simplesmente usar nosso produto, que é gratuito em comparação. Mas muito obrigado. [fungada]

Transcrição original

[00:01] [music] >> Um all right, my name is Dax. I am one of the co-founders of a company called Griptile and we build agents that review and test pull requests with the full context of the code base. And by reviewing and testing these pull requests, we reveal bugs, logical errors, code quality concerns, primarily from the AI-generated code.

[00:32] Now, to give you a sense of scale, many thousands of companies use Griptile every day. About 1% of all pull requests on GitHub go through us and a variety of many different types of code bases, whether it’s the CUDA code base at Nvidia or the wallet code base at Coinbase and many, many others. And every now and then, we meet a company where we’re actually not the right code review or code testing product for them. Their needs are so specialized and so esoteric that it’s actually beneficial for them to build their own. And when that happens, we tend to help

[01:03] them for free. There’s two reasons for this. One, we have a lot of specialized knowledge about how to do this really, really well. And second, we get to learn a lot about how we can serve customers like those in the future. And in this presentation, I want to tell you what we tell them, which is how to build a really great AI code review agent yourself. Now, there’s kind of three things that people like about Griptile and I’m going to talk through how to implement those yourself. The first one is code base context. When customers use Griptile on their pull requests, they find that it really understands their code base.

[01:35] As a matter of fact, before we were a code validation company, we were a code base context company. We were teaching language models from 2023 how to understand the very large code bases and as a result of that, we got very good at indexing code. Uh the second thing that people like about Griptile is that it runs your code in the sense that spins up your stack in a fully loaded dependency-rich sandbox and it clicks around and tests things using computer user through pressure testing API endpoints and so on. And the third thing is we’re actually very efficient allocators of inference. We pick the right model, the right quantity of inference budget for each

[02:06] subtask in the review and validation process. As a result of that, we’re able to get a lot more performance per dollar than an internal tool could or any competitor could. So, there’s kind of two reasons that you would want this presentation. Uh the first one is you want to build your own review agent. And the second reason, which is a bit more subtle, is if you’re trying to pick a review or testing agent for your company and you want to understand what makes a good one and what makes a great one. All right. So, let’s start right in. Now,

[02:37] blank slate. You are part of the platform team at your company or you’re just the uh local uh AI psychotic member of your team and you want to build the review validator of your company. Um Companies are writing lots of code. People are vibe coding. Uh you have, of course, engineers vibe coding. Some of them are a little too close to the sun. Uh you have marketing people writing code. And uh the new problem is the review bottleneck, the validation bottleneck. And so, that’s what you want to address. The first thing that you should do is you should get yourself a sandbox. There’s many, many companies here that

[03:08] will sell you a sandbox. Uh you can also just use firecracker or something like that. And you’ll want to put an agent in that sandbox. Uh the agent can be Code X or Cloud Code. Personally, I recommend going model independent for reasons that I will get into, so you can use something like Open Code or Pi as your harness. Those are both open source. And uh you will need to then connect your GitHub or your GitLab. Have a PR webhook send it the contents of a pull request to any pull requests that are opened. The agent can have some type of prompt that just says, “Hey, review this and send back some feedback.” And then you can wire that back using GitHub’s review

[03:39] APIs. Very simple. In fact, many people think that’s actually all it takes to build a review agent. There’s a few things that are going to go wrong when you start using this. But what will happen is you will, in fact, have a pull request go live. The contents will go to an agent and about 5 minutes later you will get some feedback on your pull request. But here’s what’s going to go wrong in the time that it takes you to build this. The first one is you’re going to miss a lot of bugs. As it turns out that actually bugs are interactively large. They’re In fact, I saw a a tweet not very long ago that said that bugs are

[04:09] fractally infinite. So you will never run out of a of bugs in a particular piece of code. That’s the first thing that’s going to go wrong is you’re going to miss bugs. Of course, that’s the one thing that your system needs to do is to prevent at least very catastrophic outages and incidents. Second thing that’s going to happen is it’s going to miss context and it’s it’s going to misunderstand parts of how your code base works. It maybe won’t understand where you’re going with your code base. It won’t understand how a specific part of it works. It maybe will not understand how one of your libraries works. It’s possible you’re one of those companies that never recovered from the microservices apocalypse of the 2010s

[04:39] and so you just have thousands and thousands of repos and you have to have context of all of them to be able to operate. So that’s the second thing that’s going to go wrong. The third thing is it’ll be very expensive. I think people are very surprised by this. So generally from people who have seen try to do this, they’ll find that they’re spending between $3 and up to $25 per pull request on reviewing it using coding agents. These tokens can add up really really fast. Very quietly they got very expensive. The fourth problem they’ll find is nitpicky comments. Now this matters more than you might think. Nitpicky comments are comments that are technically

[05:09] correct but overly pedantic. There’s two things that go wrong when you have nitpicky comments. If you are a as a human reading those comments, they’re very annoying. They’re like a boy that cries wolf. You’ll just see lots and lots of comments and it’ll be kind of annoying for you to just read through them and figure out which ones are just minor stylistic complaints and which ones are actually catastrophic problems. The second thing that will go wrong is they will wreck your code base because typically the way the review agents work is they’ll leave comments on GitHub and your coding agent picks them up and resolves them. And coding agents are not discerning. They’re going to look at review comments and just address all of them and you’ll end up with extremely

[05:41] painfully defensive code as we found the coding agents are particularly astute at writing. The next thing that go wrong is that every time you run a review agent on the same pull request, you will somehow find new bugs in the sense that it will keep catching new things in the pull request very annoyingly, and you will And like I said, bugs will appear to be fractally infinite. So, the first thing that you want to do, the lowest hanging fruit, what is you want to optimize the prompt. You started with a very simple prompt, something like review this PR and then output the

[06:11] comments in GitHub’s API schema format. Generally, there’s two themes within the bugs. Look for specific bug types, and second, skip the nitpicks. And that’s what you want to orient your prompt around. You’ll want to ask for specific bug types, and you can kind of do some internal data science on existing outages and incidents that have happened in your code base and figure out what types of bugs you have the highest propensity to produce. Create a catalog of them, and then have your prompt look for those specific bug types. The second is you’ll need to expressly tell it what a nitpick is and not to look for them. And nitpicks can be anything from

[06:43] asking why there isn’t three layers of defense on this particular thing, or why error handling is done in this slightly shoddy way. Now, the thing that you’ll run into when you change these prompts is when you change a small thing in the prompt, it’ll have a weirdly big impact on the number of comments that your agent is writing on your pull request. This is quite scary because it means you don’t really know if it’s missing a bug or not. You don’t know the counterfactual. The validation agents, or really any reviewer or tester, can can tell you about the presence of bugs, but it fortunately can’t tell you about the absence of bugs. That’s that’s sort of a

[07:14] a limitation of the format. And what makes this particularly difficult are bugs that are extraordinarily rare and getting rarer by the day. In fact, according to our data science, only about one out of every thousand pull requests has a generally catastrophic bug in it. Or maybe one out of every thousand lines of code has a catastrophic bug in it. And so, because these bugs are very rare, you might release a version of your agent that you think is very good, but it secretly misses a catastrophic bug in a pull request, and you wouldn’t know for a long time because you don’t produce those bugs very often.

[07:44] And so that brings us to the second improvement. You will want a data set of historical PRs. This is relatively easy if you’re one of those companies that very nicely catalogs every time something goes wrong in your code base. If you have that, then you’ll have a list of pull requests that have caused outages and incidents in the past. You’ll want to catalog them and then essentially have any version of your review agent run through those and see with what frequency it can catch those bugs. Now, this will allow you to tune the prompt a little bit more confidently. But at the same time, the interesting thing about bugs is in a changing world, the topology and

[08:15] ontology of bugs changes over time. And so you’ll need to have a real-time updating data set. And this is tricky because unless you have millions and millions of pull requests, it’s actually hard to have reasonably high coverage of bug types. It’s true that about 80 or 90% of your bugs will be just repeats of prior mistakes, but increasingly as code agents get good, they’re going to start making novel mistakes. They’ll fail in new ways that we’ve not anticipated before. And so this is where you will start to hit limitations. Now, quick side note, this is kind of what we do at Reptile, except we actually have a lot of code from a lot of different companies and we can test across a very,

[08:47] very large corpus of pull requests and therefore improve our agent very confidently. It’s one of the reasons why we’re able to eke out little bits of performance on the margins in ways that internal review agents can’t. But you can get decently far, especially for your particular company, to do this with your internal data. The next thing you want to do is model inversion. So, for in case anyone was at my talk earlier this year in San Francisco at AI Engineer, I talked a lot about the ways in which coding agents fail. And I discovered an interesting pattern through that research, which is that the types of bugs produced by Claude models

[09:17] or Codex models are actually quite different from each other. And they’re different in a number of ways. As an example, Claude models are something like three times more likely to produce one-off errors than GPT models. GPT models, on the other hand, are significantly more likely to produce auth bypasses than Claude models. And these are all just artifacts of the post-training, as far as I understand. Now, to prevent this, you’ll find that if you’re using the same model to review the code written by the same model, um you’ll actually have relatively fewer bugs caught because they fail in the same ways during review that they do

[09:48] during code generation. And so you’ll want to invert the model. If you’ve used Claude code to write the code, you’ll want to use a GPT model to review it and so on. Now, doing this is somewhat straightforward for the 80th percentile and quite tricky for the last 20. So, if you’re using coding agents, you’ll notice they leave some type of fingerprint to tell you what coding agent was used for a particular pull request. For instance, Codex will name branches in a codex/branch name format. Or Claude is going to write a co-authored by Claude in the PR description and commit message. And about 80% of the time, this will be

[10:19] true. In the final 20, when you happen to manually create a branch name or there was some other reason that a different coding agent was perhaps used, it’s significantly harder to figure out which model was used during generation. And you have to develop some type of heuristics to figure out what are the signatures of models being used. Often you might have an internal catalog where people report what coding agents are using these days or have some type of telemetry that’s coming out of your dev machines and and your engineers’ computers. We found that there’s a 10% higher catch rate if you flip models. And this might sound very small, but you have to know that 10% is in terms of incidents and

[10:51] outages is actually quite a lot. It means that there’s a 10% higher chance that something will go wrong if you’re not using model inversion, which can be quite catastrophic. And so we highly recommend that you use some type of model inversion in your process. The third improvement is code base context. Now, this is something that I care a lot about. Before we were doing code validation, we were doing code base context. Uh we were trying to figure out better ways to do rag over very large code bases. And even today, people consider grep to effectively solved all of code base context. I actually think that’s not true for a number of reasons.

[11:21] One, grep is extremely imprecise. And second, it’s very expensive. To give you some sense of scale, single-digit percentage points of GDP growth last year were inference. A very large percentage of inference was coding agents. And if you actually look at a coding agent trace, the vast majority of tokens used by coding agents are all the same. grep, file read, cache write for the file contents. That means a non-trivial percentage of GDP growth is grep, file read, cache write. That’s very bad. And this is because grep is very imprecise. It’s reading files in very large quantities, and I don’t know, there’s perhaps some adverse

[11:52] incentives for companies paid by the token to figure out ways to burn more tokens. But even so, you’ll find that you’ll need to use slightly more surgical methods of figuring out where you should be reading. And the way we do this is we produce an internal knowledge base where we essentially check across the entire code base all the different parts, catalog them, and then index saying, “Okay, well, this is authentication. Here’s how it works. Here are the flows. Here’s a diagram of the flows. Here’s every file that’s involved.” One example of where code base context matters is, for instance, when you’re trying to catch an off bypass. It’s actually very difficult to figure out if an off bypass has occurred

[12:23] because you need to have a pretty concrete understanding of whether you’re in an authenticated environment when you’re in that part of the code base or not. And that’s very tricky. And so, you’ll find that you will need some type of uh of sort of code base context to be able to do this. Now, I’ve been very centered around the concept of bugs, but code can be very, very bad even if it’s not buggy. For one, it can be terrible quality, but second, it can just not fulfill the expressed intent of the author. Recently, I saw a post that said that people were increasingly using Slack as their IDE.

[12:53] Now, I think that’s a little funny, but at the same time, there’s not that much ex- expressed intent in a Slack message. You’re only saying maybe a sentence or two, if even, asking an agent to go and fix something, which means the there’s a lot of ambiguity in your instruction. As a result of this, you might find that the coding agent has either misinterpreted your instructions or just it was too ambiguous and it didn’t know exactly what to do. And so, your correct code can actually still be quite wrong. Now, one of the ways in which we fight this is by giving agents increasingly more context. And we find that the two types of context that matter most are

[13:23] docs and tickets, and then of course, the code base from your code base indexer or knowledge base. You can get remarkably far if you give it access to your Jira and Linear, and then your Confluence or Notion or whatever it is that you store your docs. You’ll find that there’s a lot of tribal knowledge that is subconsciously helping you produce better code. And when you have agents do the same thing, it feels like they just don’t know what’s happening. And because you you underestimate how much depth of knowledge you yourself have. Now, the way that Reptile approaches this problem is we actually disintermediate

[13:55] all of these context sources with a living wiki. This wiki is essentially a sort of world model of how your company works. It’s everything that it knows about your code base, everything it knows about your application through production telemetry, through logs, everything it knows about your road map from your documentation and your linear tickets and so on and so forth. And it uses this wiki to supply context both making the agent more context aware and making its code searches significantly more precise because it will never read a file that it didn’t need to read.

[14:26] The last thing that you should do, or this might be four out of five. The next thing that you should do is autonomous testing. >> [clears throat] >> One of the things that we think about a lot is that for instance, for UI changes, you might be able to read through a bunch of changed files for React code and conclude that there’s nothing wrong with the code. But in fact, when you render it, it might be, for instance, hidden on an iPhone. Now, this is one of the more technically difficult problems to solve. The way that we approach this at Reptile is we essentially build these dependency-rich

[14:56] sandboxes, which are completely configurable virtual machines, and we have customers, we work with them to essentially spin up their stack in these sandboxes. And then Reptile’s agent uses computer vision to test them end to end. If you haven’t been paying attention, computer vision has gotten very good, and it’s like far better in these new generation of GPT models and Opus models than it was in the previous. For the first time, I think end to end QA is nearly solved. The thing that you need to do though is you need to document all the flows through your application. And second, you need to be able to have a sufficiently simple build script so that

[15:26] the agent can spin up your stack in your environments. We have a team of forward deployed engineers that help companies do this. We found that it’s one of the trickier parts. Unless of course, you have very good dev boxes already, in which case congratulations on working at Stripe. So, oh, I This is the diagram I’m going to show you. But yes, you will need a dev box, you will need PR branch dependencies where you’re running the app, and you’ll need some type of flow map that says, “This is the auth code and then this is the sign-up flow.” and so on. And using this, your agent can now test your code end-to-end and use vision

[15:57] models to say, “Oh, like this button technically appears, but it actually is hidden on iPhones, or it’s not in the first fold on the iPhone duo, etc.” Now, if you do all of this, you’ll find that the costs are still quite high. It can cost you anywhere from three bucks to 15 to 20 to do a single pull request review. And the thing you’ll want to solve for now is to use cheaper models for some things. Now, to me, frontier models are still generally speaking more capable than open source models. This has been true for some time, even though the rubber band is tightening. So, our share today is about 20%

[16:29] frontier models for the most critical tasks. And then the long tail of tokens, which is exploratory, file reads, and so on, we use a variety of smaller models. And so, if you do this, you can actually reduce the cost of running your review agent quite drastically. So, this is sort of a illustrative example of what we do, which is we’ll use a small model for our finding context, we’ll use a very lightweight computer use model for testing user flows, and we use a frontier model for things like analyzing bugs, applying the review process, and first submission. In practice, we have actually 20 different subtasks, and each of them has

[17:00] a very specific set of models that we use for each of them. And we have a small research team that is constantly iterating exactly what models we use for what task. You can probably get 70 to 80% of the way there using something of this kind where you just swap out very simple tasks with very simple models. Now, this is another example of where it really helps to have a very large data set. If you don’t have a good data set, you might be able to have trigger happily replace a lot of different sub agents with smaller, faster models, and you won’t know that it’s this agent is actually now quite a bit worse at catching bugs, and you would only find out when it misses something that then

[17:30] causes an outage or incident. And you will also find that you can kind of combat this problem of overactive file reads using a cheap model that essentially looks through all of your context pieces and figures out which ones actually should be included. In theory, you should be able to use a decision model for this, something like Java, or the Decisions API, to do effective re-ranking on all of the different things, and deciding what should be and shouldn’t be loaded into Frontier Model Cache, which is in some ways your most expensive and most scarce resource. If you do all of these things, you might be able to actually get quite far in

[18:01] building your own review agent. And if you do, please let me know. My email is daksh@prod.com. I’d love to help you. And uh if you choose not to build it, then you can also just use our product, um which is free in comparison. But, uh thank you so [snorts] much.