--- title: Being Linux Torvalds | daily.dev description: Antirez draws a parallel between Linus Torvalds' evolution from hands-on coder to project director and the role expert programmers should assume when working... canonical: https://daily.dev/posts/being-linux-torvalds-w5dfs3ymz twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Being Linux Torvalds | daily.dev og:description: Antirez draws a parallel between Linus Torvalds' evolution from hands-on coder to project director and the role expert programmers should assume when working... og:url: https://daily.dev/posts/being-linux-torvalds-w5dfs3ymz og:image: https://api.daily.dev/og/posts/w5dfS3YMZ.png og:image:alt: Being Linux Torvalds og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Being Linux Torvalds **[Lobsters](https://daily.dev/sources/lobsters)** · 7 min read · 0 upvotes · 0 comments ## Summary Antirez draws a parallel between Linus Torvalds' evolution from hands-on coder to project director and the role expert programmers should assume when working with AI coding agents. The key insight is that Torvalds' real genius wasn't writing the initial kernel — many could do that — but his early decision to stop writing most code and instead focus on design direction, coherence, and communicating with subsystem maintainers. When using LLMs and agents, skilled developers should adopt this same orchestrator role: setting direction, evaluating design decisions, and guiding agents rather than just prompting blindly. This is contrasted with 'vibe coding', which Antirez sees as valid for non-technical users but a misunderstanding of what AI-assisted programming means for expert developers. True automatic programming requires deep technical judgment, architectural intuition, and learned skill — it is not easy for everyone just because LLMs exist. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 19 comments across hackernews, lobsters (as of 2026-07-27). **TL;DR:** The community is largely skeptical of Antirez's analogy, questioning whether LLMs can genuinely fill the role of trusted subsystem maintainers; some find partial truth in the orchestrator framing but feel it overstates both the developer's role and current AI capabilities. **Sentiment:** 20% positive · 40% mixed · 40% skeptical **The case for** - The orchestrator/director framing captures a real shift in how expert developers can leverage AI for larger-scale projects. - For well-specified, automatically verifiable problems (e.g., device drivers, file formats), AI agents can produce trustworthy results with enough validation scaffolding. - The analogy correctly highlights that deep upfront design and planning — not just prompting — is what makes AI-assisted development work. **The pushback** - LLMs lack the trust, accountability, and domain ownership that real subsystem maintainers earn over time, making the analogy misleading. - AI output tends to be overfit to obvious cases, ignores performance/binary-size tradeoffs, and struggles with problems where correctness is hard to verify automatically. - The framing risks inflating developers' sense of importance ('delusions of grandeur') and obscures that vibe-coded AI projects often lack real communities or users. - The analogy breaks down because Linus's maintainers were elite engineers who could be trusted with ownership, whereas LLMs regularly produce overcomplicated, sloppy, or incomplete solutions. - Human contributions being slower-paced gave Linus time to become deeply intimate with the project — a luxury not replicated when AI floods a codebase with output. **By community** - hackernews (mixed): Discussion is split between dismissing the analogy as disrespectful/overblown and defending Antirez's intent as a reasonable metaphor for the orchestrator role. - lobsters (skeptical): Commenters largely challenge whether LLMs can genuinely fill the subsystem-maintainer role, citing trust deficits, confabulation, and the community/leadership dimensions the analogy ignores. **Hottest debate:** Whether LLMs have earned enough trust and produce sufficient quality to genuinely play the role of 'subsystem maintainer,' or whether the analogy flatters both the developer and the AI. **Open questions** - At what point, if ever, will LLMs earn the kind of trust required to own a subsystem the way a senior human maintainer does? - How do you verify AI-generated design decisions in domains where automated testing is insufficient or impossible? - Does the orchestrator model scale beyond individual expert developers to teams, and does it require being 'rich enough' to afford continuous agent usage? **Highlights** > I think this post reeks of delusions of grandeur, or at least it could certainly provoke them in some people. Being rich enough to be able to afford an army of agents to work on your project 24/7 does not make your project Linux and certainly does not make you Linus Torvalds. I understand Linus is being used as an analogy here, but I also think there's a lot of analogies you could make and this one is telling and it feels like reassurance and justification. Yes, what you are doing is valid and important; see? You are just like Linus Torvalds, and by extension, your project is just like Linux and could be just as popular and important if you spend enough money on AI tools. It reminds me of [a section](https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html) from Codeberg's recent post on LLM usage: > Using LLMs to work with your code gives you a kick of adrenaline. You can develop at a rapid pace, build things as if you had a large team. Only that you have none. In fact, you are (often) alone, working with a statistical machine that turns energy into code. > It seems like many ‘vibe coders’ don't realize that they don't actually have a community around them. They build projects as if they had, and spend resources accordingly. We see projects having a lot of code activity, heavy CI/CD testing, frequent and large release binaries. Sometimes, it feels like the amount of supported platforms exceeds the amount of actual users. > — [steinuil on lobsters · 13 points](https://lobste.rs/s/uwhqhi/being_linux_torvalds#c_kyyqgl) > There's an interesting analogy being made here but to me it breaks down badly. My problem mainly comes from: > Automatic programming, instead, in the hands of people that are expert technicians, or expert programmers, expert designers, expert software architects, is to assume the role of Linus, with the agents and the LLMs assuming the role of the different maintainers of the different subsystems. I disagree with this; as they exist today, even in areas I have expertise in, I do not think LLMs *cannot* play the role of "subsystem maintainer" to my role of "Linus". The main problem for me is trust. Every time I've given an LLM this role by asking it to tackle a medium to large task in areas I know well, I've been bitterly disappointed by the quality of the output: overcomplicated design, sloppy and defensive coding and, several times, not solving the full problem at hand. If a human behaved like this in a team I led, I certainly would not trust them with the role of owning an area of my project. Trust has to be earned and LLMs have not earned the trust for me to be able to play this role for me. Edit: expanded on my thoughts [here](https://lalitm.com/post/ai-subsystem-maintainer/) > — [lalitm on lobsters · 11 points](https://lobste.rs/s/uwhqhi/being_linux_torvalds#c_lkh9tj) > Could Linus have built Linux into what it is today if all of the maintainers under him suffered from short-term memory loss, regularly made confabulations from thin air and needed Linus to write precise instructions for every problem to avoid? > — [typesanitizer on lobsters · 27 points, 1 comments](https://lobste.rs/s/uwhqhi/being_linux_torvalds#c_rxkvzc) > I don't think that question maps well anymore. Partially because I think we're mostly past the phase of "regularly made confabulations" and requiring precise instructions (as long as you want "a result" rather than a very specific result). And partially because all of this matters less once you have some system of validation. If you can automatically verify the module against some test behaviour/device the question is not "can it be done", but "how much money would you spend to get it done". I've done quite a bit of implementation "to precise spec" and it works quite well with things like devices and file formats. Throw enough "generate more edge cases and adversarial inputs", "build a fuzzer", "build a validator", "create proofs for parts of this system" at it and I'm going to trust it more than things written by people. (I regularly find issues with other implementations that way) There may be weird decisions along the way, but that doesn't mean they break everything. Or in other words, you're not asking the question like a person actually using this system and trying to push the limits. The interesting part remains as: Can you make/drive a good design and verify that the result will match it? > — [viraptor on lobsters · 5 points, 2 comments](https://lobste.rs/s/uwhqhi/being_linux_torvalds#c_tvb075) > It's an interesting point, but at the same time there are benefits to human contributions being slower paced. Not only that, Linus was not immediately overwhelmed by external contributions but had the time to become intimate with the project and its evolution. While I get what Antirez is saying, and I see why it can work and scale for him, there's a bit of nuance missing: everything he says it's true, as long as you, the coder, actually spend a lot of time studying and planning what you want to achieve as you iterate. Which, coincidentally, it's what Antirez himself did both for DwarfStar or Redis Arrays. He spent a gargantuan amount of time before he wrote a single line of code till he could largely explain the system, the design choices and their tensions. > — [epolanski on hackernews](https://news.ycombinator.com/item?id=49048330) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49046683) · 28 points · 10 comments - [lobsters](https://lobste.rs/s/uwhqhi/being_linux_torvalds) · 3 points · 9 comments ## Similar posts on daily.dev - [Linus Torvalds: Vibe coding is fine, but not for production](https://daily.dev/posts/linus-torvalds-vibe-coding-is-fine-but-not-for-production-rvk4ab0mh) · The Register · 414 upvotes · 26 comments - [Cleaning up after AI rockstar developers](https://daily.dev/posts/cleaning-up-after-ai-rockstar-developers-3ctjvrfgf) · Lobsters · 16 upvotes · 2 comments --- Tags: [#open-source](https://daily.dev/tags/open-source), [#linux](https://daily.dev/tags/linux), [#llm](https://daily.dev/tags/llm), [#architecture](https://daily.dev/tags/architecture), [#ai-coding](https://daily.dev/tags/ai-coding) [View this post on daily.dev](https://daily.dev/posts/being-linux-torvalds-w5dfs3ymz) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Being Linux Torvalds","url":"https://daily.dev/posts/being-linux-torvalds-w5dfs3ymz","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/being-linux-torvalds-w5dfs3ymz"},"datePublished":"2026-07-27T14:03:06.062Z","dateModified":"2026-07-27T14:04:46.987Z","description":"Antirez draws a parallel between Linus Torvalds' evolution from hands-on coder to project director and the role expert programmers should assume when working...","image":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","thumbnailUrl":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/being-linux-torvalds-w5dfs3ymz","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"open-source,linux,llm,architecture,ai-coding","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Being Linux Torvalds"}]} ```