TLDR;

Grandes empresas de tecnologia começaram a proibir ou restringir o uso de código gerado por IA em projetos críticos, como a decisão da Oracle de banir contribuições geradas por IA no OpenJDK. A principal motivação são preocupações com carga de trabalho dos revisores, segurança, confiabilidade e questões de propriedade intelectual, já que IA costuma produzir código que parece correto mas pode conter erros graves. Projetos como OpenJDK/Oracle, Zig, Rust, LLVM e o kernel Linux já adotaram políticas que variam de proibições totais a usos privados permitidos com revisão humana, divulgação e testes rigorosos.

Resumo

Nos últimos anos houve grande hype em torno de ferramentas de IA para gerar código, mas várias grandes empresas e projetos open source começam a impor restrições rigorosas: Oracle proibiu contribuições geradas por IA no OpenJDK (embora permita uso privado de LLMs para entender, depurar e pesquisar), citando carga dos revisores, segurança e problemas de propriedade intelectual; Zig adota proibição absoluta; Rust permitiu uso privado e controles experimentais; LLVM exige que um humano assuma responsabilidade; e o Linux aceita IA como ferramenta desde que contribuições sejam revisadas, testadas e assumidas pelo autor. O problema prático é a “AI horde”: centenas de pull requests gerados automaticamente sobrecarregam mantenedores e podem levar à exaustão ou à revisão automatizada. Modelos geram código que “parece correto” mas não garantem segurança, desempenho nem compreensão do contexto, e erros em infraestruturas críticas (JVM, kernels, bancos, bancos de dados, sistemas embarcados) têm alto custo. É provável que o desenvolvimento se divida em três categorias: projetos de baixo risco onde se aceita “slop coding” com IA; software cliente onde IA ajuda mas exige testes, revisão e propriedade humana; e infraestruturas de alto impacto que demandam código artesanal, padrões rigorosos e responsabilidade contínua da comunidade global.