PORTLAND, Ore., 10 AUG 2026 — The AI story in the Linux kernel this month is not about machines writing code. It is about machines reviewing it, and the humans who have to deal with the findings.

Linus Torvalds released the seventh and final release candidate for Linux 7.2 on 9 August with a line that is doing a lot of work: he is not thrilled about the size of it, "but it is what it is: the new normal with a lot of fixes, many of them due to review by various AI tools."

What "the new normal" means here

The phrase is not new to this release. A week earlier, on rc6, Torvalds noted that even by new-normal standards it was a big one, and that he thought it was the biggest rc6 in years by commit count.

The result is not one large change, but a scattershot of small ones across unrelated subsystems: s390 crypto, a returning btrfs fixup worker, netfilter ipset, GPU and sound drivers, networking, filesystems, architecture code. Torvalds's assessment is that nothing in it looks particularly scary in itself; there is simply a lot of it.

That distribution is the tell. A release candidate that fixes many small independent things in unrelated corners is what a review process produces, not what feature development produces. Features cluster. Findings do not.

Late in the cycle is the expensive place for this

A release candidate is meant to converge. Each week should be smaller than the last, because the point of the sequence is to run out of things worth changing before the release. So when rc6 is the biggest in years and rc7 arrives large too, something is pushing back against convergence — an input the process was not built for.

None of that makes the fixes wrong. A bug is a bug in week six, and a review tool that finds a real defect has done a useful thing. But finding a defect is one thing; finding it late in the cycle is another. Each one costs a maintainer's attention against a fixed release date, forcing decisions under time pressure.

The economics are simple: machine review scales, but maintainer attention does not. A tool that can be pointed at every subsystem simultaneously produces work for a set of people whose number has not changed, and whose availability is the actual constraint on kernel throughput. That constraint has never been the writing.

The same tools produce the noise

This is the second time this year Torvalds has had something pointed to say about AI in kernel workflow, and the first was less generous.

He has previously objected to AI-generated bug reports flooding the security mailing list with duplicates, and to AI-assisted code arriving with documentation that does not explain it. Both are complaints about work that returns no value; a duplicate bug report, for example, just costs triage time.

The picture, then, is not that AI is simply good or bad for the kernel. The same class of tool is producing both real findings and unfiltered noise, both arriving through the same door, and the kernel's processes were built for a world where submitting something cost the submitter time. That assumption is what has changed, and it is more consequential than any individual patch.

The project is writing rules rather than complaining

The most substantive thing in this cycle may be procedural: the kernel is landing documentation guidelines for AI-assisted development.

That is the correct response and a notably fast one. A project that had decided to argue about whether AI belongs in the workflow would still be arguing; this one appears to have concluded that it is already there and moved to the question of what a contributor must disclose and explain. So much of kernel review depends on a maintainer reconstructing why a change is correct. A rule on how to explain AI-assisted work is therefore more valuable than a rule forbidding it.

It is also the part most likely to be copied. Every large open-source project has the same problem arriving at the same speed, and very few have written anything down.

What is actually in 7.2-rc7

The security hardening is the substantive end: work on the x86 Speculative Return Stack Overflow mitigation, an overhaul of SELinux policy validation, and bounds-checking across Open vSwitch, ipset and vmwgfx. There are GPU quirks for AMD and Intel Xe parts, and fixes for threading races in the Rust binder driver used by Android.

Bounds-checking across three unrelated subsystems in one release candidate is, again, the signature of a review sweep rather than of somebody's roadmap.

Torvalds expects 7.2 to be released at the weekend unless something bad appears. It is not a long-term support release.

What this means if you do not work on the kernel

Two things transfer.

First, a finding is not a deliverable. Pointing a review tool at a codebase is easy; somebody still has to judge every result. Without that, you have not bought review — you have bought a queue. The kernel is the most maintainer-rich open-source project in existence and it is visibly feeling this.

Second, timing matters. A finding that arrives late in a cycle is worth less than the same one found early, because the cost of action rises as the release date approaches and the appetite for risk falls. If review tooling runs continuously, it should run continuously from the start of a cycle rather than tightening as the deadline nears.

What to watch

Whether 7.3's early release candidates are also large. One cycle establishes nothing; a pattern across two would mean the process has shifted, not just absorbed a one-time burst.

What the AI documentation guidelines actually require, and whether other projects adopt the text rather than writing their own.

And whether anyone measures the acceptance rate of AI-originated findings. Right now nobody outside the maintainers knows the acceptance rate — the number that determines whether this is a windfall or just a tax.