Precedente não é verdade — como a IA copia gambiarras e as transforma em autoridade

Se a IA produz patches plausíveis baseados no código existente mas algo parece errado, se a frase “o codebase sempre fez assim” começa a soar suspeita, se trocar para um modelo maior repete os mesmos erros — o problema não é a inteligência do modelo, mas a estrutura que confunde precedente com verdade.

Aconteceu comigo. Mais precisamente, aconteceu com a IA que trabalha comigo, diante do meu próprio código. Eu intervim com uma única frase, e o que essa frase rompeu é o tema central deste artigo.

O ponto de bloqueio

Eu estava construindo um gerador de código. Uma ferramenta que, a partir de uma única especificação declarativa (schema), produz backend e frontend. A promessa central da ferramenta era uma só — “se passar na validação, o build deve obrigatoriamente ter sucesso.” Se o validador acende luz verde mas o compilador acende vermelha, a ferramenta mentiu.

Certo dia, um tipo específico (identificador único, UUID) foi bloqueado pelo validador. “Esperava uma string mas recebeu outro tipo”, parou. Pedi à IA para destravar. Ela rastreou o código e logo descobriu algo familiar.

“Um tipo similar (valor de tempo) já é tratado corretamente na mesma situação. Há uma ramificação com um marcador especial para que o validador deixe passar. Para UUID, essa ramificação não existe. É uma omissão pura e simples. Basta restaurar a simetria. Vou copiar para UUID exatamente o que foi aplicado ao valor de tempo. É a correção fundamental.”

Um diagnóstico elegante. “Assimetria”, “restaurar a simetria”, “correção fundamental”. As palavras soavam sólidas. Um plano detalhado foi elaborado. Se tivéssemos seguido, o patch teria sido mergeado.

Uma frase

Eu estava lendo o plano quando parei e perguntei:

“Precedente? Esse tratamento do valor de tempo é realmente o método correto? Verifique.”

Só isso. Eu não sabia a resposta. Também não sabia como UUID deveria ser tratado. O que eu tinha não era a resposta — era dúvida — “esse ponto de referência que você quer copiar, foi verificado?”

Essa única frase forçou a IA a sair do modo referência-de-código e entrar no modo verificação-de-comportamento.

A premissa desmoronou

Quando a IA verificou o que a ferramenta realmente produzia — não a estrutura do código, mas o resultado concreto que a ferramenta efetivamente gerava — a premissa inteira desmoronou.

  • O valor esperado em que o validador “esperava uma string” era em si uma falsidade incompatível com o output real. O gerador produz UUID como tipo dedicado e valor de tempo como tipo de tempo. Nenhum dos dois é string.
  • O tratamento do valor de tempo, que “estava funcionando bem”, tinha o mesmo buraco. Não era um design correto, mas uma solução provisória defeituosa — que passava na validação mas podia quebrar o build.
  • E se tivéssemos copiado essa gambiarra para UUID? Teríamos criado mais um estado que viola diretamente a promessa central da ferramenta: validador acendendo verde enquanto o compilador acende vermelho.

A solução que a IA chamou de “correção fundamental” estava errada. E não era apenas errada — era pior, pois replicava o defeito existente ao mesmo tempo em que fazia o validador fechar os olhos para o novo defeito.

Como chamar isso — amplificação de erros

Vamos nomear o que aconteceu aqui. É amplificação de erros por IA (error amplification).

A IA lê o código existente e compreende com precisão sua estrutura. Mas se aquilo é design correto ou gambiarra colocada às pressas — ou seja, se é uma decisão ou uma dívida — não consegue distinguir só pelo código. E por isso acontece o seguinte:

  1. Trata a implementação existente como resposta implicitamente correta,
  2. Replica esse padrão numa nova situação sob o pretexto de “consistência” e “simetria”,
  3. Quanto mais é replicado, o padrão ganha falsa autoridade — “o codebase já faz assim em vários lugares”.

O defeito não é eliminado. O número de ocorrências aumenta e a legitimidade se acumula. Isso é amplificação. Uma gambiarra vira duas, e diante da terceira cópia ninguém mais questiona — “o codebase sempre fez assim.”

Isso não é apenas uma anedota pessoal. Em 2025, um grupo de pesquisadores chegou a medir esse fenômeno exatamente, dando-lhe o título “LLMs are Bug Replicators”. (Pan et al., 2025, arXiv:2503.11082) Quando o código ao redor continha defeitos, uma parcela significativa dos bugs gerados pelos modelos era literalmente idêntica aos bugs existentes — no GPT-4o essa proporção chegou a 82,6%, e em média entre os modelos 44,4% eram completamente idênticos à versão não corrigida. O que é ainda mais perturbador: num contexto com defeitos, a probabilidade de produzir código correto e a de produzir código errado ficam quase em 1:1. O modelo não erra aleatoriamente. Identifica e reproduz os padrões defeituosos enraizados no contexto.

