Toward the end of development for Linux kernel 7.2, AI-assisted code review has begun to change the flow of fixes. The seventh release candidate (rc7), published by Linus Torvalds on August 9, included 500 commits, while the previous week's rc6 reached 615 commits. Torvalds explained that much of this large volume of fixes stemmed from reviews by various AI tools, calling the trend toward larger release candidates the "new normal." The focus has shifted away from how many lines AI wrote, and toward how thoroughly humans verify the issues AI finds and safely incorporate them before the final release.
rc6 with 615 commits, rc7 with 500 commits
The anomaly became clear with rc6 on August 2. Torvalds opened his announcement by saying "this rc is huge," explaining that, at least in terms of commit count, it was the largest rc6 in several years. Comparing tags on Torvalds's official GitHub mirror, 615 commits were added between rc5 and rc6. This is a striking volume for a period after the merge window has closed and new feature integration has ended.
Moreover, the increase didn't subside the following week. rc7 on August 9 also brought in 500 commits since rc6. An rc is a candidate for verifying fixes before progressing to the final release, and the further the numbering advances, the closer the release decision comes. Even so, 7.2 carried a large batch of fixes for two consecutive weeks. While Torvalds said he couldn't exactly say he was "happy" about the volume, he has come to accept carrying a large number of fixes as the new normal.
What 615 and 500 represent here is the commit count—not the number of lines of code changed, nor the number of vulnerabilities found. A small boundary check addition and a major infrastructure rewrite are both counted as a single commit, so the scale figure alone cannot directly indicate the level of risk or quality.
Fixes following AI review, not AI-generated code
What Torvalds connected in the rc7 announcement was not AI code generation and the rise in commits. Rather, it was the relationship that "many of the fixes" arose from review by various AI tools. This doesn't mean AI wrote a large volume of patches that went straight into Linux. After a tool flags an issue, there still remains the work of drafting a fix, testing it, having the responsible maintainer confirm it, and merging it with a signature.
No exact figures for AI review-derived fixes, nor a breakdown by tool used, have been disclosed. Therefore, the 615 commits in rc6 and the 500 in rc7 cannot be read as "the number of AI fixes." What can be confirmed from Torvalds's explanation is only that multiple AI reviews generated a non-negligible number of fixes, and the result showed up in the overall scale of the release candidates.
The entry point of review and the author of the patch also need to be considered separately. Even if an AI tool points out a boundary condition or a resource-release leak, the decision on which fix to adopt is made based on the code's context and reproduction testing. A record that AI was used to discover an issue is not evidence that AI generated either the original code or the fix. What this increase in commits tells us is the expansion of discovery capability, and the amount of human work required afterward.
Still, the change is significant. Linux's official guidelines take the view that while tools can increase the volume of contributions, reviewer and maintainer time remains scarce. Even as the volume of discovered issues grows, the work of verifying the findings and turning them into appropriate fixes remains. AI review has entered Linux development not as something that eliminates verification, but as a mechanism that increases the number of candidates requiring verification.
Why large doesn't mean delayed
The 500 commits in rc7 are scattered across a wide range. According to Torvalds, most are small fixes that went into drivers for GPU, sound, and networking, along with filesystem, core networking, and architecture code. Since this isn't a batch of changes replacing a specific core feature all at once, the large commit count itself didn't become a reason for delaying the release.
There are some relatively large changes as well. Torvalds cited fixes to s390/zcrypt, which handles cryptographic processing for IBM Z, a change reviving the fixup worker infrastructure in btrfs, and a netfilter ipset fix. However, even including these, he judged that "nothing particularly scary" stood out. Caution about the sheer volume and an assessment that no individual change presents an anomaly requiring delay can coexist.
The previous week's rc6 had a similar composition: just under 60% drivers, 20% networking, and the remaining 20% architecture, tools, filesystems, and so on. Part of the networking portion reflected work that had accumulated during conference season. At that point too, Torvalds expressed unease about the scale of changes, but stated there were no signs that would delay the release.
In other words, the standard being applied in 7.2 isn't a simple cap on commit count. What's being examined is whether changes are localized, testable, and whether there are signs of serious regression. A single regression that breaks an entire subsystem would weigh far more heavily on the schedule than an rc7 carrying 500 minor fixes.
The volume tools add, and the responsibility humans take on
Linux's official guidelines explicitly state that while tools, including AI, can increase the volume of contributions, reviewer and maintainer time remains scarce. When a tool detects an issue, that fact should be recorded in the changelog. Disclosing what was used, what part it affected, and how it was tested is also recommended. The more AI review results are incorporated, the more necessary it becomes to keep records that allow tracing their origin.
What the guidelines cover isn't limited to functions generated by a chatbot. Changes proposed by conventional fix tools, changelogs written by tools, and testing after issue detection or fixing are all included as subjects of disclosure. Rather than setting up a separate entry point exclusively for AI, transparency is required based on whether a tool was substantively involved in a development decision.
Where responsibility lies also remains unchanged. The submitter must understand what they're submitting and be able to explain it during review. Maintainers can reject a change if they cannot request additional testing, lower its priority, or confirm its content—treating it as they would any ordinary change. Even as AI increases the volume of discovered issues, it hasn't become a rule that automates the decision of what gets merged into Linux.
As of August 10, the mainline listed on kernel.org is 7.2-rc7. Torvalds expects the final release around the following weekend—roughly August 16—barring any serious issues. Whether the massive volume of minor fixes born from AI review can be sustained as the "new normal" will depend on whether the volume of changes settles down in this final week, and whether no serious regressions are found following the 500 commits.