Estudo complementar · Parte 2

De volta ao C? A IA destravou as linguagens difíceis

Os agentes passaram a pagar o custo de entrada das linguagens de baixo nível. O resultado: ports de 535 mil linhas em 11 dias, 832 mil linhas de Rust no runtime do Copilot, a Microsoft prometendo eliminar C/C++ até 2030 — e devs escolhendo stack por RAM, watts e tamanho de binário em vez de "o que é mais fácil de escrever".

535 mil linhasZig → Rust em 11 dias (Bun)
US$ 165 milcusto em tokens do port do Bun
832 mil linhasde Rust no runtime do Copilot
18×startup in-process (Copilot runtime)
#2C no TIOBE (jan/2026)

Complementa o estudo “A IA acabou com a maior vantagem do React Native?” — mesma base de fontes: transcrição e comentários do vídeo original, artigos oficiais (Anthropic, GitHub, Shopify) e cobertura independente (The Register, The New Stack, InfoQ). Pesquisa conduzida em 27/09/2026.

01 · O gatilho desta aba

O que as pessoas estão falando

Nos comentários do vídeo que originou o estudo principal, um tema aparece repetidas vezes — quase sempre na mesma direção: “por que não usar a linguagem mais próxima da máquina, se a IA escreve o código?”. Antes dos dados, o sentimento:

@leandrofreirex · 24 likes

“Eu já tô fazendo isso. Algumas APIs, principalmente de serviço local, a inferência de modelos eu fazia em Python, algumas com C#, agora tô indo direto pro C/C++. IA é o futuro.”

Nas respostas: “C# é muito eficiente, mudar pra C/C++ perde segurança de memória (…). Só valeria a pena se mudasse pra Rust, pois mantém a segurança” — e o alerta oposto: “você está criando uma dependência sinistra de IA”.

@edfcsx

“Esses dias eu vi uma publicação muito boa sobre esse assunto, um desenvolvedor falando que agora temos motivos para voltar a programar em C devido à IA (…) no sentido de que agora não precisamos mais de tantas abstrações. Eu vejo no caso da Shopify a mesma coisa.”

@tiagoelr

“Eu programo em C para Android e acredito que em breve C vai tomar conta de tudo por causa de IA.”

Respostas: “acorde, jovem: Rust”, “e o Assembly?” — e o balde de água fria útil: “o código vai ficar amarrado no hardware, seu produto não seria fácil de vender e gerenciar.”

@gogodev2

“Por que eu faria um programa em Electron que consome meio giga de RAM se posso fazer em Rust, com binários otimizados para aquele computador em específico, consumindo 25 MB de RAM e rodando bem até em um computador de 2001? Estou usando um caso real meu.”

@andersoncosta8366

“Se com IA eu posso gerar qualquer código, pra que vou usar JavaScript com React Native pra celular? Isso vale pro Python também. Agora o pessoal vai focar nas linguagens com mais performance.”

@wpbarcelos

“A linguagem que usar menos tokens vai ser mais bem aceita. (…) Ter um conjunto de soluções mais sólidas e menos inventivo também é [critério].”

Um critério de escolha de linguagem que só existe na era dos agentes: eficiência de token.

Menção honrosa para o @alex-couto (“O Delphi está de Volta!”) e a resposta perfeita do @railsbr: baixou o Delphi Community e “a IA não conseguiu sair de uma trava de compilação automática que não está disponível na versão community” — lembrete de que tooling e licenciamento continuam mandando, por melhor que o agente seja.

Do sentimento aos fatos

Comentário de YouTube é termômetro, não prova. O resto desta aba mostra o que empresas e projetos reais fizeram em 2026 nessa direção — com números, custos e regressões. E onde o entusiasmo merece freio.

02 · A mecânica

Por que isso está acontecendo agora

Quatro mudanças de custo, todas documentadas nos relatos oficiais, explicam o fenômeno. Nenhuma delas é “a IA escreve C melhor que humanos” — é mais estrutural que isso:

1 · O código antigo virou spec executável

Para um LLM, uma codebase existente é a melhor especificação que existe: comportamento, edge cases e contratos estão todos lá. Traduzir deixou de ser “reescrever do zero” e virou “portar com referência”. A Anthropic resume: “o código velho serve como uma ótima spec para o modelo” — e a fila de trabalho escreve a si mesma: cada erro de compilação ou teste que falha vira o próximo item.

