Kernel 7.2 and the Assisted-by Era: Six Weeks of Living With AI in the Bazaar

Return to Part 0: Table of ContentsPrevious Article: Episode 21, Regaining the Keys: France Orders 2.5 Million PCs Off Windows


The sentence a maintainer never wanted to write

In the middle of May 2026, in the routine announcement that opens a new kernel release candidate, Linus Torvalds described the Linux security mailing list as "almost entirely unmanageable." That list is one of the quiet load-bearing structures of the whole open-source world. It is the private channel where people report security holes in the kernel that runs most of the internet, most of the cloud, and, as this series has noted before, most of the satellites overhead. For Torvalds to say it had stopped working is not a small admission.

The cause was not a hostile state or a clever exploit. It was volume. Roughly two years ago the list took two or three vulnerability reports in a week. By early 2026 it was taking five to ten a day. The new reports were mostly generated by AI vulnerability scanners, and the problem was not only that there were more of them. It was that many researchers were running the same tools over the same code and filing the same findings independently, each with no idea the others existed. The channel built for careful, private disclosure had been flooded with duplicates. By the time Torvalds closed the merge window for kernel 7.2 on 28 June 2026, the source tree had passed 43 million lines and the project was still shipping on schedule. The machinery worked. The trust model underneath it was the part under strain.

What the bazaar assumed

When Eric Raymond wrote "The Cathedral and the Bazaar" in 1997, he gave the open-source movement its founding metaphor and its most quoted line: given enough eyeballs, all bugs are shallow. The claim rested on three assumptions that were so obviously true in 1997 that nobody thought to write them down. The crowd was human. It was varied, so different people saw different things. And it was self-limiting, because a person can only file so many reports before they run out of time, patience, or interest.

I came into that bazaar in 1994, and the entry cost was real. My first kernel compile took twenty-eight hours on the hardware I had, and at the end of it every line I had touched was a line I had come to understand, because there was no other way to get it to build. That cost was not a bug in the old model. It was the filter. It self-selected for contributors who cared enough to stay. An AI vulnerability scanner breaks all three assumptions at once. It is not human, it is not varied when many people run the same one, and it does not get tired. The bazaar was never designed for a contributor that does not know when to stop.

The patch nobody was told about

The written rule that followed did not arrive out of nowhere. The incident that forced it involved Sasha Levin, an NVIDIA engineer and a longstanding maintainer on that same kernel security list. During the 6.15 development cycle he submitted a patch that had been generated almost entirely by an AI tool, changelog and tests included, without telling the reviewers that AI had written it. The patch later caused performance regressions, and the community reaction was sharp. What stung was not that a patch had a bug; every maintainer ships bugs. It was that the people reviewing it had been given no way to know what they were actually reviewing.

Levin then did the responsible thing and pushed, at the 2025 Maintainers Summit, for the community to agree a documented position on AI contributions. No policy emerged from that meeting. Months of tension followed, including a public disagreement in January 2026 between senior engineers at Intel and Oracle over how hard the kernel should police AI-written code. The argument was real, and it was not resolved by consensus so much as by someone finally writing the rule down.

What "Assisted-by" actually says

That rule shipped with Linux 7.0 in April 2026, as a short document in the kernel's own tree called coding-assistants.rst. Its logic is worth stating plainly, because the design choices are the whole point.

Any use of an AI tool must be declared with an Assisted-by tag naming the tool and model. AI may never sign the Developer Certificate of Origin; only a human can certify where code came from and that it may lawfully be contributed. And the human who submits stays fully responsible for reviewing the output, for licence compliance, and for any bug or security hole that results. The kernel did not ban AI tools. Copilot, Claude Code, and the rest are all permitted. What the policy refuses to allow is for the human to disappear behind the tool. The choice of the word "assisted" rather than "co-developed" was deliberate: a co-developer would have standing to sign, and the entire structure exists to say that AI has no such standing. It is help, not authorship. The line of accountability has to end at a person.

The first six weeks

A written rule does not stop a flood, and the security list showed it. This is where Torvalds' "unmanageable" comes from, and where his second remark in that same announcement matters more than the first. He told the AI-assisted bug reporters that if they wanted to add value they should read the documentation, write an actual patch, and add something real on top of what the tool produced, rather than being, in his words, the "drive-by" reporter who sends a finding with no understanding behind it.

Read against Raymond, that is an inversion. The bazaar's founding promise was that more eyes make bugs shallow. Torvalds is pointing out that eyes which cannot tell signal from noise do not make bugs shallow; they bury the serious ones under the trivial. The community's structural answer, written into new security documentation by the longtime kernel developer Willy Tarreau and merged during the 7.1 cycle, was counter-intuitive but sound. Bugs found with AI tools should usually be reported in public, to the relevant maintainers, not through the private list. If ten people running the same scanner will all find the same issue, private disclosure buys no secrecy; it only creates duplication. The private channel goes back to what it was for: urgent, genuinely exploitable holes that affect many users. The rest moves into the daylight.

The verifiable floor

