Se você já viu um agente tentar corrigir um bug, você o viu chutar. Ele lê o código, cria uma teoria, faz uma edição e torce. Às vezes acerta. Muitas vezes você recebe uma correção que parece confiante e esconde silenciosamente o verdadeiro bug.
O Modo Debug foi o que criamos para isso. Em vez de ficar raciocinando sobre o código, o agente vai e obtém evidências sobre o que o código faz quando é executado.
Aqui está o ciclo:
- O agente cria múltiplas hipóteses e começa a trabalhar na mais plausível primeiro.
- Em seguida, logs são adicionados para testar uma hipótese (sem tocar na implementação).
- Um pequeno servidor de debug coleta a saída de execução em
.cursor/debug.logenquanto seu programa roda. - Você reproduz o bug, e o agente agora pode ler os logs e entender o que aconteceu, em vez de ter que chutar.
- O Cursor encontra a causa raiz nos logs, faz a correção e remove os logs que adicionou.
Aqui está em um bug real, acelerado para cerca de um minuto:
Como a equipe usa
Algumas coisas interessantes que resolvemos internamente com o modo debug:
- Uma condição de corrida que ocorria em 1 a cada 20 execuções. Estava corrompendo metadados do git em nossas execuções de melhor-de-N. O Modo Debug a identificou em menos de uma hora.
- Um vazamento de memória, rastreado em uma única passada. A causa era um uso incorreto do nosso framework frontend. A correção foi uma única linha.
- Uma falha nativa profunda em C++. Uma falha no Electron que as pessoas normalmente contornariam. Os logs tornaram possível encontrá-la.
- Um flicker de SSR que havia sido abandonado. Um bug de renderização que ninguém queria tocar, corrigido assim que o agente pôde ver o que a página estava fazendo em tempo de execução.
Experimente com Shift+Tab (também está no CLI, via /debug).
Tenho certeza de que as pessoas estão usando de maneiras que não imaginei, então me avise!