2 · O veredito ficou objetivo

Compiladores, suítes de teste e diffs dão aos agentes um juiz mecânico. Isso muda a escala do que dá para tentar: “os agentes rendem mais quando a verificação é objetiva, porque o modelo pode insistir contra um ground truth por dias sem um humano arbitrando qualidade.”

3 · O custo humano de entrar na linguagem caiu

O desenvolvedor não precisa mais dominar lifetime, ponteiros ou o idioma de turno para começar: ele precisa entender arquitetura, definir limites e revisar. Um engenheiro supervisiona o que antes exigia um time — e devs de React Native viram produtivos em SwiftUI/Compose, devs de TS conduzem ports em Rust.

4 · O cálculo de carreira deixou de ser existencial

Migrar de linguagem era um projeto plurianual com risco de carreira: dois codebases em paralelo, e 90% de paridade no final era um problema maior que o inicial. Agora, diz a Anthropic, “o pior cenário é você deletar o branch e tentar de novo.” Ainda custa (dezenas a centenas de milhares de dólares), mas deixou de custar a empresa.

Anthropic · guia de migração em escala

“A ideia central é que você não conserta o código. Você conserta o processo (o loop) que produziu o código.”

How Anthropic runs large-scale code migrations with Claude Code (jul/2026)

É exatamente a mesma mecânica que destravou a migração da Shopify de React Native para Swift/Kotlin (Tardis, Helix, checkpoints, revisores adversariais — veja a outra aba). O que muda aqui é o alvo: linguagem, não framework.

03 · Os fatos

Os casos reais de 2026

Esta é a lista que responde à pergunta “o que tem acontecido?”. Todos os casos abaixo aconteceram (ou estão em curso) entre dezembro de 2025 e setembro de 2026:

Bun: Zig → Rust julho de 2026 · o caso que virou referência

Jarred Sumner (criador do Bun) portou o runtime JavaScript de Zig para Rust com uma frota de agentes Claude rodando em paralelo — e publicou o método junto com o resultado. A Anthropic transformou o experimento no seu playbook oficial de migrações em escala.

535 mil linhas de Zig traduzidas +1 milhão de linhas de Rust geradas 11 dias de execução 64 agentes em paralelo ~US$ 165 mil em tokens 100% da suíte de testes legada passando antes do merge

Pico de ~1.300 linhas de código por minuto. “Uma reescrita em outra linguagem levaria um time pequeno um ano inteiro” — e congelaria bugfixes e features durante todo esse tempo. Depois do port: um benchmark de 2.000 builds repetidos caiu de 6.745 MB para 609 MB de memória, o binário ficou 19% menor (Linux/Windows) e 2–5% mais rápido em HTTP, next build e tsc. Cerca de 4% do Rust ficou em blocos unsafe, quase todos em fronteiras C/C++.

Método (6 passos, com starter kit open source): montar rulebook + mapa de dependências + inventário de lacunas → stress-test em 3 arquivos (“shakedown cruise”) → tradução em massa com dois revisores adversariais por lote → compilar (fora do loop: cargo é lento) → rodar → comparar comportamento até o fim.

“Não existe absolutamente nenhuma forma de um engenheiro com aquele salário ter alcançado os marcos que o Claude alcançou em 11 dias.”

Mitchell Hashimoto (co-fundador da HashiCorp), no X
GitHub Copilot runtime: TypeScript → Rust mai–ago/2026 · o caso “empresarial”

Stephen Toub (Distinguished Engineer da Microsoft) portou o runtime que roda por trás do Copilot CLI, do app, do SDK, do VS Code, do Visual Studio, do Excel, do Outlook e do PowerPoint de TypeScript/Node/V8 para Rust — sem parar de shippar, em PRs atômicos componente por componente.

832.378 linhas de Rust em produção 430 mil linhas de TS substituídas 128 PRs em 14,5 semanas ~US$ 120 mil em tokens + ~3 semanas de 1 dev 96,2% de prompt-cache hit
Métrica (benchmark)TypeScript/NodeRustGanho
Client + sessão + 1 turno5,25 s292 ms (in-process)18×
1.000 ciclos de sessão (100 pipelines)7,55/s120/s15,9×
Memória de 10 clients concorrentes1.383 MB126 MB−91%
CPU agregada (mesma carga)312 s~110 s−65%
Números do post oficial de Toub no GitHub Blog. “Eu não parti para mover para Rust; eu parti para sair do Node.js e do V8.”

