Linus Entered the AI Debate transcript

This AI fad has gone way too far. There is no world in which this stuff will be useful for real projects. Things like the Linux kernel need a really high bar for code, and AI is just never going to meet it. That's why people like Linus Torvalds are so against AI. As you can see in this email he just sent to the official Linux mailing list, where he says that wait, Linux is not one of those anti-AI projects, and if someone has issues with that, they can do the open-source thing and fork it, or just walk away.

Huh. Apparently, Linus has taken a hard stance here. He's no longer entertaining the people who are socially anti-AI, the ones who are doing it on principle, not on a technical basis. There's real technical merit to these tools, and they're not going away anytime soon. Hell, we're in a world now where there are open-source models, well, open weight models, that are incredibly good, more talented than any one dev can be across the field, and these are accessible for all of us to use for surprisingly cheap prices.

Obviously, this is valuable. It's been fun to watch the mighty fall. All of these super anti-AI people that have been against it from the start are coming around. And even those who have been on the line, people like The Primeagen, are finding more and more fun with these tools as they figure out the right ways to use them within their workflows and aligning with their goals. I want to talk about this, though. What does this mean for the rest of software development history?

What are the pushback points that these people are making? And what does the future look like if we're all just prompting to write code? I can't see into the future, but what I do know is coming up is a quick break for today's sponsor. Today's sponsor is two different things, and I need you to hear me out on this one. BackerScope's an AI code review bot, and I'm sure you've used plenty of those. It's a really good, really fast one, and it's worth using just for that, but that's not why I am so hooked on it.

BackerScope's dashboard is the thing that keeps me coming back. My team loves it cuz they get good reviews really fast. I love it cuz I can see what my team is doing. They have this awesome contributors view where I can get estimates of how many hours people have put in during a given sprint. Julius hasn't actually done 254 hours, but with agents, it looks like that. But much more importantly, I can see what's actually changing in our projects.

This is a summary of everything that's happened in this last sprint, and it's a really useful way for me to know what's going on. So if you're a manager or a team lead trying to keep track of what's going on, Macroscop is going to save your butt. And then we get to macros, which is one of the coolest features they offer. Macros are a simple way to give an agent access to all of the data on Macroscop to do useful things, like summarize all of the work going on on a given project and then ping you on Slack.

And it's not just Slack it supports, by the way. They let you have it get delivered to a webhook. So you set up a schedule, you write some markdown, and now you have real work being done using all of the data that Macroscop provides. If you want to keep bugs from shipping and know what features are shipping, look no further than swedev.link/macroscop. I want to start with where this most recent Linux drama began. It started with this open-source tool called Sashiko.

Sashiko's an agentic Linux kernel code review system. It uses a set Linux kernel specific prompt and a special protocol to review proposed Linux kernel changes. Sashiko can ingest patches from mailing lists or from local Git. It's fully self-contained. It doesn't use any external agentic CLI tools, and it can work with various LLM providers. If you're a kernel maintainer, please see our guide for kernel maintainers for information on interacting with Sashiko.

They call out the quality of reviews here as well, which is pretty impressive. Sashiko's not perfect, but in their measurements, the quality of review is high. In their tests, Sashiko is able to find 53.6% of bugs based on unfiltered last thousand upstream commits with fixed tags, specifically using Gemini 3.1 Pro. It does seem like for various reasons, Linus is still using the Gemini models. I'd be very curious to see how this would go if he was to switch over to something from OpenAI or Anthropic.

Because 3.1 Pro is not great. It's a pretty dated model. In some sense, it's already above the human level given that 100% of these bugs had made it through human-driven code reviews and were accepted into the main tree. The rate of false positives is harder to measure, but based on limited manual reviews, it's well within 20% range and the majority of it is a gray zone. Please note that as with any other LLM based tools, Shishiga's output is probabilistic.

It may or may not find bugs or find other bugs with the same inputs. This is a great realistic call out. They're not saying AI is going to replace all of our jobs, they're not saying it's the best developer they've ever seen. They are saying that it is similarly capable to a human and having more resources doing more review to keep the kernel stable is beneficial. Remember that video I did recently everybody was mad at me for where I talked all about how you need to be reading less code because you should be using AI to do more code review, to generate code, to do testing, to write elaborate end-to-end systems just to validate code.

