Segunda-feira de manhã. Você digita um prompt no Cursor, Claude Code ou Copilot. Três minutos depois, uma feature aparece no seu PR — o pull request que seu código submete antes de ser mergeado na branch principal. CI verde. Ticket fechado. Dose de dopamina. Você agora é um dev 10x.

Uma semana depois, aquela feature quebra às 3 da manhã. Você abre o arquivo. Não consegue rastrear o bug. Você não escreveu esse código. A IA escreveu. E não deixou nenhuma pista. Você precisa de um debugger. Mas nem todo debugger significa a mesma coisa mais.

Dois Debuggers Entram Num Bar na Mesma Semana

Entre 14 e 16 de abril, enquanto o resto da indústria continuava construindo geradores de código cada vez mais rápidos, duas ferramentas finalmente admitiram que código gerado por IA quebra de forma diferente do código escrito por humanos — e precisa de ferramentas diferentes para consertar.

No dia 14, o Cursor 3.1 lançou tanto um comando /debug via CLI quanto background agents que criam PRs automaticamente a partir de issues do GitHub — um release montado nos dois lados da cerca. No dia 16, o Visual Studio 18.5 soltou um debugger agêntico que gera hipóteses de falha e configura breakpoints pra você. Enquanto isso, o lado da geração não ficou pra trás: o Claude Code lançou Routines no dia 14 e a OpenAI atualizou o Codex no dia 16 para 3 milhões de usuários semanais com uso do desktop e mais de 90 plugins.

Ratio geração-para-debugging nessa semana: 3:2 (contando os background agents do Cursor no lado da geração e o /debug no lado do debugging). Progresso, eu acho.

Mesma Palavra, Duas Filosofias Diferentes

O /debug do Cursor e o debugger agêntico do Visual Studio prometem debugar. Fazem coisas fundamentalmente diferentes.

O /debug do Cursor lê a saída de erro do seu terminal — stack traces, assertions que falharam, gritos do compilador — correlaciona com seus arquivos abertos e contexto do projeto, e gera um patch. Por baixo dos panos, é um re-prompt com contexto melhor. A IA ingere o erro, chuta o que quebrou e cospe código substituto. Se o patch não colar, você re-prompta. Se isso não colar, você deleta a função e regenera do zero. O workflow otimiza pra velocidade: erro → patch → deploy. Seu trabalho é avaliar o resultado, não entender o caminho.

Essa é uma escolha de design legítima. Aqueles background agents no mesmo release do Cursor 3.1 — rodando em sandboxes na nuvem, transformando issues do GitHub em PRs sem intervenção humana — revelam a filosofia do produto com clareza. O código é descartável, o resultado importa, iteração é barata. O /debug é consistente com essa visão de mundo. Não entenda o código quebrado. Substitua por código que funciona. Siga em frente.

O debugger agêntico do Visual Studio faz a aposta oposta. Quando você descreve um bug ou cola uma exception, o agente não gera um fix. Ele gera hipóteses — explicações ranqueadas sobre por que a falha aconteceu. Depois ele instrumenta seu código: configura breakpoints condicionais nos pontos que cada hipótese prevê como defeituosos, configura watch expressions em variáveis suspeitas e te guia pelo caminho real de execução passo a passo.

O anúncio da Microsoft descreve o agente avaliando "código relevante, mudanças recentes e padrões comuns de erro" para produzir sua lista de hipóteses. O debugger então entra no que eles chamam de loop de investigação: bate num breakpoint, inspeciona o estado, confirma ou rejeita uma hipótese, segue pra próxima. Você não está lendo código gerado por IA. Está lendo o comportamento real do seu runtime, guiado por uma IA que reduz o espaço de busca.

A diferença mecânica chave: o /debug do Cursor opera sobre texto — código-fonte como uma string a ser reescrita. O debugger do Visual Studio opera sobre execução — estado do runtime como evidência a ser examinada. Um trata código como documento. O outro trata código como máquina.

Por Que Essa Distinção Realmente Importa

Pra um null pointer numa função utilitária, não importa. O /debug do Cursor resolve em segundos. O debugger do Visual Studio seria matar formiga com bazuca.

