Erros de assistentes de programação com IA e como evitá-los

A maioria dos erros de assistentes de programação com IA começa antes de o código ser gerado: a tarefa é vaga, as restrições estão ocultas ou ninguém define como o resultado será validado. A prevenção não é evitar a IA. É dar ao assistente um problema de engenharia melhor para resolver.

Estes são os padrões de falha que tornam alterações tecnicamente válidas arriscadas, além de um hábito concreto que evita cada um deles.

“Mova o botão para a barra lateral” diz a um assistente onde colocar algo, não por que o posicionamento atual falha.

Prevenção: Declare primeiro o problema do usuário e o resultado.

Problema: O seletor de tópicos compete com a navegação global, mas as pessoas o
usam enquanto comparam lições em um curso.

Resultado: Facilite encontrar a troca de tópicos perto da navegação do curso sem
alterar as ações globais da barra de navegação.

Agora o assistente pode questionar a escolha do local se outro padrão para telas pequenas for mais seguro.

“Limpe o fluxo de autenticação” convida a um diff grande. O assistente pode alterar provedores, rotas, testes e chamadas de API porque não enxerga um limite.

Prevenção: Nomeie o primeiro limite e os itens fora do escopo.

Inspecione apenas o callback de login e seus testes diretos. Não altere a
vinculação de contas, a cobrança ou os guardas de rota, a menos que as evidências
mostrem que o callback não pode ser corrigido isoladamente.

Se o trabalho realmente atravessar um limite, o assistente deve explicar por quê antes de expandir.

Um assistente não consegue inferir todas as regras do produto a partir de um componente. Ele pode introduzir um caminho exclusivo do servidor em um aplicativo estático, quebrar uma rota que preserva a localidade ou duplicar um escritor de estado.

Prevenção: Coloque invariantes essenciais no prompt ou em orientações duráveis do projeto.

Preserve a exportação estática, a navegação com localidade ativa, os nomes
existentes de eventos de analytics e o escritor único atual das preferências de
notificação.

Mantenha a lista curta e específica. Uma longa lista de desejos é menos útil do que alguns contratos que podem ser aplicados.

Código gerado pode compilar e ainda ter a transição de estado, o caminho de erro, o comportamento de acessibilidade ou o limite de segurança errados.

Prevenção: Exija um plano de validação antes da implementação.

Liste os testes focados, a verificação de tipos e o cenário manual que
comprovariam esta alteração. Explique qual comportamento cada verificação cobre
e o que permanece sem verificação.

Execute as verificações. Revise o diff. Percorra o caminho do usuário. A saída da IA é uma proposta, não um critério de lançamento.

Um diff grande esconde se o bug real foi corrigido. É difícil de revisar e quase impossível de reverter com segurança.

Prevenção: Peça uma sequência de pequenos pontos de verificação.

Primeiro reproduza e explique a falha. Em seguida, faça apenas a correção de
estado e adicione o teste de regressão. Não refatore componentes relacionados até
que o teste focado passe e o diff seja revisado.

A alteração menor pode revelar que a refatoração planejada não era necessária.

“Torne esta página mais rápida” pode produzir cache, memoização ou divisão de código que escondem o verdadeiro gargalo e criam novos riscos de invalidação.

Prevenção: Peça medição e alternativas.

Identifique se a lentidão está na rede, na computação ou na renderização. Indique
a medição, a linha de base e o impacto esperado antes de propor uma otimização.
Não adicione cache persistente até que atualização e invalidação estejam definidas.

O trabalho de desempenho deve alterar um custo medido, não apenas adicionar uma técnica conhecida.

Um assistente pode remover uma barra lateral do desktop para melhorar o layout móvel ou simplificar um fluxo de que as pessoas dependem. O código pode estar limpo enquanto o produto piora.

Prevenção: Nomeie as pessoas, o fluxo de trabalho e o comportamento que devem permanecer.

Alunos em dispositivos móveis precisam de mais espaço horizontal. Alunos no
desktop dependem da barra lateral para navegar pelo curso. Melhore o layout móvel
preservando o fluxo de trabalho do desktop e seu caminho de teclado.

Isso transforma “remova a barra lateral” em uma restrição de design real.

Incidentes de produção geram urgência, mas urgência não é motivo para deixar um assistente adivinhar a partir de um sintoma.

Prevenção: Use a sequência de evidência até validação:

evidências -> hipóteses -> verificação -> menor correção -> teste de regressão ->
checagem de rollout seguro

Inclua logs com valores confidenciais removidos, etapas de reprodução, ambiente, alterações recentes, comportamento esperado e comportamento observado. Não aplique cegamente patches gerados na produção.

Problema: [Quem é afetado e o que está acontecendo?]
Escopo: [O que deve ser inspecionado primeiro?]
Resultado: [Qual resultado observável é necessário?]
Restrições: [O que não deve mudar?]
Evidências: [Teste, log, captura de tela, saída de comando ou reprodução.]
Critérios de aceitação: [Como saberemos que funcionou?]
Validação: [Testes, verificações manuais ou medições.]

Questione o pressuposto antes de editar. Se a solução solicitada não for
respaldada pelas evidências, explique a alternativa mais segura.

Para uma explicação completa dessa estrutura, leia como escrever prompts melhores para IA. Para padrões de implementação do dia a dia, use engenharia de prompts para desenvolvedores. Quando houver um incidente, siga os modelos de prompt para depurar problemas de produção.

Saída de terminal também é evidência. Pratique um fluxo de trabalho de linha de comando no navegador antes de codificá-lo em um relatório de bug, teste ou prompt de automação.