Re: [MAINTAINERS SUMMIT] The role of AI and LLMs in the kernel process

["H. Peter Anvin" <hpa@zytor.com>]

On December 7, 2025 5:12:51 PM PST, Sasha Levin <sashal@kernel.org> wrote:
>This (and parallel) threads have generated substantial discussion across
>several related topics.  In preperation for the Maintainer's summit, here's a
>summary of where we appear to have consensus, where we don't, and some
>questions to consider before the summit.
>
>Where We Have Consensus:
>
>1. Human accountability is non-negotiable:
>
>The From: line must always be a human who takes full responsibility for the
>patch. No "but the AI wrote that part" excuses. This maps cleanly to our
>existing DCO requirements and approach to tooling.
>
>2. Some form of disclosure is needed:
>
>Whether it's a trailer tag, a note below the cut line, or something else,
>there's broad agreement that AI involvement should be disclosed. The exact
>mechanism is debatable, but the principle is not.
>
>3. Maintainer autonomy matters:
>
>Individual subsystem maintainers should be empowered to set their own policies.
>An opt-in approach per-subsystem seems preferred over a kernel-wide mandate
>that doesn't account for different subsystem needs.
>
>4. This isn't going away:
>
>Industry is already using AI extensively. We're already receiving AI-generated
>bug reports. Ignoring this won't make it disappear; better to have a thoughtful
>policy than no policy.
>
>5. Language assistance for non-native speakers is legitimate
>
>Using AI to improve documentation and commit messages should not be stigmatized
>or treated the same as AI-generated code.
>
>
>Where We Don't Have Consensus:
>
>1. The nature of AI errors:
>
>Some argue AI makes fundamentally different errors than humans - subtle
>mistakes that slip past review because we're trained to spot human-pattern
>errors. Others argue AI errors are obvious when the model is under-trained, and
>that better training can address most issues. This affects how much scrutiny
>AI-assisted patches need.
>
>2. Same bar or higher bar?
>
>The kernel already has a significant bug rate - roughly 20% of commits in a
>release cycle are fixes. Should we hold AI to the same standard we hold humans,
>or does the kernel's criticality demand a higher bar for AI? There's genuine
>disagreement here.
>
>3. Legal risk tolerance:
>
>DCO clause (a) requires certifying "I have the right to submit it under the
>open source license." With AI training data provenance unclear and litigation
>ongoing, how cautious should we be? Some advocate waiting for legal clarity;
>others argue the legal concerns are overblown and we should focus on practical
>guardrails.
>
>4. The asymmetric effort problem:
>
>AI can generate patches in seconds; review takes hours. Unlike human
>contributors who learn from feedback and improve, AI models will repeat the
>same mistakes. How do we prevent maintainer overload? There's no clear answer
>yet.
>
>
>Questions for the Summit:
>
>1. Policy scope: Should we establish a kernel-wide minimum policy, or
>   simply document that subsystem maintainers set their own rules?
>
>2. Disclosure format: What should disclosure look like? Options discussed
>   include:
>
>   - Trailer tag (e.g., `Assisted-by:`, `Generated-by:`)
>   - Below-the-cut note
>   - Verbose commit log explanation
>   - Technology-agnostic "tooling" terminology vs. AI-specific
>
>3. Generation vs. review: AI for code review and debugging seems less
>   controversial than AI for code generation. Should we treat these
>   differently in policy?
>
>4. What requires disclosure?: Where's the line? Clearly, wholesale
>   AI-generated patches need disclosure. What about:
>
>   - AI-suggested fixes that a human then implements?
>   - Using AI to understand an API before writing code?
>   - AI assistance with commit message wording?
>
>5. Legal stance: Should we take a position on AI-generated code and DCO
>   compliance, or leave that to individual contributors to assess?
>
>6. Enforcement reality: We can't even get everyone to run checkpatch.
>   Whatever policy we adopt, how do we think about enforcement?
>
>Looking forward to the discussion.
>

I contend there is a huge difference between *code* and descriptions/documentation/...

Although git is an enormous help, it is still far harder to unwind code than the auxiliary stuff. 

AI bug reports? We have gotten robot bug reports for decades. Translation tool? Not a problem. Using AI to get ideas? Not really different than reading out of a textbook 

However, *code* taken out of an AI seems to me that it would have to be presumed plagiarized. Furthermore, it is very often wrong in both subtle and blatant ways.