| ▲ | teekert 5 hours ago |
| Please stop with the "AI assisted development" = "Vibe coding slop" narrative. It comes across as pretty dumb (sorry, I mean "uninformed") nowadays. Please experiment with LLMs, find your way (or don't, but), learn to talk about it in an informed way and don't post obviously inflammatory one liners that are essentially just "AI is bad m'kay". There are intelligent arguments against using AI, your comment is not referring to any of them. In short: Linus feels responsible for the quality of the Kernel, he expects the same of other devs. He does not care about the tools used to generate the code. He (or some other human) will call out submitted slop, whether LLM generated or human generated. |
|
| ▲ | jillesvangurp 4 hours ago | parent | next [-] |
| It's increasingly the other way around, actually. You are being sloppy if you don't use the tools available to you. Including AI, static code analysis, testing tools, etc. to check if your work is any good. That doesn't mean you have to surrender to the AI tools and blindly generate everything and then commit without testing or any form of validation. That would be sloppy. But then if you manually write your code and did that, that would be sloppy too. Whether you manually type in all your code or have it generated is immaterial. What matters is the work you do to ensure it all works as advertised and is fit to be merged. The kernel developers are probably a bit further in their thinking then some developers. They've been dealing with many thousands of contributors for decades. Git was invented by Linus Torvalds specifically to deal with ensuring only the best patches make it into the kernel. Somebody posted a video with Greg Kroah-Hartman last week or so commenting on how he's been dealing with all the AI generated security bug reports. His key point is that AI generated reports are meaningless unless they come with a suggested fix as well. If you are going to generate the report, you might as well generate the fix. And it's a lot easier for him to review if the fix fixes anything worth fixing then to piece together a fix from a lengthy report. The larger the report, the less likely it is to get any attention. If the person contributing can't articulate why the fix is needed or how it works, they just reject the change and toss it back. That strikes me as very pragmatic. Judge a change on its merits. Not on how it was created. A report without a suggested fix is relatively meaningless. |
| |
| ▲ | teekert 4 hours ago | parent | next [-] | | 100%. I think there are a lot of people here on HN that are very threatened by LLMs, rightly so. I'm also afraid of my future and my day-to-day work has already changed from "loosing myself in a flow state solving technical puzzles" to "micro-managing LLMs". I don't like it, but hope I will learn to, at some point, or perhaps I find different work. I feel like I don't have a choice right now but to adapt and learn. The answer to this issue is not to equate any code generated by LLMs to slop. It is just not true. As you say, the latest models often flag things that I would definitely miss, or they simplify my code significantly with a just-released feature. I see benefits to code quality all day from using LLMs. I'm just saying (not to you but to comments below): Lets keep it constructive, which means: lets keep it real, as in close to truth. Yes vibe coding exists, and it has it's place (ie in prototyping?). But not in the kernel, and also not in my own line of works. LLMs do have a place there though. | |
| ▲ | MisterMunchkin 4 hours ago | parent | prev [-] | | There’s such a breadth of slop quality. Like I’ve seen people using ChatGPT with thinking disabled, which is just garbage. But you can also use an LLM to do automated testing of your product, in a real browser window, where it actually sees how it looks via screenshots. That’s insanely useful. And it can read all of the logs in the backend and browser simultaneously and understand what is causing issues. I’ve used that a few times and it is such a game changer for weird bugs. |
|
|
| ▲ | colesantiago 4 hours ago | parent | prev | next [-] |
| no. slop is slop. |
| |
| ▲ | teekert 4 hours ago | parent [-] | | Hard to argue against X = X. Just curious, are you are including human slop in your statement? | | |
| ▲ | colesantiago 4 hours ago | parent [-] | | The rate at which AI introduces bugs is higher than human ones about 2x more bugs than humans. Human slop is equally as bad, but this is not what Linus chose in this case, he chose to accept the higher risk of almost 2x as much more bugs using LLMs which lead to the introduction of LLM slop. I don't care if it is Linus or anyone else, slop is slop human or not, with LLMs it is far worse. | | |
| ▲ | ThunderSizzle 3 hours ago | parent | next [-] | | If the human is doing a proper workflow for the AI, I'm not so sure it's big central. Yes, AI needs to be guided strongly, and if it's not, it makes very poor choices/decisions routinely, but that's why you keep an engineer controlling the process. I force all work to be split up into chunks, properly investigated, spiked, and planned out, and then implemented via TDD (with only system-boundary mocking permitted). It's not perfect, but I've seen regression bugs very much cut so far. Beyond that, if it's a GUI app, I also require the TDD cycle to require GUI tests with screenshot evidence, and proper assert statements. | |
| ▲ | simianwords 2 hours ago | parent | prev | next [-] | | This is the kind of argument Linus was attacking. His tone against the anti-ai commitment in Linux now makes sense. | |
| ▲ | kelnos 3 hours ago | parent | prev [-] | | It sounds like you've defined "slop" as "anything an LLM produces". Seems unlikely you're going to get much agreement here. | | |
|
|
|
|
| ▲ | ozgrakkurt 3 hours ago | parent | prev [-] |
| Making LLM write code is super susceptible to generating problems imo. You know it won't be properly reviewed and understood. Using LLMs to review code is much more useful imo but it can also cause problems due to the natural lazyness of a person. You wouldn't want the OS you are using to be developed by a dilligent but a low IQ and mediocre skill level programmer. I'm not saying other people can't possibly use LLMs to generate code effectively but it seems super suspicious from my experience as it triggers laziness and reluctance to put effort into understanding every piece of code. |
| |
| ▲ | palata 3 hours ago | parent [-] | | > You know it won't be properly reviewed and understood Do you now? > You wouldn't want the OS you are using to be developed by a dilligent but a low IQ and mediocre skill level programmer. So you also know that people using LLMs to produce code are diligent but low IQ and mediocre skill? > it triggers laziness and reluctance to put effort into understanding every piece of code. Linus has been mostly reviewing code for what... decades? The rest of the contributors have been his LLM in some way. Would you say that he has gotten "reluctant to put effort into understanding every piece of code" he reviews? | | |
|
