Linus Torvalds released the Linux kernel release candidate "Linux 7.4-rc1" on November 1, 2026 (the morning of November 2 in Japan). In his announcement, he praised the tendency for AI-assisted bug finding and code fixes to land in the merge window, when new features and other changes are accepted, rather than in the release-candidate stabilization period, calling it a "much healthier model." He also took a cautious stance, saying we will see how the coming rcs go. When XenoSpectrum's editorial team counted commits carrying the "Assisted-by" tag in the official Linux repository, the 7.4 merge window had 3,008, about 2.4 times the number in 7.3. However, the tag was abolished partway through that same merge window, so whether the improvement in the development process that Torvalds hopes for is actually happening will need to be confirmed from the fixes that arrive in rc2 and later.
Linux 7.4-rc1 Released, With Torvalds Assessing the Shift in AI-Driven Fixes
According to kernel.org, Linux kernel development opens a roughly two-week "merge window" after each new version is released, during which new features and large changes are accepted. It then moves into a roughly seven-week period of bug fixing and stabilization, with a release candidate (rc) published every week. Normally rc7 is the last, and the next stable release arrives 9 to 10 weeks after the previous version. Linux 7.4-rc1 closes out the merge window that began with the release of Linux 7.3 on October 18, and the stabilization period starts from here.
The merge window and the stabilization period accept different kinds of changes. The former allows new features and large code rewrites, while from rc1 onward work is in principle centered on bug fixes, raising quality ahead of the official release. If AI-driven bug hunting turns up a large number of problems and the fixes concentrate in the rc period, changes keep piling up during the time that is supposed to be for stabilization. What caught Torvalds' attention was the change in which stage of the development cycle AI-related fixes are being taken in.
Torvalds looked back on this merge window as large enough to write "BIG" in capital letters, yet he regarded it as a welcome sign. He said he is "much happier" to have the large volume of AI-triggered work taken in during the merge window than brought in as extra fixes during the rc period. He also expressed hope that this is a sign that fixes for AI-discovered problems are being folded into the normal development process rather than concentrating in the stabilization period. "I think that's a much healthier model," he said, while adding that the state of the coming rcs needs to be watched.
The changes taken in this time include many fixes for problems found by AI, and AI-proposed patches are also increasing. However, AI-generated patches are not necessarily adopted as they are, and are often rewritten by humans. Torvalds himself also explained that AI is not the only reason the merge window was so large. The expectation that Linux 7.4 will be the next LTS (long-term support) release may also be a contributing factor in the concentration of changes. In kernel.org's list, the latest LTS is Linux 6.18, released on November 30, 2025, and there has been no official announcement designating 7.4 as an LTS.
Commits Declaring AI Use Rose About 2.4x in the 7.4 Merge Window
On November 2, the XenoSpectrum editorial team tallied non-merge commits between each pair of version tags in the official "torvalds/linux" repository. For the 7.4 merge window, for example, the target was the commits from v7.3 to v7.4-rc1. From those, we extracted commits containing "Assisted-by:" at the start of a line in the commit message, without distinguishing upper and lower case. Assisted-by was a tag used by contributors to declare that they had received help from AI tools.
In his 7.4-rc1 announcement, Torvalds described the changes taken in this merge window as "almost 20k" (about 20,000), but he did not say whether that includes merge commits. In our count, the total including merge commits was 19,780, which is close to that figure. Excluding merge commits, it comes to 18,591. The following are the results tallied for non-merge commits only, to keep the comparison conditions consistent (as of November 2, 2026).
| Period | Range (tags) | Non-merge commits | With Assisted-by | Share |
|---|---|---|---|---|
| 7.2 merge window | v7.1..v7.2-rc1 | 13,412 | 706 | 5.3% |
| 7.2 rc period | v7.2-rc1..v7.2 | 3,006 | 404 | 13.4% |
| 7.3 merge window | v7.2..v7.3-rc1 | 15,267 | 1,257 | 8.2% |
| 7.3 rc period | v7.3-rc1..v7.3 | 3,498 | 675 | 19.3% |
| 7.4 merge window | v7.3..v7.4-rc1 | 18,591 | 3,008 | 16.2% |
| 7.4 rc period | v7.4-rc1..v7.4 | Not yet observed (rc2–rc7) | Not yet observed | Not yet observed |
Non-merge commits with the Assisted-by tag in the 7.4 merge window numbered 3,008, up about 2.4 times from 1,257 in 7.3. The overall increase in non-merge commits was 3,324, of which 1,751, about 53%, came from the increase in Assisted-by commits. The remaining 47% or so is growth in untagged commits, which may include changes driven by factors other than AI, such as the expected next LTS.
What stands out is the large difference in the share of Assisted-by commits between the merge window and the rc period. In 7.3, the share was 8.2% in the merge window against 19.3% in the rc period, more than double. In 7.2 as well, it was 5.3% in the merge window against 13.4% in the rc period, so the same pattern appears in two development cycles. In the 7.4 merge window, by contrast, the share rose to 16.2%. At least among commits where AI use was declared, the concentration of fixes in the stabilization period that Torvalds is concerned about was already visible in the numbers for the past two cycles.
However, the Assisted-by tally does not represent the total number of commits in which AI was involved. The description of the commit that abolished the tag notes that of the 18,533 non-merge commits as of 7.3-rc7, only about 10% carried Assisted-by, while actual use of large language models (LLMs) is far broader. Furthermore, in a discussion at the Maintainers Summit reported by LWN, David Airlie said "probably 90%" of contributors are using LLMs. This is not the result of a rigorous survey of usage, though, but Airlie's own estimate.
In addition, the rule requiring the Assisted-by tag itself was removed from mainline on October 20, during the 7.4 merge window. For this reason, the 3,008 figure for 7.4 is also likely to be lower than actual AI use. Contributors' habits of declaring may also have changed between periods, so the growth rate of tagged commits cannot be read directly as the growth rate of AI use. What the tally does confirm is that, even within the declared scope alone, AI-related commits in the merge window have increased substantially. Whether similar fixes will decrease in the 7.4 rc period cannot yet be judged.
Even After the Assisted-by Tag Is Gone, Human Review and Responsibility Remain
The Assisted-by tag was defined in a document called "Documentation/process/coding-assistants.rst" written by Sasha Levin. It was introduced on January 6, 2026 through a commit by Jonathan Corbet, establishing a rule requiring contributors to declare when they used AI tools. Later, on August 3, a commit by Christian Brauner simplified the format from one that included the model name to simply "Assisted-by: LLM." The judgment was that naming a specific model amounts to free advertising for proprietary software companies while providing almost no practical information.
Abolishing the tag had been discussed for some time, and a proposal was rejected once in July. According to the removal commit's description, at that time there was a view that maintainers wanted to identify patches that had LLM assistance in order to help with review. However, according to LWN's report, the position shifted at the Maintainers Summit held in Prague on October 8. At the meeting, attended by about 30 people, Torvalds said that mandating the tag could discourage people from declaring LLM use, and showed willingness to drop the requirement. The discussion ended with a strong consensus to abolish it, and the direction was that how a patch was produced should in principle be explained in the cover letter rather than the changelog.
The next day, on the 9th, Levin posted the removal patch, and on the 13th Greg Kroah-Hartman also announced that he had changed the position he held in July. Kroah-Hartman pointed out that the tag mechanism "is not working at all and is really annoying maintainers." On the same day, Torvalds also criticized rules that ban the use of tools for particular purposes, saying it is no different from banning the use of a compiler or an editor. What matters, he said, is not the tool used but that the contributor understands the code they submit. The removal patch was committed to the documentation tree on the 14th and taken into mainline on the 20th.
What was abolished is the tag for declaring AI use; the responsibility of the human submitting the code has not gone away. When submitting patches to the Linux kernel, the contributor adds a "Signed-off-by" line, certifying under the DCO (Developer Certificate of Origin) that they have the necessary rights to the code they submit. coding-assistants.rst prohibits AI agents from adding this signature, and states that only humans can give the DCO certification. Even for AI-generated code, it is the signing human who reviews the content, checks the license, and takes responsibility for the submitted patch. This principle has not changed since the Assisted-by tag was abolished.
Provisions on transparency about AI-generated material also remain. "Documentation/process/generated-content.rst" asks that contributions containing a substantial amount of tool-generated content be explained in the cover letter and changelog. It also allows maintainers to reject such contributions outright or to lower their review priority. In addition, on August 4, a commit by Willy Tarreau added nine mandatory steps for AI-based bug hunting. They require, among other things, reproducing a discovered problem to confirm it actually exists and always producing a fix, against a background in which AI bug reports, especially security-related ones, still do not meet the required quality standard.
The Focus Now Is the Volume of rc-Period Fixes, and Linux 7.4 May Become the Next LTS
Even if AI-related fixes concentrate in the merge window, the burden on the stabilization period will not necessarily get lighter. According to LWN, Kroah-Hartman said at the Maintainers Summit that AI tools find a large number of vulnerabilities but half of them are false reports. He added his view that a "flood" of fixes will continue for the next 18 months. If AI bug discovery progresses, problems may be resolved earlier in development, but the burden of verifying false positives and reviewing large numbers of fix patches cannot be ignored.
What draws attention, then, is the volume of fixes in 7.4-rc2 through rc7, which will be released weekly from November into December. Non-merge commits in past rc periods were 3,006 for 7.2 and 3,498 for 7.3. These include fixes unrelated to AI, but they are one metric that can still be compared under the same conditions after the Assisted-by tag's abolition. If the stabilization period ends at rc7 as usual, then based on the development cycle shown by kernel.org, the official release of Linux 7.4 would come in late December.
These developments are not irrelevant to Japanese industry either. The Civil Infrastructure Platform (CIP) under the Linux Foundation is working on SLTS (Super Long Term Support), which maintains LTS kernels for even longer, and Renesas Electronics, Toshiba, Hitachi, and others take part as major members. As of now, there is no announcement that CIP will adopt Linux 7.4 as an SLTS. However, if 7.4 is designated the next LTS as expected, its stability would become an important factor in maintaining industrial systems that are used over long periods.
In this tally, among the changes Torvalds hoped for, the increase in AI-related commits in the merge window was confirmed in the numbers. If non-merge commits in the 7.4 rc period fall below 7.3's 3,498, that would at least be evidence that the volume of fixes in the stabilization period has decreased. However, that alone does not establish that AI-related fixes have decreased, and verification that includes the content of the changes is needed. Whether Torvalds' hope of folding AI-assisted fix work into the normal development process leads to actual stabilization will become clear in the coming rc period.