Using LLMs to take already written code and verify it better is so powerful. And I'm not saying that you shouldn't read the code before you merge it. If your project wants that, awesome. For most projects, it's probably a good idea you should read the code. But having AI also read the code, also build tools to test the code, also do additional things to verify the code, and maybe write a bunch of slop tests that never merge just to continuously verify your assumptions, that's all great.

And it seems like the best maintainers in the world are realizing this, too, because the Linux kernel, whether or not you like Linus, it is a phenomenal example of the best of open source. And it's really nice to see Linus not falling behind beyond his model choices. This is a pretty big flip for them, too, because previously they were complaining about all of the slop reports they were getting, but they've even announced since that that isn't the case.

Greg Kroah-Hartman is one of the lead maintainers of the Linux kernel, and he said that there is a huge change in the quality of bug reports they're getting from AI generations. It went from junk to legit overnight. He can't explain the inflection point, but it's not slowing down or going away. This article was in March, by the way. The author of this article spoke with Greg about how over the last month AI-driven activity around Linux security and code review has really jumped in a way no one in the open source world saw coming.

Months ago, we were getting what we called AI slop, AI-generated security reports that were obviously wrong and low quality. It was kind of funny. It didn't really worry us. Of course, there were many Linux kernel maintainers, so for them AI slop isn't as burdensome as it is for, say, Daniel Stenberg, the founder and lead developer of curl, where AI slop reports caused the curl team to stop paying bug bounties entirely.

Things have changed, according to Greg. Something happened a month ago and the world switched. Now we have real reports. So, what happened here? My guess is that in December and November of last year, we started using Opus 4.5 more actively. After the holiday break, it started to ramp up in real-world use cases in the enterprise space. And as more people and real developers started to take advantage of this and saw how powerful it was, they started building tools around it and figuring out how to take more advantage of the model's capability, which led to it downstream a few months after starting to affect things like the reports going to the Linux kernel.

It's not like a new model drops and suddenly the quality goes up. It's that a new model drops, the best people start to see what it's capable of, and as that happens, they start to use it for more and more things, and slowly the quality of things goes up over time. Greg says that it's not just Linux and that all open source projects have real reports that are made with AI, but now they're good and they're real. All open source security teams are hitting this right now.

Greg said that he doesn't know why this happened. Either a lot more tools got a lot better or people started going, "Hey, let's start actually looking at this." Seems lots of different groups and different companies have had this realization. What's clear, though, is the scale. For the kernel, we can handle it. We're a much larger team, very distributed, and our increase is real, and it's not slowing down. These are tiny things, they're not major things, but we need help on this for all the open source projects.

Small projects have far less capacity to to a sudden flood of plausible AI-generated bug reports and security findings. At least now they're finding real ones and not garbage. One of the biggest immediate wins is turnaround time. When an AI reviewer flags obvious problems, submitters get feedback long before a human maintainer would realistically read the patch. If I see it respond to something, it gives feedback to the submitter faster than the maintainer had a chance to, which is nice.

We have a number of bots that run on patches as it is. If I see those fail, I just know I don't have to look yet as a maintainer. It gives the developer an oh, I can do another version tomorrow, which helps increase feedback a little better. Absolutely agree. AI code review is so powerful. It's so so nice. But on the other side here, going and auditing these big code bases with more manpower, manpower in quotes we've ever had before, is brutal.

Because now we're seeing things like 2 days ago, there was how many of these happened? 432 CVEs in the Linux kernel in a single day. It's insane. It's absolutely insane. And the reality is if these open source maintainers don't use AI to find and fix these things, then the malicious people are going to use that as an attack surface. If the maintainers don't check their code with AI to prevent these types of regressions and these types of security issues from being in the official product, then someone else will.

It's a matter of who's going to use AI. Are they going to use it to fix the thing or is it going to be used to hack the thing? In a war of attrition like this, you got to use the thing. So let's see Linus's crash out. I feel like he does a great job of being stern but realistic. Even when he's crashing out at somebody, he's giving really clear reasons why they are wrong and how they could think differently about a thing.

