GCC traça a linha para código gerado por IA

A nova política de IA do GCC importa porque cria uma regra objetiva para uma pergunta que muitas equipes ainda tratam no improviso: código gerado por LLM pode entrar em um projeto crítico? A resposta do GCC, anunciada em 28 de julho de 2026 e divulgada pela LWN em 29 de julho de 2026, é direta: contribuições legalmente significativas com conteúdo gerado ou derivado de LLM devem ser recusadas, embora IA continue permitida para pesquisa, análise, descoberta de bugs e revisão.

Esse movimento não é só ideológico. O GCC é uma das bases do ecossistema de software: compila C, C++, Fortran, Ada, D, Go, Rust em evolução e outras linguagens para múltiplas arquiteturas. Quando um projeto desse porte decide explicitar uma política para IA, ele sinaliza que a questão deixou de ser produtividade individual e virou governança de supply chain.

O que o GCC decidiu?

O Steering Committee do GCC aceitou a recomendação do AI Policy Working Group em uma mensagem pública enviada à lista do projeto em 28 de julho de 2026. Segundo o anúncio arquivado pela LWN, a política será incorporada ao site do GCC e deve ser revisitada periodicamente.

O ponto central é o limite de contribuição legalmente significativa. A LWN reportou que o GCC usa a definição das diretrizes de mantenedores do GNU, em que algo por volta de 15 linhas de código ou texto já pode ser significativo para fins de copyright. A regra prática é simples: se a contribuição inclui ou deriva de conteúdo gerado por LLM e passa desse limite, ela deve ser rejeitada.

Ao mesmo tempo, a política não proíbe o uso de ferramentas como ChatGPT, Claude, Gemini, Copilot, Cursor ou modelos locais para entender código, investigar regressões, resumir discussões, revisar patches ou encontrar hipóteses de bug. Também abre uma exceção relevante: mantenedores podem aceitar casos de teste gerados por LLM, desde que julguem apropriado.

• Proibido: enviar patch legalmente significativo com código ou documentação produzidos por LLM.
• Permitido: usar IA para pesquisa, análise, revisão, triagem e descoberta de bugs.
• Possível exceção: testes gerados por IA, a critério dos mantenedores.
• Critério concreto: o limiar citado é em torno de 15 linhas de código ou texto.

Por que isso importa para desenvolvedores?

Porque a maior parte das empresas ainda está no estágio errado da conversa. Elas perguntam se devem liberar IA no editor, mas deixam indefinido quem é o autor real do código, quem responde por uma regressão, como provar a origem de um trecho e qual material pode ser enviado para repositórios externos.

O GCC está separando duas coisas que muita gente mistura: assistência cognitiva e autoria incorporada. Usar um modelo para explicar uma função de 200 linhas é uma coisa. Copiar a solução proposta por ele para dentro de um patch é outra. A primeira melhora o processo de engenharia. A segunda altera a cadeia de responsabilidade do artefato entregue.

Para contribuidores open source, a consequência prática é clara: se você usa LLM no fluxo, precisa conseguir reconstruir a decisão técnica sem depender da resposta do modelo. Em revisão, mantenedores não querem apenas um diff que compila. Eles querem saber se você entende invariantes, casos de borda, ABI, compatibilidade, desempenho e manutenção futura.

Em projetos críticos, isso muda também o padrão de revisão. Um patch grande vindo de alguém sem histórico já era difícil de avaliar. Com LLMs capazes de gerar mudanças plausíveis em minutos, o custo de revisão pode crescer mais rápido que o valor da contribuição. A política do GCC tenta proteger o gargalo mais caro do open source: atenção qualificada de mantenedores.

Como empresas devem adaptar o fluxo?

A lição para empresas não é bloquear IA por reflexo. É documentar onde a ferramenta pode ajudar e onde ela não pode virar fonte invisível de código. Times que usam GitHub Copilot, ChatGPT Enterprise, Claude Code ou agentes internos precisam de regras diferentes para prototipação, código de produção, testes, documentação e contribuições upstream.

Uma política mínima deveria caber no próprio repositório. Por exemplo:

# Política de uso de IA no repositório

- IA pode ser usada para pesquisa, explicação, revisão e geração de ideias.
- Código de produção deve ser escrito, entendido e assumido pelo autor do commit.
- Trechos gerados por IA acima de 15 linhas não devem ser enviados a projetos upstream sem checar a política do projeto.
- PRs que usaram IA devem declarar o uso quando isso afetar implementação, testes ou documentação.
- O reviewer pode pedir explicação técnica independente da saída do modelo.

Esse tipo de regra evita dois extremos ruins. De um lado, a proibição total que empurra o uso para a sombra. De outro, a automação sem rastreabilidade, em que ninguém sabe se uma função veio de um engenheiro, de um modelo, de uma resposta copiada ou de uma mistura impossível de auditar.

Para empresas que contribuem com Linux, GCC, LLVM, PostgreSQL, Kubernetes, Drupal, WordPress ou qualquer projeto de infraestrutura, a orientação é ainda mais direta: leia a política do projeto antes de abrir um PR. O que é aceitável internamente pode ser recusado externamente. E uma contribuição rejeitada por origem nebulosa custa reputação, não só tempo.

O caso do GCC deve virar referência porque troca opinião por contrato social explícito. Em vez de discutir se IA é boa ou ruim, o projeto definiu onde ela entra, onde não entra e qual limite operacional será usado. Esse é o tipo de maturidade que empresas brasileiras também precisam adotar em 2026.

Perguntas frequentes

O GCC proibiu o uso de IA?

Não. A política permite IA para pesquisa, análise, descoberta de bugs, revisão e outras atividades de apoio. O que ela recusa são contribuições legalmente significativas que incluam ou derivem de conteúdo gerado por LLM.

Qual é o limite de código gerado por IA no GCC?

A referência citada pela LWN usa o conceito GNU de contribuição legalmente significativa, em torno de 15 linhas de código ou texto. Acima desse patamar, patches com conteúdo de LLM devem ser recusados.

Empresas devem banir Copilot e ChatGPT do desenvolvimento?

Não necessariamente. O melhor caminho é definir política por contexto: uso livre para estudo e revisão, mais controle para código de produção e atenção especial para contribuições a projetos open source.

Por que código gerado por IA preocupa projetos open source?

Porque dificulta autoria, manutenção, responsabilidade e análise de licença. Em projetos críticos, um patch plausível não basta; o contribuidor precisa entender e sustentar tecnicamente a mudança.