Last week I reviewed a pull request that was 90% AI-generated. The contributor didn't mention it. I only caught it because the code had that weird, overly-commented, slightly-too-clean pattern Claude tends to produce. The logic was sound. The variable names were suspiciously perfect. And there was a comment explaining something obvious — dead giveaway.
I rejected it.
Not because the code was bad. It wasn't. I rejected it because I couldn't trust what I was looking at. Was this a solution someone thought through, or just a plausible-looking output from a model that doesn't actually understand our codebase? I had no way to know. And that's the core problem nobody's talking about: when AI involvement isn't disclosed, the entire review process breaks down.
This isn't theoretical. According to GitHub's 2024 Octoverse report, developers are increasingly integrating AI assistants into their workflows, with a significant portion of new code on the platform touching AI tools in some capacity. The Linux kernel maintainers have already wrestled with this publicly. Debian's been debating it for months. The question isn't whether people are using AI for contributions. They absolutely are. The question is what happens to trust when nobody admits it.
The trust problem hiding in plain sight
Code review relies on a pretty simple contract. You submit code. I assume you wrote it, understood it, and can stand behind it. When AI enters the picture, that assumption crumbles. Maybe you prompted carefully and reviewed every line. Maybe you copy-pasted a Stack Overflow answer into ChatGPT and shipped whatever came out. I can't tell the difference from the diff alone.
I've been on both sides of this. I've submitted AI-assisted code that I'd thoroughly tested and understood. And I've also, in a rush, shipped something Claude suggested that I only skimmed. Guess which one caused a production incident three weeks later.
The disclosure part matters because it changes how reviewers approach the code. If I know AI was involved, I'm going to scrutinize edge cases more carefully. I'm going to ask different questions. I'm going to look for the specific failure modes that LLMs are prone to — hallucinated API methods, plausible-but-wrong logic, subtle security oversights that look correct at first glance. Without disclosure, I'm reviewing blind.
What the big projects are already doing
The conversation isn't hypothetical anymore. Major open-source projects are starting to draw lines in the sand, though the approaches vary wildly.
The Linux kernel mailing list saw a notable exchange in early 2024 when a maintainer flagged AI-generated patches and essentially said: we need to know. The sentiment wasn't "AI bad." It was "I need to know what I'm reviewing." The Gentoo Linux distribution went further, officially banning AI-generated contributions unless explicitly disclosed and verified. Their council policy basically says: if you used AI, tell us, or we'll reject it outright.
Debian's approach has been more nuanced. Their discussions on the debian-devel mailing list in late 2024 centered around a practical question: how do you even verify disclosure? Anyone can say "I wrote this myself." The conversation is still ongoing, but the direction is clear — some form of mandatory disclosure is coming, likely tied to their existing Developer Certificate of Origin process.
What's interesting is that none of these projects are saying AI-assisted contributions are unwelcome. They're saying undisclosed AI contributions are unwelcome. That distinction matters. A lot.
Why "just review the code" doesn't work
I hear this argument constantly. "If the code is good, who cares how it was written?" It sounds reasonable. It's also wrong, and here's why.
Code review isn't just about correctness. It's about intent. When I review a human-written contribution, I'm evaluating not just whether the code works, but whether the contributor understood the problem. Did they consider the right tradeoffs? Do they grasp the architectural implications? Will they be able to maintain this code six months from now?
AI-generated code short-circuits all of that. The code might be correct. It might even be elegant. But the contributor might have zero understanding of why it works. And when that code breaks — and it will break — who fixes it? The person who prompted it into existence? They might not know where to start.
I've seen this play out in real projects. A contributor submits a beautifully structured React component with perfect TypeScript types. Gets merged. Three weeks later, a subtle state management bug emerges that only manifests under specific race conditions. The contributor can't debug it because they don't actually understand the closure pattern the AI used. Now it's my problem. The maintainer's problem.
Disclosure doesn't prevent this scenario. But it lets me, as a reviewer, ask better questions before merging. "Walk me through the state management approach here." If the contributor can explain it, great — AI was a tool, not a crutch. If they can't, we have a conversation before the code hits main.
The legal tangle nobody's sorted out yet
Here's where it gets genuinely messy. Open-source licensing depends on clear provenance. The GPL, MIT, Apache — they all assume a human author with the legal right to contribute code under those terms. When AI generates code, who holds the copyright? Can AI-generated code even be copyrighted?
The U.S. Copyright Office has been fairly clear on this: works created entirely by AI without sufficient human creative input aren't copyrightable. But "sufficient human creative input" is doing a lot of heavy lifting there. If I prompt an AI, review the output, modify it, and integrate it — is that sufficient? Probably. If I paste an error message into Copilot and accept whatever it suggests? Less clear.
This isn't just academic. The Software Freedom Conservancy has raised concerns about AI-generated contributions to GPL-licensed projects. If the provenance is unclear, the entire license chain becomes questionable. A project could inadvertently incorporate code that isn't properly licensed. The legal exposure is real, even if it hasn't been tested in court yet.
Disclosure doesn't solve the legal problem. But it's a necessary first step toward solving it. You can't assess copyright risk if you don't know AI was involved.
What actual disclosure looks like in practice
So what should we actually do? I've been experimenting with different approaches across projects I contribute to, and I've landed on something that feels practical without being burdensome.
The simplest method: a line in the commit message or PR description. Something like "Portions of this code were generated with Claude/Copilot/ChatGPT and reviewed by the contributor." That's it. Not a legal document. Not a detailed breakdown of which lines came from where. Just a flag that tells reviewers: hey, adjust your scrutiny level accordingly.
Some teams I work with have added a checkbox to their PR template. It sits right next to "I have tested these changes" and "I have updated documentation." It says: "I have disclosed any use of AI tools in creating this contribution." Simple. Binary. Hard to ignore.
I've also seen projects adopt a more granular approach. Contributors note not just that AI was used, but how. Was it used for ideation? For boilerplate generation? For debugging? For writing tests? Each of these carries different implications for review. AI-generated tests, for instance, need particularly careful scrutiny — models are great at writing tests that pass, but terrible at writing tests that actually catch meaningful failures.
The key is that disclosure shouldn't be punitive. It's not about shaming people for using AI. It's about giving reviewers the context they need to do their job well. When I see a disclosure, I don't think less of the contributor. I think: okay, this person is being honest, let me review accordingly.
The tools that make this easier
Disclosure sounds simple until you're actually doing it across dozens of contributions. You forget. You're in a rush. The PR template checkbox becomes muscle memory and you click it without thinking. I've done all of these.
What's helped me is building disclosure into my workflow rather than treating it as an afterthought. When I'm using Copilot in VS Code, I keep a running note of which files had significant AI input. When I'm using Claude for architecture discussions, I document the prompts that led to key decisions. It takes maybe two extra minutes per contribution. Worth it.
Some tools are starting to bake this in natively. Git's trailer system — those lines like "Signed-off-by" and "Co-authored-by" at the bottom of commit messages — could easily accommodate an "AI-assisted-by" trailer. A few projects are experimenting with this already. It's not standardized yet, but I'd bet money it will be within two years.
Of course, there's a faster way to handle the documentation side of this. Tools like AI-Mind let you generate contribution descriptions and disclosure statements without wrestling with prompt engineering. You describe what the AI helped with, and it produces a clear, honest disclosure suitable for a commit message or PR description. The first 30 are free, so there's no reason not to try it if you're contributing regularly and want to build the disclosure habit.
What happens when disclosure becomes the norm
I think we're heading toward a world where AI disclosure in contributions is as routine as signing off on the DCO. It'll feel weird not to mention it. Like submitting a patch without a commit message.
When that happens, a few things shift. First, reviewers get better at spotting AI-specific failure modes because they know when to look for them. Second, contributors become more thoughtful about how they use AI — if you know you'll have to disclose it, you're more likely to actually review what the model produced. Third, the legal questions start getting real answers because we'll have data on how AI is actually being used in contributions.
I'm not anti-AI. I use these tools daily. They make me faster, help me explore ideas I wouldn't have considered, and catch bugs I would have missed. But I also know that the code I produce with AI assistance is different from the code I write entirely by hand. Not necessarily worse. But different. And reviewers deserve to know which kind of code they're looking at.
The projects that handle this well won't be the ones that ban AI or pretend it doesn't exist. They'll be the ones that normalize disclosure, build it into their workflows, and treat it as a basic professional courtesy. Like citing sources. Like writing clear commit messages. Just part of the job.
Sources: GitHub Octoverse Report 2024, "AI in Open Source Development"; Gentoo Linux Council AI Contribution Policy, 2024; Debian-devel mailing list discussions on AI-generated contributions, 2024; U.S. Copyright Office guidance on AI-generated works, 2023