cross-posted from: https://piefed.social/c/[email protected]/p/2509642/linus-torvalds-posts-his-first-ai-assisted-patch-to-the-linux-kernel-synthetic-test-clo
cross-posted from: https://piefed.social/c/[email protected]/p/2509642/linus-torvalds-posts-his-first-ai-assisted-patch-to-the-linux-kernel-synthetic-test-clo
What gets me is that this is roughly the best-case scenario for “capable hands” — Linus knows this codebase better than anyone alive — and a race condition plus a 9% read regression still slipped through on the first attempt. Reviews and testing caught it, which is the system working, but it moves the bottleneck from writing code to reviewing it. And review doesn’t scale the way generation does; skimming a patch is quick, but actually proving an LLM-assisted one is correct takes real effort. I say that as someone who uses AI tooling daily — reading code you didn’t write is genuinely more tiring than writing it, and that tax compounds the more you lean on generation. The maintainer-burnout angle might end up being the real story here, more than the AI one.
What I keep saying. Good take except that you don’t use “AI” tooling, you use copyright evasion slop tooling.
I thought code couldn’t be copywritten? It’s instructions, isn’t it?
Half a century of companies suing each other over code licenses suggests otherwise
Instructions can be copywritten just like recipes can.
Code is just a recipe for computer brains
Does he? Is it even possible to know the entirety of the Linux kernel within one head?
Does one need to know the entirety in their head to know it better than anyone else? If not Linus, who?
I’d argue the people who wrote the code for the various subsystems know more about it than the guys who “just” review and merge them.
That’s a fair point that I hadn’t considered
He’s spiraling downward, so even if he once lnew the kernel best, I am sure he no longer does by a long shot.
Verifying LLM code isn’t necessarily harder than verifying a human PR. I hope that this also boosts automated test tooling so that it also gets easier to test these PRs, since the focus will shift to review rather than writing.
Verifying 10 pounds of incoherent architectural choices and over engineered submodules is certainly harder than reviewing tee bits of coherent human work.
Sure, that’s why I said “not necessarily”. LLMs can be misused and made to do dumb shit too. But I have seen plenty of bullshit come from human developers too.
LLMs make dumb shit by default. Even Linus had a race condition caught in review when he used AI to bulldoze his way through a feature.
Agentic loops have major flaws which humans don’t, a tradeoff you seem to keep ignoring while you suggest that developers and agents are comparable in their output quality. The only comparison is, at surface value, they both produce code. Deeper than that, there are plenty of tradeoffs.
Yes tradeoffs in code quality, project quality, maintainability, technical debt, … you need to be a good programmer to get a good project out of an agent — and even that isn’t enough at times.
And verifying 10 pounds of incoherent architectural choices and over engineered submodules of human work is certainly harder than reviewing tee bits of coherent agent work.
You are? I can also make false dichotomy fallacies!
The difference is that AI is prone to this issue, even a single agentic process. Humans only really run into this issue with large, disorganized teams.
Humans burn out.
https://maevyn.codes/decoherence
edit: hold up. Presenting as though what I said works in reverse,
as though agentic and human contribution is equatable… wouldn’t that be false equivalency? Tisk tisk…
Human work is not swappable with agentic work without tradeoffs, which is kind of why I was making a point at all.