Like I cannot fathom anyone's ever had Linus crash out of them and didn't have something to learn from it. So let's see what he said. Again, this started because of the discussion around Sashito, the AI code review tool they were using. Someone was mad about Sashito and trying to push back on it, but it seemed like they didn't care about the tool. They were more upset about LLMs in general. So Roman tried to push the conversation to be about that to which Linus responded and said, "Yeah, this person's clearly expressing a very anti-LLM position in general.

And this is not the position of the Linux kernel. I realize that some people really dislike AI, but this is an area where I'm willing to absolutely put my foot down as the top-level maintainer, the good old BDFL. Thank you, Linus. Linux is not one of those anti-AI projects, and if someone has issues with that, they can do the open-source thing and fork it or just walk away. AI is a tool just like other tools we use, and it's clearly a useful one.

It may not have been that clearly even just a year ago, but it's no longer in question today. Yep. For those who don't know, BDFL stands for Benevolent Dictator for Life. That's what I was talking about as the top-level maintainer. It means that Linus will maintain Linux until he's not alive, probably. Back to what he had to say here, though. There are other questions around AI, like what's this going to look like economically in the end, but the is it useful thing is no longer one of those valid questions.

Anybody who doubts that clearly hasn't actually used the modern tools. I absolutely agree. And remember, Linus is using Gemini, supposedly, here. I don't know if he's tried Claude, Code, Codex, Cursor, whatever else, but he has confirmed before publicly that he is using anti-gravity and Gemini for real work. He knows these tools are useful. He does cave that it is sometimes painful, especially for maintainer workloads, and just from an it keeps finding embarrassing bug standpoint.

Like, yeah, it hurts. Having somebody with unlimited manpower and money just digging into your [ __ ] and finding all of these things can feel awful. But it's awesome that we can do it, too. And if your goal is to do the best thing for your users, you should be embracing these tools where they are useful to you and your team. But the solution is not to put your head in the sand and sing, "La la la, I can't hear you" at the top of your voice, like some people seem to do.

Absolutely agree. I've seen these people, and if you want to see some, too, all you have to do is scroll down and see them in my comment section. While you're scrolling, though, if you see a little red button that says subscribe, it's cuz you haven't and you should consider clicking it because I cover these things, it's a lot of work, and if you want to stay on top of this stuff as it changes, probably a good idea to start watching a bit more.

Only half of you guys are subscribed. Helps a lot if you hit the button. I really like where Linus goes here. He says the solution is to make sure these LLM tools are helping maintainers instead of just causing them pain. There's no question on that side, and I absolutely agree. It sucks that a lot of the creators of these agentic tools, of these models, of these things did not go more into the open source world and try to help directly.

There has been some effort here since things like open source programs for both Cloud Code and Codex, things like the secure Project Glass Wing type stuff where they reach out to essential open source projects and do a bunch of free auditing privately. All of that stuff is awesome. But, it's not enough, and it started too late, especially considering that these LLMs got where they were from an open source start using a lot of open source code.

But, that doesn't mean these things aren't helpful to maintainers. It just means that the companies that made them weren't considerate enough about maintainers initially, and they're slowly working on it. But, it is our job as the developers who are between these big companies and the open source projects to keep on doing what we can to funnel value to the open source maintainers, whether that is paying them directly, whether that is contributing to the projects in ways that are less burdensome, whether it's giving them free inference or donating money for tokens, or helping them set up tools that are more useful to themselves.

Whatever maintainers need, we should be going out of our way for because they are doing a thankless job, and we did make it harder. It is important to understand and appreciate the burden of open source maintainers in this time. It is harder and more annoying than ever in a lot of ways. But, when done right, it can be really powerful, too. Following along with what Linus said here, he's not trying to force anyone to use it, but he's very loudly going to ignore people who try to argue against other people using AI.

And no, AI isn't perfect, but Christ, anyone who points to the problems that AI had better be looking in the mirror and pointing at themselves at the same time. Because it's not like natural intelligence is always all that great, either. The kernel project has been and will continue to be around the technology. Sure, the social angle of working at open source is important and often a very motivating part of the project, but in the end, that's a side benefit, not the point of the project.

This is not some kind of social warrior project, never has been, and never will be. In the kernel community, we do open source because it results in better technology, not because of religious reasons. And so, we make the decision primarily based on technical merit, not fear of new tools. [ __ ] based. I would love to see a Linus take I don't agree with. Seriously, one of the greatest of all time. Also, Nvidia's OG hater.

