Erros de código com IA:4 formas de sabotar o teu sistema

Os erros de código com IA não vão sabotar o teu sistema com código que se parte. Sabotam-no com código que funciona — durante uns seis meses. O Claude está confiantemente errado a toda a hora, e a versão perigosa não é quando está obviamente errado. É quando está plausivelmente errado: código que compila, corre e parece estar bem, construído sobre um pressuposto errado acerca dos teus dados ou da tua lógica de negócio.

Ao longo dos onze meses a construir o FIKR Space, os mesmos quatro maus padrões continuaram a sair da IA. Cada um teria criado um tipo diferente e específico de dor seis meses depois, se eu o tivesse aceitado. Aqui estão, em linguagem simples — o que o Claude propõe, porque é que parece razoável e exatamente quanto te custa mais tarde.

Erros de código com IA: porque é que tende para o medíocre

O Claude foi treinado com milhões de bases de código, e a maioria era medíocre. Quando não especificas o que queres, recebes o resultado da base de código mediana — cheio de atalhos e compromissos que engenheiros experientes nunca aceitariam. Nenhum destes atalhos falha hoje. Todos falham mais tarde, e é exatamente por isso que sobrevivem à revisão de um fundador que só verifica se a funcionalidade funciona agora.

O teu trabalho não é escrever o código. O teu trabalho é ser a voz sénior da parceria — contestar quando alguma coisa não te cheira bem, mesmo quando não consegues explicar logo porquê.

Erro 1: O blob JSON — uma gaveta da tralha em vez de um arquivador

O Claude vai sugerir guardar dados estruturados como um blob JSON — um campo flexível que guarda tudo — em vez de uma tabela a sério com colunas a sério. Pensa nisto como atirar os teus documentos para a gaveta da tralha em vez de os arrumar num arquivador. A gaveta funciona bem enquanto lá estão dez documentos.

Isto aconteceu-me na terceira semana. O Claude propôs guardar os dados de objetivos estratégicos dos utilizadores — objetivos trimestrais, estado dos OKR, métricas de alinhamento — como uma coluna JSON na tabela de utilizadores. Teria funcionado. Durante uns três meses. Depois precisei de responder a uma pergunta de negócio básica: mostra-me todos os utilizadores cuja conclusão de objetivos do 3.º trimestre está abaixo dos sessenta por cento. Com um blob JSON, responder a isso significa abrir a gaveta da tralha de cada utilizador e ler tudo o que lá está antes de conseguires filtrar — uma abordagem que aguentava cinquenta utilizadores e teria morrido aos quinhentos. Corrigir isso mais tarde teria significado migrar seis meses de dados de clientes e reescrever doze serviços. Contestar na terceira semana custou uma hora extra de conversa de design. Reconstruir ao sexto mês teria custado três semanas.

Erro 2: Enums — gravar em pedra as opções de hoje

Um enum é um campo cujos valores permitidos são fixados à partida — como imprimir o menu do teu restaurante em vez de o escrever num quadro branco. O Claude tem uma forte tendência para usar enums em qualquer campo com um conjunto pequeno e conhecido de valores: nível de subscrição, função do utilizador, tipo de notificação. Cada um parece obviamente fixo no momento.

Todos os meus acabaram por precisar de novos valores em menos de um ano — um novo nível de subscrição, uma nova função, uma nova categoria de notificação. E alterar um enum na base de dados exige um ritual de vários passos: remover restrições, recriar o tipo, atualizar cada linha. Uma tabela de consulta — a versão do quadro branco — é uma tabela normal que cresce acrescentando uma linha. O enum prende a coluna à realidade de hoje; a tabela de consulta acomoda a de amanhã. O mesmo padrão, uma escolha por defeito diferente. Contesta. Exige a tabela de consulta.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Erro 3: Tipos any — desligar o detetor de fumo

O trabalho todo do TypeScript é apanhar uma classe inteira de bugs antes de os teus utilizadores os verem, verificando que cada dado tem a forma que o código espera. Quando essa verificação falha em algo complexo, o Claude propõe por vezes marcar os dados como any — o que quer dizer "deixa de verificar isto". O erro desaparece. A compilação passa. A funcionalidade é lançada. Acabaste de desligar um detetor de fumo, e nada acontece até haver fumo.

