"Se LLMs modernos podem lidar com 200k tokens, por que não simplesmente enviar o diff com contexto relevante e deixar o modelo descobrir? Qual é o sentido de toda essa complexidade de agente?"
Um prompt só pode ver o que você envia. Para revisão de código significativa, você precisa de contexto de toda a sua base de código — imports, dependências, arquivos relacionados, testes, convenções.
Pesquisas provam que despejar mais contexto em LLMs prejudica ativamente a performance. Isso é chamado de "diluição de contexto."
10-20%
queda de performance de muitos documentos
Curva U
info no meio fica "perdida"
60-80%
taxa de falso positivo em ferramentas de despejo de contexto
Agentes não apenas "leem prompts melhor". Eles investigam ativamente sua base de código:
Buscar apenas arquivos relevantes sob demanda, não despejar tudo antecipadamente
"Suspeito de incompatibilidade de tipo" → buscar chamadores → confirmar com análise estática
Seguir pistas entre arquivos, investigar mais profundamente quando algo parece suspeito
Executar linters, verificadores de tipo e analisadores para verificar descobertas com dados reais
Um prompt vê o que você dá a ele.
Um agente encontra o que precisa.
A diferença entre revisão útil e ruído não é quanto contexto você tem — é ter o contexto certo
Antes da revisão começar, construímos um mapa de como os arquivos se conectam — imports, exports, definições de tipo e cadeias de chamadas
Cada agente recebe apenas o contexto relevante para sua tarefa — agente de segurança recebe fluxos de auth, não estilização de UI
Agentes buscam contexto adicional apenas quando necessário — seguindo pistas sem sobrecarga antecipada
Contexto central (diff, tipos) permanece residente; contexto circundante (chamadores, testes) carregado conforme necessário
200k tokens de tudo — diff, arquivos completos, dependências aleatórias...
Pedaços focados — diff + dependências diretas + padrões relevantes
Uma única chamada de LLM revisando código tem limitações fundamentais
Limitado ao diff que você fornece
Sem iteração ou verificação
Cego a dependências e contexto
Sem maneira de validar afirmações
Atenção espalhada por todas as preocupações
"Certifique-se de que os chamadores estejam atualizados"
Navega por todo o seu projeto
Segue pistas, investiga mais profundamente
Entende imports e dependências
Executa analisadores estáticos para confirmar
Cada agente se especializa em uma área
"3 locais de chamada têm incompatibilidades de tipo nas linhas 45, 89, 112"
A diferença é entre especulação e investigação.
Um agente é um sistema de IA que pode pensar, agir e verificar
Ler arquivos, buscar código, executar analisadores estáticos
Escolher o que investigar com base em descobertas
Seguir pistas, verificar hipóteses, investigar mais profundamente
Validar raciocínio contra dados reais
Quando o diffray revisa seu PR, os agentes não apenas "olham o diff"
Seguir imports para entender como o código alterado afeta todo o sistema
Examinar testes, configs e documentação para contexto
Executar análise estática para confirmar que problemas suspeitos realmente existem
Consultar definições de tipo, contratos de API e convenções
Considere uma mudança de assinatura de função em um PR:
"Isso muda o tipo de retorno, certifique-se de que os chamadores estejam atualizados"
Conselho genérico. Sem especificidades.
→ "Encontradas 3 mudanças incompatíveis: src/api/users.ts:45, src/hooks/useAuth.ts:89, src/utils/validate.ts:112"
Para realmente entender mudanças, você precisa ver como elas se encaixam em toda a base de código
Nova função formatUserName() adicionada
Parece sintaticamente correto
Sem bugs óbvios nessas 20 linhas
Veredito: "LGTM" — mas perdendo completamente o panorama geral
Esta função duplica utils/names.ts:formatName()
Função existente lida com casos extremos que esta perde
3 outros arquivos já usam o utilitário existente
Isso quebra a convenção de nomenclatura em /docs/CONVENTIONS.md
Veredito: "Considere usar formatName() existente de utils/names.ts"
O desenvolvedor está reinventando a roda? Uma solução similar já existe na base de código?
Essas mudanças seguem padrões estabelecidos? Ou introduzem uma abordagem conflitante?
Como essas mudanças afetam o resto do sistema? O que depende do código modificado?
As convenções do time e padrões documentados estão sendo seguidos?
Um diff mostra o que mudou. Contexto completo da base de código mostra se deveria ter mudado.
Fundações poderosas permitindo verdadeira colaboração multi-agente
Cada revisão passa por um pipeline multi-fase, cada fase otimizada para seu propósito
Clonar
Buscar repo e fazer checkout do PR
Prep de Dados
Construir grafo de dependências
Resumir
LLM resume mudanças
Triagem
Rotear arquivos para agentes
Regras
Carregar e filtrar regras
Revisar
Análise paralela dos agentes
Deduplicar
Mesclar e re-pontuar
Validação
Verificar e re-pontuar
Reportar
Gerar comentários do PR
Clonar
Buscar repo e fazer checkout do PR
Prep de Dados
Construir grafo de dependências
Resumir
LLM resume mudanças
Triagem
Rotear arquivos para agentes
Regras
Carregar e filtrar regras
Revisar
Análise paralela dos agentes
Deduplicar
Mesclar e re-pontuar
Validação
Verificar e re-pontuar
Reportar
Gerar comentários do PR
O Resultado
Um sistema multi-agente que combina raciocínio de IA com análise concreta de código — entregando descobertas precisas e verificadas em vez de especulação.
Insights baseados em dados de mais de 50 fontes de pesquisa. Por que desenvolvedores gastam 5-6 horas semanais em revisão, por que código gerado por IA precisa de mais escrutínio, e como implementar ferramentas de IA em que desenvolvedores realmente confiam.
Veja como investigação vence especulação. Experimente o diffray grátis no seu próximo PR.