O relato é também o melhor catálogo público de como isso dá errado: dezenas de regressões conhecidas (todas corrigidas) — semântica ambígua (f64 onde deveria ser inteiro, quebrando SDKs tipados), comportamentos “ambientes” do Node que sumiram, pares de operações portados pela metade, ciclos de vida e ownership. Lições oficiais: “traduza primeiro, redesenhe depois”, testes E2E são o oráculo e devem ser protegidos dos próprios agentes, e “se compila, está correto” só funciona como piada. Detalhe tranquilizador: dos 158 blocos unsafe (todos em fronteiras externas — C ABI, Win32, POSIX, SQLite), nenhuma regressão conhecida veio de um deles.

Curiosidade do log: os agentes gastaram 10× mais tempo explorando do que editando — “a imagem popular da IA despejando código é quase o oposto”.

Microsoft: eliminar C e C++ até 2030 dez/2025 → · a aposta mais radical

Galen Hunt, Distinguished Engineer da Microsoft, anunciou publicamente a meta: “My goal is to eliminate every line of C and C++ from Microsoft by 2030.” O grupo responsável (“Future of Scalable Software Engineering”) combina análise algorítmica de programas + agentes de IA em escala + engenharia humana para traduzir sistemas legados para Rust — cerca de 1 bilhão de linhas na mira, com mandato de Rust para código novo no Azure.

Motivação declarada: memory safety e redução de superfície de ataque. Ressalvas importantes da própria cobertura: por ora trata-se de um programa de ferramentas e infraestrutura de migração (e de uma ambição), não de uma reescrita monolítica do Windows amanhã. Mas o sinal é o que importa: quando uma big tech diz “vamos nos livrar de C/C++ em 5 anos via IA”, a conversa sobre linguagem mudou de patamar.

Google · Bug Hunters

C → Rust com Gemini

Piloto concluído para avaliar “AI-assisted rewrites”: usar o Gemini para reescrever rapidamente bibliotecas C para Rust, atacando o problema do ecossistema gigantesco de dependências C/C++ legadas.

Canonical + Univ. Bristol

AppArmor e snap-confine

Pesquisa para traduzir C → Rust com prova de equivalência de comportamento (fuzzing + análise formal + reparo simbólico). O alvo difícil: Rust seguro e fiel ao original. “Gerar código em escala deixou de ser a parte difícil — a difícil é provar que ele faz o que o original fazia.”

Ladybird

Navegador: 25 mil linhas em 2 semanas

O navegador Ladybird migrou ~25.000 linhas de C++ para Rust em duas semanas com agentes (motor LibJS: lexer, parser, AST, bytecode), mirando “zero regressões” — módulo autocontido com boa cobertura de testes, exatamente o caso ideal.

DARPA

TRACTOR

Programa que explora tradução automatizada de C++ para Rust em contexto de defesa — sinal de que o tema virou política de infraestrutura crítica, não só preferência de dev.

Matz · Ruby

Compilador nativo com IA

O criador do Ruby está desenvolvendo um compilador nativo com ajuda de IA para o Ruby — mais um caso de “usar a IA para dar à linguagem uma propriedade que ela não tinha” (neste caso, performance).

Ecosistema

TypeScript→Go, compiladores por agentes

O compilador do TypeScript 7 (port em Go) chegou à primeira release estável; o próprio Bun portado é o motor do Claude Code em produção. Até times de agentes construindo um compilador de C do zero entraram no noticiário de 2026.

O padrão que se repete

Em todos os casos: (1) existe uma implementação de referência (o código antigo) e um juiz objetivo (testes, diff, benchmark); (2) o alvo é Rust, não C — quando o motivo é segurança de memória; (3) o ganho aparece em startup, memória e binário — as métricas que a era do Electron ensinou a ignorar; (4) o custo vai de dezenas a centenas de milhares de dólares, contra o custo humano equivalente de um time por 1–4 anos.

04 · O caso específico do C

Por que “C puro” voltou para a conversa