Huge respect for that. While I feel physically incapable of disagreeing with Linus, others did. And he had plenty to say to them. Laurent said in the mail list that he considers today that there's no ethical justification for the use of generative AI in free and open source development. To which Linus said, "I guess this is where the discussion ends." As I mentioned, Linux has never been a social warrior project. If you don't have technical reasons, you don't have reasons.

You can choose not to use AI, but that's your personal choice. It has absolutely no impact on anybody else, and you should not expect it to have any. Put another way, if you're a vegetarian because you think meat is murder, that's perfectly fine. I know for a fact we have several vegan kernel developers, and I'm sure they have varied reasons for it. Maybe they just don't like the taste. Maybe they have some social or religious reasons for it.

Lots of perfectly valid reasons, possibly driven by ethics. But they don't expect the rest of the kernel community to become vegetarian because of their personal ethical standpoint, do they? This is absolutely no different. And yes, I feel very strongly about this, not because I feel strongly about AI per se, but because we have a long history interacting with the Free Software Foundation. They have their ethical reasons, too, and use them as a weapon, and as a way to drive away sane people.

It's why Linux is not GNU/Linux and why we call things open source instead of free software. So, keep your ethics where they belong in your personal life. Don't try to enforce your ethics on others. Based is [ __ ] hell. I have no notes. He's very accurate with this. And you're going to see more people doing the same. It's been fun watching more and more fall as the models and tools get better. I remember a year and a half ago when the things were just starting to get okay at code.

Like when GPT-5 finally came out and I could talk about it. It was like, "Oh, wow. These are way more capable than I thought they would get." I thought we were going to hit a ceiling and we didn't. And I went from, "Oh, this is useful to like make some small edits in a file." to this can actually complete real work to barely even editing code myself anymore because this can do almost all of the work itself. And every developer, even the ones who are still against AI, if they have any real technical merit, will eventually see this, too.

A bar will be hit where the tools are better than they thought was possible, not better than them necessarily, but better than they expected, and they will have to reflect on that or just shove their head in the sand and pretend none of it's happening. Some have already done that and some will continue to do that, but the best maintainers all have been coming around. I'm going to give a weird analogy here, but I saw this with TypeScript back in the day.

When TypeScript first happened, it was quite controversial. Not cuz it was bad or terrible or slow or something, just because the best people in the JavaScript community didn't see a need for it. They wrote JavaScript that was good and it worked and behaved how they expected it to. Why would we add all of this stuff on top where we now have to transpile our TypeScript into something else in order to even be able to run it.

And a lot of those really talented maintainers just kind of pooh-poohed TypeScript entirely and ignored it. But, the goal of TypeScript wasn't to replace JavaScript and become the industry default. It was to solve very specific problems that Microsoft had. They built it at Microsoft because JavaScript had become the global language and they wanted to write things that were Microsoft size and scale. When you have a lot of engineers at various skill levels and none of them knew the whole code base cuz it was physically impossible to.

Making sure changes in one place didn't break somewhere else was a real challenge. And TypeScript was built by Anders Hejlsberg, the creator of C#, in order to try and solve that orchestration problem when you have lots of engineers of various skill levels contributing to a thing. But that's also again where that problem comes in. If you're on a small team with incredibly talented devs building a small to medium-size JavaScript project, even a pretty big one, but everyone on the team knows where everything is, you're not going to have that many problems that TypeScript solves.

And it's going to seem like this big unnecessary thing that complicates your whole process. And a lot of people did feel that way. Here's a fun interaction I had back in 2022 with one of my good friends and somebody I owe for a lot of my success, Ryan Carniato, the creator of SolidJS and one of the best JavaScript devs alive. Joe is another friend of mine who was iffy on if TypeScript was worth it or not in 2022 and asked if he felt like TypeScript made people more productive.

He will respond. I said that I firmly believe anyone who doesn't feel a productivity win out of TypeScript isn't using it correctly. Honestly, same if you feel like you're writing TypeScript and not {quote} JavaScript with warnings in your editor. TypeScript gave me back a huge chunk of my brain that was previously second-guessing every line. I have since refined this take. One of the things TypeScript did is it moved the burden of describing how your systems work off of the application devs and the people building things that are user-facing and onto the libraries we consume.

