Não peça pra IA escrever em C — o que os dados sobre código gerado por IA mostram

51% a 67% dos programas em C gerados por IA carregam vulnerabilidade comprovada por verificação formal, e a taxa não melhora com modelo maior. O que funciona de verdade, com quatorze estudos por trás.

Circula um argumento sedutor: já que a IA escreve o código, e humano deixou de ser o gargalo, por que não usar C? Sem garbage collector, sem runtime, binário mínimo, controle total do hardware. Fui atrás dos estudos que realmente mediram isso. A resposta não é sobre C ser ruim — é sobre C ser a linguagem errada pra parear com um gerador probabilístico.

O que acontece quando alguém mede

O FormAI (Tihanyi et al.) pediu a modelos que gerassem programas em C e rodou cada um num verificador formal (ESBMC), que produz um contraexemplo concreto pra cada falha — não é heurística, é prova. Com GPT-3.5, 51,24% dos 112 mil programas saíram vulneráveis. Na segunda rodada, com 9 modelos incluindo GPT-4o-mini e Gemini Pro, a taxa subiu pra pelo menos 62,07%. Um prompt tão trivial quanto “some dois números” já basta: o GPT-4 gera overflow de inteiro e dois buffer overflows em scanf na mesma resposta. Pedindo explicitamente “evite vulnerabilidade de segurança”, ele trata só a entrada não-numérica — o overflow continua.

Isso não é peculiaridade de um dataset. A Veracode testou mais de 150 modelos, incluindo os mais recentes (GPT-5.1/5.2, Gemini 3, Claude 4.5/4.6), em quatro linguagens: a taxa de código seguro está travada em ~55% há dois anos, enquanto a taxa de sintaxe correta subiu de 50% pra mais de 95% no mesmo período. O detalhe mais informativo não é a média — é a quebra por tipo de falha: SQL injection (82% seguro) e criptografia (86%) são bem resolvidos, porque são reconhecimento de padrão local, o tipo de coisa que um modelo já viu corrigida milhares de vezes. XSS (15%) e log injection (13%) continuam péssimos, porque exigem rastrear dado por várias funções até o ponto de uso — análise de fluxo que nem humano faz bem de forma consistente. A única exceção real: modelos de raciocínio estendido chegam a 70-72%, porque o raciocínio interno funciona como uma revisão de código antes da resposta final — ainda assim, é 1 em cada 3 respostas com falha.

E juntar humano não resolve sozinho. No estudo de Stanford (Perry et al.), quem usou assistente de IA escreveu código menos seguro em 4 de 5 tarefas — e ficou mais confiante, não menos, exatamente quando errava mais (nota de confiança 4,0 vs. 1,5 numa tarefa). 87% das respostas seguras exigiram edição substancial em cima do que a IA sugeriu — segurança correlaciona com desconfiar da resposta, não com aceitá-la.

A pergunta certa não é qual linguagem, é qual malha

O padrão que atravessa todos esses números é sempre o mesmo: quando o compilador consegue expressar a propriedade que importa, existe um loop — o modelo erra, o compilador aponta, o modelo corrige. Quando não consegue, o erro vira bug silencioso que só aparece em produção. Em C, um buffer overflow compila limpo. Não existe sinal automático dizendo ao modelo que ele errou.

Essa malha é comprovadamente reaproveitável por LLM. O SafeTrans traduziu C pra Rust com 6 modelos: sem reparo, 54% de acerto; com reparo guiado pelo erro do rustc, 80%. O RustAssistant chega a 74% de sucesso corrigindo erro real de compilação em repositório Rust de produção. E um estudo da ETH Zurich mediu a causa raiz: 94% dos erros de compilação em código gerado por LLM são falha de checagem de tipo, não de sintaxe — forçar tipo correto durante a geração cortou esses erros pela metade. O ganho é real, mas tem atrito: modelos de ponta ainda erram 18-39% gerando Rust em tarefas difíceis, porque o mesmo rigor que barra o bug também barra o modelo até ele acertar.

A malha do Rust tem um buraco conhecido

A garantia é de Rust seguro, não de unsafe{}. O Google quase enviou seu primeiro CVE de memória em Rust no Android — um buffer overflow dentro de um bloco unsafe, só pego porque o alocador (Scudo) transformou corrupção silenciosa em crash barulhento. Um estudo separado (Qin et al.) achou 17 bugs de concorrência em sistemas Rust reais causados exatamente por memória compartilhada via unsafe sem sincronização. A malha existe e funciona — mas só nos ~4% de código que normalmente não é unsafe.

