Insetos São Irritantes

Uma análise de QA adversarial para qualquer base de código, em qualquer idioma. IDEs de IA são otimizadas para produzir código que parece finalizado — elas não são otimizadas para produzir código que é correto. Esta habilidade existe para fechar essa lacuna, tentando ativamente quebrar o código em vez de confirmar que ele funciona.

Mentalidade Principal

Trate todo código como culpado até que se prove inocente. A pergunta padrão ao ler a saída de um agente construtor não é "isso parece certo?" — é "como isso quebraria, e o que o autor não pensou?".

Esta é uma análise adversarial, não confirmatória. Não leia rapidamente e aprove. Não pule uma categoria porque "parece bem". Cada categoria na taxonomia abaixo deve ser verificada ativamente contra o código real, não assumida como limpa.

Quando Usar

Acione em: "encontrar bugs", "auditar este código/base de código", "executar caçador de bugs", "verificar erros", "encontrar falhas", "revisar isto para bugs", "este código é sólido", ou qualquer solicitação para uma análise profunda de correção em vez de uma revisão de estilo/legibilidade.

Processo — Execute Estas Fases Em Ordem

Não pule fases ou as combine em uma única leitura rápida. Cada fase captura coisas que as outras perdem.

0. Determinar escopo — Se o usuário nomeou um arquivo ou pasta específica, limite a isso. Caso contrário, pergunte antes de começar: confirme se deve auditar toda a base de código, apenas os arquivos alterados em relação ao branch principal (git diff), ou uma área específica. Nunca adivinhe silenciosamente o escopo em uma base de código de tamanho desconhecido — uma passagem "exaustiva" sem escopo em um repositório grande pode estourar o contexto no meio da auditoria. Dentro do escopo, sempre exclua diretórios gerados e de dependências (node_modules, vendor, dist, build, .git) e arquivos minificados/empacotados — este não é o código escrito pelo usuário e auditá-lo desperdiça a passagem. Arquivos de lock são excluídos por padrão, mas devem ser inspecionados ao verificar Problemas de Dependência.
1. Mapear a base de código — Identifique os pontos de entrada, o fluxo geral de dados e o que chama o quê antes de procurar qualquer coisa. Você não pode encontrar um bug entre arquivos sem primeiro conhecer as relações entre os arquivos.
2. Passagem estática linha por linha — Leia todos os arquivos relevantes/alterados completamente, não uma leitura rápida. Verifique cada linha contra a taxonomia abaixo.
3. Rastrear caminhos críticos de dados — Siga os dados da entrada para a saída através de limites de arquivos/funções. A maioria dos bugs reais vive nas junções entre funções e arquivos, não dentro de uma única função.
4. Simulação adversarial — Execute mentalmente o código contra entradas hostis/de borda: nulo, indefinido, string vazia, array vazio, zero, números negativos, entrada de comprimento máximo, chamadas duplicadas, chamadas concorrentes, entrada malformada, campos ausentes.
5. Passagem de referências cruzadas — Quando um bug é encontrado, verifique ativamente se o mesmo erro foi repetido em outro lugar. IDEs de IA frequentemente copiam e colam o mesmo padrão falho em vários arquivos.
6. Triagem de gravidade — Classifique cada achado usando as definições abaixo. Não invente novos rótulos de gravidade.
7. Escrever/atualizar bugs.md — Use o formato exato abaixo. Esta é a única saída de uma caçada — não narre um resumo longo no chat; aponte o usuário para o arquivo.

Taxonomia de Bugs

Independente de linguagem. Verifique cada categoria — estes são padrões, não sintaxe, então eles se aplicam independentemente da pilha.

• Erros de lógica — erros de um a mais, condicionais invertidos, precedência incorreta de operadores, lógica booleana incorreta
• Segurança de nulo/tipo — nulo/indefinido não tratado, conversões inseguras, falta de encadeamento opcional, tipo assumido incorreto
• Casos de borda — entrada vazia, zero, números negativos, coleções de item único vs. múltiplos itens, primeira/última iteração de um loop
• Tratamento de erros — exceções engolidas, falta de try/catch em torno de chamadas falíveis, erros capturados mas não registrados ou exibidos, erro incorreto propagado na pilha
• Concorrência/assíncrono — condições de corrida, promessas não aguardadas, closures desatualizadas, estado atualizado após um componente/processo já ter sido encerrado
• Segurança — pontos de injeção, segredos/chaves codificados, bypass de autenticação ou permissão, desserialização insegura
• Vazamentos de recursos — identificadores de arquivo/streams/conexões não fechados, listeners ou assinaturas nunca removidos
• Consistência entre arquivos — uma função/tipo/campo alterado em um arquivo, mas os locais de chamada em outros não atualizados (o modo de falha mais comum de IDEs de IA, já que os agentes construtores tendem a editar um arquivo por vez)
• Incompatibilidades de API/contrato — chamador e chamado discordam sobre um nome de campo, tipo ou parâmetro necessário
• Gerenciamento de estado — mutação de estado que deveria ser imutável, estado derivado que fica desatualizado, atualizações duplas

…