Erros que a IA comete em produção:10 e como os evitar
Os 10 erros que a IA comete em produção: o que o Claude fez mal, o padrão correto e a instrução exata que impede cada um de se repetir no teu próprio código.
Os erros que a IA comete em produção são previsíveis e documentados: escreve código que funciona na demonstração e falha ao vivo. Enquanto construía a minha própria plataforma com o Claude, mantive um registo de cada erro que ele cometeu e que precisou de correção: 28 lições recorrentes, cada uma com a instrução exata que a previne. Eis as dez que saem mais caras quando passam.
O objetivo desta lista não é assustar-te para longe do desenvolvimento com IA. É o contrário: como os erros são previsíveis, são evitáveis — com uma frase no teu prompt ou uma regra permanente nas instruções do teu projeto. Não precisas de escrever o código correto. Precisas de reconhecer o padrão incorreto e saber o que dizer.
Porque é que a IA comete sempre os mesmos erros
A IA otimiza para o caminho feliz — a versão da tua funcionalidade em que os dados existem, o utilizador tem sessão iniciada, nada falha e só um cliente alguma vez usa a app. Essa versão fica lindamente numa demonstração. A produção é todo o resto: as sessões expiram, dois utilizadores clicam ao mesmo tempo, faltam dados, e o cliente A nunca pode ver os registos do cliente B.
A IA não salta estas coisas por descuido. Salta-as porque não as pediste — e, ao contrário de um programador sénior, não preenche requisitos não declarados com base na experiência. Esses quatro comportamentos de sabotagem são uma lista relacionada, mas diferente, que tratei à parte; os dez de hoje são sobre aquilo de que o código de produção precisa e que a IA omite por defeito.
Os 10 erros que a IA comete em produção, e a instrução
| O que o Claude fez | O padrão correto | Como lho indicar |
|---|---|---|
| Criou um serviço duplicado para uma funcionalidade que já existia | Uma fonte única de verdade por domínio — estender o serviço existente | "Antes de criares um ficheiro novo, procura um serviço existente que faça algo parecido e estende-o" |
| Deixou os componentes da interface falarem diretamente com a base de dados | Três camadas: os componentes usam hooks, os hooks usam serviços, só os serviços tocam na base de dados | "Nunca importes o cliente da base de dados nos componentes — segue a arquitetura de 3 camadas" |
| Usou tipos ENUM rígidos para estados e categorias | Tabelas de referência que podes estender sem mudar código | "Nada de enums — cria uma tabela de referência com código, nome a apresentar, ordem e indicador de ativo" |
| Criou chaves estrangeiras sem índices | Cada chave estrangeira tem um índice; as combinações de consulta frequentes têm índices compostos | "Cada coluna de chave estrangeira tem de ter um índice" |
| Construiu tabelas sem coluna de organização | Multi-tenancy desde o primeiro dia: cada tabela de negócio pertence ao cliente que é dono dos dados | "Cada tabela de negócio tem organization_id, not null, como segunda coluna" |
| Saltou por completo a row-level security | RLS ativa em todas as tabelas, com políticas para leitura, inserção, atualização e eliminação | "Depois de criares qualquer tabela, ativa a RLS e acrescenta as quatro políticas com âmbito na organização" |
| Tratou apenas o caminho feliz nos componentes | Quatro estados em todo o lado: carregamento, erro, vazio e sucesso | "Cada componente que vai buscar dados tem de tratar os estados de carregamento, erro, vazio e sucesso" |
| Deixou os erros falharem em silêncio | Apanhar, registar com contexto e mostrar ao utilizador a opção de tentar de novo | "Cada função assíncrona tem tratamento de erros: regista-o, lança um erro compreensível, mostra a opção de tentar de novo" |
| Apagou dados de forma permanente a pedido | Eliminação lógica — marcar os registos como apagados, manter os dados, permitir desfazer | "Nunca apagues fisicamente dados de negócio — preenche deleted_at e deleted_by e filtra-os nas consultas" |
| Executou escritas em vários passos sem uma transação | Escritas relacionadas têm sucesso ou falham juntas, nunca a meio | "Estas escritas têm de ser atómicas — ou têm todas sucesso ou são todas revertidas" |
O conjunto completo das 28 lições — incluindo segurança de tipos, registo, 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 a copiar.
O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →Os dois erros que podem acabar com o teu negócio
Oito dos dez custam-te tempo. Dois podem custar-te a empresa.
A falta de multi-tenancy e a falta de row-level security são máquinas de fugas de dados. Sem uma coluna de organização em cada tabela, os dados de todos os teus clientes vivem numa única pilha indivisa, e só a sorte no código da aplicação impede o cliente A de ver os registos do cliente B. A row-level security é a muralha ao nível da base de dados que aguenta mesmo quando o teu código tem erros — e o teu código vai ter erros. A IA salta as duas coisas se não lhe disserem, porque nada em "constrói-me um gestor de projetos" diz as empresas de outras pessoas também vão viver nesta base de dados.
Corrigir depois é brutal: acrescentar a coluna de organização mais tarde obriga a migrar todas as tabelas, preencher todas as linhas, atualizar todas as consultas e voltar a testar tudo. Uma frase no prompt original, ou uma semana de cirurgia de migração mais tarde. Escolhe a frase.
Transforma as correções em regras permanentes
Corrigir a IA erro a erro é lutar contra a maré. A jogada que se acumula é escrever cada correção no ficheiro de instruções do teu projeto, para que cada sessão futura comece com as regras já carregadas — expliquei a mecânica em o ficheiro que evita 90% dos erros da IA. Um bloco de regras tão curto como este muda tudo o que vem a seguir:
Segue a arquitetura de 3 camadas. Cada tabela tem organization_id, colunas de auditoria e políticas de RLS. Nada de enums — tabelas de referência. Indexa cada chave estrangeira. Só eliminação lógica. Cada componente trata carregamento, erro, vazio e sucesso. Cada função assíncrona tem tratamento de erros.
Dez linhas. Escritas uma vez. Aplicadas em cada prompt que alguma vez correres. Essa é a diferença entre corrigir a IA e dirigi-la — que é o verdadeiro trabalho, como defendi em tu és o arquiteto.
12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →Perguntas frequentes
Se a IA comete todos estes erros, é seguro construir com ela?
Sim — porque os erros são consistentes, não aleatórios. Um programador júnior comete erros diferentes todas as semanas; a IA comete os mesmos dez até escreveres a regra que trava cada um. Um modo de falha documentado com uma prevenção conhecida de uma linha é um risco de engenharia gerível, não uma razão para contratar uma equipa.
Como apanho estes erros se não leio código com fluência?
Revê com perguntas, não a ler linha a linha. Pergunta diretamente à IA, depois de gerar qualquer coisa: todas as tabelas têm coluna de organização e políticas de RLS? As eliminações são lógicas? Este componente trata os estados de carregamento, erro e vazio? A IA é honesta sobre as suas próprias omissões quando lhe perguntam especificamente — a tabela acima é, na prática, a tua lista de verificação para a revisão.
Devo corrigir estes problemas no código que a IA já escreveu?
Prioriza pelo risco. Corrige primeiro o par de segurança — o âmbito por organização e a row-level security — antes de aceitares clientes reais, porque corrigi-los depois só fica mais difícil à medida que os dados crescem. Os estados em falta, o registo e a eliminação lógica podem ser corrigidos funcionalidade a funcionalidade, à medida que mexes em cada ecrã.
Onde ficam, na prática, as regras permanentes?
Num ficheiro de instruções do projeto que a tua ferramenta de IA lê no início de cada sessão — no caso do Claude, um ficheiro CLAUDE.md no teu projeto. Cada correção que alguma vez fizeres é promovida para esse ficheiro, por isso só a fazes uma vez. A configuração leva minutos e está explicada no guia do CLAUDE.md.
Quão preso estás, a sério?
Faz o Índice de Sufocamento Corporativo, a avaliação gratuita para saberes se estás pronto para ser um EUpreendedor.