Greg Kroah-Hartman runs the part of the Linux kernel where new developers are supposed to learn the craft by submitting real work. This week he banned AI-generated patches from that specific subsystem. The policy is narrow, the carve-outs are real, and the reasoning is about pedagogy, not technology. If you maintain any project that depends on new contributors learning by doing, the kernel’s move is a case study worth working through carefully.
Linus Torvalds has spent the last year shifting his tone on AI in the kernel. He has said openly that Linux is not an anti-AI project. Critics, he added, are welcome to fork the project or walk away. That broader openness is not in conflict with what GKH just did. The two positions cover two different jobs. One keeps the kernel maintainable for the next decade. The other keeps the on-ramp workable for the next decade of contributors.
This piece is for the maintainer of a smaller project who is staring at the same problem from a different angle. drivers/staging is the example. The topic is what it means to design a subsystem where learning is part of the work.
A subsystem where learning is the deliverable
drivers/staging is not where finished code lives. It is where code goes when it is not yet ready for the main tree. The drivers in there typically need cleanup, style fixes, and a more careful API. The whole point of the tree is that the code is rough around the edges, and the cleanup is the lesson.
The kernel already rejected automated style-cleanup patches in staging for years before the LLM era. If a bot wipes the rough edges clean, there is nothing left for a new contributor to learn from. GKH is extending that older rule to LLM-generated patches, on the same logic. The cleanup work is the deliverable, not a chore to be outsourced.
That framing matters because it changes how you read the policy. It is not “AI is bad.” It is “this tree exists for a specific job, and the tool is wrong for that job.” Tools can be right for one tree and wrong for another. The kernel is structured well enough to allow that distinction.
How to read the policy without taking sides
Before forming an opinion, three things are worth holding in mind at the same time.
First, the carve-out is real. A genuine security fix that an LLM helped find can still land in staging. The condition is that the contributor personally tested it on the actual hardware the driver targets. They also need to be able to explain the test in plain English. That is not a polite suggestion. The window is narrow on purpose.
Second, the enforcement is by maintainer read, not by technical check. GKH’s post calls out that the writing is obvious when an LLM wrote a patch, but that is a maintainer’s judgment, not a verifiable test. False positives will happen, and the policy accepts that cost.
Third, the kernel has room for both positions. Torvalds’ openness to AI in the kernel as a whole and GKH’s narrower rule for drivers/staging can both be true at the same time. If your read of the news is “the kernel is divided,” the division is by subsystem and is structural, not political.
What an honest carve-out looks like
The drivers/staging exception is the most useful part of the policy to study, because it shows what an honest carve-out looks like in practice. It is not “AI is allowed for X.” It is “AI is allowed for X, and here is the bar you have to meet.”
The bar, broken down:
- Physical hardware is non-negotiable. The driver targets a real device. Anything you find in an emulator does not count, because the timing bugs and IRQ races that show up on real silicon will not show up that way. If you do not have the device, the AI’s contribution does not clear the bar.
- A plain-English test write-up is the second requirement. Another contributor should be able to repeat what you did. “I ran it on my laptop” is not enough when the driver is for a network card. Spell out the steps, the inputs, and the expected results.
- The third requirement is on you, not the model. You have to be the person who understands the fix well enough to defend it in review. The AI is the assistant that helped surface the bug. You are the engineer who closes the loop.
Most contributors will never meet that bar, and that is the design. A carve-out that almost nobody uses is the right shape for an exception inside a learning-focused subsystem. If the carve-out were easy, it would be a loophole.
Why this is not a template you can paste into your own project
A common reaction to the news is to copy the policy into a smaller project’s contribution guide and call it done. Resist that urge. The drivers/staging rule only works because drivers/staging is a specific kind of subsystem with a specific purpose.
If your project does not have an explicit “this is where new contributors learn” subsystem, the kernel rule does not translate cleanly. What you can borrow is the underlying structure: identify the part of your codebase where the cleanup work is the lesson, write a rule that protects that work from automation, and write the exception narrowly enough that almost nobody will use it.
What you should NOT borrow is the AI framing. The kernel policy is about AI because that is the current automation. The structure of the rule (a defended subsystem, a narrow exception, a maintainer’s read for enforcement) is older than the LLM era and applies to any automation that threatens learning-by-doing.
A short checklist for maintainers thinking about this
If you maintain a project that depends on new contributors learning by submitting work, here is a five-question diagnostic before you write any policy.
- Do you have a clearly identified part of the codebase where the cleanup work is the lesson, or is learning spread across the whole project?
- If you have such a subsystem, do you already have a rule that protects it from automated style fixes?
- Do you know which kinds of automated help you would still accept in that subsystem, and what evidence you would require?
- Have you told your contributors why the subsystem exists, in language that a model could also read?
- Do you have a maintainer-time budget for spotting submissions that try to slip through?
If any of those answers is no, the policy is not the next thing to write. The next thing to write is the contributor-facing explanation of what the subsystem is for.
Trade-offs
A policy like this one has real costs and pretending otherwise would make this less useful than it should be. The honest limits are worth naming up front.
Reviewer time is the first cost. The maintainer will now spend cycles spotting AI-generated submissions that try to slip through the carve-out. That is time not spent on the genuine backlog. The project accepts that cost because the alternative is a quieter queue and a worse on-ramp, and the on-ramp is a structural investment.
Contributor friction is the second cost. Some new developers will decide the bar is too high and walk away. That is a real loss to the contributor base, especially for contributors who do not have access to the hardware their target driver needs. The narrow exception is not as accessible as a more permissive policy would be.
Enforcement consistency is the third cost. Policing whether a patch was AI-generated is hard in practice. The signal is usually stylistic and pattern-based, not definitive. Maintainers will sometimes guess wrong, and the policy accepts that.
Upside is the on-ramp itself. If the learning-focused subsystem stays a place where humans learn the craft by doing it, the project gets the next generation of maintainers. That is a long-term investment that does not show up in any short-term metric.
What I would tell past me about maintaining a learning subsystem
If I were going back to the start of any project where I knew new contributors would be doing the work, I would do three things before writing any AI policy.
Naming the subsystem where learning happens goes first, in writing, in the contribution guide. Not as a vague “we welcome new contributors” sentence. As a specific tree, a specific purpose, and a specific reason it is protected.
Writing the exception comes before the rule. If you cannot articulate the narrow case where automation is welcome, you cannot write the rule that protects the rest of the subsystem. The exception is the harder part of the policy to get right.
Reviewer time for enforcement needs a budget line. A policy without a maintainer-time budget is a policy that quietly stops being enforced after the first quarter. If the project is not willing to spend the cycles, the policy should not ship.
What I would not do is write the policy in response to a single bad submission. The kernel’s move is structural, not reactive. The smaller projects that copy it should be doing the same structural work, not the same reactive one.