When the master uses AI: Linus Torvalds and the heart of Linux.
A real case that shows what artificial intelligence can do and why we still need people who can check the result.
When a beginner uses artificial intelligence to write a program, its usefulness is easy to understand. But what happens when the one turning to it is the creator of one of the world's most important systems?
That is what happened with Linus Torvalds, creator of Linux. Linux is an operating system (the program that makes a computer work), found in servers, Android phones and supercomputers. Torvalds used Claude Code, an AI programming tool from Anthropic, to tackle a performance problem that had challenged developers for more than two years. He himself had spent about 18 months testing a solution of his own that didn't work properly.
According to reports, the AI wrote the code, the tests and the first documentation, and also reviewed the work under his direction. Torvalds ran the measurements himself and made clear what the tool had done.
A library inside the computer
To understand the problem, we need to know a small part of how Linux works.
The kernel is the core of the operating system, the "manager" that distributes memory, processors and devices among programs.
When a program asks for data from a file, the kernel may already have it stored in RAM (the computer's fast, temporary memory). That quick-access copy is called a cache. It avoids going back to the SSD or disk, which are slower.
Imagine a library where a highly requested book sits on a table. Picking it up is quick, but every reader must write on a single sheet when they start and when they finish reading, so nobody takes the book while it is in use. With few readers, that's fine. With a crowd, the sheet becomes a bottleneck: everyone can see the book, but they all queue up to sign.
In modern computers, the equivalent of that crowd is the processor cores, the "work units" that carry out tasks at the same time. The more cores there are, the more they compete over that sign-in, and speed drops even though the data is already available.
One caveat: the analogy simplifies things. In practice, what slows things down is a shared counter that every core must update safely. Torvalds' proposal creates a "fast path" that, under certain conditions, skips that record and shortens the queue.
Where do the "23 times" come from?
In the published test, the kernel went from about 13.3 million to 304 million small reads per second, roughly 23 times more.
But Torvalds himself warned that the test was artificial. It was a microbenchmark: a measurement that isolates a single operation and repeats it to the extreme. In it, all cores repeatedly read the same small piece of the same file. That is useful for revealing a bottleneck, but almost no real program behaves that way.
Think of a factory that greatly speeds up one stage of production. The total gain depends on how much that stage was holding back everything else.
To give a more realistic picture, a developer at Meta (the company that owns Facebook) adapted the work and measured gains of about 4.5 times when reading files in a very common storage format, ext4. In a test with just one task reading, practically nothing changed, because there was no queue to improve. The gain shows up where there is a lot of competition, not everywhere.
Review is part of the discovery
Soon after publication, other developers found a flaw called a race condition: an error that only appears when two events happen at the same time, in a rare order. It's like two drivers reaching the same intersection at the same instant: it almost always works out, but when it fails, the damage is big.
Another example: in a joint bank account with $100, two people try to withdraw $100 at the same moment. Each app sees the full balance and approves the withdrawal, and $200 leaves an account that only had $100. Nobody made a mistake on their own; the problem was the coincidence in timing. In Linux, the "fast path" skips part of the coordination between processor cores, which leaves room for a core, at some rare moment, to release a piece of information while another is still using it.
This type of error is hard to spot. Code can work millions of times and fail on the one occasion when bad luck lines up. That is why the proposal is still under discussion and has not yet been merged into Linux.
The episode can be read in two ways, and both are true:
- Positive side: the kernel's review process worked. Specialists examined the code and found the problem before it reached users.
- Side to watch: the AI delivered code with a subtle flaw, and experienced people were needed to notice it. In addition, reviewing AI-assisted contributions takes effort from Linux maintainers, and the community is still debating how to handle that.
What this case teaches (and what it doesn't)
Torvalds is probably the most qualified person in the world to evaluate this kind of code, and the kernel has one of the most rigorous review processes in existence. So we can't conclude that anyone will get the same result with AI.
What the case shows is a combination:
- Experience to frame the problem well and recognize a good suggestion.
- A tool that speeds up parts of the work.
- Transparency about what the AI did and about the limits of the result.
- Review by other people, who look for what the author missed.
Perhaps the lesson is this: AI can expand what we are able to do, but the judgment to check what it delivers remains ours. And that judgment only grows with study and experience.
Sharing what I learn, as I learn.
