Cursor e Microsoft Research testam se um agente de IA precisa de acesso completo ao depurador

Para um agente de IA que corrige bugs, ler código e coletar logs já não basta: quando ganha acesso a um depurador de verdade, ele passa a agir mais como um desenvolvedor humano e entende bem melhor em que ponto exato o programa quebra.

No fim de 2025, o Cursor lançou o Debug Mode, um modo em que o agente pode coletar logs diretamente do runtime e usá-los como fonte adicional de contexto. Para a depuração prática, é um passo importante: em vez de adivinhar a partir de stack traces, o modelo vê o que acontece no momento da execução, quais valores passam pelas funções e em que ponto o sistema se comporta de forma diferente do esperado.

A abordagem também pareceu intuitiva para os desenvolvedores: pela reação da comunidade, a ideia não é vista como mais um modo de marketing, mas como uma ferramenta realmente útil para o trabalho cotidiano com bugs.

Mas o logging não é a única forma de aproximar a IA da prática normal de engenharia. A pergunta seguinte é ainda mais direta: se o agente já vive ao lado da IDE, por que não dar a ele as mesmas ferramentas que uma pessoa usa? Isso significa breakpoints, execução passo a passo, inspeção do estado do programa e evaluate expression na linha desejada.

Foi exatamente isso que os pesquisadores da Microsoft Research testaram no framework experimental Debug2Fix. Na configuração deles, um subagente separado recebeu ferramentas para interagir com o depurador e, em tarefas do GitBug-Java e do SWE-Bench-Live, lidou com os bugs cerca de 20% melhor do que um agente comum sem esse acesso. Não é uma melhoria cosmética: para a correção automática de código, uma diferença dessas muda o valor prático da ferramenta.

A ideia é simples. Os logs quase sempre ajudam a enxergar os sintomas, mas o depurador permite chegar à mecânica da falha. O agente pode fazer mais do que ler que um valor está errado: pode rastrear em que momento ele se tornou errado, qual ramo da condição foi executado, o que há nos objetos agora e como uma expressão se comporta ao testar uma hipótese na hora. Na prática, o modelo ganha não só observação, mas um experimento controlado. Para depurar estados complexos, condições de corrida, valores null inesperados ou erros de lógica de negócio, isso pode ser crítico, porque é aí que a análise estática e até logs detalhados muitas vezes ficam aquém.

Nesse contexto, é lógico que assistentes de IDE completos comecem a ir além da simples leitura de arquivos. Se o agente já está integrado ao ambiente de desenvolvimento, o acesso ao depurador parece menos algo exótico e mais uma extensão natural de suas capacidades. Por isso, a versão mais recente do assistente para IntelliJ trouxe o Debug Agent, que pode interagir com o depurador diretamente na IDE. O cenário é quase humano: o agente executa o programa, para no ponto certo, examina o estado, testa uma hipótese e só depois propõe a correção. É uma diferença importante em relação à abordagem em que o modelo se apoia principalmente em logging e em sinais indiretos do problema.

O mais interessante dessa história não é só o ganho nos benchmarks, mas a própria pergunta: o que é mais útil para o desenvolvedor de IA do futuro, um bom acesso aos logs de runtime ou verdadeiras «mãos» dentro do depurador? Um único experimento ainda não dá uma resposta completa, mas já dá para ver que o mercado avança em duas direções ao mesmo tempo. Um caminho aposta na observação de qualidade da execução do programa; o outro, na intervenção ativa no processo de depuração.

Se a segunda abordagem confirmar a vantagem em mais casos reais, os AI coding assistants deixarão rapidamente de ser meros autocompletadores inteligentes e se tornarão parceiros de verdade, capazes não só de escrever código, mas também de ir metodicamente até a raiz de um bug.