Por que uma sessão com a ferramenta de debug do Cursor trava
Depurar é um ciclo: observar, levantar uma hipótese, mudar, observar de novo. Um agente que trabalha a partir dos seus arquivos dá conta de três dessas quatro etapas. Ele não consegue observar. Toda vez que você cola um stack trace ou descreve o que viu na tela, é você executando manualmente a única etapa que ele não faz — e a qualidade do ciclo inteiro fica limitada pela sua capacidade de descrever as coisas.
É por isso que a terceira rodada costuma ser pior que a primeira. O cansaço bate, a descrição fica mais curta e o agente passa a raciocinar sobre o resumo de um resumo.
As três descrições que induzem o agente ao erro
"Não funciona"
O agente precisa adivinhar a qual dos cinco modos de falha plausíveis você se refere.
Ele costuma escolher o mais fácil de corrigir, que raramente é o seu.
"Está dando este erro"
Um erro é um sintoma que aparece depois do problema real, muitas vezes várias camadas adiante.
Corrigir o ponto onde o erro é lançado faz o sintoma sumir e o defeito permanecer.
"Já tentei X"
Sem saber o que X de fato fez com o app, o agente não consegue descartar nada.
Então ele propõe X de novo, com outra roupagem.
O que fecha o ciclo
Entregue a etapa de observação ao agente em vez de executá-la você mesmo. Isso significa ter algo que opera a aplicação publicada como uma pessoa faria e relata o que aconteceu como evidência, não como texto corrido.
O formato dessa evidência importa mais do que o volume. O que foi tentado, o que a aplicação realmente fez e onde as duas coisas divergiram. Um agente consegue agir sobre isso diretamente. Um screenshot e um stack trace ainda exigem um humano para interpretá-los, o que coloca você de volta no ciclo do qual estava tentando sair.
A configuração instala uma skill de verificação dentro do próprio Cursor, para que ele saiba criar um caso, executá-lo e ler o resultado sem que você explique o fluxo a cada vez.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Você pode fazer o mesmo pelo dashboard do TestSprite. Todo o resto que a CLI faz está no repositório da CLI.
Uma reprodução que você pode entregar vale mais que uma descrição
O hábito de maior impacto é parar de descrever o bug e começar a reproduzi-lo. Um caso escrito diz qual página abrir, o que fazer e o que deve ser verdade depois. Três linhas disso rendem mais que três parágrafos de explicação, porque não deixam ambiguidade e porque podem ser executadas de novo.
Isso também muda a conversa com o agente. Em vez de "o dropdown está quebrado", a entrada passa a ser uma execução que chegou à etapa quatro e encontrou a opção errada selecionada. Não sobra nada para interpretar.
Escreva o caso antes da primeira tentativa de correção, não depois da terceira. Nesse momento você ainda lembra exatamente o que fez para provocar o bug — um conhecimento que evapora mais rápido do que qualquer um espera.
Um exemplo prático do ciclo se fechando
Veja um caso concreto. Um usuário relata que a edição de um filtro salvo às vezes é revertida. Você descreve o problema, o agente encontra uma condição de corrida entre duas atualizações de estado e propõe uma proteção. Você aplica, testa uma vez, funciona, e segue em frente. Dois dias depois, o relato volta.
O que deu errado não foi a correção. É que uma única tentativa manual é uma amostra de tamanho um contra um bug intermitente, e bugs intermitentes passam em uma tentativa isolada quase tantas vezes quanto falham. O ciclo que realmente converge é outro: escreva a sequência como um caso, execute-a várias vezes e leia a taxa. Quatro falhas em dez é uma instrução completamente diferente de "está quebrado" para o agente, porque descarta toda uma classe de causas determinísticas e aponta para uma questão de temporização.
A segunda coisa que muda é o que acontece depois da correção. O mesmo caso roda de novo, dez vezes, e a taxa vai a zero ou não vai. Agora você tem evidência em vez de impressão, e o caso permanece na suíte, de modo que o terceiro relato nunca chega.
A afirmação que merece desconfiança
"Corrigi o problema" é a frase mais cara do debug assistido por agentes. Ela é gerada pelo mesmo raciocínio que produziu a mudança, então não carrega nenhuma informação independente. Uma correção só está confirmada quando o comportamento é observado como correto e, por definição, o agente que a escreveu não pode ser quem confirma.
Isso não é uma crítica ao modelo. Um humano que escreve um patch e depois o declara correto sem rodar nada receberia a mesma resposta na revisão.
Faça a verificação sobreviver à sessão
O caso que você escreveu para reproduzir o bug vale mais depois da correção do que durante. Guarde-o e execute-o a cada mudança, para que o mesmo defeito não volte silenciosamente três semanas depois.
O GitHub App é um webhook que você configura no dashboard do TestSprite. Ele escuta o evento de deploy que o seu pipeline já produz, então nada muda no seu repositório.
GitHub Actions coloca a etapa dentro do seu próprio workflow, configurada pelo terminal.
O que muda com uma etapa de verificação no ciclo
O TestSprite fornece a observação que falta no ciclo. A configuração instala uma skill de verificação dentro do próprio Cursor, para que o agente possa criar um caso, executá-lo contra o seu app publicado e ler o resultado sem que você precise repassar nada.
O efeito prático em uma sessão de debug é que as rodadas param de se repetir. O agente deixa de raciocinar sobre a sua lembrança do que viu; ele tem um registro do que foi tentado, do que a aplicação fez e de onde as duas coisas divergiram. Uma correção proposta por ele é confirmada por algo diferente do raciocínio que a produziu, que é a única forma de "corrigi isso" virar informação.
A reprodução também sobrevive à sessão. O caso que encontrou o bug permanece na suíte e roda a cada mudança, de modo que o mesmo defeito não volta silenciosamente dali a seis semanas.
O Cursor consegue depurar sem executar a aplicação?
Ele consegue raciocinar sobre o código e, muitas vezes, encontrar o defeito assim, especialmente em erros de lógica com um rastro claro. O que ele não consegue é confirmar uma correção, nem enxergar problemas de estado, temporização ou integração que só aparecem com o app em execução.
Por que o mesmo bug volta?
Porque a reprodução costuma viver no chat, não em um teste. Quando a conversa acaba, ninguém mais está verificando aquele comportamento.
Isso substitui o fluxo de debug do Cursor?
Não. Ele fornece a etapa de observação que falta. O Cursor continua propondo a mudança, você continua decidindo se ela faz sentido, e a verificação diz aos dois se funcionou.
Quanto do meu código ele enxerga?
A verificação roda contra a aplicação publicada, pela interface dela, então ela relata comportamento em vez de ler o seu repositório.
E se o bug só aparece em produção?
Aponte uma execução para um ambiente que o reproduza. Se o comportamento muda de um ambiente para outro, essa diferença costuma ser o bug de verdade e vale investigar antes de mexer no código.
Dê olhos ao agente, não prompts mais longos.
O Cursor como ferramenta de debug trava porque nada no ciclo observa o app em execução. Forneça essa etapa, exija evidência em vez de uma declaração de sucesso e mantenha a reprodução como teste para que a correção se sustente.