Linus Torvalds Working On A Hefty Linux Kernel Improvement With Claude Code

Personally, I can definitely distinguish Claude prose from other models' prose. It has a very distinctive writing style. Between other models, I generally cannot tell no.

It's possible to do automatically - we've already got services that do it reliably. For human recognition, I wouldn't risk your house. There are specific phrases that are common to family models. Claude has the load bearing, seams and list of no-s for example.

I once watched a presentation on a piece of research that shows LLMs change the meaning of a text ever so slightly when you feed text through it (because of synonyms, adding/removing repetitions, etc.). The particular graph I remember is some kind of point cloud, where two clusters can be seen. One of human written text, and another of their LLM "improved version". The paper showed that an LLM tends to push writing in a certain direction, if you project each before and after piece of text on some kind of 2D plane.

Based on the position in that field, you could probably give an estimate about LLM taintedness... I'll have a look if I can find the paper but it's been a while.

Edit: gotcha: https://arxiv.org/html/2603.18161v1

Wikipedia has done a pretty good job listing many the common tells but you're right that it's much more than that. It's a fundamental alienness, a sense that "no human would try to communicate that way." There are mundane words like "sits" or "gap" that while not incorrect are suddenly much more frequent and used in tortuous ways where there are obvious better alternatives - like "knowing where each responsibility sits" (and ugh, just google that phrase and see if you can find any human writing in the results.)

Bryan Cantrill wrote an article saying Pangram's AI detector is really good at this:

A little over a month ago, they introduced Pangram 4, which I found to be a step-function improvement over the already-impressive Pangram 3: in my experience it has an astonishingly low false positive rate and low false negative rate (which is to say: very high accuracy!). I am finding it to be so effective (and the loss of trust in voices that use LLMs to be so precipitous) that I recently extended RFD 576 to be explicit about public writing, specifically mandating that public Oxide writing be reported by Pangram as human-authored.

It's objectively controversial, people have sharp disagreements about not only whether but how to use LLMs and there's a wide range of opinions. But also, read the room. "Half the commenters here are flat earthers" is not really conducive to discussion.

Using AI to generate prose is significantly less controversial, in that it is widely disdained.

Yeah. If I had to pick literally one single human to read through 100,000 lines of bullshit PRs and firmly reject the bad ones, well, Linus has spent the majority of his "development" time doing that for 30 years now. And he's not especially shy about rejecting bad code. (By which I mean mainstream media was starting to write about his rejections, and so he was sent for remedial social skills training.)

So just to troll a bit, my new position on this issue is that only Linus should be allowed to use LLMs. I trust Linus to read the code and tell Claude what he really thinks.

I can't comment that he will fail to review LLM code, but code churned by LLMs has different failure modes than human written code, so reviewing it is different. Notably LLMs easily use good terms and the code looks plausible, disregarding whether it is correct or wrong; while sloppy (no pun intended) code made by a person has often tells -- i.e noticeable habits, wrong terms pointing out that they are new to the domain etc.

This is true but I find it almost entirely irrelevant. Everyone's code review practices are skewed by their incentives. Therefore "code review" is not one thing and very little of it is objective.

When accepting the code from a human-submitted patch set, Linus loses none of his own productivity when rejecting the code. One of his super powers is having almost no specific productivity goals for the kernel code. He has plenty of productivity goals related to the kernel development process and he would certainly see a change-less release cycle as unproductive. However there has been no lack of supply on the change side for 30 years. When he is reviewing the code of an LLM, in the pursuit of some code production goal of his own, the quality bar for him accepting the code is lower. How much lower is an open question. However I think it is beyond debate that the demands of code review for others is drastically different than code review for our own ends.

Critically, rejecting a human-submitted patch has a long term productivity benefit in many cases. Each of those rejections is a chance for Linus to not just make the engineer better informed about the kernel but also more familiar with the processes and values of the kernel project. I think it is safe to say that no one has become a subsystem maintainer without having many patches rejected. When Linus rejects a code generation from an LLM there is barely even a signal of positive intent to discard it. The code just goes unused.

but the software quality of some projects is improving

I'd be very interested to know which software project quality has improved over the last year. Almost every software I am using had dropped to insane low levels. I am using an M5 with the latest macOS and the amount of glitches/bugs/defects is beyond shameful.

Linux already contains LLM-generated code anyway. And you know what? It doesn't matter because there's no way to avoid LLM-generated code. GCC and LLVM can be used for Linux compilation and they both contain LLM-generated code already.

Looking at https://codeberg.org/ethical-foss/open-slopware#operating-systems, to be LLM-free, you would have to use an OS that is against LLM, compiled by a compiler written without LLM. That removes all the Linux distributions, BSD systems (even NetBSD, against using LLM, is using GCC and LLVM) and even Illumos. Probably the only one left would be 9front (Redox uses Rust compiler, which also was written with LLM help). Good luck using it for everything.

Also, keep in mind that firmware code is not granted by the heavens, but written - or these days probably "hallucinated" is a better word. As it turns out: https://codeberg.org/ethical-foss/open-slopware#bootloaders even coreboot allows for LLM, U-Boot as well.