Torvalds Tells AI-Assisted Kernel Contributors to Back Off
Linus Torvalds is losing patience. The Linux kernel maintainer has warned he'll start rejecting pull requests he considers pointless, particularly the wave of minor fixes showing up late in the development cycle, some of which have been triggered by AI code review tools.
The warning came in his weekly kernel status post, which also announced the fifth release candidate for Linux 7.1. RC5 is, by his own assessment, too big.
"Quite a bit bigger than rc5's have traditionally been," Torvalds wrote, adding that he's not happy about it. Most of the submissions are described as trivial changes to random drivers, which might sound harmless enough, but his point is that harmless doesn't mean necessary. At rc5, the kernel should be converging, not accumulating noise.
The Linux development cycle works like this: there's a two-week merge window, then a series of release candidates, typically seven, each one supposed to edge the codebase closer to a stable release. Flooding rc5 with minor cleanups defeats the purpose. These things belong in the linux-next tree, waiting for the next merge window, not landing this late.
He's not being subtle about the AI angle either. "Several of these series were triggered by AI code review," he noted, before announcing he'll be "more hardnosed" about unnecessary churn going forward.
The core argument is straightforward: trivial fixes have a low probability of introducing regressions, but low probability is not zero. Pile enough of them together late in the cycle and you're trading stability for the appearance of productivity. Not a great deal.
His message to contributors is blunt. Before submitting, ask yourself whether the fix addresses a genuine regression or something serious enough to justify landing now, rather than sitting in the development queue. If the honest answer is no, hold it.
This is the second consecutive week Torvalds has called out AI as a complication. Last week he described the volume of AI-generated security reports as having made the kernel security mailing list "almost entirely unmanageable," with multiple people independently flagging identical issues using the same tools.
The pattern is becoming familiar. AI lowers the cost of running a code review or vulnerability scan to nearly zero, which sounds useful until everyone does it simultaneously and the maintainers end up buried in duplicated, low-priority noise. At that point the tooling is solving a problem that didn't exist while creating one that does.