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

[Sasha Levin <sashal@kernel.org>]

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.

-- 
Thanks,
Sasha