CuraLoc encontra bugs em repositórios com um único plano e gasta 90% menos tokens

Pesquisadores da equipe de Sangeeta Warrier propuseram o CuraLoc, um método de localização de erros em nível de repositório inteiro. Ele troca a longa cadeia de chamadas ao modelo por um único plano de inspeção do código. No SWE-bench Verified com GPT-5.2, o sistema obteve Func@1 de 59,3%, contra 53,8% do LocAgent, e consumiu 90,3% menos tokens registrados. O preprint apareceu no arXiv em 22 de outubro de 2026, e a segunda versão saiu em 26 de outubro.

Por que o relatório de bug diz pouco sobre onde corrigir

Um relatório de bug descreve o sintoma: o que quebrou e em quais condições. Quase nunca diz em que ponto exato o código precisa mudar. Por isso, os agentes de correção de erros têm uma etapa separada de localização, na qual é preciso encontrar, entre milhares de arquivos e funções, os que merecem ser alterados.

A maioria dos métodos atuais resolve o problema de forma iterativa. O modelo examina a estrutura do repositório, escolhe um arquivo, lê o conteúdo, decide para onde ir depois e repete o ciclo. Cada passo significa uma nova chamada ao LLM e mais tokens no contexto. A conta cresce rápido, e a qualidade depende de o agente não seguir uma pista falsa no terceiro ou no quinto passo.

Os autores do CuraLoc testam uma hipótese diferente: as decisões sobre o que inspecionar podem ser planejadas com antecedência, antes de o código-fonte ser carregado.

Um plano no lugar de uma cadeia de passos

O pipeline do CuraLoc tem várias etapas. Primeiro, o sistema seleciona arquivos candidatos e descreve seus símbolos (funções, classes, métodos) com resumos compactos de comportamento e estrutura. Nessa fase, o código-fonte em si não chega ao modelo.

Em seguida vem uma única decisão de planejamento. Em uma só chamada, o modelo faz três coisas:

• escolhe os símbolos iniciais;
• define quais conexões a partir de cada um vale verificar (chamadas, dependências e outras relações estruturais no código);
• formula hipóteses sobre quais alterações são mais prováveis.

Depois disso, entra em cena uma busca determinística, que reúne o código-fonte solicitado sem participação do modelo. Então o modelo faz o ranqueamento final, com base nas hipóteses já formuladas. Seu raciocínio se concentra em escolher e comparar código, e não em conduzir cada etapa da extração.

O que os benchmarks mostraram

Os autores testaram o método no SWE-bench Lite e no SWE-bench Verified. A métrica principal no Verified é o Func@1, ou seja, a proporção de casos em que a função correta aparece na primeira posição. Para o Lite, foi usado o Func@5, quando ela aparece entre as cinco melhores.

Comparação no SWE-bench Verified com GPT-5.2, por Func@1:

• CuraLoc: 59,3%;
• RepoSearcher: 56,2%;
• LocAgent: 53,8%;
• Agentless: 39,6%.

Em consumo de tokens, o CuraLoc gasta 90,3% menos tokens registrados que o LocAgent. Não é uma otimização pequena: em vez de dezenas de chamadas ao modelo, toda a navegação se reduz ao mínimo possível de chamadas.

No SWE-bench Lite, o CuraLoc atingiu 83,8% de Func@5. Em relação ao Agentless, isso representa uma melhora de mais de 15%.

Os autores também mostraram que o método não depende de um único modelo. O CuraLoc demonstra forte precisão de localização tanto com GPT-5.2 quanto com GPT-6 Astra.

O que dá para aproveitar na prática

A principal conclusão para quem desenvolve agentes é que a navegação autônoma do modelo pela base de código nem sempre compensa o custo. Se parte das decisões for transferida para uma camada determinística, e o modelo ficar com as tarefas em que é forte (hipóteses sobre alterações e comparação de candidatos), é possível ganhar ao mesmo tempo em precisão e em custo na localização de erros.

Para equipes que constroem seus próprios agentes de programação, é um motivo para rever o orçamento de tokens na etapa de busca. A localização costuma vir antes da geração do patch e determina se o patch fará algum sentido. Uma primeira etapa barata e estável reduz também o custo de todo o ciclo de correção.

Há ainda limitações apontadas pelo próprio desenho do estudo e pelas métricas. Todos os resultados vêm do SWE-bench Lite e do Verified, que reúnem repositórios Python com tarefas conhecidas. Como o método se comportará em monorrepositórios fechados e em outras linguagens ainda precisa ser verificado separadamente. Mesmo assim, para a tarefa de "encontrar a função a partir de um relatório de bug", o CuraLoc apresenta um argumento forte a favor do planejamento em vez da navegação errática.

O trabalho foi publicado na seção Machine Learning, com categoria cruzada em Software Engineering (cs.SE), DOI 10.48550/arXiv.2610.31809.