Linus Torvalds Says He No Longer Reads Code, Calls Himself a Development Lead Not a Programmer

Torvalds, 35 Years In, Redefines His Own Job

Linus Torvalds has been running the Linux kernel since 1991. At Open Source Summit India 2026 in Mumbai, he sat down with Dirk Hohndel — longtime friend and frequent interview partner — for a candid conversation about where the project stands and what his days actually look like now.

The answer on the latter was blunt: "Let's be entirely honest. I hardly read code at all anymore. I'm not a programmer, I'm a development lead."

It's a description of how a project that now spans millions of lines of code, thousands of contributors, and a global maintainer hierarchy actually functions at the top.

Two Weeks, 200 Merges

Torvalds described his workflow during kernel merge windows as roughly 200 merges over two weeks. The kernel ships on a steady nine-to-ten-week release cadence, a rhythm he credited largely to the discipline that came from building Git, the version control system his team created specifically to manage Linux's complexity.

"We don't do releases that have big new splashy features, and I actually actively try to avoid that kind of model," he said. "We want to have this kind of incremental improvement and steady progress all the time."

On the Linux 7.1 release specifically, Torvalds brushed past any notion of a landmark moment. The highlight, he said, was the same as always: "a very steady progression of continued improvements."

He Still Writes Code. Sort Of.

Torvalds does still send patches, but he's careful to frame them differently than he once would have. "I still write code in the sense that I send people patches... but then I make it very clear that, hey, this is a suggestion. This is untested... I expect the maintainers of the code to be the ones who then send me the fix back."

He uses patches as a communication tool — a way to show maintainers what direction he's thinking — not as finished work he expects to commit himself. He said he very seldom commits his own code anymore.

What he does focus on is intent. When reviewing a pull request, he said, what matters is understanding the bigger picture: "I want to understand what's going on." He dives into code mainly when something forces his attention, like build breaks or merge conflicts.

AI Is Complicating the Steady Rhythm

The one area where Torvalds acknowledged genuine friction in the current development cycle is AI-generated bug reports. "It's been getting a bit harder lately because of AI finding interesting bugs, and that has stressed out people in the community," he said.

He didn't elaborate extensively on this, but the implication is straightforward: automated tooling that surfaces valid but obscure bugs at scale puts pressure on a human review process that was designed around a slower pace of discovery. Whether the kernel community's maintainer structure can absorb that volume without eroding quality controls is an open question he left hanging.

The Hardest Problems Aren't Technical

Torvalds was direct about where he spends his real energy. "New code is a technical problem... we can fix those... What tends to stress me out is that occasionally we have personality issues, and trust me, code is easy to fix. Personality is not always as easy to fix."

He acknowledged he's contributed to those personality problems himself in the past and has worked on that. He also noted that he pushes back hard on last-minute changes before a release, even from contributors he trusts. "If it's not a really important fix, please queue it for the next release instead of sending me last-minute fixes" — because a marginal fix that introduces a new problem is worse than the original bug.

The Fairest Counterpoint

Some in the open-source community have raised a legitimate concern: as Torvalds' role becomes more curatorial and less technical, does that concentrate institutional knowledge — and therefore risk — in the maintainer layer rather than the top level? If Torvalds is trusting maintainers to vet the code he no longer closely reads, the quality of the kernel increasingly depends on how well that distributed trust network holds. That's not a criticism of Torvalds' judgment; it's a structural question about succession and single points of failure in a project the global internet runs on.

His Mumbai conversation touched on many aspects of how Linux is run today, but the long-term question of what the project looks like without him at the helm was not among the topics he settled.