Seu LLM Não Escreve Código Correto. Ele Escreve Código Plausível.

O problema não é que os LLMs escrevam código errado, é que eles escrevem código que parece certo. O rewrite de SQLite em Rust, com 576.000 linhas (3,7× maior que a base original em C), compila, passa em testes unitários e até responde consultas, mas falha em duas camadas críticas: semântica de desempenho (full table scan em vez de busca em B-tree por falta de verificação do flag is_ipk) e operacional (uso de fsync em cada INSERT, não fdatasync). Isso não é um bug isolado: é o comportamento esperado de um modelo treinado para maximizar a plausibilidade estatística da saída, não sua corretude algorítmica ou eficiência estrutural.

Essa limitação se agrava em cenários reais. Benchmarks como HumanEval medem apenas geração de funções curtas e autônomas, saturados há anos. Já SWE-bench, que simula correções reais em repositórios do GitHub, mostra que modelos de ponta atingem ~80% de acerto em tarefas simples, mas caem para menos de 20% em casos com múltiplas dependências, histórico de commits ou arquitetura complexa. A IA entende código como sequência de tokens, não como sistema com invariáveis, contratos de API e trade-offs de I/O.

Engenheiros estão gastando tempo revisando código que parece profissional, mas esconde custos ocultos: latência 20 mil vezes maior, consumo excessivo de CPU, riscos de concorrência e vazamentos de recursos. Um relatório da SonarSource (ago/2025) mostra que Claude Sonnet 4 e GPT-4o geram proporcionalmente mais bugs 'BLOCKER', como condições de corrida e violações de contrato, do que versões anteriores. Isso não é mero ruído: é um viés estrutural. Quando uma ferramenta de IA reduz a taxa de conclusão de PRs em apenas 8% mesmo com 65% de aumento no uso (DX, abr/2026), o gargalo não está na escrita, está na revisão, depuração e validação do que foi gerado.