Por que os bugs de código do Windsurf passam pela revisão
A revisão humana escala com o número de linhas que uma pessoa consegue manter na cabeça. Uma mudança ampla e mecânica derrota isso de um jeito específico: cada trecho é plausível isoladamente, então a atenção vai escorregando. Você aprova o décimo segundo arquivo com menos rigor do que o primeiro, e o defeito quase sempre está no fim da fila.
O defeito também raramente está no que mudou. Está no que não mudou. Uma renomeação que deixou passar um ponto de chamada, um novo campo obrigatório que três construtores não passam, um handler atualizado em todo lugar menos no caminho de erro.
As três formas em que uma mudança ampla quebra
Varreduras incompletas
Onze pontos de chamada atualizados, um esquecido, e ele está num caminho que ninguém exercita todo dia.
Os tipos muitas vezes não pegam isso porque o ponto esquecido já era fracamente tipado.
Desvio de premissas
Dois arquivos acabam discordando sobre o que um valor significa, como se um timestamp está em segundos ou em milissegundos.
Cada arquivo é internamente consistente, então nada parece errado isoladamente.
Mudança silenciosa de comportamento
Uma refatoração preserva a interface e muda sem avisar a ordenação, os valores padrão ou um caminho de erro.
Testes escritos contra a implementação antiga continuam passando porque verificam a interface.
As três compartilham uma propriedade: você as encontra usando a aplicação, não lendo. É isso que as torna caras.
Verifique o comportamento, não o diff
Para uma mudança ampla, a pergunta útil não é "cada edição está correta", e sim "o produto continua fazendo o que fazia, mais a coisa nova". Essa é uma pergunta sobre comportamento, e ela é respondida conduzindo a aplicação implantada pelos fluxos que a mudança poderia plausivelmente ter tocado.
A cobertura não precisa ser exaustiva para ser útil. Uma mudança que renomeia um campo ao longo do caminho de checkout precisa que o checkout seja exercitado de ponta a ponta uma vez, o que vale mais do que ler doze diffs com atenção.
Instale a skill de verificação no editor para que o próprio agente possa rodar essa checagem em vez de esperar por você.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
O dashboard faz a mesma configuração, caso você prefira não instalar nada. O restante da superfície da CLI está no repositório da CLI.
Dê ao agente a falha, não o seu resumo
Quando algo de fato quebra, o ciclo de correção só se fecha se a evidência for utilizável. O que foi tentado, o que a aplicação fez, onde os dois divergiram. Com isso em mãos, o agente consegue voltar aos mesmos doze arquivos com um alvo específico. Com um screenshot em mãos, ele adivinha, e você volta a ter que descrever tudo.
Lendo um diff amplo sem fingir
Existe uma versão honesta de revisar uma mudança de doze arquivos, e ela não é ler cada trecho. É decidir, antes de abrir o diff, o que precisaria ser verdade para essa mudança estar correta, e então checar apenas essas coisas.
Para uma renomeação, isso é se todos os pontos de chamada mudaram, o que o compilador em boa parte responde, e se algo constrói o nome dinamicamente, o que ele não responde. Para um novo campo obrigatório, são todos os caminhos que constroem o objeto, incluindo testes e fixtures que vão continuar passando silenciosamente uma versão incompleta. Para uma refatoração que preserva uma interface, são a ordenação e os caminhos de erro, porque é isso que as refatorações mudam sem avisar.
Três perguntas por mudança valem mais do que passar o olho em quatrocentas linhas, e isso deixa você com a lista honesta do que ainda precisa ser verificado rodando a coisa.
Escolha os fluxos pelo raio de impacto, não pela importância
Por instinto, as pessoas cobrem a funcionalidade mais importante. Para uma mudança ampla, a pergunta melhor é quais fluxos a mudança poderia plausivelmente ter tocado, ordenados por quão silenciosamente eles falhariam.
Um fluxo de pagamento é importante e também é vigiado. Se ele quebra, você fica sabendo em uma hora. Os perigosos são os fluxos que importam, mas são usados semanalmente e não de hora em hora: uma exportação, um convite, uma página de configurações, um resumo agendado. É neles que uma varredura incompleta fica intocada por um mês.
Então, depois de uma mudança ampla, exercite primeiro os caminhos silenciosos. Eles são baratos de cobrir e são justamente os que mais ninguém está checando.
Rode isso em todo pull request
Mudanças amplas são exatamente aquelas em que as pessoas se sentem tentadas a fazer merge rápido porque o diff é chato. Esse é o argumento para que a verificação seja automática em vez de depender de alguém lembrar.
São dois caminhos, e a escolha é, na real, sobre quem é dono do pipeline. Conectar o GitHub App pelo dashboard não exige nenhuma mudança no seu repositório, porque ele reage ao deploy que o seu build já emite. Adicionar um passo de GitHub Actions coloca a verificação dentro do repositório, onde ela é revisada como o resto do build.
Verificando uma mudança ampla sem lê-la
O TestSprite responde à pergunta que um diff amplo não consegue: o produto continua fazendo o que fazia, mais a coisa nova. Ele abre a aplicação implantada, percorre os fluxos que a mudança poderia plausivelmente ter tocado e relata comportamento em vez de estrutura.
Esse é o formato certo para esse problema. Varreduras incompletas, premissas que divergem e mudanças silenciosas de comportamento são todas invisíveis no código-fonte e óbvias no uso. A cobertura é gerada a partir do seu produto em vez de escrita à mão, então os fluxos silenciosos, a exportação e o convite e a página de configurações, entram sem que ninguém precise lembrar deles.
Quando algo de fato quebra, a falha volta como um pacote único sobre o qual o seu agente pode agir, e é isso que mais importa aqui: apontá-lo para a divergência específica é melhor do que pedir que ele reexamine doze arquivos.
Por que os tipos não pegam esses casos?
Eles pegam boa parte das varreduras incompletas e quase nada do desvio de premissas ou das mudanças silenciosas de comportamento, porque esses dois são corretos em termos de tipo por construção.
Devo simplesmente pedir mudanças menores?
Ajuda, e abre mão de boa parte do motivo para usar um editor agêntico. Uma etapa de verificação permite manter a largura e ainda assim saber se o resultado funciona.
Isso funciona quando a mudança é só de backend?
Sim, por meio de cobertura no nível da API em vez da interface. O princípio é o mesmo: exercitar o comportamento em vez de ler a mudança.
Quanto tempo leva uma verificação dessas?
Tempo suficiente para você não rodá-la a cada tecla digitada, e pouco o bastante para caber em um pull request. É esse o lugar certo para ela.
E se o agente já tiver rodado os testes unitários?
É útil, mas testes unitários costumam ter sido escritos contra as premissas que a mudança acabou de alterar. Eles confirmam consistência interna, não correção externa.
Com doze arquivos, ler o diff não é uma verificação.
Bugs de código do Windsurf se escondem em varreduras incompletas, premissas que divergem e mudanças silenciosas de comportamento. Verifique o produto rodando em vez do diff, devolva as falhas como evidência e faça a verificação rodar em todo pull request.