It's a shame you're misrepresenting what is actually going on.

In another comment here I explained that I have run a test: asking Claude Code to add a substantial feature to 270 different C programs.

Despite your beliefs - it went extremely well.

▲

qustio 3 hours ago | parent [-]

Huh, are you confusing me with someone else? I don't doubt Claude Code did that, I do the same for refactors all the time.

But xscreensaver theme tweaks for personal use have a much lower standard for quality control, regression testing, side effects, etc than a kernel used by billions of devices with thousands of interconnected drivers and subsystems.

Not to mention the coordination problem to get every maintainer on board and patches approved for each specific area when working on a project of that scale, even for a relatively narrow change.

Claude Code doesn't really help with that so don't see why the expectation would be a significant speed up (and doing it all in a single patch would definitely be rejected).

▲

qarl 3 hours ago | parent [-]

Yes, I understand the difference in rigor.

I refuse to believe the six year delay here was getting people to test a patch.

Which, actually, Claude Code will also do quite well.

▲

qustio 2 hours ago | parent [-]

Not sure why you'd refuse to believe that when a single, simple patch in Linux can take months to make it into a kernel release. Here we're looking at 300 patches scattered throughout a kernel with millions of LoC. That's going to translate to a lot of mailing list back and forth even if every change was accepted on the first try without a fuss.

▲

qarl 2 hours ago | parent [-]

The lag there is not due to the review time. How many maintainers were involved? 300? Because I'm still finding it hard to understand how the work of 300 people handling 300 commits cannot be parallelized into months (per your own stat.)

▲

qustio 2 hours ago | parent [-]

To be clear my original statement was that the bottleneck was most likely not mechanical code changes (where CC would have the most direct speedup) but everything else involved in the process (testing, discussion/approval, inclination towards caution, deliberately narrowly scoped changes, etc).

Not that the Linux kernel approval procedures couldn't be streamlined, work couldn't be parallelized, or anything else like that, which would be a different discussion entirely.

You stated that Claude Code could have significantly sped up the process, so the burden of evidence here should be on how specifically these patches would have benefited/time saved from using LLMs. Hand wavingly saying "LLMs = faster" is too vague/broad of a claim without providing any evidence (and also unfalsifiable).

▲

qarl 2 hours ago | parent [-]

Right.

And what I'm saying is I refuse to believe the Linux kernel approval procedures are that inefficient. Therefore, your belief "bottleneck was most likely not mechanical code changes" is most likely incorrect.

It would be interesting to get the actual answer to this question.

EDIT: Substantially changing your argument after posting isn't nice. But to answer your charge - no - I never made that claim.

▲

qustio an hour ago | parent [-]

Sorry, I didn't feel like this thread needed to be dragged out any longer since it's going in circles at this point and expanded my comment, but I didn't realize you had already replied.

	▲	qarl 28 minutes ago \| parent [-]
		Well - not really a circle. I keep saying the same thing over and over and you keep throwing arguments at it, unsuccessfully.