Ainda assim, o resultado em produção é o argumento mais forte que existe: o próprio Google reporta 1.000x menos densidade de vulnerabilidade de memória no Rust do Android comparado a C/C++, com revisão de código 25% mais rápida e 4x menos rollback. Não é trade-off — é ganho nos dois eixos, medido em bilhões de linhas reais, não em benchmark.

Go e Elixir fecham malhas diferentes, não a mesma malha mais fraca

Go elimina a classe de memória por outro caminho: sem ponteiro cru, sem free() manual, acesso fora do limite de array vira panic controlado, não corrupção explorável. Só que deixa duas malhas abertas que o Rust fecha. Erro ignorado (err) não trava compilação — e um estudo real da engenharia do Uber (Chabbi et al., mais de 1.000 data races em produção) achou que Go corrige cerca de 5 races novas por dia, mesmo com detector rodando continuamente; a causa isolada nº1 foi acesso concorrente a slice (391 casos), algo que o compilador nunca sinaliza. Outro estudo (Tu et al., 171 bugs reais em Docker/Kubernetes/etcd) achou que 58% dos bugs de bloqueio vêm de uso incorreto de channel — nem o idioma que o próprio Go recomenda é imune. Conclusão prática: se o modelo já gera Rust que funciona pra aquela tarefa, aceitar a malha mais fraca do Go só por menos atrito é abrir mão de garantia de graça.

Elixir/Phoenix não joga esse jogo. Isolamento de processo tira data race do mapa por não compartilhar memória — não é prova, é arquitetura. “Deixa quebrar” contém o estrago em vez de preveni-lo (o switch da Ericsson rodou “nove noves” de uptime nesse princípio, com 2 milhões de linhas de Erlang). E o Ecto tem uma trava real de compilação contra interpolação de string na posição de SQL do fragment() — fechando exatamente a classe de bug (injection) que nem Rust nem Go tocam, porque não é memória, é lógica de aplicação. Sendo direto sobre o limite: não existe nenhum estudo medindo IA gerando Elixir com segurança — isso é raciocínio a partir de como a linguagem funciona, não achado experimental como os números de Go e Rust acima.

O argumento de desempenho não sustenta o C sozinho

Mesmo o motivo mais citado a favor do C — eficiência — não aguenta como justificativa isolada. Num estudo de 27 linguagens (Pereira et al.), Rust gasta 1,03x a energia do C — praticamente empatado, e é o único ocupante isolado do segundo lugar no conjunto ótimo de energia+tempo, à frente do C++. Go gasta 3,23x — pior que o próprio C++.

A indústria já apostou nisso, antes da IA

A Microsoft já dizia em 2019, olhando 15 anos de CVE próprio: ~70% das vulnerabilidades vêm de erro de memória em C/C++, e a resposta certa não é mais ferramenta de treinamento, é “impedir o desenvolvedor de introduzir a falha” — trocando de linguagem. A DARPA financia hoje um programa (TRACTOR) inteiro pra usar LLM traduzindo C legado pra Rust, exatamente o oposto do “IA deveria escrever mais C”. E o resultado de 2025 do Google mostra que essa aposta, começada antes de qualquer LLM existir, está funcionando.

O que fizemos com essa mesma lógica

Não somos espectadores neutros aqui — a maior parte dos sistemas de produção da Althora roda em Elixir/Phoenix, não porque vence essa comparação em todo eixo, mas porque, pra classe de bug que nossas aplicações mais encontram (lógica de negócio, não memória de baixo nível), o framework tornar o caminho fácil o caminho certo importa mais do que uma prova de memória que a gente nem estaria usando. E como toda essa investigação nasceu de uma pergunta prática, formalizamos a disciplina: qualquer árvore de supervisão ou SQL cru gerado por IA em nossos projetos Elixir passa por leitura humana obrigatória antes de produção, sem exceção — porque “compilou” prova bem menos ali do que provaria em Rust.

Se você decide em qual linguagem pedir código pra IA hoje: a pergunta não é qual é mais rápida de gerar. É onde o erro do modelo vira mensagem legível antes de virar incidente. Pra bug de memória e concorrência de baixo nível, é Rust ou nada. Pra lógica de aplicação — a classe mais cara e mais comum, independente de linguagem — nenhuma dessas resolve sozinha por tipo; resolve por framework que torna o seguro o caminho de menor esforço, ou por verificador externo vigiando.

Fontes

Este texto foi escrito em conjunto por Alvaro Lopes e o Claude Code. O Claude escreveu Elixir ao longo do caminho; um humano leu tudo antes de ir pra produção, seguindo exatamente a disciplina descrita acima.