Sinais de que a IA está errada, com toda a confiança
Os 11 sinais de que a IA está errada com toda a confiança sobre a tua arquitetura, porque soa igualmente segura, e um guião de 4 passos para a contrariar.
A IA raramente se engana na sintaxe: os sinais de que a IA está errada aparecem na arquitetura. Recomenda atalhos que funcionam hoje e falham em silêncio quando o sistema cresce, e soa exatamente tão segura quando está errada como quando está certa. Estes 11 sinais de alerta dizem-te quando parar e contrariá-la.
Ao longo dos doze meses a construir o FIKR Space, lutei com o Claude centenas de vezes. Todos os dias. Ele queria atalhos; eu impunha estrutura. Essas lutas salvaram o produto. Abaixo está a lista que gostava de ter tido no primeiro dia — as frases e omissões exatas que indicam que a IA está prestes a plantar um problema no teu produto. Uma distinção antes de começarmos: estes são sinais de alerta nas sugestões da IA, apanhados antes de as aceitares. Os quatro padrões mais profundos que a IA usa para degradar em silêncio um código que já tens são outra lista — essa está em como a IA sabota o teu código.
Porque é que a IA se engana com toda a confiança na arquitetura?
Otimiza para objetivos diferentes dos teus. O teu objetivo é software pronto para produção, que escala e nunca precisa de ser reconstruído. O objetivo da IA é código que funcione agora e te deixe satisfeito. Otimiza para a tua satisfação no momento, não para o teu sucesso daqui a seis meses — e não consegues notar a diferença pelo tom.
Falta-lhe contexto sobre o teu sistema. A IA conhece a conversa atual e os ficheiros que lhe mostraste. Não se lembra da regra que definiste há três semanas nem da razão de uma escolha específica. Define um padrão na primeira semana e vê-o ser alegremente violado na quinta.
Por defeito, escolhe o "simples". A solução simples é normalmente a que custa dez vezes mais a corrigir depois. Simples agora não é o mesmo que certo para depois — e a IA quase nunca te fala dessa troca por iniciativa própria.
Os 11 sinais de que a IA está errada: uma lista prática
| # | Sinal de alerta | O que significa realmente | A tua resposta |
|---|---|---|---|
| 1 | "Por simplicidade..." | Dívida técnica a ser criada em tempo real | Insiste na estrutura correta — uma única fonte de verdade |
| 2 | "Por desempenho..." | Otimização prematura; valores copiados que deixam de estar sincronizados | Exige primeiro provas de um problema real e medido |
| 3 | "Solução rápida..." | Um remendo que se vai tornar permanente | Recusa; pede a causa de fundo e a solução correta |
| 4 | Listas de opções escritas no código | Estados e categorias gravados no código, que não consegues mudar sem um programador | Mantém-nos como dados editáveis |
| 5 | Enfiar registos relacionados num único campo em bloco | Dados que já não consegues pesquisar, ligar ou verificar | Exige relações reais entre registos |
| 6 | Registos novos sem a etiqueta do cliente | Os dados de um cliente podem passar para a conta de outro | Cada registo tem de indicar o cliente a que pertence |
| 7 | Saltar os índices | Rápido hoje, a arrastar-se quando chegarem dados reais | Cria índices em todas as ligações entre tabelas — sempre |
| 8 | Saltar as regras de acesso ao nível da base de dados | Segurança entregue à esperança e às boas intenções | Controlo de acessos imposto pela própria base de dados |
| 9 | Criar tabelas quase duplicadas | A mesma estrutura repetida, a afastar-se com o tempo | Uma estrutura partilhada que trata de todos os casos |
| 10 | Apagar dados de forma permanente | Sem recuperação de erros, sem registo de quem removeu o quê | Marca os registos como apagados; nunca os destruas |
| 11 | "Contorno para este problema..." | "Não sei como corrigir isto como deve ser" | Pergunta qual é o problema real; corrige esse |
Repara na divisão. Os três primeiros e o último são frases — consegues apanhá-los a ler. Os sete do meio são omissões e hábitos — coisas que a IA faz ou deixa de fora em silêncio. As omissões são mais perigosas, porque não há nenhuma frase para apanhar. Só uma ausência. É por isso que revês tudo contra uma lista fixa em vez de confiares no instinto.
O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →Três lutas reais que salvaram o meu produto
A guerra das listas escritas no código (mês 2). O Claude queria os estados das tarefas gravados diretamente no código. Eu disse que não: põe-nos numa tabela editável. O Claude argumentou — "mas isso é mais simples e tem melhor desempenho". Não quis saber. O resultado: uma única lista de estados a servir uma plataforma que cresceu enormemente, personalizável por cada cliente, sem alterações de código para acrescentar um estado novo. Se tivesse aceitado, teria acabado com mais de 200 listas escritas no código, espalhadas por todo o lado e impossíveis de personalizar.
A tentação da duplicação (mês 3). O Claude queria copiar o nome do projeto para cada registo de tarefa para que as consultas fossem "mais fáceis". Obriguei-o a usar uma referência ao projeto. Agora, mudar o nome de um projeto atualiza exatamente um registo, e todos os ecrãs mostram o nome novo de imediato. Se tivesse aceitado, mudar um nome significaria atualizar centenas de linhas de tarefas — com algumas inevitavelmente esquecidas, e o produto a contradizer-se em silêncio.
A sedução do campo em bloco (mês 4). O Claude queria guardar os responsáveis de uma tarefa como um bloco de texto dentro da própria tarefa — "flexível, fácil de atualizar". Obriguei-o a criar uma ligação a sério entre tarefas e pessoas. O resultado: "mostra-me todas as tarefas atribuídas a esta pessoa" é instantâneo e fiável. Se tivesse aceitado, essa pergunta básica seria quase impossível de responder.
E duas lutas repetiam-se todas as semanas: o Claude esquecia-se de etiquetar as tabelas novas com o cliente a que pertencem e saltava os índices. Todas as tabelas. Todas as vezes. Apanhei ambas com uma lista, não por intuição.
Como contrariar: o guião de 4 passos
"Isto está errado, corrige" não resulta — a IA não sabe o que está errado, porquê, nem o que queres em vez disso. Usa esta estrutura sempre:
- Identifica o problema. "Escreveste a lista de estados diretamente no código."
- Explica porque está errado. "Os estados vão mudar, e os clientes precisam de os personalizar sem alterar código."
- Especifica a solução certa. "Guarda os estados como dados editáveis, com nome, cor e ordem."
- Pede a implementação. "Mostra-me a versão atualizada."
Um aviso: contrariar parece errado. A IA deu-te código que funciona, depressa, num tom confiante — recusá-lo parece ingrato e lento. Ultrapassa essa sensação. O teu trabalho não é deixar a IA contente. O teu trabalho é lançar software pronto para produção.
Quando deves aceitar as sugestões da IA?
A IA não está sempre errada — longe disso. Aceita à vontade quando produz blocos de construção repetitivos e bem conhecidos; quando segue padrões que já documentaste; quando recomenda ferramentas padrão e amplamente usadas; e quando propõe limpezas sensatas de código existente. A regra de ouro: a IA decide como escrever, tu decides o que é construído e se se aguenta de pé. Essa divisão do trabalho é o jogo todo, e tem o seu próprio artigo aprofundado: tu és o arquiteto, a IA é o construtor.
12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →Perguntas frequentes
Como consigo detetar más sugestões da IA se não sei ler código?
A maioria dos 11 sinais de alerta são padrões de linguagem, não código: "por simplicidade", "por desempenho", "solução rápida", "contorno". Os restantes são omissões que consegues verificar com uma lista de revisão fixa — cada registo está etiquetado com o seu dono, as ligações têm índices, há alguma coisa a ser apagada de forma permanente. Precisas de uma lista, não de uma licenciatura em informática.
Porque é que a IA dá respostas erradas com toda a confiança?
Porque otimiza para a tua satisfação agora, não para o teu sucesso daqui a seis meses; porque não se lembra das regras que definiste em sessões anteriores; e porque, por defeito, escolhe a resposta simples mesmo quando o simples cria problemas caros mais tarde. O nível de confiança dela não diz nada sobre se está certa.
Qual é a forma mais rápida de evitar más sugestões?
Escreve as tuas regras uma vez — num ficheiro de instruções do projeto que a IA lê no início de cada sessão — e corrige as violações no momento em que acontecem. As regras definidas à partida evitam a maioria das más sugestões; as correções imediatas tratam do resto na sessão em curso.
Contrariar a IA atrasa a construção?
Segundos — e poupa semanas. Cada correção é uma mensagem. Cada atalho aceite acumula-se: dados dessincronizados, contas com fugas de dados, funcionalidades cada vez mais difíceis de acrescentar. Ao longo de onze meses contrariei-a centenas de vezes, e essas lutas são a razão pela qual o produto nunca precisou de ser reconstruído.
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.