Que Erros Devs Cometem Programando Com Assistentes de IA?

Assistentes de IA como Copilot, Claude e os modelos integrados do Cursor mudaram a velocidade com que o código é escrito. Eles não mudaram com que cuidado precisa ser revisado. A maioria dos danos que vi da codificação assistida por IA vem de um punhado de hábitos repetíveis, não dos modelos em si.

Aceitar sugestões sem lê-las

O maior deles é aceitar um preenchimento com tab porque parece plausível e compila. Plausível não é correto. Já vi uma consulta SQL sugerida silenciosamente descartar uma cláusula WHERE durante um refatoração, e a pessoa aceitou porque os nomes de variáveis correspondiam. Se você não está lendo cada linha que um assistente entrega na mesma velocidade que leria um pull request de um colega, você vai enviar algo que não entende. Trate cada sugestão como um primeiro rascunho de um dev júnior que é rápido mas não tem memória das convenções do seu repositório.

Confiar nele com código sensível a segurança

Assistentes de IA são treinados em pilhas enormes de código público, e muito desse código tem problemas de segurança já baked in. Peça um manipulador de upload de arquivo rápido e frequentemente você vai receber algo sem verificação de extensão, sem limite de tamanho, e um caminho construído por concatenação de string em vez de os.path.join ou uma chamada de biblioteca segura. Mesma história com auth: assistentes adoram sugerir armazenar JWTs em localStorage, ou comparar secrets com == em vez de uma comparação de tempo constante. Nada disso é malicioso, é apenas estatisticamente comum nos dados de treinamento. Para qualquer coisa tocando autenticação, I/O de arquivo, desserialização, ou SQL, escreva a lógica você mesmo ou execute a saída da IA pelas mesmas perguntas de threat modeling que faria de qualquer código novo: o que acontece com entrada hostil, o que acontece se essa chamada falhar, quem mais pode alcançar esse endpoint.

Deixar isso inventar dependências e APIs

Modelos alucinam nomes de pacotes e assinaturas de função com confiança total. Este é o problema "slopsquatting" — atacantes registram os nomes de pacotes falsos que modelos frequentemente sugerem, então um pip install ou npm install não verificado pode baixar algo que não é sua biblioteca de logging. Antes de adicionar qualquer dependência que um assistente recomenda, verifique que ela realmente existe em PyPI ou npm, verifique sua contagem de downloads e data de última publicação, e dê uma folheada no código se for pequeno o suficiente. A mesma cautela se aplica a chamadas de API: se o assistente referencia um método que você não reconhece, verifique os docs reais antes de assumir que existe.

Perder o modelo mental do seu próprio código

Quando você escreve código você mesmo, você constrói um mapa mental do porquê cada peça existe. Quando você aceita blocos grandes de código gerado por IA ao longo de uma sessão, esse mapa fica fino rápido. Daí um bug aparece três semanas depois e você está debugando código que nunca realmente escreveu e não lembra completamente. O conserto não é evitar código gerado por IA, é desacelerar o suficiente para explicar cada pedaço para você mesmo, ou para um colega, antes de fazer merge. Se você não consegue explicar o que uma função faz e por que faz desse jeito, não faça merge ainda.

Pular testes porque o código