Este é o padrão mais traiçoeiro, porque o sintoma é invisível. Seis meses depois, mudas outra coisa noutra parte do produto, e o erro de tipo que devia ter apanhado a avaria não aparece — porque algures a montante um any está a engolir o sinal em silêncio. O bug vai para produção. Descobres por uma queixa de um cliente. Cada any que aceitas agora é uma futura terça-feira à tarde passada a depurar um problema que o sistema de tipos devia ter evitado.

Erro 4: Engolir erros em silêncio — falhas que ninguém ouve

O pior dos quatro. O Claude escreve por vezes o equivalente a try { ... } catch (e) { return null } — "se alguma coisa correr mal, não digas nada e devolve um resultado vazio" — e chama-lhe tratamento elegante de erros. Esse código passa em todos os testes que escreves, porque os teus testes não provocam deliberadamente o modo de falha.

Em produção, quando a falha real acontece, a função não devolve nada. Em silêncio. O resto do sistema não sabe que algo correu mal. O utilizador vê um ecrã em branco. O erro não fica registado em lado nenhum. Só descobres quando um cliente se queixa — e mesmo assim não consegues rastrear o que aconteceu, porque nunca foi lançado nenhum erro. Combate isto todas as vezes: falhas específicas, tratadas de forma específica, registadas bem alto. As cinco linhas de código a mais poupam-te a próxima falha geral.

O padrão por trás dos quatro erros de código com IA

A boa notícia: o Claude reage bem quando é contestado. Quando dizes "não, quero isto numa tabela separada, não num blob JSON — e é por isto", ele reestrutura o código sem resistência e muitas vezes melhora o que tinha proposto. O modelo é colaborativo. Só tens de ser a voz sénior.

Dois hábitos tornam a contestação sistemática em vez de uma questão de sorte. Faz um bom briefing à IA antes de ela construir o que quer que seja — é esse o método PRP. E nunca deixes a velocidade substituir a estrutura — é essa a lição toda da armadilha do vibe coding. Especifica. Contesta. Exige a estrutura certa. Custa um pouco mais de tempo por funcionalidade, e compra-te um sistema que ainda consegues fazer evoluir ao décimo segundo mês, em vez de um que tens de reconstruir.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Perguntas frequentes

Porque é que o código gerado por IA causa problemas meses depois?

Porque a IA otimiza para pôr a funcionar o pedido de hoje, não para a forma como o código evolui. Treinada com milhões de bases de código, na maioria medíocres, tende para atalhos — blobs flexíveis, listas de valores fixas, verificações desligadas, erros engolidos — que passam em todos os testes agora e só revelam o seu custo quando o produto cresce ou muda.

Como consigo detetar mau código de IA se não sei ler código?

Interroga a mudança e a falha, não a sintaxe. Pergunta à IA: o que acontece quando precisarmos de acrescentar um novo valor aqui? Como pesquisaríamos estes dados quando tivermos dez vezes mais? O que acontece quando esta operação falha — para onde vai o erro? Se as respostas envolverem migrações, reescritas ou "devolve nada", contesta.

Devo deixar o Claude tomar as minhas decisões de arquitetura?

Não. O Claude é um implementador brilhante e um arquiteto medíocre. Pergunta-lhe se uma coisa deve ser uma tabela separada ou uma coluna JSON e a resposta costuma estar bem, às vezes está mal, de vez em quando é ótima — e não consegues distinguir, a menos que tenhas desenvolvido o teu próprio gosto arquitetural. As decisões de arquitetura são tuas; as decisões de implementação são do Claude.

Contestar a IA não torna a construção mais lenta?

Um pouco, por funcionalidade — e é a melhor troca que alguma vez vais fazer. Contestar o blob JSON custou-me uma hora extra de conversa de design na terceira semana. Aceitá-lo teria custado três semanas de reconstrução ao sexto mês, mais a migração de seis meses de dados de clientes.