Being Linux Torvalds

antirez's July 2026 post at https://antirez.com/news/171, adapted from the transcript of his YouTube video. The title says "Linux Torvalds" rather than Linus; that is his own wording, carried over from the spoken original.

Writing the kernel was not the rare part

The opening claim is deliberately deflationary. When Torvalds wrote the first Linux kernel he had read the Minix sources, knew computer architecture, and was plainly a brilliant programmer, but writing a minimal working Unix kernel for the 386 — one architecture, at the start — was within reach of a lot of people. antirez puts it at something like one in a thousand to one in ten thousand: not most programmers, but many. His evidence is the last few years of Hacker News, full of kernels in C, microkernels from scratch, kernels in Rust, small Unixes built vertically for the Raspberry Pi, operating systems for the ESP32. Most of those people would do it worse than Torvalds did. That still leaves the feat itself short of an explanation for why there is only one of him.

He stopped writing code

What is rare is what happened next. Very early in Linux's history, Torvalds almost completely stopped writing code in order to lead the project: to be the coordinator, and the single mind holding clarity about what the goals are. antirez notes that most maintainers of famous open-source projects do not do this, and includes himself among them for a long stretch.

He is careful to say this was not a mistake in the other direction either. It follows from what kind of software each project is. A kernel that wants to cover many devices, platforms, and subsystems, and to keep adapting to new hardware and new software needs, has to grow past what one person can implement. Redis could stay self-contained, which is why antirez could keep his hands on the code — a point that reads differently after the feature accretion described in redis-cost-of-ambition. His other example is D. Richard Hipp, who recently sent him a pull request on linenoise: Hipp also aimed at stability, minimalism, and performance, kept the SQLite codebase very small, and went on writing code for a very long time. Small stayable projects permit that. Linux did not.

So what does Torvalds do instead? Not line-by-line review of every patch. He goes deep into a specific implementation when he needs to understand what is going on, and he has occasionally written or rewritten a subsystem himself — antirez recalls the USB layer years ago, and the virtual filesystem, where the structure of inodes and the inode cache was reworked. He wrote Git. But mostly he talks to the maintainers of the subsections and decides whether a given feature or direction is a road worth taking. In Brooks' terms from The Mythical Man-Month, he holds the design concepts and keeps them coherent through dialogue with everyone below him in the hierarchy, on both axes at once: how something is implemented and what quality the code has, and separately what the project wants and does not want from the scheduler, the module system, hardware support, the integration of Rust. That combination — brilliant programmer, maintainer, designer, and someone who can hold the structure of a huge project coherent while talking to a lot of people — is what antirez calls the real genius.

The role transfers

The turn in the second half is that programming with LLMs puts you in exactly that seat. You are not reviewing every line; you are holding the ideas and steering. antirez thinks the job is easier in this form than Torvalds' version of it, at least until you run many agents in parallel: fewer parties to coordinate, and instead of a large team moving at human speed you have the equivalent of one to three collaborators, one per branch you have in flight, returning feedback immediately. Less context switching, and none of the friction that comes from personalities. (The parallel-agent case is where it stops being simple, which is the argument log-distributed-llms makes at the level of impossibility results.)

From that he draws a line against vibe coding as a description of what automatic programming is. He is not dismissive of it: for people without technical skills who want to build their own tools, it is genuinely democratizing and he says welcome. But it is not the thing. In the hands of an expert programmer, designer, or architect, automatic programming means taking Torvalds' role while the agents take the role of subsystem maintainers — which requires knowing which implementations to do and which not to, and how to phrase the design hints a good programmer works out in advance. It is a skill that has to be learned, the same transition Torvalds made from implementing everything to conducting. His closing use for the argument is polemical: this is the answer to people claiming LLMs make programming easy for everybody.

This is the same thesis as control-the-ideas-not-the-code with a biography attached instead of an instruction. It also cuts against cult-of-vibe-coding from the other side — Bram Cohen's complaint is that refusing to read generated code is dogma, while antirez's claim is that not reading every line is what leadership of a large project has always looked like. The disagreement is narrower than it appears: both want someone holding the design, and they differ on how much of the artifact that person has to read to keep holding it. The Brooks lineage under all of it is traced in no-silver-bullet-llms.