The agent helps a lot to fix bugs. Just point the agents at the bug reports. They do the reproduction, debugging and fixes. We "just" have to review. (Sometimes ask more details and tell we'd prefer another approach.) This makes bug fixing much faster and automated.
And at the same time, it seems we get less bug reports to our library.
I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.
So overall, the open bug count is decreasing. Which somehow feels good.
On the other hand, we get a lot of PR made by other's people agents, which can be a bit overwhelming when it's just a huge code drop. We can't easily review that.
> > and agents don't report bugs, they just work it around somehow.
Yeah I've definitely noticed this. On a project I'm working on Opus 5.5 found a bug in Smithay and another in Winit. It did tell me about them but its preferred solution was just to work around them locally. To be fair we don't really want agents going off and reporting bugs automatically...
I don't run any big open source projects but I think my preferred solution to AI PRs would be to get my AI to implement the same thing, and give then afterwards tell it to look at the PR for anything it missed. Then I at least know that I'm using a competent model and it reduces the danger of just blindly accepting someone else's code. (And obviously review the code if you have time and care, but that isn't always the case.)
Yes the default behavior of working around the bug is good, that’s what everyone was doing anyway pre-LLMs. The good practice is to report the bug. Simply add instructions to your agents to report you the bugs it found in the summary, so you can check the bug and report it correctly upstream.
>I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.
Claude comes up with some truly delicious insane workarounds these days. Like launching something in a subprocess and capturing stdout/stderr and doing string parsing on info logs because of a desire for some hook not exposed by API (or at least that it didn't find on its quick scan).
There's probably no such thing as semver reliability for dependencies anymore in stuff that agents glue together, since they will poke at ANY sort of way of getting additional insight or control if they want it.
also the agent might introduce bugs, just like a human (see rsync which now has very busy development). Likely we (and the LLM) just won't notice them as easily. Fun times I guess.
The headline is "Development statistics for the 7.2 kernel", and the last paragraph is highly LLM critical in contrast with the editorialized headline "Linux bugs fixed per release over time: >2× rise since 2026-04", which seems to imply some sort of Mythos bug finding.
From the last paragraph:
"The Linux kernel is aimed at production use, not research or experimentation. But there is currently a massive experiment being run on the kernel's development processes and community."
"This community has absorbed new processes and tools many times over its 35-year history, and will almost certainly find a way to do that this time as well. But that absorption has not always been without turbulence along the way."
Not quite. My C++ Linux rewrite is already production ready, meaning in theory I no longer need to rely on the Linux kernel devs. This will, in a matter of months I presume, become the norm.
I also want to see the known abstraction skills of LLM used to properly recognize where the objective nature of C++ makes most sense in Kernel code. All the new interfaces, polymorphism.
The major issue with these kinds of blurbs is that there's no control.
Historical numbers are not valid because incentivizes of a well funded entity have changed. It would require an equally well funded push to up the patch numbers without LLMs to really measure the impact in a quantifiable way.
So it seems worth vibecoding a survival analysis for bugs introduced. But not quite a survival analysis because we don't even know the bugs exist until the event of their discovery.... Is there a publicly available dataset for this, with a URL?
Heads up for those upgrading to 7.3, I just downgraded my slackware box from 7.3-rc7 to 7.2.10 because /dev/input/events was missing. Keyboard and mouse only worked in the console as a result.
Submitted title was "Linux bugs fixed per release over time: >2× rise since 2026-04". We've reverted it now.
Submitters: If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
To the surprise of no one. Although, I must recognise that I did not envision a future where Linus embraced AI as frictionless has its been, then again after the inclusion of Rust in the kernel, I probably would've risked some money on it.
I’m strongly with you on that. Current models aren’t perfect, but neither am I. In a lot of my daily use, they’re as good as or better than I am at certain tasks.
I hear people around me talking about a bad experience they had with ChatGPT last summer as though it proves all AI coding is “slop”. Honestly, it makes me sad for them. There are reasons to dislike AI, but so many detractors skip right past those to anecdata that just aren’t relevant anymore, if they ever were.
I've had a lot of bad experiences with current chatgpt (mainly, it tends to just get sidetracked and hyper-fixated on literally anything, so if I give it a rodmap of tasks to do it will fixate on the first one and keep adding caveats as to why something isn't complete) and a lot more success with Claude (not) doing that. But I don't use Codex, but chat chatgpt (I don't have the max plans so Codex gobbles up usage limits in like 20 minutes even on the simplest of tasks) so Idk, maybe that's why?
To counter the bad though: right now Claude and I have been doing some very interesting work on acoustics and advancing steam audio. I've been researching this for several years trying on and off again to make my hopes a reality but could never take all the math and make something coherent out of it by hand, and Claude has helped with that (well, and Steam Audio). The trouble mainly comes from being blind and trying to build geometry from code and not being able to mentally visualize the geometry in question (which is also why I struggle with physics engines). It's been really fun just experimenting with this and seeing how good it gets. Who knows, I might make it a library that I publish someday.
Current models are still worse than I am, or any competent developer I've ever worked with. You act as though people tried ChatGPT in 2023 and gave up forever, but that isn't what is happening here. The cold hard truth is that, contrary to what AI boosters claim, LLMs still suck at programming and output slop.
> I hear people around me talking about a bad experience they had with ChatGPT last summer as though it proves all AI coding is “slop”.
They always quit right before it got good.
> Honestly, it makes me sad for them.
The the consternation? They’re going to be obsoleted in no time anyway, so we’re told. Are they missing out on some months’ worth of coasting as meat proxies before exponential takeoff? Is that the sad part?
Or, he has a full understanding that, like everything single thing he's ever been involved with in his career, it's a new tech under development and will, as every measure up to now has demonstrated, improve over time. And, as all tech that has ever existed since the beginning of man starts, has somewhat initially limited, but still very practical and real, use in its current state.
Again, he's pragmatic, and has seen countless types and iterations of tech come into existence. The people expecting perfection from the start have no actual experience with the creative process, engineering or design, and and only want progress to stop (because there is, literally, without exception ever existing, no alternative to iteration).
Yes, Linus is quite forward thinking, and we can credit that with why Linux has stayed relevant for so many decades. Not many software projects manage to pull that off.
Linus has always been pragmatic as opposed to dogmatic.
20 years ago he was fine using BitKeeper, proprietary software, for kernel source control, because it was better than Subversion and CVS. He only created git when BitKeeper introduced some road blocks.
While great in theory, the flip side is all the slop patches and PRs that both the kernel and open source in general now has to deal with, often with only agents as responders.
It honestly doesn't want to make me open anything for outside contributions anymore.
He used Claude Code to write one of his patches in [0] and introduced a data race bug in the kernel unbeknownst to himself but this bug was caught by other reviewer [1] before it made it into a new kernel release.
So I'm afraid Linus himself did not understand the changes Claude made to the code he submitted in the mailing list, despite his "principles" in telling others previously that AI was creating slop patches and then now shouting at others who were concerned about using LLMs on code where they do not understand the generated code themselves when it all applied to....himself.
"introduced a data race bug in the kernel unbeknownst to himself but this bug was caught by other reviewer […therefore] Linus himself did not understand the changes Claude made to the code he submitted in the mailing list"
What other reading of this is there? A bug is being cited as evidence of slop generation, which implies pre-AI the bug would not have happened.
You extrapolated from a single instance where something did happen to an entirely different thing never happening as a position the original poster might have held, whereas it is 100% obvious that that would not be the case.
That effectively makes it a strawman argument.
We are talking about this bug, in this context. Not about pre-AI bugs that did happen and that also were caught (and then there is of course all the ones that were not caught).
Again, "Linus himself did not understand the changes Claude made to the code he submitted" implies that Linus writing the code himself would've prevented the bug.
The data race is exactly the kind of subtle bug that even very experienced programmers would make in this circumstance.
The patches that Linus posted are relatively small and self contained and from reading the thread it seems came from a series of in depth conversations with Claude and were carefully reviewed by Linus.
So what we're seeing here is a tricky concurrency bug that even an expert would make. You can't use it as an example of slop
> Here's a new rule just for you: don't use compilers for any of your kernel submissions.
> Because if you can't show that you really understand what the machine is actually doing by writing your code in assembler, then I don't want to see your code contribution. You clearly aren't competent if you can't write it that way.
Typical AI sophistry. But it’s from Linus Torvalds so it becomes a slam-dunk.
> The kind of expectations I have is that people do their best and I expect people to understand what they are doing.
> But that understanding has very little to do with what tools they use.
> And quite honestly, in my experience, the people I respect and call intelligent are not the ones that shy away from using new and interesting tools.
He’s saying that understanding or competence are more about the person than their AI use. I think that’s a reasonable argument, even though I disagree on the basis that it’s at least a little correlated in the shortcuts in understanding the many devs I’ve seen (not all, but a nontrivial amount) seem to be taking.
To be clear: I believe that it's entirely possible to use LLMs to amplify understanding and competence, but that in practice LLM usage is anticorrelated with understanding and competence. This is about empirical reality, not logical entailment.
As an example, I’m in the process of putting up a patch series to optimize some specific filesystem operations. The amount of boilerplate that has to know to get done is completely unapproachable to an outsider both from the amount of time needed to learn that boilerplate and form it in such a way that maintainers will be happy. Even though I know exactly how the code is working, it bridges that understanding gap but I don’t see how it correlates with incompetence. I may be an outlier but I suspect there’s a huge amount of people who are extremely capable and competent and it’s just that the Linux kernel has so many processes that it’s difficult to onboard into the community without LLM assistance.
The Linux kernel project is not hurting for contributors nor was it prior to LLMs. The processes you describe as roadblocks don’t seem to have been preventing the Linux kernel from getting code contributions. Maybe they don’t need or want more easy onboarding or broader audience?
Go look at the statistics in the article. LLMs are having a huge impact both in terms of new people developing and fixing bugs. “Not hurting” is a value judgement. The actual question is whether people wanted to contribute and the process was what kept them away or talent to enact the change. I suspect process has more impact than you’re willing to give credit too.
> The actual question is whether people wanted to contribute and the process was what kept them away or talent to enact the change.
My point was basically that this question misunderstands the purpose of large open source projects. They are not primarily things people have a right to contribute to, but rather things we want to improve for everyone. Anyone has the right to make changes to the Linux kernel for their own purposes, but contributing is not a right. It is primarily for serving the public good.
I’m not surprised the processes discourage some portion of would be contributors from contributing. I just don’t think that is a problem.
Presumably the person who's full-time job is staying on top of proposed changes to the linux source tree knows something about this; what are your credentials on the topic?
Linus himself is actually comically incompetent. He only became famous after the Linux kernel took off... decades ago? Since Git, he has made ZERO code contributions whatsoever (not even to the Linux kernel). He doesn't even review code and has his team of capos do it for him. All in all he's no different than the CEO of some tech company, his thoughts on LLMs are no longer relevant (for more lack of credibility, see his stance on Rust, C++, Go)
> Here's a new rule just for you: don't use compilers for any of your
kernel submissions.
> Because if you can't show that you really understand what the machine
is actually doing by writing your code in assembler, then I don't want
to see your code contribution. You clearly aren't competent if you
can't write it that way.
The point is, new technology arrived that allowed developers to do much more. Existing programmers hemmed and hawed about it because it threatened their egos, making easy what they once found very difficult. But the sensible engineers adopted the technology.
AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility.
> AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility.
How do you define correctness for any given task? If you know the correct logical process for any given process, writing it in code is just a matter of typing. The issue is that the human author, even when assisted by AI tools, does not know what is the correct algorithm for the task. In most cases, the output is probable code, not correct code.
I believe we are at a crossroads here. The key question is: Do we want (desire or require) humans to understand the implementation?
If the answer is no, then AI agents producing code faster and "more correct" (in some arguably questionable sense but let's fly with the assumption for a moment) should be embraced fully. Take the humans out of the loop, why review code, if there is a problem later then just ask the next AI agent to fix it. Similar to not looking at generated code by a compiler. Iterate fast, don't look back. Some code bases and some entire companies have adopted this view.
If the answer is yes then we need to keep the human in the loop, ensure they have enough understanding to maintain the thing, review all the code etc. AI is just another tool to produce the code which ultimately the human still owns. Many code bases follow this philosophy.
It seems to me that the discussion always ultimately falls on one of these two sides. They are incompatible but you need to pick one. Depending on which you pick, it is easy to predict how you argue in such discussions.
> The key question is: Do we want (desire or require) humans to understand the implementation?
Understanding the implementation is not the root cause here. The actual issue is that all software are built for a particular needs which is human related. In most software, the cost mostly decays to a constant value unless that need has changed or an external event has occurred.
Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users.
The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints.
> Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users.
You can pin down existing expected behavior pretty well with automated test cases and even bringing formal verification into the mix. Using LLMs to create those, it's not even a major cost factor. Then you are safe from such regressions. Just like when humans make changes. So, I don't see how this is introducing a difference.
> The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints.
Indeed. Though I don't see the connection to my point.
> You can pin down existing expected behavior pretty well with automated test
Test cases are sample based, they do not take care of the whole range of input and output. Type checking in the other hand are set based and sometimes the types are too coarse. In both instances, you need to carefully choose your axiomatic foundation, and if you can do that, that means you’re already aware of both programs and solution. As defining the problem is a major step in problem solving.
> Indeed. Though I don't see the connection to my point.
A lot of AI proponents are touting the tools as better hammers while purposely not saying anything about the house. You need to show how it can help with building a new house and not gush that it’s a new shape, different from all the other hammers in history.
So the focus on line of codes, number of PRs, all the harness talks,… is worth nothing if better software can’t be built.
> Test cases are sample based, they do not take care of the whole range of input and output.
Indeed, but they are not random or arbitrary. They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space. If you want to make things water tight, you use formal verification like I mentioned earlier (of which type checking is just a lightweight variant, in a sense) but for general screwups that's not even necessary. If tests are chosen well then the code must be formed very weirdly to produce bugs that the tests would not find.
> They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space.
The thing is you can have code that passes the tests, but are wrong for the general cases. With manual coding, you will have the knowledge that the code is about right, then add test cases to precisely check that intuition.
Like being aware that you used a linear function so as soon as 2 points in the test are ok, the code is right. But if you don’t read the code and have not noticed the quadratic function, your test cases will pass while the code is incorrect.
That's right. But isn't it conceivable that the entity (human or LLM) which adds a quadratic function also takes that into account? Oh, earlier it was a linear function so 2 test cases were enough, now it is quadratic and I need to add a test case, and all of that flags that something extraordinary might be going on requiring extra attention. At least we are already far removed from accidental screwups.
If anything then I would expect a human to be more susceptible to such an error than a coding agent. At least frommy experience from how they deal with (admittedly test-heavy) code bases.
(But again, if unsure, add a formal correctness proof for a few more extra tokens if that makes you sleep better at night.)
Nice rhetorical sleight of hand, trying to paint your opponents as ego-driven and senseless. But LLMs are not compilers. They cannot be relied upon to work correctly, and indeed can be relied upon to introduce bugs that a human would never introduce. The situation is different, therefore the reactions are different.
> AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does.
the question is about whether you understand in the slightest the output of the tool. does the determinism of the compiler somehow imbue you with a better understanding of the assembly it generates?
> You must have a very weak understanding on this topic
i work on the codegen for a C compiler i'm pretty sure my understanding is better than yours <shrug>
EDIT: and also you've clearly never read that article
> One of the key attributes of a low-level language is that programmers can easily understand how the language’s abstract machine maps to the underlying physical machine
so you did exactly imply "C is a low level language"
The idea that C is a smol language that can be completely understood by one person is one of those myths that need to be put to bed. C is riddled with complexities and footguns, especially but not exclusively around undefined behavior.
> The idea that C is a smol language that can be completely understood by one person is one of those myths that need to be put to bed
You don’t need to understand the language completely. You only need to understand the general semantics and refer to the standard and docs to get the semantics down. That’s what they’re here for.
UB is basically impossible to avoid in practice--that is why the Linux kernel forced GCC to add a bunch of flags to "do what I mean", making UB defined in those cases.
They are also now vibe coding the kernel which is a major issue. Race conditions were already found in one of the slop suggestions. Linus is apparently fine with this degradation in quality.
Who’s vibecoding the kernel? I’ve heard stories of devs using AI to help write code, but don’t recall a single story of an experienced kernel dev vibecoding anything.
I'm serious. Linus does not rule Linux because of some cabal of dark overlords. He leads because he continues to deserve the job. I think Linus would be the first to admit it's time to retire if he started failing in his leadership of Linux development. That being said, there is truly nothing standing in the way of anyone forking the kernel and building their own version, over which they have complete control. So, I think it's an entirely fair suggestion to make.
OP says that a change in leadership for THE one existing linux kernel project is warranted. Your reply is "just fork it"? The Linux kernel? And what exactly is that going to be good for?
No, it's not a fair suggestion, because it's not a real suggestion at all. Over 2000 skilled maintainers work on the kernel, there's hierarchy, processes, culture, community, the linux kernel project both adapts to and shapes computing globally, companies are in talks with the linux foundation in regards to drivers etc, distros are tightly coupled and tested on it, there are north-star people like Linus... It's very much a big ship.
So firstly, yes, there IS something "standing in the way of anyone forking a kernel and building their own version" - for example that it's absolutely useless, unless you can do the job of 2000 maintainers, your "fork" will be the upstream base + 3 little patches on top and you'll spend a month getting it stable on your system.
Secondly, this isn't something you solve by saying "screw it, I'll do it myself" and abandoning the ship. Even if you did build your own linux kernel to your liking, this doesn't address the concern about the global linux kernel project that other 99.9% of the planet and distros and hardware uses.
This "don't like it? Fork it" argumentation fallacy has been present ever since open source became a thing, and it's quite frankly insufferable, but applying it to the goddamn Linux kernel, that's a new level.
I have noticed the same on my project.
The agent helps a lot to fix bugs. Just point the agents at the bug reports. They do the reproduction, debugging and fixes. We "just" have to review. (Sometimes ask more details and tell we'd prefer another approach.) This makes bug fixing much faster and automated.
And at the same time, it seems we get less bug reports to our library. I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.
So overall, the open bug count is decreasing. Which somehow feels good.
On the other hand, we get a lot of PR made by other's people agents, which can be a bit overwhelming when it's just a huge code drop. We can't easily review that.
> > and agents don't report bugs, they just work it around somehow.
Yeah I've definitely noticed this. On a project I'm working on Opus 5.5 found a bug in Smithay and another in Winit. It did tell me about them but its preferred solution was just to work around them locally. To be fair we don't really want agents going off and reporting bugs automatically...
I don't run any big open source projects but I think my preferred solution to AI PRs would be to get my AI to implement the same thing, and give then afterwards tell it to look at the PR for anything it missed. Then I at least know that I'm using a competent model and it reduces the danger of just blindly accepting someone else's code. (And obviously review the code if you have time and care, but that isn't always the case.)
Yes the default behavior of working around the bug is good, that’s what everyone was doing anyway pre-LLMs. The good practice is to report the bug. Simply add instructions to your agents to report you the bugs it found in the summary, so you can check the bug and report it correctly upstream.
I usually report the bug and leave a link to it in a comment beside the work-around code.
>I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.
Claude comes up with some truly delicious insane workarounds these days. Like launching something in a subprocess and capturing stdout/stderr and doing string parsing on info logs because of a desire for some hook not exposed by API (or at least that it didn't find on its quick scan).
There's probably no such thing as semver reliability for dependencies anymore in stuff that agents glue together, since they will poke at ANY sort of way of getting additional insight or control if they want it.
That's so fragile.
also the agent might introduce bugs, just like a human (see rsync which now has very busy development). Likely we (and the LLM) just won't notice them as easily. Fun times I guess.
And? People also introduce bugs. If you are too lazy to setup verification harness, you will be even more lazy to do all testing manually.
Rsync is hopelessly underfunded under staffed. Current developer was forced to takeover, because everyone quit!
> I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.
It's quite a pity, preventing us from improving our model of the domain, from Naurian theory building and presenting a perfected API etc.
The headline is "Development statistics for the 7.2 kernel", and the last paragraph is highly LLM critical in contrast with the editorialized headline "Linux bugs fixed per release over time: >2× rise since 2026-04", which seems to imply some sort of Mythos bug finding.
From the last paragraph:
"The Linux kernel is aimed at production use, not research or experimentation. But there is currently a massive experiment being run on the kernel's development processes and community."
The following sentence:
"This community has absorbed new processes and tools many times over its 35-year history, and will almost certainly find a way to do that this time as well. But that absorption has not always been without turbulence along the way."
Elaborated in here https://news.ycombinator.com/item?id=50133642
Greg KH did a video on the flood of LLM created stuff: https://www.youtube.com/watch?v=NnV_cWeoo5Q , HN thread: https://news.ycombinator.com/item?id=49929391
Which covers how he responds and pushes back on much of this, as well as asking for a patch (not just bug reports)
> pushes back on much of this
He's "pushing back on this" because he's being obsoleted in real time.
Oh, you dont have to worry. You'll be obsoleted waaay before him.
Not quite. My C++ Linux rewrite is already production ready, meaning in theory I no longer need to rely on the Linux kernel devs. This will, in a matter of months I presume, become the norm.
This has to be satire
Yes the Linux kernel was in desperate need of a c++ rewrite
Pah, that's nothing. I rewrote the Linux kernel in c++ but only using template metaprogramming
I also want to see the known abstraction skills of LLM used to properly recognize where the objective nature of C++ makes most sense in Kernel code. All the new interfaces, polymorphism.
Seriously doubt there's much of value there.
Then Linux kernel should be rewritten in FreePascal now.
My B port is going well. C was a mistake. /s
I can rewrite the kernel in C++ too: update the Makefile to treat .c files as C++. It’ll almost work :)
What is the need for this?
The major issue with these kinds of blurbs is that there's no control.
Historical numbers are not valid because incentivizes of a well funded entity have changed. It would require an equally well funded push to up the patch numbers without LLMs to really measure the impact in a quantifiable way.
Just how massive can the machine-generated amdgpu header files get, it may be time to set some limits.
So it seems worth vibecoding a survival analysis for bugs introduced. But not quite a survival analysis because we don't even know the bugs exist until the event of their discovery.... Is there a publicly available dataset for this, with a URL?
Heads up for those upgrading to 7.3, I just downgraded my slackware box from 7.3-rc7 to 7.2.10 because /dev/input/events was missing. Keyboard and mouse only worked in the console as a result.
YMMV
Please don't editorialize titles.
(Edit: title has been fixed)
Submitted title was "Linux bugs fixed per release over time: >2× rise since 2026-04". We've reverted it now.
Submitters: If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
I got shadow banned. How do I delete my account?
You haven't been banned, but quite a few of your comments have been breaking the site guidelines, and so correctly flagged.
Bummer that you got shadow banned.
I see your comment.
To the surprise of no one. Although, I must recognise that I did not envision a future where Linus embraced AI as frictionless has its been, then again after the inclusion of Rust in the kernel, I probably would've risked some money on it.
> where Linus embraced AI as frictionless has its been
Why? He seems very pragmatic. I fully expected him to embrace it, with the only concern being correctness and quality.
True, but I think there are quite a few very pragmatic people in here, and yet you see the they don't exactly go around singing praises.
You can usually be pragmatic but entirely emotional about something specific. Famously, Linus is both pragmatic AND emotional about being pragmatic.
This is really short-circuiting my brain right now.
The pragmatic ones are excited about where things are going.
The ones complaining about "slop" are the ones going on vibes now.
I’m strongly with you on that. Current models aren’t perfect, but neither am I. In a lot of my daily use, they’re as good as or better than I am at certain tasks.
I hear people around me talking about a bad experience they had with ChatGPT last summer as though it proves all AI coding is “slop”. Honestly, it makes me sad for them. There are reasons to dislike AI, but so many detractors skip right past those to anecdata that just aren’t relevant anymore, if they ever were.
I've had a lot of bad experiences with current chatgpt (mainly, it tends to just get sidetracked and hyper-fixated on literally anything, so if I give it a rodmap of tasks to do it will fixate on the first one and keep adding caveats as to why something isn't complete) and a lot more success with Claude (not) doing that. But I don't use Codex, but chat chatgpt (I don't have the max plans so Codex gobbles up usage limits in like 20 minutes even on the simplest of tasks) so Idk, maybe that's why?
To counter the bad though: right now Claude and I have been doing some very interesting work on acoustics and advancing steam audio. I've been researching this for several years trying on and off again to make my hopes a reality but could never take all the math and make something coherent out of it by hand, and Claude has helped with that (well, and Steam Audio). The trouble mainly comes from being blind and trying to build geometry from code and not being able to mentally visualize the geometry in question (which is also why I struggle with physics engines). It's been really fun just experimenting with this and seeing how good it gets. Who knows, I might make it a library that I publish someday.
[dead]
Current models are still worse than I am, or any competent developer I've ever worked with. You act as though people tried ChatGPT in 2023 and gave up forever, but that isn't what is happening here. The cold hard truth is that, contrary to what AI boosters claim, LLMs still suck at programming and output slop.
It's fascinating how far experiences can diverge. I've had fantastic luck with it starting about a year ago, and it's been rapidly improving since.
Looks like Linus doesn't agree with you
You sound like a dinosaur looking at a meteorite.
> I hear people around me talking about a bad experience they had with ChatGPT last summer as though it proves all AI coding is “slop”.
They always quit right before it got good.
> Honestly, it makes me sad for them.
The the consternation? They’re going to be obsoleted in no time anyway, so we’re told. Are they missing out on some months’ worth of coasting as meat proxies before exponential takeoff? Is that the sad part?
> The the consternation?
* Why the
Also, it took a long time for rust to mature to be considered for linux kernel development. AI is faster but easier to integrate.
That's exactly why one would expect him to not embrace it. LLM usage is anti-correlated with either of those things.
Or, he has a full understanding that, like everything single thing he's ever been involved with in his career, it's a new tech under development and will, as every measure up to now has demonstrated, improve over time. And, as all tech that has ever existed since the beginning of man starts, has somewhat initially limited, but still very practical and real, use in its current state.
Again, he's pragmatic, and has seen countless types and iterations of tech come into existence. The people expecting perfection from the start have no actual experience with the creative process, engineering or design, and and only want progress to stop (because there is, literally, without exception ever existing, no alternative to iteration).
As someone who hates c++ so much, he is surprisingly nice to llm.
LLMs write C for the kernel. He would hate them too if they only outputed C++.
100%. Too many people equate LLM assisted programming with vibe coding some slop. Which is just a weird thing to do at this point.
Yes, Linus is quite forward thinking, and we can credit that with why Linux has stayed relevant for so many decades. Not many software projects manage to pull that off.
Linus has always been pragmatic as opposed to dogmatic.
20 years ago he was fine using BitKeeper, proprietary software, for kernel source control, because it was better than Subversion and CVS. He only created git when BitKeeper introduced some road blocks.
[dead]
While great in theory, the flip side is all the slop patches and PRs that both the kernel and open source in general now has to deal with, often with only agents as responders.
It honestly doesn't want to make me open anything for outside contributions anymore.
greatly exaggerated as indicated by linus' own feelings
https://lore.kernel.org/lkml/CAHk-=whTs09_ozN+e09GU68N1wPP56...
Clearly, Linus is all over the place here.
He used Claude Code to write one of his patches in [0] and introduced a data race bug in the kernel unbeknownst to himself but this bug was caught by other reviewer [1] before it made it into a new kernel release.
So I'm afraid Linus himself did not understand the changes Claude made to the code he submitted in the mailing list, despite his "principles" in telling others previously that AI was creating slop patches and then now shouting at others who were concerned about using LLMs on code where they do not understand the generated code themselves when it all applied to....himself.
[0] https://lkml.iu.edu/2610.1/13146.html
[1] https://lkml.iu.edu/2610.1/13573.html
Is your belief that Linus never had a bug caught in code review prior to Claude?
Why would that be your conclusion?
"introduced a data race bug in the kernel unbeknownst to himself but this bug was caught by other reviewer […therefore] Linus himself did not understand the changes Claude made to the code he submitted in the mailing list"
What other reading of this is there? A bug is being cited as evidence of slop generation, which implies pre-AI the bug would not have happened.
You extrapolated from a single instance where something did happen to an entirely different thing never happening as a position the original poster might have held, whereas it is 100% obvious that that would not be the case.
That effectively makes it a strawman argument.
We are talking about this bug, in this context. Not about pre-AI bugs that did happen and that also were caught (and then there is of course all the ones that were not caught).
Again, "Linus himself did not understand the changes Claude made to the code he submitted" implies that Linus writing the code himself would've prevented the bug.
Who knows, it might have. We just don't know.
> We just don't know.
Yes, that's why the parent poster's argument is bunk; it implies we know.
The data race is exactly the kind of subtle bug that even very experienced programmers would make in this circumstance.
The patches that Linus posted are relatively small and self contained and from reading the thread it seems came from a series of in depth conversations with Claude and were carefully reviewed by Linus.
So what we're seeing here is a tricky concurrency bug that even an expert would make. You can't use it as an example of slop
> Here's a new rule just for you: don't use compilers for any of your kernel submissions.
> Because if you can't show that you really understand what the machine is actually doing by writing your code in assembler, then I don't want to see your code contribution. You clearly aren't competent if you can't write it that way.
Typical AI sophistry. But it’s from Linus Torvalds so it becomes a slam-dunk.
Since you're such a philosopher apparently what's your response then
I don’t respond to chat comments.
i have no idea what this means
Linus's claim that use of LLM tools is uncorrelated with understanding or competence is ludicrous.
What he actually said was:
> The kind of expectations I have is that people do their best and I expect people to understand what they are doing.
> But that understanding has very little to do with what tools they use.
> And quite honestly, in my experience, the people I respect and call intelligent are not the ones that shy away from using new and interesting tools.
He’s saying that understanding or competence are more about the person than their AI use. I think that’s a reasonable argument, even though I disagree on the basis that it’s at least a little correlated in the shortcuts in understanding the many devs I’ve seen (not all, but a nontrivial amount) seem to be taking.
To be clear: I believe that it's entirely possible to use LLMs to amplify understanding and competence, but that in practice LLM usage is anticorrelated with understanding and competence. This is about empirical reality, not logical entailment.
Very much this. Experimentation and careful usage is ok, but we’ve all seen that is pretty much dwarfed by blind slop generation.
As an example, I’m in the process of putting up a patch series to optimize some specific filesystem operations. The amount of boilerplate that has to know to get done is completely unapproachable to an outsider both from the amount of time needed to learn that boilerplate and form it in such a way that maintainers will be happy. Even though I know exactly how the code is working, it bridges that understanding gap but I don’t see how it correlates with incompetence. I may be an outlier but I suspect there’s a huge amount of people who are extremely capable and competent and it’s just that the Linux kernel has so many processes that it’s difficult to onboard into the community without LLM assistance.
The Linux kernel project is not hurting for contributors nor was it prior to LLMs. The processes you describe as roadblocks don’t seem to have been preventing the Linux kernel from getting code contributions. Maybe they don’t need or want more easy onboarding or broader audience?
Go look at the statistics in the article. LLMs are having a huge impact both in terms of new people developing and fixing bugs. “Not hurting” is a value judgement. The actual question is whether people wanted to contribute and the process was what kept them away or talent to enact the change. I suspect process has more impact than you’re willing to give credit too.
> The actual question is whether people wanted to contribute and the process was what kept them away or talent to enact the change.
My point was basically that this question misunderstands the purpose of large open source projects. They are not primarily things people have a right to contribute to, but rather things we want to improve for everyone. Anyone has the right to make changes to the Linux kernel for their own purposes, but contributing is not a right. It is primarily for serving the public good.
I’m not surprised the processes discourage some portion of would be contributors from contributing. I just don’t think that is a problem.
Presumably the person who's full-time job is staying on top of proposed changes to the linux source tree knows something about this; what are your credentials on the topic?
Linus himself is actually comically incompetent. He only became famous after the Linux kernel took off... decades ago? Since Git, he has made ZERO code contributions whatsoever (not even to the Linux kernel). He doesn't even review code and has his team of capos do it for him. All in all he's no different than the CEO of some tech company, his thoughts on LLMs are no longer relevant (for more lack of credibility, see his stance on Rust, C++, Go)
Why does he need to write code to be "competent." He's a structural and architectural genius.
Projects like the Linux kernel do not pop up out of thin air. They need a leader.
how do you feel about his analogy
> Here's a new rule just for you: don't use compilers for any of your kernel submissions.
> Because if you can't show that you really understand what the machine is actually doing by writing your code in assembler, then I don't want to see your code contribution. You clearly aren't competent if you can't write it that way.
I feel like you can't compare deterministic tools to non-deterministic ones so not a great analogy.
It doesn't really matter.
The point is, new technology arrived that allowed developers to do much more. Existing programmers hemmed and hawed about it because it threatened their egos, making easy what they once found very difficult. But the sensible engineers adopted the technology.
AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility.
> AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility.
How do you define correctness for any given task? If you know the correct logical process for any given process, writing it in code is just a matter of typing. The issue is that the human author, even when assisted by AI tools, does not know what is the correct algorithm for the task. In most cases, the output is probable code, not correct code.
I believe we are at a crossroads here. The key question is: Do we want (desire or require) humans to understand the implementation?
If the answer is no, then AI agents producing code faster and "more correct" (in some arguably questionable sense but let's fly with the assumption for a moment) should be embraced fully. Take the humans out of the loop, why review code, if there is a problem later then just ask the next AI agent to fix it. Similar to not looking at generated code by a compiler. Iterate fast, don't look back. Some code bases and some entire companies have adopted this view.
If the answer is yes then we need to keep the human in the loop, ensure they have enough understanding to maintain the thing, review all the code etc. AI is just another tool to produce the code which ultimately the human still owns. Many code bases follow this philosophy.
It seems to me that the discussion always ultimately falls on one of these two sides. They are incompatible but you need to pick one. Depending on which you pick, it is easy to predict how you argue in such discussions.
> The key question is: Do we want (desire or require) humans to understand the implementation?
Understanding the implementation is not the root cause here. The actual issue is that all software are built for a particular needs which is human related. In most software, the cost mostly decays to a constant value unless that need has changed or an external event has occurred.
Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users.
The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints.
> Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users.
You can pin down existing expected behavior pretty well with automated test cases and even bringing formal verification into the mix. Using LLMs to create those, it's not even a major cost factor. Then you are safe from such regressions. Just like when humans make changes. So, I don't see how this is introducing a difference.
> The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints.
Indeed. Though I don't see the connection to my point.
> You can pin down existing expected behavior pretty well with automated test
Test cases are sample based, they do not take care of the whole range of input and output. Type checking in the other hand are set based and sometimes the types are too coarse. In both instances, you need to carefully choose your axiomatic foundation, and if you can do that, that means you’re already aware of both programs and solution. As defining the problem is a major step in problem solving.
> Indeed. Though I don't see the connection to my point.
A lot of AI proponents are touting the tools as better hammers while purposely not saying anything about the house. You need to show how it can help with building a new house and not gush that it’s a new shape, different from all the other hammers in history.
So the focus on line of codes, number of PRs, all the harness talks,… is worth nothing if better software can’t be built.
> Test cases are sample based, they do not take care of the whole range of input and output.
Indeed, but they are not random or arbitrary. They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space. If you want to make things water tight, you use formal verification like I mentioned earlier (of which type checking is just a lightweight variant, in a sense) but for general screwups that's not even necessary. If tests are chosen well then the code must be formed very weirdly to produce bugs that the tests would not find.
> They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space.
The thing is you can have code that passes the tests, but are wrong for the general cases. With manual coding, you will have the knowledge that the code is about right, then add test cases to precisely check that intuition.
Like being aware that you used a linear function so as soon as 2 points in the test are ok, the code is right. But if you don’t read the code and have not noticed the quadratic function, your test cases will pass while the code is incorrect.
That's right. But isn't it conceivable that the entity (human or LLM) which adds a quadratic function also takes that into account? Oh, earlier it was a linear function so 2 test cases were enough, now it is quadratic and I need to add a test case, and all of that flags that something extraordinary might be going on requiring extra attention. At least we are already far removed from accidental screwups.
If anything then I would expect a human to be more susceptible to such an error than a coding agent. At least frommy experience from how they deal with (admittedly test-heavy) code bases.
(But again, if unsure, add a formal correctness proof for a few more extra tokens if that makes you sleep better at night.)
Nice rhetorical sleight of hand, trying to paint your opponents as ego-driven and senseless. But LLMs are not compilers. They cannot be relied upon to work correctly, and indeed can be relied upon to introduce bugs that a human would never introduce. The situation is different, therefore the reactions are different.
> AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does.
That is not remotely true.
> They cannot be relied upon to work correctly, and indeed can be relied upon to introduce bugs that a human would never introduce.
Please provide examples of bugs that a human would "never introduce", ever, under any circumstance whatsoever.
the question is about whether you understand in the slightest the output of the tool. does the determinism of the compiler somehow imbue you with a better understanding of the assembly it generates?
Yes. If you understand C code well, you have a very good understanding of what will actually happen when the binary is executed.
This is a myth https://queue.acm.org/doi/10.1145/3212477.3212479
I did not say that C is a low level language. You must have a very weak understanding on this topic.
> You must have a very weak understanding on this topic
i work on the codegen for a C compiler i'm pretty sure my understanding is better than yours <shrug>
EDIT: and also you've clearly never read that article
> One of the key attributes of a low-level language is that programmers can easily understand how the language’s abstract machine maps to the underlying physical machine
so you did exactly imply "C is a low level language"
lol nobody "understands C code well"
The idea that C is a smol language that can be completely understood by one person is one of those myths that need to be put to bed. C is riddled with complexities and footguns, especially but not exclusively around undefined behavior.
> The idea that C is a smol language that can be completely understood by one person is one of those myths that need to be put to bed
You don’t need to understand the language completely. You only need to understand the general semantics and refer to the standard and docs to get the semantics down. That’s what they’re here for.
Undefined behavior is something that you will avoid - of course, only if you know the language pretty well.
UB is basically impossible to avoid in practice--that is why the Linux kernel forced GCC to add a bunch of flags to "do what I mean", making UB defined in those cases.
do you want the bugs in your project fixed, no matter the source, or do you want only humans to contribute.
Linus wants the bugs fixed.
[flagged]
They are also now vibe coding the kernel which is a major issue. Race conditions were already found in one of the slop suggestions. Linus is apparently fine with this degradation in quality.
New leadership is needed over there.
Who’s vibecoding the kernel? I’ve heard stories of devs using AI to help write code, but don’t recall a single story of an experienced kernel dev vibecoding anything.
I suppose, feel free to fork the kernel and take the lead?
Come on.
I'm serious. Linus does not rule Linux because of some cabal of dark overlords. He leads because he continues to deserve the job. I think Linus would be the first to admit it's time to retire if he started failing in his leadership of Linux development. That being said, there is truly nothing standing in the way of anyone forking the kernel and building their own version, over which they have complete control. So, I think it's an entirely fair suggestion to make.
OP says that a change in leadership for THE one existing linux kernel project is warranted. Your reply is "just fork it"? The Linux kernel? And what exactly is that going to be good for?
No, it's not a fair suggestion, because it's not a real suggestion at all. Over 2000 skilled maintainers work on the kernel, there's hierarchy, processes, culture, community, the linux kernel project both adapts to and shapes computing globally, companies are in talks with the linux foundation in regards to drivers etc, distros are tightly coupled and tested on it, there are north-star people like Linus... It's very much a big ship.
So firstly, yes, there IS something "standing in the way of anyone forking a kernel and building their own version" - for example that it's absolutely useless, unless you can do the job of 2000 maintainers, your "fork" will be the upstream base + 3 little patches on top and you'll spend a month getting it stable on your system.
Secondly, this isn't something you solve by saying "screw it, I'll do it myself" and abandoning the ship. Even if you did build your own linux kernel to your liking, this doesn't address the concern about the global linux kernel project that other 99.9% of the planet and distros and hardware uses.
This "don't like it? Fork it" argumentation fallacy has been present ever since open source became a thing, and it's quite frankly insufferable, but applying it to the goddamn Linux kernel, that's a new level.
This should be a headline of its own: a first ever condition race found in a kernel patch submission
https://news.ycombinator.com/item?id=50134666
atlantic 0000:0f:00.0: PM: dpm_run_callback(): pci_pm_resume.llvm.11545057702175119861 returns -12
atlantic 0000:0f:00.0: PM: failed to resume async: error -12
AI fix this, thanks
You can literally do that now. Exactly as you wrote it...
Not good enough, I am testing if some agent is checking hackernews and will fix it for me