O Seguidor de Distribuição: O Que um Compilador de $20K Revela Sobre Governança

Em janeiro de 2026, alguém gastou aproximadamente $20.000 em créditos de API para que o Claude gerasse um compilador C completo do zero. O Claude C Compiler — CCC — produz código para quatro arquiteturas de CPU, tem design inspirado no LLVM e representa, por qualquer métrica razoável, uma façanha técnica impressionante.

Também falhou na etapa de linking com aproximadamente 40.784 erros de referência indefinida.

Chris Lattner — criador do LLVM, do Swift e do MLIR, e atualmente CEO da Modular — publicou uma análise detalhada do projeto. Sua conclusão central: LLMs são “seguidores extraordinariamente poderosos de distribuição.” Reproduzem o centro estatístico dos dados de treinamento. Não inventam.

Essa frase merece atenção. Não pela originalidade — outros já disseram algo semelhante. Mas pelo que ela revela quando aplicada a decisões de governança.

O Que o CCC Faz Bem e o Que Revela

O compilador funciona. Gera assembly para x86-64, ARM64, RISC-V e WebAssembly. Tem parser, AST, otimizações, geração de código. Para quem acompanha a evolução de LLMs, o escopo é genuinamente notável.

Mas a análise de Lattner expõe padrões que qualquer líder técnico deveria reconhecer — porque provavelmente já os encontrou no código gerado por IA da sua própria equipe.

O CCC hardcoda valores de retorno para passar em testes específicos. Re-parseia assembly ao invés de usar representação intermediária. A recuperação de erros é precária. Há overfitting ao test suite: o compilador foi otimizado para os testes que validavam seu progresso, não para robustez geral.

Cada um desses problemas é uma instância do mesmo fenômeno: o modelo reproduziu padrões de compiladores existentes — e fez isso com competência real — mas sem o entendimento de design que torna um compilador sustentável. Funciona no centro da distribuição. Falha nas bordas.

Seguidor de Distribuição É uma Declaração de Governança

Lattner tem interesse próprio nessa conclusão. Como CEO da Modular, empresa que constrói a linguagem Mojo, sua tese de que design humano de linguagens é insubstituível serve diretamente ao negócio. Compiladores também são o domínio mais documentado da ciência da computação — se LLMs vão reproduzir padrões existentes com competência, compiladores são o terreno ideal.

Honestidade intelectual exige notar esses conflitos.

Mas honestidade intelectual também exige notar que o argumento não depende da imparcialidade de quem o faz. Os padrões que Lattner identifica no CCC — overfitting, hardcoding, ausência de design coerente — são verificáveis por qualquer engenheiro que leia o código. E são os mesmos padrões que aparecem nos dados de escala.

Se IA é um seguidor de distribuição — se reproduz o que é comum nos dados de treinamento — então a questão de governança não é se a IA sabe programar. É quem define a distribuição que ela segue.

Quem escolhe a arquitetura. Quem define as interfaces. Quem decide que um compilador precisa de representação intermediária, não de re-parseamento de assembly. Quem estabelece os critérios de aceitação que vão além de “os testes passam.”

Essas são decisões humanas. E são, fundamentalmente, decisões de governança.

Os Números de Escala Confirmam o Padrão

Se o CCC fosse um caso isolado, seria anedota. Não é.

O relatório CircleCI 2026 analisou 28 milhões de workflows. O próprio relatório formula a conclusão: “mais atividade, menos entrega.” Atividade em feature branches subiu 15%. Throughput da branch principal caiu 7%. A taxa de sucesso da branch principal caiu para 70,8% — abaixo do benchmark de 90%.

Mais código sendo gerado. Menos código chegando a produção. O gargalo migrou de geração para validação.

A Veracode encontrou que 40 a 48% do código gerado por IA contém vulnerabilidades de segurança. O estudo do METR com desenvolvedores experientes mostrou que IA os tornou 19% mais lentos — enquanto eles acreditavam estar 24% mais rápidos. Percepção e realidade divergindo em 43 pontos percentuais.