Mas bugs gerados por IA geralmente não são null pointers. As pesquisas continuam se empilhando — dados de qualidade de código da GitClear, múltiplas replicações acadêmicas — mostrando que código co-autorado com IA carrega significativamente mais erros de lógica e problemas de performance que código escrito à mão. Os bugs que importam não são problemas de sintaxe. São incompatibilidades comportamentais sutis: um handler de API que passa nos testes mas faz escrita dupla sob requisições concorrentes, uma query de banco que retorna resultados corretos em datasets pequenos mas gera joins O(n²) em escala, uma máquina de estados que lida com o happy path mas corrompe dados silenciosamente no retry.

Esses bugs não se anunciam na saída do terminal. Eles se manifestam como degradação lenta, falhas intermitentes, inconsistências de dados que surgem dias depois. O /debug do Cursor precisa de uma mensagem de erro pra trabalhar. O que você alimenta ele quando o sintoma é "a receita do checkout caiu 4% na terça e ninguém sabe por quê"?

A abordagem baseada em hipóteses do Visual Studio lida com isso de forma diferente. Você descreve o sintoma. O agente propõe causas candidatas — talvez a lógica de retry do pagamento cobre duas vezes, talvez a verificação de estoque faça race condition com a atualização do carrinho, talvez o cálculo de desconto trunca em vez de arredondar. Ele configura breakpoints em cada local candidato. Você reproduz o cenário e observa o caminho de execução revelar qual hipótese se sustenta.

Mais lento? Absurdamente. Exige que você use o cérebro? Infelizmente, sim. Mas é a única ferramenta lançada esse mês que trata debugging como investigação em vez de mais uma rodada de geração.

A Bifurcação dos Workflows

É aqui que a indústria se divide.

Caminho A: modelo do Cursor. Código é barato. Debugging é regeneração. Quando algo quebra, joga fora e prompta de novo. O /debug aperta esse loop. Background agents tornam ele autônomo. O ponto lógico final é código que ninguém jamais lê — gerado, testado, deployado e substituído por máquinas num loop contínuo. Devs viram product managers que descrevem intenções e avaliam resultados.

Caminho B: modelo do Visual Studio. Código é infraestrutura. Debugging é compreensão. Quando algo quebra, entenda por quê antes de consertar, porque a mesma falha estrutural vai reaparecer na próxima geração se você não entender. O ponto lógico final são devs que entendem menos código no total mas entendem ele em profundidade — especialistas em comportamento de sistemas em vez de produção de sintaxe.

Nenhum dos caminhos é burro. Mas são incompatíveis no mesmo codebase. Um time que debuga por regeneração não constrói nenhum conhecimento institucional de como o sistema realmente se comporta. Um time que debuga por investigação gasta tempo que times regeneration-first chamam de desperdício.

Adivinha Qual Abordagem Ganha

A do Cursor, obviamente. É mais rápida. Exige menos pensamento. Encaixa no workflow de vibe coding que a indústria abraçou unanimemente. Deleta, re-prompta, deploya, repete. Investigação é problema dos outros — até a produção pegar fogo e "os outros" ser você às 3 da manhã, olhando pra três serviços que três prompts diferentes escreveram, assistindo a interação entre eles derrubar o checkout.

Você não consegue sair de uma falha de sistema distribuído na base do re-prompt. Você precisa de alguém que mapeou os caminhos de execução. E se sua cultura de debugging é "substitui até ficar verde", essa pessoa não existe no seu time.

A abordagem do Visual Studio é mais difícil de vender. "Deixa eu te ajudar a pensar" perde pra "deixa eu resolver pra você" em todo demo, todo tweet, todo ciclo de hype. Mas compreensão se acumula. Regeneração não.

A Parte Desconfortável

A pergunta não é qual debugger é melhor. É qual filosofia de debugging seu time adota — e se vocês escolheram deliberadamente ou só foram na que é mais rápida por inércia.

Se sua stack é de funções stateless e serviços de vida curta, o loop de regeneração do Cursor pode genuinamente ser suficiente. Substitui a lambda quebrada. Segue em frente. Ninguém precisa entender uma função que vive por um ciclo de release.

Se sua stack tem estado, tem transações distribuídas, tem comportamento que emerge da interação entre componentes — alguém tem que entender o runtime. Não o texto do código-fonte. O runtime. O debugger do Visual Studio é a primeira ferramenta de IA que reconhece que esse trabalho existe.

Segunda-feira de manhã, você vai digitar outro prompt. Algo vai quebrar. A pergunta não é se você vai debugar. É se debugar significa "gera de novo" ou "entende por quê". Escolha de propósito. O padrão é regeneração. E às 3 da manhã, o padrão é tudo que você tem.