Linus Torvalds linked the spike in Linux 7.0 patches to AI and the risk of a release delay

On March 30, 2026, Linus Torvalds publicly complained about an unusually large flow of patches for Linux 7.0 RC6. In his opinion, part of this surge could have come along with the mass use of AI tools, and the load on maintainers grew so much that at that time the risk of shifting the stable release was even being discussed.

Why There Are More Patches

The sixth release candidate usually means that the kernel is already entering a calm phase: major changes are behind, only point fixes, testing and polishing remain. In the case of Linux 7.0, the picture turned out to be different. Torvalds noted that at the end of March he received noticeably more fixes than usual at this stage, and it was not about a few controversial series, but about a wide stream of small improvements from different parts of the tree. For the maintenance team, this automatically means more manual review and more risks to the release schedule.

The growth in the number of fixes by itself does not mean that the release is broken. On the contrary, Torvalds separately emphasized that most patches looked real and useful. What troubled him was something else: the volume. When such changes become too many, the cost of review, discussion, re-testing and decision-making on schedules grows sharply. Even good patches in such a situation begin to slow down the release, because maintainers run out of bandwidth in the final stage before the stable build.

Why AI Surfaced Here

Torvalds suggested that the surge might be related to the fact that AI tools have become better at finding edge cases and quickly proposing small fixes. This is an important nuance: he did not say that the kernel was flooded with obvious garbage generated without review. Rather, it's about a new development mechanic in which the cost of creating a patch drops sharply, which means that more small, but formally valid changes enter the review queue. This very asymmetry between generation and review is what is starting to hurt the process right now.

"A lot of rather trivial, but real fixes," that's how

Torvalds described the nature of this wave.

For Linux this is a sensitive topic, because the bottleneck has always been not the code itself, but the human attention of maintainers. If AI helps find additional bugs, the quality of the kernel in the long run could increase, especially in rare and poorly covered scenarios. But if it simultaneously creates a stream of micro-fixes that are difficult to filter quickly, review becomes a bottleneck. And this is what seems to irritate the creator of Linux the most: not the presence of AI as such, but the new operational burden on people making decisions.

What Changes in Linux 7.0

Against the backdrop of the discussion about the role of AI, the 7.0 release itself did not look like a revolution. Torvalds had said before that a new version number does not mean a sharp architectural turn. The main body of changes in this branch was quite mundane: filesystem fixes, drivers and infrastructure code, without one dominant feature that would explain all the noise around the release. This is also important: the calmer the release is in itself, the more noticeable the anomalous surge of small fixes looks at the late stage of the cycle.

Among the directions that particularly stood out in the stream of patches and fixes, several areas usual for the kernel were mentioned. That is why the story looks not like an accident in one subsystem, but like a distributed load on the entire maintenance process, where each individual fix can be small, but their total volume breaks the usual rhythm of the team's work. This is especially noticeable at the RC stage, when maintainers usually try to let in only truly necessary changes.

• improvements for EXT4 and XFS filesystems
• typical GPU driver fixes
• changes in the network subsystem and RDMA
• updates in the audio stack and utility tools
• many point fixes for various edge cases

A separate context is also important here. Previously, Torvalds had already harshly criticized some patch series for Linux 7.0, for example changes around the MMC subsystem, which he called poorly prepared. Against this background, his current reaction was even unusually calm: instead of ripping into quality, he spoke precisely about the scale of the incoming flow. This makes the story illustrative — the problem with AI in open source is increasingly not about fake code, but about the overload of the maintenance process and a drop in signal-to-noise ratio.

What This Means

The Linux 7.0 story shows how AI is changing the development of infrastructure software: it has become easier to generate and find fixes, but review bandwidth has not grown as fast. For open source this could mean a new norm, where the main shortage becomes not code, but the time of experienced maintainers. If this imbalance intensifies, the most valuable skill will turn out to be not writing another patch, but quick filtering, verification and prioritization of what really deserves to be included in the release.