O time do Go debateu se pode aceitar código gerado por IA
E aí, pessoal!
Em fevereiro de 2026, uma contribution chegou no repositório do Go. O diff era razoável, os testes passavam, e o revisor estava quase aprovando quando notou uma linha no commit:
1
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Ian Lance Taylor abriu uma thread no golang-dev com o título direto: “What should we do with CLs generated by AI?”. Russ Cox, vários core contributors e engenheiros do Google responderam. O que era pra ser uma pergunta simples virou uma discussão com argumentos legais, questões de manutenção e zero consenso fácil.
E o Go não estava sozinho. O mesmo debate estava acontecendo em paralelo no PyTorch, OpenSSL, Kubernetes e Qt. Cada um chegou em uma resposta diferente.
O que uma linha de commit levanta
Quando você adiciona Co-Authored-By: Claude num commit, parece só uma questão de transparência. Mas para um projeto open source com CLA, essa linha aciona três problemas concretos.
Problema 1: o bot do CLA não entende o que é uma IA
O PyTorch descobriu isso da pior forma. Em maio de 2026, o projeto proibiu o uso de Co-authored-by: Claude em commits. A razão foi prática: o bot da Linux Foundation que gerencia o CLA lê cada linha de Co-authored-by e espera que a pessoa listada tenha assinado o acordo. Como Claude não pode assinar nada, o bot bloqueava o commit.
O commit que formalizou a proibição foi direto:
“The Linux Foundation CLA bot reacts to the trailer, so disclose Claude authorship informally in the commit body instead.”
Ou seja: não tire o crédito, mas coloca no corpo do commit, não no trailer. Problema técnico resolvido. Problema legal, não necessariamente.
Problema 2: quem é o dono do código?
Quando você assina um CLA, você está dizendo que tem o direito legal de ceder aquele código ao projeto. Mas se parte do código foi gerado por uma IA treinada em código de terceiros com licenças diversas, essa cessão ainda é válida?
Giuseppe D’Angelo levantou exatamente isso na lista de desenvolvimento do Qt em julho de 2026:
“Licensor represents and warrants that it or its Affiliate is the owner of the Licensor Contribution(s) […] which is pretty much a gray area right now.”
A questão não tem resposta definitiva. O US Copyright Office tem a posição de que obras precisam ser criadas por humanos para ter copyright. Se código gerado por IA não tem copyright, o projeto pode usar sem restrição. Mas se tiver algum copyright derivado dos dados de treinamento, aí a coisa complica.
Na thread do Go, os participantes referenciaram dois casos em andamento: Bartz v. Anthropic e NYTimes v. Microsoft & OpenAI. Sem resolução judicial, qualquer projeto que aceitar código de IA está operando em terreno indefinido.
Um contribuidor no LWN resumiu bem:
“I remember doing this, co-authored attribution, back in the day because I thought it was ethical to flag this, given concerns about code quality. Some maintainers were very uncomfortable on the grounds of copyright (which I had not considered). Those concerns don’t really go away by not flagging co-authorship, instead you get ‘deniability’.”
Ou seja: esconder o uso de IA não resolve o problema de copyright, só cria deniability.
Problema 3: quem vai manter esse código?
Esse foi o ponto mais prático na discussão do Go. O revisor que aprova um CL assume responsabilidade por aquele código. A pergunta foi direta: o revisor entende o que está aprovando a ponto de debugar daqui a dois anos?
Não é sobre qualidade imediata. Código gerado por IA pode ser sintaticamente correto e passar em todos os testes. O problema é que pode usar padrões que o revisor não teria escolhido, ou fazer suposições implícitas que ficam invisíveis numa revisão rápida.
Como cada projeto respondeu
Ao longo de 2026, vários projetos grandes precisaram tomar uma posição. As respostas foram bem diferentes.
PyTorch: proibiu Co-authored-by: Claude nos trailers por causa do conflito com o CLA bot. Divulgação no corpo do commit ainda é permitida e encorajada.
Kubernetes: exige divulgação quando IA foi usada, mas proíbe listar IA como co-autor ou usar qualquer trailer de atribuição (nem Co-authored-by, nem Assisted-by). A posição é que o projeto aceita código de qualidade independente de como foi escrito, mas precisa saber.
OpenSSL: foi o mais rigoroso. Em junho de 2026, publicou uma política completa com dois requisitos:
- Declarar uso de IA no commit com um trailer específico:
1
Assisted-by: Claude:claude-sonnet-4-6
- Assinar uma nova versão do CLA que inclui cláusulas sobre IA. O CLA antigo não é suficiente para contribuições com IA, mesmo quem já assinou.
A política do OpenSSL é explícita que o contribuidor humano é responsável por tudo que submete, revisou o output da IA, e garante que o código não viola licenças de terceiros.
Qt: até julho de 2026, sem política formal. A thread aberta por Giuseppe D’Angelo ainda estava em discussão.
Go: sem política formal, sem proibição. A conclusão da thread foi pragmática: o processo de code review existente é suficiente. O revisor que aprova assume responsabilidade, independente de como o código foi gerado. Se o revisor entende e topa manter, pode ir.
O que isso muda na prática
Se você usa Claude Code, Cursor ou Copilot no dia a dia, já está nessa situação. Cada commit seu pode ter código gerado por IA. A maioria dos projetos open source ainda não tem política.
Algumas coisas práticas:
Antes de contribuir para um projeto open source com código gerado por IA:
- Verifique se o projeto tem política de IA. A maioria ainda não tem, mas OpenSSL, Kubernetes e PyTorch já publicaram a delas.
- Se o projeto usa Linux Foundation CLA,
Co-authored-by: Claudevai quebrar o bot. Coloca no corpo do commit. - Revise o que você está submetendo. Não só se compila e os testes passam. Você entende o código o suficiente para manter?
Se você mantém um projeto open source:
- É mais fácil definir uma posição antes de receber o primeiro PR com
Co-Authored-By: Claudedo que decidir na hora com o contribuidor esperando. - A política do OpenSSL é um bom ponto de partida: openssl-library.org/policies/general/ai-policy.
No trabalho, em código proprietário:
- As questões de CLA e copyright são diferentes, mas a questão de manutenção é a mesma. Quem aprovou entende o que está aprovando?
O que é mais interessante nessa história toda não é o Go em si. É que em menos de um ano, projetos como Go, PyTorch, OpenSSL, Kubernetes e Qt todos tiveram a mesma discussão, de forma independente, e chegaram em respostas diferentes. Não tem consenso. Provavelmente não vai ter tão cedo.
Mas uma coisa ficou clara em todos os projetos: a linha de Co-Authored-By: Claude no commit não é só um detalhe de atribuição. Ela força uma conversa que as ferramentas de IA não tiveram o cuidado de antecipar.
Referências: