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.)
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."
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.
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...
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.
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.
> 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?
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?
> 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.
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?
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.
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.
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.
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.)
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."
Which covers how he responds and pushes back on much of this, as well as asking for a patch (not just bug reports)
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.
(Edit: title has been fixed)
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...
New leadership is needed over there.
It honestly doesn't want to make me open anything for outside contributions anymore.
https://lore.kernel.org/lkml/CAHk-=whTs09_ozN+e09GU68N1wPP56...
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
> 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.
> 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.
Why? He seems very pragmatic. I fully expected him to embrace it, with the only concern being correctness and quality.
The ones complaining about "slop" are the ones going on vibes now.
atlantic 0000:0f:00.0: PM: failed to resume async: error -12
AI fix this, thanks