greatly exaggerated as indicated by linus' own feelings
https://lore.kernel.org/lkml/CAHk-=whTs09_ozN+e09GU68N1wPP56...
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.
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.
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).
Yes, that's why the parent poster's argument is bunk; it implies we know.
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
> 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.
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.
Projects like the Linux kernel do not pop up out of thin air. They need a leader.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.)
> 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.
Please provide examples of bugs that a human would "never introduce", ever, under any circumstance whatsoever.
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.
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.