If AI writes the code, who checks it?

From sceptic to user

In two years Linus Torvalds has changed his mind. In September 2024, at the Open Source Summit in Vienna, he called the artificial intelligence industry "90% marketing and 10% reality" and said he would tune it out until things changed.¹ On 9 October 2026, on stage at Open Source Summit Europe in Prague, interviewed by Dirk Hohndel, he said the opposite: "Now I'm at the point where I actually really like using AI."²

The Italian site HDblog covered it too,³ and the most interesting detail is how he uses it. For a personal project, a guitar pedal, he had written a working but bare interface in C. To give it a modern look, with technologies he knows little about, he got help from AI: "I use AI to do the things that I'm bad at." In the same weeks he published eight kernel changes written with Claude Code under his direction. In a test on his laptop, eight threads reading the same file at once go from about 10 to more than 30 million reads per second. He took the measurements himself.⁴

Then he added the sentence that matters most: "I think that you need to be very careful using AI when you're doing something real and important." It moves the conversation from how much code AI can write to who has to check it.

Writing is cheaper, checking is not

The Linux kernel is the ideal case study. Thousands of people propose changes, and a much smaller group of maintainers reads them, discusses them and decides what goes in. For thirty years the bottleneck was writing good code. With AI, writing keeps getting cheaper, and the bottleneck has moved to the people who check.

You can see it clearly on the private list where security reports arrive. In March Willy Tarreau, one of the developers who handle it, said that two years ago it received 2-3 reports a week and now 5-10 a day. In May Torvalds called it "almost entirely unmanageable": different people run the same tools on the same code and report the same bugs, each on their own. His answer was practical. Bugs found with AI are by definition not secret, so they go straight to the maintainers, in public, in plain text and with a verified proof that the problem can be reproduced.⁵

It is not only Linux. On 31 January 2026 curl, the library billions of devices use to fetch data from the internet, closed the programme that paid people for finding vulnerabilities. Its author, Daniel Stenberg, wanted to remove the incentive to send poor, unchecked reports, "AI generated or not".⁶

In Prague Torvalds put it bluntly: AI is improving the code, but "it is also stressing maintainers out to the point that it's a problem." At the Maintainers Summit the day before, about three talks in four were about making it less of a burden for reviewers. "People are jokingly saying that there are bots talking to bots, and it does actually happen."²

Every innovation has a hidden price.

Third law of innovation, from Un perché alla volta (translated)

In this case the hidden price is the time of the people who have to read each change, understand it and, when needed, turn it down.

AI checking AI

The kernel's answer has been to use AI on the other side too. In March some Google engineers presented Sashiko, a system that reads every proposed change, looks for errors and posts its review on the mailing list as a colleague would. In a test on 1,000 recent bugs, all of which had already slipped past human review, it found 53%. In less than a year it has examined more than 191,000 changes across 99 mailing lists, and 463 kernel vulnerabilities registered this year cite it. Google pays for the computing, and the project has moved to the Linux Foundation.⁷

It works, and some maintainers now expect a change to have gone through Sashiko before it reaches them. But every automatic review is more text to read on lists that are already full, and at launch its authors admitted they had not yet properly measured how many of its reports were wrong. AI checking AI only helps if someone decides what is worth reading.

Declaring the tool or understanding the code

With Linux 7.0, in the spring, the kernel documentation introduced precise rules for people who use coding assistants. Only a person can add the sign-off that certifies a change, and that person answers for it even if a machine wrote the code. On top of that, contributors were asked to declare the help with a tag, "Assisted-by", followed by the name of the tool.⁸

The tag did not last long. Many did not add it, and on 9 October Sasha Levin proposed removing it from the documentation, because that was what the Maintainers Summit had decided. Laurent Pinchart objected: without a disclosure requirement, he predicted, submitters would push back when asked whether they had used AI. Torvalds answered him on 13 October in his own way, calling such rules "UTTERLY STUPID": "The kind of expectations I have is that people do their best and I expect people to understand what they are doing. But that understanding has very little to do with what tools they use."²

Other projects have chosen the opposite path. NetBSD has not accepted AI-generated code since 2024, and System76 has banned it from COSMIC, its desktop environment.²

Linux and artificial intelligence, in two years

1. 2024Torvalds calls the AI industry "90% marketing and 10% reality".¹
2. 2025The Maintainers Summit establishes that a person must answer for every change, even one written with AI.⁸
3. Mar 2026Google engineers present Sashiko, the automatic reviewer.⁷
4. Apr 2026Linux 7.0 brings the rule: a human sign-off is mandatory and the "Assisted-by" tag declares the help.⁸
5. May 2026Torvalds: the security list is "almost entirely unmanageable".⁵
6. Oct 2026In Prague Torvalds says he likes using AI. The kernel drops the tag; responsibility stays with whoever signs.²

On the principle Torvalds is right: whoever signs answers, not the tool. But the declaration also served another purpose: telling reviewers how carefully to read. In companies I often see the opposite problem: a lot of debate about which tools to allow and very little about who answers for the result.

Faster, or just more convinced?

Then there is a more uncomfortable question: does AI really save time for people who write code? In 2025 METR, an independent research organisation, followed 16 experienced open-source developers through 246 real tasks, randomly assigning the ones where they could use AI. Before the experiment they expected to be 24% faster, and at the end they were convinced they had been 20% faster. The stopwatch said otherwise: they had taken 19% longer.⁹

Faster, or just more convinced? Experienced developers working with AI

Forecast before the experiment24% faster

Impression at the end20% faster

Measured time19% slower

It is a single study, run with early-2025 tools, and today's models are better. But the gap between feeling and measurement remains the most useful lesson. The same goes for quality. In a Veracode test of more than 100 models, the generated code contained security flaws in 45% of cases, and newer models did no better than older ones.¹⁰ Developers know it: in Stack Overflow's 2026 survey, with more than 30,000 responses, almost half trust AI when they can easily check its output, but only 6.6% would trust it with important decisions.¹¹

What Linux teaches anyone bringing AI into a company

The kernel is an open project with its own rules and pace. But the problem it is facing is the same one every organisation meets when it brings AI into its work: output grows, the capacity to check it does not. From what is happening to Linux I draw four practical rules.

1. MeasureReview time, not linesIf code grows faster than the capacity to read it, productivity is only apparent.
2. SignWhoever proposes answersThe tool can change. Responsibility stays with whoever signs the change, who must be able to explain it.
3. FilterReports come with proofA problem found with AI arrives with a verified reproduction, or it does not arrive.
4. ReviewAI in checking tooUse it to review, deciding first who reads its comments and how much time they give them.

After 35 years Torvalds's method is still the same: small changes, read and accepted one at a time. Artificial intelligence can become part of this process, and it already is. It works as long as the time saved by the people who write does not turn into extra work for the people who check.