Things like React and React Query, things like SolidJS, things like the GraphQL bindings a lot of us use, tRPC. All of these tools needed to have types defined in TypeScript and that is real work that is often complex that has to be done by open source maintainers for their things to be taken seriously with TypeScript. And that was a real burden that sucked. But by doing that, it made their tools way easier to adopt.

Remember what I said before though, the best developers didn't need that ease, they already were there. Ryan said the following, "I'm pretty much the person you're describing. I'm told it will click, but after 4 years of using TypeScript every day, I'm not convinced anymore." It's something that he puts up with for the greater good. He's used other type languages, but when it's applied to JavaScript it feels different.

He gave an example of an API that he built in 20 minutes cuz it was intuitive to him and apparently others as well. And 5 years later they're still discussing how to type it properly for months at a time. Yeah, writing the types for complex APIs is a real difficulty, but that's not why I'm showing you guys this post. I'm showing you guys this post because of a diagram I drew on why this is the case. TypeScript takes the potential quality of a code base and it shrinks it from both ends.

It greatly raises the floor and it slightly lowers the ceiling. So, a relic Ryan Carniato who is a 10 out of 10 JS dev almost feels like he has to lower his quality in order for TypeScript to be useful to him. But someone like me who is a dumb YouTuber benefits greatly from TypeScript yanking me off of the floor into a much better more maintainable place. This is kind of what AI does too. Are the absolute best developers in the world capable of writing code better than AI in the areas they specialize?

Almost certainly yes. I'd be incredibly surprised if some of the best maintainers of the Linux kernel couldn't write better code than Fable does for Linux. But how about the kernel code I would write? How about the kernel code that Ryan Carniato would write? He's incredibly talented. He does not know the Linux kernel at all. You don't know what his knowledge of low-level memory stuff is. But he's an incredibly talented dev where if he tried to contribute over there would benefit a lot from AI.

Or we can go back to the original example of Linus 5 coding which is that he wanted to visualize some work he was doing on a fun side project and didn't know how to do that the right way, so he asked Gemini to. And while the code wasn't perfect and the UI stuff wasn't great, the thing he wanted came out much faster and he didn't have to go as far out of his way to go figure out all of these things. He was very happy with the result because he got to work outside of his area of expertise and the floor was higher and the work was less.

That is an awesome thing. TypeScript was similar for me in this way where I was coming from other spaces. I had done most of my time in Elixir, Ruby, and Java. So I didn't like working in JavaScript, but TypeScript raised the quality of what I was doing and guided me through fixing things in such a way that I ended up liking it a lot and ended up going all in on this idea of full stack type safety eventually, the T3 stack.

That's kind of what AI has done to me as well. It has affected me and my career in a way very, very similar to TypeScript in this way. It has me bolder doing bigger, crazier things and trying to take more advantage of what the tool's capable of to make my life easier and to make my team more effective. And I'm very thankful Linus agrees here. Because as he said, anyone who doubts that these tools are useful clearly hasn't actually used them.

And if you're still in that bucket, I hope you take the opportunity to experiment a bit more. If you're looking for things to use AI for that aren't just generating code in your projects, but can help you take the code you already wrote and validate it better and be more likely to ship less buggy software, you can check out my video about reading code because I go in depth on that. And I want to be clear, my stance is not that you shouldn't read code.

My stance is that code is too useful and now too cheap to justify not generating a bunch of code to do random things that you want to have done. Whether that's going through open pull requests and giving you an audit at the start of the day on what you should focus on, or if it's verifying changes you make, or if it's writing a really elaborate test suite for one thing you really want to confirm. There is so much use to AI other than contributing slop to projects and I really hope more people take the opportunity to use these tools for the awesome things they can be used for.

It's been a wild journey for me and it's awesome to see so many other people realize the capability here as well. AI is continuing to get more and more useful and more and more powerful and as great as something like TypeScript is, it definitely hit a ceiling pretty early. AI does not seem to have any ceiling in sight. So, if you don't get in now, you'll have plenty of chances to later. Don't feel like you have to rush here everything's over.

Just consider using these tools a bit more and finding more creative ways to apply them to your work. I have a feeling you'll be surprised. I certainly know I was. Until next time. Peace nerds.