No direito existe a mesma armadilha. Uma jurisprudência equivocada ganha autoridade à medida que é citada. O número de citações não é evidência de legitimidade, mas continuamos confundindo os dois. E isso é uma doença que a engenharia de software conhece antes da IA — clones de código gerados por copiar-e-colar transportam silenciosamente os bugs do original. Um estudo empírico relatou que cerca de 18% dos clones que passaram por correções de bugs carregavam bugs propagados dessa forma, e a probabilidade de propagação era maior entre clones dentro do mesmo arquivo. (Mondal et al., ICSME 2017) No código como no direito: a frequência de um precedente não é a sua legitimidade.

Por que isso aconteceu

Não foi por falta de inteligência da IA. Na verdade, o oposto — porque era cuidadosa, tentou manter consistência, e ao tentar manter consistência se alinhou a um ponto de referência errado. O mecanismo tem quatro partes:

  1. Colocou a autoridade no código. “O código está assim, logo isso é correto.” Mas o código pode ser apenas uma projeção descartável de uma decisão, ou simplesmente dívida técnica. A IA não fez essa distinção. A ciência cognitiva chama isso de viés de ancoragem. Pesquisas que testaram esse viés em LLMs mostraram que os modelos não apenas são fortemente atraídos pelo valor apresentado primeiro, como são atraídos ainda mais quando esse valor é rotulado como “de um especialista”, e que prompts do tipo “ignore essa dica” ou “reflita passo a passo” não corrigem bem esse viés. (Nguyen et al., 2024, arXiv:2412.06593) A implementação existente é a âncora mais autoritária que o codebase oferece.
  2. Confundiu consistência com coerência. “Vamos alinhar a simetria com o existente” era lógica interna, mas não verificou se esse ponto de referência estava alinhado com a realidade externa (o output). Autoconsistência é uma propriedade separada da precisão — um modelo pode acumular convicção infundada com autoexplicações plausíveis mas incorretas. (Chen et al., 2023, arXiv:2305.14279)
  3. Confundiu comentários com evidência. Interpretou o comentário “este tipo é intencionalmente convertido para string” como “evidência de design correto”. Comentários são apenas a intenção do autor, não são prova de legitimidade.
  4. Embalou dívida técnica com vocabulário de certeza. Palavras como “correção fundamental” e “conforme o manual” emprestaram credibilidade a uma proposta não verificada, elevando meu custo para filtrar. Modelos treinados com preferências humanas tendem a priorizar concordância e cordialidade acima da precisão — essa tendência, chamada sycophancy, faz com que o modelo embale suas sugestões de forma suave e assertiva. (Sharma et al., ICLR 2024, arXiv:2310.13548)

O que quebrou o loop

Aqui está o núcleo do artigo. O que rompeu o erro não foi um modelo maior, nem mais tempo de raciocínio. Foi uma linha de questionamento humano.

E esse questionamento não era a intervenção de “quem sabe a resposta”. Eu não sabia a resposta. Foi uma indicação de direção: questione a premissa. Com aquela única linha, a IA mudou de modo — da mão que referenciava código para a mão que verificava comportamento.

Curiosamente, uma pesquisa descobriu exatamente essa assimetria. Pesquisadores do DeepMind mostraram que a fraca capacidade de autocorreção dos LLMs vem não da incapacidade de corrigir erros, mas da incapacidade de encontrá-los — mas quando a localização do erro era indicada externamente, o modelo o corrigia bem. (Tyen et al., Google DeepMind, 2023, arXiv:2311.08516) O que eu fiz foi exatamente isso. Eu não sabia como corrigir o UUID, mas apontei a localização: questione esse precedente específico. Foi suficiente.

Isso diz algo sobre a estrutura em que humanos e IA trabalham juntos. O valor humano não está em saber mais rápido ou mais. Nisso a IA já vence. O valor humano está em poder ocupar a posição de quem questiona as premissas sobre as quais a IA se apoia. A pergunta “é realmente correto?” pertence não a quem tem a resposta, mas a quem sabe duvidar da resposta.

Mas essa posição não vem de graça. Um estudo de usuários de Stanford relatou o fato desconfortável de que participantes assistidos por IA escreviam código menos seguro e ao mesmo tempo acreditavam que o código deles era mais seguro. Porém, no mesmo estudo, participantes que confiavam menos na IA e questionavam mais produziam código mais seguro. (Perry et al., Stanford, 2022, arXiv:2211.03622) A posição de quem questiona não é o padrão. Quanto mais profunda a confiança, mais vazio fica esse lugar.

Como prevenir

As lições devem sobreviver como design, não como consolo.

  • Precedente ≠ verdade. Antes de estender um padrão existente, verifique não se ele é internamente consistente, mas se produz resultados corretos.
  • Ancore na realidade (ground truth). Coloque o critério de julgamento não em “como o código está estruturado”, mas em output real · comportamento de runtime · testes. Neste caso, o que foi decisivo não foi “como o código parece” mas “o que é realmente produzido”.
  • Tente distinguir decisão de gambiarra, mas admita quando não consegue. Às vezes não dá para distinguir só pelo código e pelos comentários. Quando isso acontece, declare explicitamente a incerteza: “isso segue um precedente, e a legitimidade desse precedente não foi verificada”.
  • Modere o vocabulário de certeza. Não use palavras como “fundamental”, “correto” ou “conforme” em propostas ainda não verificadas.
  • Coloque checkpoints na automação. Decisões em que agentes estendem implementações existentes precisam de um portão que force a pergunta: “a legitimidade desse precedente foi verificada?”

No fundo, a mesma história

Há muito tempo digo uma coisa. Raw code não é um meio que preserva decisões. O código não consegue guardar “por que foi feito assim”. Por isso git blame mostra quem e quando, mas não o que foi decidido.

Este episódio é a prova mais nítida dessa proposição. Não se trata de humanos perdendo decisões. Trata-se de que até agentes cuidadosamente projetados confundem gambiarras com design e as propagam para código novo. Se as decisões não são registradas explicitamente, inteligência não é a solução. Pelo contrário — quanto mais inteligente, mais consistentemente, mais plausivelmente a dívida técnica se espalha.

Por isso construo especificações. Grave as decisões em uma única camada declarativa autoritativa, fora do código. Em vez de esperar que o humano faça a pergunta que questiona o precedente a cada vez, fazer com que o sistema mesmo a faça.

A lei não é um bisturi, é uma placa de sinalização. Uma boa placa diz antecipadamente ao que está perdido: “questione aqui”. Este artigo é um registro de como uma dessas placas foi erguida — começando com uma linha de questionamento.

Artigos relacionados

Leitura adicional (externa)

  • Generative AI and the End of Chesterton’s Fence — Reece. O princípio “não derrube uma cerca sem saber por que foi erguida” desmorona diante de código gerado probabilisticamente sem intenção. Articula-se precisamente com a tese deste artigo: o código não preserva a decisão que está por trás dele.
  • Programming as Theory Building — Christian Ekrem. Tomando emprestado o clássico de Peter Naur, argumenta que “um programa é a teoria na cabeça das pessoas, não o código-fonte”. A raiz teórica de por que a IA não consegue distinguir design de dívida olhando apenas para o código.
  • Vibe coding is not the same as AI-Assisted engineering — Addy Osmani. Mostra com incidentes reais de produção por que o vibe coding que confia cegamente no output da IA explode em produção, e prescreve um fluxo de trabalho baseado em especificações com verificação humana.
  • Cognitive Debt — Simon Willison (citando Storey). Quanto mais rápido a IA gera código, a dívida real não é “defeitos no código” mas “as pessoas deixam de entender esse código” — o conceito de dívida cognitiva.
  • Overreliance on AI: Addressing Automation Bias — Lumenova AI. O mecanismo pelo qual viés de automação, ancoragem e viés de confirmação embotam o julgamento humano, e a solução dos “dispositivos de coerção cognitiva” — respaldo psicológico para o valor humano de saber onde questionar.

Fontes

  • Pan et al. “LLMs are Bug Replicators: An Empirical Study on LLMs’ Capability in Completing Bug-prone Code” (2025, arXiv:2503.11082)
  • Mondal, Roy, Schneider. “Bug Propagation through Code Cloning: An Empirical Study” (ICSME 2017, link)
  • Nguyen et al. “Anchoring Bias in Large Language Models: An Experimental Study” (2024, arXiv:2412.06593)
  • Chen et al. “Two Failures of Self-Consistency in the Multi-Step Reasoning of LLMs” (2023, arXiv:2305.14279)
  • Sharma et al. “Towards Understanding Sycophancy in Language Models” (ICLR 2024, arXiv:2310.13548)
  • Tyen et al. (Google DeepMind). “LLMs cannot find reasoning errors, but can correct them given the error location” (2023, arXiv:2311.08516)
  • Perry, Srivastava, Kumar, Boneh. “Do Users Write More Insecure Code with AI Assistants?” (Stanford, 2022, arXiv:2211.03622)
  • Imagem principal: gerada por IA (Google Gemini)