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

Os erros de código com IA não sabotam o seu sistema com código que quebra. Sabotam com código que funciona — por uns seis meses. O Claude erra com confiança o tempo todo, e a versão perigosa não é quando ele está obviamente errado. É quando está plausivelmente errado: código que compila, roda e parece ok, construído sobre uma premissa errada a respeito dos seus dados ou da sua lógica de negócio.

Durante os onze meses de construção do FIKR Space, os mesmos quatro padrões ruins continuaram saindo 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 eles em português claro — o que o Claude propõe, por que parece razoável e exatamente quanto isso te custa depois.

Erros de código com IA: por que ela tende ao medíocre

O Claude foi treinado em milhões de bases de código, e a maioria delas era medíocre. Quando você não especifica o que quer, recebe o resultado da base de código mediana — cheia de atalhos e concessões que engenheiros experientes jamais aceitariam. Nenhum desses atalhos falha hoje. Todos eles falham depois, e é exatamente por isso que sobrevivem à revisão de um fundador que só confere se a funcionalidade funciona agora.

O seu trabalho não é escrever o código. O seu trabalho é ser a voz sênior da parceria — contestar quando algo não cheira bem, mesmo quando você não consegue explicar na hora o porquê.

Erro 1: O JSON blob — uma gaveta de bagunça em vez de um arquivo

O Claude vai sugerir guardar dados estruturados como um JSON blob — um campo flexível que guarda tudo — em vez de uma tabela de verdade com colunas de verdade. Pense nisso como jogar os seus documentos numa gaveta de bagunça em vez de num arquivo organizado. A gaveta funciona bem enquanto há dez documentos dentro.

Isso apareceu para mim na terceira semana. O Claude propôs guardar os dados de metas estratégicas dos usuários — metas trimestrais, status de OKR, métricas de alinhamento — como uma coluna JSON na tabela de usuários. Teria funcionado. Por uns três meses. Aí eu precisei responder a uma pergunta básica de negócio: me mostre todos os usuários cuja conclusão de metas do terceiro trimestre está abaixo de sessenta por cento. Com um JSON blob, responder isso significa abrir a gaveta de bagunça de cada usuário e ler tudo o que tem dentro antes de poder filtrar — uma abordagem que aguentava cinquenta usuários e teria morrido com quinhentos. Corrigir depois teria significado migrar seis meses de dados de clientes e reescrever doze serviços. Contestar na terceira semana custou uma hora a mais de conversa sobre design. Reconstruir no sexto mês teria custado três semanas.

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

Um enum é um campo cujos valores permitidos são fixados de antemão — como imprimir o cardápio do seu restaurante em vez de escrevê-lo num quadro branco. O Claude tem uma forte tendência a usar enums para qualquer campo com um conjunto pequeno e conhecido de valores: plano de assinatura, papel do usuário, tipo de notificação. Cada um parece obviamente fixo no momento.

Cada um dos meus acabou precisando de novos valores em menos de um ano — um novo plano de assinatura, um novo papel, uma nova categoria de notificação. E mudar um enum no banco de dados exige um ritual de várias etapas: remover restrições, recriar o tipo, atualizar cada linha. Uma tabela de referência — a versão quadro branco — é uma tabela normal que cresce adicionando uma linha. O enum prende a coluna à realidade de hoje; a tabela de referência acomoda a de amanhã. Mesma lógica, outra escolha padrão. Conteste. Exija a tabela de referência.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

Erro 3: Tipos any — desligar o detector de fumaça

O trabalho inteiro do TypeScript é pegar toda uma classe de bugs antes que os seus usuários os vejam, conferindo se cada dado tem o formato que o código espera. Quando essa checagem falha em algo complexo, o Claude às vezes propõe marcar o dado como any — que significa "pare de checar isso". O erro some. O build passa. A funcionalidade vai para o ar. Você acabou de desligar um detector de fumaça, e nada acontece até haver fumaça.

Esse é o padrão mais traiçoeiro, porque o sintoma é invisível. Seis meses depois, você muda algo em outra parte do produto, e o erro de tipo que deveria ter pegado a quebra não pega — porque em algum lugar lá atrás um any está engolindo o sinal em silêncio. O bug vai para produção. Você descobre pela reclamação de um cliente. Cada any que você aceita agora é uma futura tarde de terça-feira gasta depurando um problema que o sistema de tipos deveria ter evitado.

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

O pior dos quatro. O Claude às vezes escreve o equivalente a try { ... } catch (e) { return null } — "se algo der errado, não diga nada e devolva um resultado vazio" — e chama isso de tratamento de erro elegante. Esse código passa em todos os testes que você escreve, porque os seus testes não provocam de propósito o cenário 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 deu errado. O usuário vê uma tela em branco. O erro não fica registrado em lugar nenhum. Você só descobre quando um cliente reclama — e mesmo assim não consegue rastrear o que aconteceu, porque nenhum erro foi disparado. Brigue contra isso todas as vezes: falhas específicas, tratadas de forma específica, registradas em alto e bom som. As cinco linhas extras de código te poupam da próxima pane.

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 você diz "não, quero isso como uma tabela separada, não como um JSON blob — e o motivo é este", ele reestrutura o código sem resistência e muitas vezes melhora o que tinha proposto. O modelo é colaborativo. Você só precisa ser a voz sênior.

Dois hábitos tornam a contestação sistemática em vez de sorte. Passe um briefing adequado para a IA antes que ela construa qualquer coisa — esse é o método PRP. E nunca deixe a velocidade substituir a estrutura — essa é toda a lição de a armadilha do vibe coding. Especifique. Conteste. Exija a estrutura certa. Custa um pouco mais de tempo por funcionalidade, e te compra uma base de código que você ainda consegue evoluir no décimo segundo mês, em vez de uma que você precisa reconstruir.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

Perguntas frequentes

Por que código gerado por IA causa problemas meses depois?

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

Como identificar código ruim de IA se eu não sei ler código?

Questione mudança e falha, não sintaxe. Pergunte à IA: o que acontece quando precisarmos adicionar um novo valor aqui? Como faríamos buscas nesses dados quando tivermos dez vezes mais? O que acontece quando essa operação falha — para onde vai o erro? Se as respostas envolverem migrações, reescritas ou "ela não devolve nada", conteste.

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

Não. O Claude é um implementador brilhante e um arquiteto medíocre. Pergunte se algo deve ser uma tabela separada ou uma coluna JSON e a resposta costuma ser ok, às vezes ruim, de vez em quando ótima — e você não consegue saber qual é, a menos que tenha desenvolvido o seu próprio senso arquitetural. As decisões de arquitetura são suas; as de implementação são do Claude.

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

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