Erros que a IA comete em produção:10 e como impedi-los
Os 10 erros que a IA comete em produção: o que o Claude fez de errado, o padrão correto e a instrução exata que impede cada um de se repetir no seu código.
Os erros que a IA comete em produção são previsíveis e documentados: ela escreve código que funciona na demo e falha de verdade. Enquanto construía a minha própria plataforma com o Claude, mantive um registro de cada erro dele que precisou de correção: 28 lições recorrentes, cada uma com a instrução exata que a evita. Aqui estão as dez que mais custam quando passam despercebidas.
O objetivo desta lista não é te afastar do desenvolvimento com IA. É o contrário: como os erros são previsíveis, eles são evitáveis — com uma frase no seu prompt ou uma regra permanente nas instruções do seu projeto. Você não precisa escrever o código correto. Precisa reconhecer o padrão incorreto e saber o que dizer.
Por que a IA comete os mesmos erros toda vez
A IA otimiza para o caminho feliz — a versão da sua funcionalidade em que os dados existem, o usuário está logado, nada falha e só um cliente usa o app. Essa versão fica linda na demo. Produção é todo o resto: sessões expiram, dois usuários clicam ao mesmo tempo, faltam dados, e o cliente A nunca pode ver os registros do cliente B.
A IA não pula essas coisas por descuido. Ela pula porque você não pediu — e, diferente de um desenvolvedor sênior, ela não preenche os requisitos não ditos com base na experiência. Os quatro comportamentos de sabotagem são uma lista relacionada, mas diferente, que tratei em outro post; os dez de hoje são sobre o que um código de nível de produção precisa e que a IA omite por padrão.
Os 10 erros que a IA comete em produção, e a instrução
| O que o Claude fez | O padrão correto | Como instruí-lo |
|---|---|---|
| Criou um serviço duplicado para uma funcionalidade que já existia | Uma única fonte de verdade por domínio — estenda o serviço existente | "Antes de criar um arquivo novo, procure um serviço existente que faça algo parecido e estenda-o" |
| Deixou componentes de interface falarem direto com o banco de dados | Três camadas: componentes usam hooks, hooks usam serviços, só os serviços tocam o banco de dados | "Nunca importe o cliente do banco de dados em componentes — siga a arquitetura de 3 camadas" |
| Usou tipos ENUM rígidos para status e categorias | Tabelas de consulta que você pode estender sem mudar código | "Nada de enums — crie uma tabela de consulta com código, nome de exibição, ordem e flag de ativo" |
| Criou chaves estrangeiras sem índices | Toda chave estrangeira ganha um índice; combinações comuns de consulta ganham índices compostos | "Toda coluna de chave estrangeira precisa de um índice" |
| Construiu tabelas sem uma coluna de organização | Multi-tenancy desde o primeiro dia: toda tabela de negócio é delimitada pelo cliente dono dos dados | "Toda tabela de negócio ganha organization_id, not null, como segunda coluna" |
| Pulou totalmente a segurança em nível de linha | RLS ativado em toda tabela, com políticas para leitura, inserção, atualização e exclusão | "Depois de criar qualquer tabela, ative o RLS e adicione as quatro políticas delimitadas por organização" |
| Tratou só o caminho feliz nos componentes | Quatro estados em todo lugar: carregando, erro, vazio e sucesso | "Todo componente que busca dados precisa tratar os estados de carregando, erro, vazio e sucesso" |
| Deixou erros falharem em silêncio | Capturar, registrar com contexto e oferecer ao usuário uma nova tentativa | "Toda função assíncrona ganha tratamento de erro: registre, lance um erro amigável, mostre uma opção de tentar de novo" |
| Apagou dados permanentemente quando solicitado | Exclusão lógica — marque os registros como excluídos, mantenha os dados, permita desfazer | "Nunca apague dados de negócio de verdade — preencha deleted_at e deleted_by e filtre esses registros nas consultas" |
| Executou gravações de várias etapas sem uma transação | Gravações relacionadas dão certo ou falham juntas, nunca pela metade | "Essas gravações precisam ser atômicas — ou todas dão certo, ou todas são revertidas" |
O conjunto completo das 28 lições — incluindo segurança de tipos, logs, acessibilidade, IDs fixos no código e cobertura de testes — está dentro do curso AI Product Builder, cada uma com código de antes e depois e o prompt pronto para copiar e colar.
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 →Os dois erros que podem acabar com o seu negócio
Oito dos dez te custam tempo. Dois podem te custar a empresa.
Falta de multi-tenancy e falta de segurança em nível de linha são máquinas de vazamento de dados. Sem uma coluna de organização em cada tabela, os dados de todos os seus clientes ficam numa pilha só, sem divisão, e só a sorte no código da aplicação impede o cliente A de ver os registros do cliente B. A segurança em nível de linha é o muro, no nível do banco de dados, que se mantém mesmo quando o seu código tem bugs — e o seu código vai ter bugs. A IA pula as duas coisas se você não pedir, porque nada em "construa um gerenciador de projetos para mim" diz que as empresas de outras pessoas também vão viver neste banco de dados.
Corrigir depois é brutal: adicionar a coluna de organização mais tarde significa migrar todas as tabelas, preencher todas as linhas, atualizar todas as consultas e testar tudo de novo. Uma frase no prompt original, ou uma semana de cirurgia de migração depois. Escolha a frase.
Transforme correções em regras permanentes
Corrigir a IA erro por erro é lutar contra a maré. A jogada que se acumula é escrever cada correção no arquivo de instruções do seu projeto, para que toda sessão futura comece com as regras já carregadas — expliquei a mecânica em o único arquivo que evita 90% dos erros da IA. Um bloco de regras curto assim muda tudo daí para a frente:
Siga a arquitetura de 3 camadas. Toda tabela ganha organization_id, colunas de auditoria e políticas de RLS. Nada de enums — tabelas de consulta. Indexe toda chave estrangeira. Só exclusão lógica. Todo componente trata carregando, erro, vazio e sucesso. Toda função assíncrona tem tratamento de erro.
Dez linhas. Escritas uma vez. Aplicadas em todo prompt que você rodar. Essa é a diferença entre corrigir a IA e dirigi-la — que é o trabalho de verdade, como defendi em você é o arquiteto.
12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →Perguntas frequentes
Se a IA comete todos esses erros, é seguro construir com ela?
Sim — porque os erros são consistentes, não aleatórios. Um desenvolvedor júnior comete erros diferentes toda semana; a IA comete os mesmos dez até você escrever a regra que impede cada um. Uma falha documentada com uma prevenção conhecida de uma linha é um risco de engenharia administrável, não um motivo para contratar uma equipe.
Como pego esses erros se não leio código com fluência?
Revise com perguntas, não lendo linha por linha. Pergunte diretamente à IA depois que ela gerar qualquer coisa: toda tabela tem coluna de organização e políticas de RLS? As exclusões são lógicas? Este componente trata os estados de carregando, erro e vazio? A IA é honesta sobre as próprias omissões quando você pergunta de forma específica — a tabela acima é, na prática, o seu checklist de revisão.
Devo corrigir esses problemas no código que a IA já escreveu?
Priorize pelo risco. Corrija primeiro a dupla de segurança — delimitação por organização e segurança em nível de linha — antes de receber clientes reais, porque corrigir depois só fica mais difícil à medida que os dados crescem. Estados faltando, logs e exclusão lógica podem ser corrigidos funcionalidade por funcionalidade, conforme você mexe em cada tela.
Onde as regras permanentes ficam, na prática?
Num arquivo de instruções do projeto que a sua ferramenta de IA lê no início de toda sessão — no caso do Claude, um arquivo CLAUDE.md no seu projeto. Toda correção que você fizer é promovida para esse arquivo, então é feita exatamente uma vez. A configuração leva minutos e está explicada no guia do CLAUDE.md.
Quão preso você está, de verdade?
Faça o Índice de Sufocamento Corporativo, a avaliação gratuita para saber se você está pronto para ser um EUpreendedor.