How much of the kernel is AI-assisted now? The honest answer is that nobody can fully know, and the most useful number available makes a point of saying so. A community-built tracker, assisted-by.dev, counts contributions that carry the tag. Three months into the policy it found that about 0.29 per cent of new mainline lines were tagged as AI-assisted. The site calls this "the verifiable floor," and the phrase is doing careful work. It is not a claim that only 0.29 per cent of the kernel is AI-assisted. It is a claim that at least that much is, because it is what people chose to declare. The true figure is certainly higher, because the tag depends entirely on a human volunteering it.

That gap, between what is disclosed and what is real, will be familiar to anyone who has watched enterprises try to govern staff use of AI. The disclosed number is never the whole number. A policy narrows the gap; it does not close it. What the kernel has done is make the gap measurable and put a floor under it, which is more than most organisations running the same risk can currently say.

The quiet half of the story

It would be easy to file all of this under crisis, and wrong. The same six weeks that produced the bug flood also produced a piece of housekeeping that tells the other half of the story. In 7.2 the kernel finished removing strncpy, a string-copying function with a well-known tendency to leave buffers in an unsafe state. Retiring it took more than 360 patches spread across more than six years, each one small, each one with a clear and checkable correctness test: does the replacement behave exactly as it should?

That is precisely the kind of work AI assistance suits. The goal is well specified, the correctness bar is tractable, and the effort is broken into pieces small enough for a human to review honestly. I am not saying an AI removed strncpy; the point is that this whole category of patient, long-tail cleanup is exactly what the Assisted-by era can accelerate when a person is genuinely standing behind each change. The flood and the cleanup are the same tool used two different ways. The difference is not the model. It is whether the human on the submitting end did the reading.

There are louder framings on offer, and they are worth a glance rather than a chapter. One line of commentary argues that the Linux Foundation, with its hundreds of millions in revenue and its professional maintainers, is less a free-for-all bazaar than a well-funded institution, and that the Assisted-by policy is that institution formalising its position rather than a crowd governing itself. Microsoft, at an open-source summit in May, framed the trajectory as running "from open source to agentic systems," toward AI agents that contribute on their own rather than merely assisting a human. Both are worth holding lightly. The policy in front of us governs the present arrangement, where a human submits and a tool assists. It says nothing yet about the moment, if it comes, when no human is in the loop at all.

The provenance question does not stay inside the community. Defence software supply chains have been asking a version of it for years. The United States Air Force runs a platform called Platform One, and inside it an accredited repository called Iron Bank, so that open-source components entering military systems arrive with a known, attributed, hardened lineage rather than as anonymous code. United States Space Force ground systems are built on the same open foundations this series has traced. When an armed service treats who wrote a line, and whether it can be trusted, as a control rather than a courtesy, it is answering the question the kernel just wrote down: attribution is what lets a reviewer decide how hard to look. The Assisted-by tag records that AI was used. It does not certify that anyone had time to check what it did.

Your own tag

I founded a Linux distribution and ran it from New Zealand, and I spent the years after inside enterprise architecture watching people decide how much to trust the code in front of them. The question the kernel has just formalised is the oldest one in the craft, wearing new clothes. When I compiled that first kernel over twenty-eight hours in 1994, the ownership was total because there was no shortcut: every line was mine because I had no way to make it work without understanding it. An AI assistant removes that particular hardship, and with it that particular guarantee.

So here is the question worth sitting with. If you shipped a patch today with the tag Assisted-by: Claude:claude-sonnet-4-6 on it, would you feel the same ownership you would have felt writing it by hand, and if not, what exactly would you need to do during review to earn that feeling back?


The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.


About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at linux@linux.co.nz.

A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era.


I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.


References

[1] The Register. "Linus Torvalds says AI-powered bug hunters have made Linux security mailing list 'almost entirely unmanageable'." May 2026. https://www.theregister.com/

[2] Kernel documentation. "Coding Assistants: the Assisted-by tag and human accountability." Linux 7.0, April 2026. https://docs.kernel.org/process/coding-assistants.html

[3] Tom's Hardware. "Linux kernel adds AI contribution policy after undisclosed AI-generated patch." 2026. https://www.tomshardware.com/

[4] Phoronix. "Linux kernel adds documentation for what qualifies as a security bug and responsible AI use." May 2026. https://www.phoronix.com/

[5] Phoronix. "Linux 7.2-rc1 released: 43 million lines, Cache Aware Scheduling, strncpy removal complete." 28 June 2026. https://www.phoronix.com/

[6] OSTechNix. "Linux Kernel 7.1 Final Released: NTFS driver, Intel FRED, major code cleanup." 14 June 2026. https://ostechnix.com/

[7] assisted-by.dev. "How much of the Linux kernel is written by AI? The verifiable floor." 2026. https://assisted-by.dev/

[8] It's FOSS. "The Linux Kernel's 'Assisted-by' Tag: how the Sasha Levin incident sparked contributor guidelines." 2026. https://news.itsfoss.com/

Previous
Previous

A Coruña and the Quiet Rust-ification: How Linux Is Rewriting Its Own Foundations

Next
Next

Regaining the Keys: France Orders 2.5 Million PCs Off Windows