qustio

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.

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).

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.

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).

I don't think the bottleneck was that it took six years to Ctrl-F strncpy and type in new code for each file.

It's entirely reasonable to ask for the underlying research in response to a blog post hyping up an unproven claim in an area notoriously full of amateurs making the same claim that historically fail to stand up to scrutiny.

Particularly when the only source is a friend of the author, posting on a blog named "AI Clambake" about "A weekly, human-powered newsletter for advertising folks who want to stay on top of the AI mayhem" and not a publication with any credibility in linguistics.

None of that means it can't be true, but some basic skepticism is warranted here. Otherwise we end up in a situation like the LK99 room temperature superconductor where a lot of HN commenters were also upset at the cynical "downers" who just couldn't root for a good thing/progress.

But the entire corpus for Linear A is tiny, you could backfill a "translation" that has no actual similarity with the real language when properly tested against novel examples. How was this tested?