- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
cross-posted from: https://piefed.social/c/linux@programming.dev/p/2509642/linus-torvalds-posts-his-first-ai-assisted-patch-to-the-linux-kernel-synthetic-test-clo
cross-posted from: https://piefed.social/c/linux@programming.dev/p/2509642/linus-torvalds-posts-his-first-ai-assisted-patch-to-the-linux-kernel-synthetic-test-clo
As per Linux kernel AI policy (and a common fucking sense), you’re the one responsible for the code that is submitted from your side, regardless of the tools and pipeline you use. Now get this, when an agent makes a mistake, that you didn’t notice, that’s still a learning opportunity, especially when you’re held accountable for the fuck up.
True… When you give them a general task that involves solution of technical problems and decision making. But when it’s a concrete “do the x thing over here, using this, this, and this”, which is then accompanied by your manual review of the changes, they actually do fine, basically allowing you to minimize the tedium, while not robbing you of the most interesting and important parts of development.
Did Linus’s pipeline look like what i described, tho, when he introduced the aforementioned bugs? Was it his technical decision that, by proxy, introduced bugs? I don’t know. Regardless of the answers, he’s a grown-ass man, and thus is responsible for the consequences of his decisions.
Is he more likely to introduce a bug now that he uses AI? Only time will show. I might be wrong, but i think Linus is too smart for it to be the case.
Despite the “AI policy and common sense” saying that the contributor is responsible for understanding the code committed, Linus did clealry not treat this with the due dilligence required. He used unproven error-prone technology to emit code for a project that millions of users depend on and sent it in despite it having the race condition and the performance regression.
If Linus was as smart as you seem to believe, he should have checked that code as if it was submitted from his worst enemy, as if it was written by a smarter and malicous adversary or at least a very enthusiastic imbecile. But the LLMs are designed in a way that trick you into believing that they are smart, reasoning and capable and you drop your guard. The code looked good, he got fooled and here we are.
I’d say, there was plenty of time for people, including Linus, to understand its limits, especially considering that before introducing current AI policy to the kernel maintainers, he used it for his personal project.
Human-written code is just as error-prone and unreliable, even if it is written by the most experienced dev there is. Do i really need to explain that your own ability to write quality code varies, based off countless factors that affect your mental state? John Dev didn’t have his breakfast — boom! Uncaught race condition, segfault, or some other critical bug, or safety vulnerability is introduced into prod.
What i’m saying is, unreliability of the submitted code is a problem as old as coding itself. It’s a well known one, hence all the static analysis tools developed over the decades, code reviews, hell, even opensource itself partially exists to solve this very issue. The fact that the bugs were caught is the living proof of just that.
“Smart” doesn’t mean “omniscient”, doesn’t mean “makes no mistakes”. “Smart” is not some kind of divine status. He’s still human, he still gets tired, his focus still can dwindle, and important things still slip his mind.
That’s your speculation, probably based off your own experience. Neither of us know the exact circumstances, by which the discussed bugs were introduced.