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.