Post
Available in: Português

The Go Team Debated Whether to Accept AI-Generated Code

Hey everyone!

In February 2026, a contribution arrived in the Go repository. The diff was reasonable, the tests passed, and the reviewer was about to approve it when they noticed a single line in the commit:

1
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Ian Lance Taylor opened a thread on golang-dev titled “What should we do with CLs generated by AI?”. Russ Cox, several core contributors, and Google engineers all responded. What should have been a simple question turned into a debate involving legal arguments, maintenance concerns, and no easy consensus.

And Go was not alone. The same debate was happening in parallel at PyTorch, OpenSSL, Kubernetes, and Qt. Each one reached a different answer.

What One Commit Line Triggers

Adding Co-Authored-By: Claude to a commit might seem like a simple transparency measure. But for an open source project with a CLA, that line activates three concrete problems.

Problem 1: The CLA Bot Has No Idea What an AI Is

PyTorch learned this the hard way. In May 2026, the project banned Co-authored-by: Claude from commit trailers. The reason was practical: the Linux Foundation CLA bot reads each Co-authored-by line and expects the listed person to have signed the contributor agreement. Since Claude cannot sign anything, the bot blocked the commit.

The commit that formalized the ban was blunt:

“The Linux Foundation CLA bot reacts to the trailer, so disclose Claude authorship informally in the commit body instead.”

So: keep the disclosure, but put it in the commit body, not the trailer. Technical problem solved. Legal problem, not necessarily.

Problem 2: Who Owns the Code?

When you sign a CLA, you are saying you have the legal right to assign that code to the project. But if part of the code was generated by an AI trained on third-party code under various licenses, does that assignment still hold?

Giuseppe D’Angelo raised exactly this on the Qt developer mailing list in July 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.”

The question has no definitive answer. The US Copyright Office holds that works need to be created by humans to qualify as authorship. If AI-generated code has no copyright, the project can use it without restriction. But if there is some derived copyright from training data, things get complicated.

In the Go thread, participants referenced two ongoing cases: Bartz v. Anthropic and NYTimes v. Microsoft & OpenAI. Without judicial resolution, any project accepting AI-generated code is operating on undefined ground.

A contributor on LWN summarized it well:

“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’.”

In other words: hiding AI use does not fix the copyright problem, it just creates deniability.

Problem 3: Who Will Maintain This Code?

This was the most practical point in the Go discussion. The reviewer who approves a CL takes responsibility for that code. The direct question was: does the reviewer understand what they are approving well enough to debug it two years from now?

This is not about immediate quality. AI-generated code can be syntactically correct and pass all tests. The problem is it may use patterns the reviewer would not have chosen, or make implicit assumptions that are invisible in a quick review.

How Each Project Responded

Throughout 2026, several major projects needed to take a position. The responses varied widely.

PyTorch: banned Co-authored-by: Claude in trailers due to the CLA bot conflict. Disclosure in the commit body is still allowed and encouraged.

Kubernetes: requires disclosure when AI was used, but forbids listing AI as a co-author or using any attribution trailer (neither Co-authored-by nor Assisted-by). The position is that the project accepts quality code regardless of how it was written, but needs to know.

OpenSSL: the strictest. In June 2026, they published a complete policy with two requirements:

  1. Declare AI use in the commit with a specific trailer:
1
Assisted-by: Claude:claude-sonnet-4-6
  1. Sign a new version of their CLA that includes AI clauses. The old CLA is not sufficient for AI-assisted contributions, even for those who previously signed.

OpenSSL’s policy is explicit that the human contributor is responsible for everything submitted, reviewed the AI output, and guarantees the code does not violate third-party licenses.

Qt: no formal policy as of July 2026. The thread opened by Giuseppe D’Angelo was still in discussion.

Go: no formal policy, no ban. The conclusion of the thread was pragmatic: the existing code review process is sufficient. The reviewer who approves takes responsibility, regardless of how the code was generated. If the reviewer understands it and is willing to maintain it, it can go in.

What This Changes in Practice

If you use Claude Code, Cursor, or Copilot day to day, you are already in this situation. Every commit you make may contain AI-generated code. Most open source projects still have no policy.

A few practical things:

Before contributing to an open source project with AI-generated code:

  • Check if the project has an AI policy. Most do not yet, but OpenSSL, Kubernetes, and PyTorch have already published theirs.
  • If the project uses the Linux Foundation CLA, Co-authored-by: Claude will break the bot. Put it in the commit body instead.
  • Review what you are submitting. Not just whether it compiles and tests pass. Do you understand the code well enough to maintain it?

If you maintain an open source project:

  • It is easier to define a position before you receive the first PR with Co-Authored-By: Claude than to decide on the spot with a contributor waiting.
  • The OpenSSL policy is a good starting point: openssl-library.org/policies/general/ai-policy.

At work, in proprietary code:

  • CLA and copyright questions are different, but the maintenance question is the same. Does the reviewer who approved it understand what they approved?

What is most interesting about this whole story is not Go specifically. It is that in less than a year, projects like Go, PyTorch, OpenSSL, Kubernetes, and Qt all had the same discussion independently, and arrived at different answers. There is no consensus. There probably will not be one soon.

But one thing became clear across all projects: the Co-Authored-By: Claude line in a commit is not just an attribution detail. It forces a conversation that AI tooling did not bother to anticipate.


References: