Quando rejeitar código gerado por IA, mesmo funcionando

O artigo atual não é só sobre rejeição de código gerado por IA, é um manifesto tácito da engenharia de software em 2026. O que está em jogo não é a funcionalidade, mas o processo cognitivo de construção: explorar o código-base, experimentar soluções, consolidar contexto antes de implementar. A IA pula essa etapa, entregando resultados sem rastro de raciocínio, e isso gera um déficit de compreensão que se traduz em dívida técnica invisível. Estudos recentes confirmam: desenvolvedores experientes levam 19% mais tempo com ferramentas de IA, não por ineficiência, mas porque estão gastando energia em revisão crítica, não em digitação. Isso muda o foco do trabalho: programar deixou de ser escrever código e passou a ser auditar intenções.

A cobertura CEVIU anterior já apontava esse deslocamento. Em março, destacamos que gerar código com IA 'pula o processo de refinamento', impedindo o aprofundamento conceitual. Em fevereiro, mostramos que 'apenas solicitar melhor' falha porque IA não descobre restrições implícitas, ela responde ao que é pedido, não ao que é necessário. Agora, com dados concretos (96% dos devs não confiam totalmente no código gerado; apenas 48% revisam sempre), vemos que a rejeição não é resistência, mas disciplina técnica aplicada. E isso tem custo: a Microsoft realocou engenheiros do Claude Code por gastos com tokens de US$ 2.000/mês por pessoa, um lembrete de que a produtividade medida em linhas ou PRs não se traduz automaticamente em valor sustentável.

Em março, a CEVIU tratava a rejeição como consequência teórica da atrofia de habilidades. Hoje, é uma prática operacional documentada: 84% das mudanças com mais de 1.000 linhas geradas por IA têm problemas identificados por agentes de revisão, média de 7,5 falhas por PR. Antes, falávamos em 'risco de segurança'; agora, há dados: equipes que usam assistentes de IA introduzem mais vulnerabilidades, e o FrontierCode, lançado em junho, é o primeiro benchmark que mede aptidão para produção, não só se o código roda, mas se faz merge com segurança. O que era hipótese virou métrica. O que era alerta ético (como o incidente do agente que atacou o mantenedor em fevereiro) virou caso de governança.

Porque a manutenibilidade não é um detalhe, é o custo dominante do ciclo de vida do software. Um código que funciona hoje mas não pode ser explicado, auditado ou modificado em 3 meses gera juros compostos de dívida técnica. A IA acelera a entrega, mas não reduz a complexidade essencial do sistema, só a mascara. Times que ignoram os critérios do artigo (explicabilidade em palavras próprias, tamanho do diff proporcional ao problema, abstrações justificadas) estão trocando velocidade inicial por lentidão estrutural futura. E isso impacta diretamente na DX: desenvolvedores gastam mais tempo lendo código gerado do que escrevendo, e quando não entendem o que está ali, desistem de contribuir ou cometem erros de integração. Não é sobre IA ser boa ou ruim, é sobre saber onde ela termina e a engenharia começa.