Esses dados não dizem que IA é inútil. Dizem que IA sem verificação é perigosa. E que a infraestrutura de verificação da maioria das organizações não acompanhou a velocidade de geração.

O Gargalo Que Migra

Há um padrão recorrente na história da automação que vale notar. Quando ATMs foram introduzidos, a previsão era de que caixas de banco desapareceriam. O oposto aconteceu: o número de caixas aumentou, porque agências ficaram mais baratas de operar, mais agências foram abertas, e o papel dos caixas migrou para vendas e relacionamento.

Exceto que essa narrativa, frequentemente citada, omite o capítulo seguinte. Décadas depois, a automação bancária realmente reduziu posições. A migração para “funções de maior valor” não é lei natural — é possibilidade que depende de condições específicas.

Com IA em código, a narrativa dominante é que desenvolvedores “subirão na cadeia de valor” — de escrever código para projetar sistemas, de implementar para especificar, de executar para decidir. Talvez. Mas a evidência atual sugere cautela.

O CCC custou $20.000 e produziu um compilador que funciona parcialmente. Se o custo de implementação tende a zero e a qualidade tende ao centro da distribuição, o recurso escasso não é código — é julgamento sobre o que construir e como verificar.

Lattner formula isso diretamente: “Decidir o que construir” é onde o valor humano se concentra. A Amp, empresa de tooling para IA, argumenta que “como você organiza seu codebase para agentes” é o gargalo real — embora, vale notar, sem apresentar dados para sustentar a afirmação.

O Risco de PI Que Ninguém Quer Discutir

Há uma implicação do “seguidor de distribuição” que não aparece nas discussões técnicas mas tem peso jurídico crescente.

Se LLMs reproduzem o centro estatístico dos dados de treinamento, o código que geram carrega proveniência indeterminada. Lattner observa que o CCC regenera artefatos “fortemente semelhantes a implementações existentes.” O U.S. Copyright Office, em maio de 2025, declarou que “não é possível pré-julgar resultados de litígios” envolvendo código gerado por IA.

Tradução prática: sua organização está comitando código cuja propriedade intelectual ninguém consegue garantir. Frameworks legais existentes, nas palavras de Lattner, “lutam para descrever sistemas que aprendem estatisticamente de trabalho protegido por direitos autorais.”

Isso não é argumento para parar de usar IA. É argumento para saber exatamente o que IA está gerando no seu codebase e ter capacidade de rastrear, auditar e substituir se necessário. Governança de PI, assim como governança de qualidade, exige infraestrutura — não promessas.

A Decisão Que Importa

O CCC é um artefato fascinante. Demonstra que IA pode produzir software de complexidade real a custo marginal próximo de zero. E demonstra, simultaneamente, que software de complexidade real sem julgamento humano de design falha de formas previsíveis.

Organizações que estão adotando IA para desenvolvimento de software enfrentam uma decisão que a maioria ainda não formulou explicitamente: se IA é um seguidor de distribuição, quem governa a distribuição?

Quem define os padrões que IA vai reproduzir no seu codebase? Quem estabelece os critérios de verificação que distinguem “os testes passam” de “o sistema é robusto”? Quem mantém a visão arquitetural que IA não pode ter porque opera tarefa por tarefa, sem memória de design entre sessões?

Se a resposta é “ninguém explicitamente,” sua organização já escolheu. Escolheu deixar que a distribuição estatística dos dados de treinamento defina a arquitetura do seu software. Escolheu que o centro da curva — a média do que existe — seja o teto do que você constrói.

Um compilador de $20.000 pode se dar ao luxo de falhar no linking. Seu sistema de produção, não.

Thiago Victorino é fundador do Victorino Group, consultoria especializada em implementação governada de IA. Para discutir como estruturar governança de IA no desenvolvimento de software da sua organização, entre em contato: contato@victorino.com.br | www.victorino.com.br