Os comentários falam em “voltar para C”, mas os grandes rewrites vão para Rust. Os dois fatos convivem — porque respondem a perguntas diferentes:

C é a cola universal — e continua sendo

Todo grande runtime que se integra a múltiplas linguagens expõe uma C ABI: o runtime do Copilot, por exemplo, serve 6 SDKs (C#, TS, Python, Rust, Go, Java) através de 19 funções de fronteira C. Se os agentes vão colar sistemas heterogêneos, o denominador comum é C. E o próprio Rust “fala C” nas fronteiras (os unsafe blocks do Copilot são quase todos C ABI, Win32 e POSIX).

C e C++ estão crescendo de novo

No TIOBE de janeiro de 2026, C subiu para a 2ª posição (troca com Java); fevereiro foi descrito como “retorno espetacular”; em abril, a análise registra que a IA está estimulando linguagens tipadas. Herb Sutter cita dados da SlashData: C++ cresceu de 9,4 milhões de devs (2022) para 16,3 milhões (2025) — e atribui o movimento a “performance por watt”, não a moda.

As LLMs “sabem” C melhor do que quase tudo

São 50+ anos de kernels, bibliotecas, exemplos e posts — o maior corpus de uma única linguagem em sistemas. Além disso, C tem poucas construções e semântica estável, o que torna o código gerado mais previsível de revisar do que a sintaxe esperta de linguagens mais jovens.

Simplicidade virou feature mensurável

O argumento do vídeo é literal: um binário nativo de 25 MB em Rust contra 500 MB de um Electron para o mesmo programa, rodando “até num computador de 2001”. Menos camadas = menos RAM, menos startup, menos dependências — e agentes reduzem o custo de escrever na linguagem que dá esse resultado, seja C, C++, Rust ou Zig.

O divisor de águas

“C puro” aparece onde o motivo é footprint, interop ou performance bruta (ferramentas greenfield, embarcados, serviço local, CLI, engine). Onde o motivo é segurança de memória, o destino é Rust — foi assim no Google, na Canonical, na DARPA e na meta da Microsoft. Voltar para C é assumir o risco de memória conscientemente; a indústria, quando pode escolher, está escolhendo o porto seguro.

05 · O outro lado

O contraponto (de novo)

Se a aba 1 já tinha contrapontos, esta emenda o freio de fábrica. Começando pelo mais forte:

1 · “Unreviewed slop”: o criador do Zig revidou

Andrew Kelley não engoliu o port do Bun. Disse que o projeto já escrevia “slop” muito antes dos LLMs, apontou que o Zig tem hoje uma política de não aceitar contribuições geradas por IA, e fez a pergunta que todo time deveria carregar:

“O argumento para shippar um milhão de linhas de código não revisado é que a suíte de testes é boa o suficiente para pegar tudo. Ela não é suficiente para pegar bugs no código Zig — mas é suficiente para pegar bugs em um milhão de linhas de slop não revisado?”

Andrew Kelley, criador do Zig (via The Register, jul/2026)

O contraponto técnico direto: teste é necessário, mas não é prova de correção. Foi a própria Microsoft que documentou dezenas de regressões que compilaram e passaram por revisões automáticas — bugs semânticos que nenhum compilador pega.

2 · Os próprios devs de C++ desconfiam

A pesquisa anual do comitê ISO C++ (1.434 respondentes, maioria com 10+ anos de experiência) mostra o paradoxo: uso de IA subindo forte (39,8% usam com frequência para código, contra 30,9% no ano anterior; testes de 20% → 33%; debug de 11,5% → 23,6%) — mas 42% ainda raramente ou nunca usam. Entre os problemas relatados: output incorreto, falta de confiança, privacidade de dados e custo. E dificuldades específicas: projetos grandes e build systems complexos.

3 · Custo, dependência e o dia em que os tokens mudarem de preço

4 · E tem gente indo na direção contrária

Em maio de 2026, Simon Willison relatou uma empresa que usou agentes para consolidar seus apps iOS + Android em um único React Native — o movimento inverso da Shopify. Assim como não existe um sentido único da história, não existe uma linguagem “certa”: existe a propriedade certa para o gargalo certo. Que é exatamente a régua proposta pelo comentário mais lúcido de todos:

“Trocar de stack, linguagem ou framework costuma ser o caminho preguiçoso quando você ainda não entendeu onde está o gargalo real. Na maioria das vezes, esse não é o seu problema.”

@gogodev2 — comentário no vídeo (que, paradoxalmente, também é o autor do caso Electron × Rust)
06 · Framework prático

Como decidir se/quando trocar de linguagem

Destilado dos três melhores relatos públicos (Anthropic, GitHub, Shopify), na ordem em que você deve se perguntar:

  1. Existe um “juiz” objetivo? Suíte de testes E2E independente, implementação de referência, benchmark. Sem juiz, não migre — você vai trocar um sistema que funciona por um que você não consegue verificar. E proteja o juiz: agentes não podem reescrever os testes que provam o comportamento (regra explícita do port do Copilot, após um agente ter “resolvido” uma falha aplicando um label de waiver).
  2. O gargalo real é a stack? Se for build system, arquitetura ou processo, trocar de linguagem não resolve nada (a régua do @gogodev2).
  3. Traduza primeiro, redesenhe depois. Preserve comportamento ao máximo; use o código antigo como spec. Só depois replaneje ownership, concorrência e performance contra uma baseline estável — o port do Copilot documenta que misturar as duas coisas multiplica regressões.
  4. Faça as contas completas: tokens (com cache), tempo humano de supervisão e revisão, e o custo do não-feito. Bun: ~US$ 165 mil + 11 dias. Copilot: ~US$ 120 mil + ~3 semanas de um sênior. Compare com o custo humano equivalente (anos de time) — e com o risco de regressões pós-merge (dezenas, nos dois casos).
  5. Escolha o alvo pelo motivo: memória/segurança → Rust; footprint/interop/embarcados → C/C++; produtividade com performance “boa o suficiente” → Go/Kotlin/Swift modernos. Não escolha por tribalismo.
  6. Rode o loop certo: rulebook + mapa de dependências + inventário de lacunas → stress-test pequeno → lotes com revisores adversariais → gates por checkpoint (testes + diff de comportamento + humano). É o Helix da Shopify e o playbook da Anthropic: o mesmo desenho, em qualquer stack.
  7. Meça antes/depois nas métricas que importam: startup, memória, tamanho de binário, throughput, estabilidade, custo de infra. Sem números, é fé — e fé é o que a indústria já tem de sobra.
Atalho honesto

Se você tem (a) código de referência, (b) testes confiáveis e (c) um gargalo claro de runtime — a troca de linguagem entrou no cardápio de 2026. Se falta qualquer um dos três, o trabalho real é construir esses pré-requisitos, não escolher linguagem.

07 · Síntese

Sete conclusões

  1. Linguagem deixou de ser “custo de entrada” e virou “escolha de propriedades”. Com agentes pagando o pedágio de sintaxe, idioma e boilerplate, o time escolhe por RAM, watt, startup, binário e segurança — não por “o que é mais fácil de achar dev”.
  2. Os números são reais e recentes: 535 mil linhas Zig→Rust em 11 dias por ~US$ 165 mil; 832 mil linhas de Rust em produção no GitHub Copilot por ~US$ 120 mil + 3 semanas de um engenheiro; 25 mil linhas C++→Rust em 2 semanas no Ladybird.
  3. “Voltar para C” é menos sobre C e mais sobre liberdade de baixo nível. C é a ABI universal e subiu a #2 no TIOBE; C/C++/Rust crescem juntos por “performance por watt”.
  4. Rust é o porto seguro, C é a estrada. Rewrites de segurança vão para Rust (Google, Canonical, DARPA, meta da Microsoft). C puro aparece onde o motivo é footprint/interop — assumindo o risco de memória conscientemente.
  5. Compilar não é estar correto. Dezenas de regressões nos maiores ports da história, todas compilando. Teste é juiz, não oráculo — e deve ser blindado dos próprios agentes.
  6. O loop venceu o one-shot — de novo. Rulebook, checkpoints, revisores adversariais, memória de review: o mesmo formato que a Shopify chamou de Helix e a Anthropic publicou como playbook.
  7. A régua antiga continua valendo: só troque de stack quando entender o gargalo. A novidade de 2026 é que, quando a resposta for trocar, o custo deixou de ser proibitivo.
08 · Referências

Fontes

Complemento do estudo principal: Shopify × React Native — a IA acabou com a maior vantagem do React Native?