Everyone Quoted Torvalds’ README. Nobody Read His Diffs (They Say More)

Six months after the “Linus vibe-codes now” story, the repo’s git history tells a sharper story than the headline ever did, including one bug that’s still there.

Photo by Yancy Min on Unsplash

On January 7, 2026, at 14:38 Pacific time, Linus Torvalds merged a branch literally named antigravity into his AudioNoise repo, eight commits of AI-generated Python, 331 insertions, written in a single afternoon.

That merge launched a thousand hot takes, including the one that probably brought you here. I’ve read a dozen of them. Every single one quotes the same README paragraph. As far as I can tell, almost nobody ran git log on the actual repository.

So I cloned it and spent an evening in the diffs. I went in with an assumption I’m slightly embarrassed to admit: that the sloppy AI code everyone mocked in January came from that famous vibe-coding session. I was wrong. It arrived ten days later, and what it’s done since is the most useful part of the whole story.

The part everyone already knows (30 seconds)

AudioNoise is Torvalds’ holiday project: toy digital audio effects, grown out of his guitar-pedal tinkering. He hand-wrote the DSP core in C. For the waveform visualizer, he needed Python, a language he describes as “monkey-see-monkey-do” territory, so he let Google Antigravity write it, and said so in the README.

The consensus took form within days: use AI for the parts you don’t know, hand-write the parts you do. Sensible. Quotable. And it quietly skips the interesting question one commenter asked out loud and never got answered: Does vibe-coded code have a fingerprint you can actually see?

It does. The repo is a clean specimen, because the boundary between human and AI code runs exactly along the C/Python border.

Fingerprint #1: The merge commit is a prompt-engineering lesson

Read the merge commit itself, not the news about it. Torvalds describes the one place the agent got stuck: matplotlib’s built-in rectangle selection kept fighting the rest of the UI. His fix wasn’t to debug the AI’s code.

“After telling antigravity to just do a custom RectangleSelector, things went much better.”

That’s the actual senior-engineer move hiding in this repo: when an agent thrashes against a framework built in, stop iterating on its output and change the instruction to tell it to build the small custom thing instead. He couldn’t have written the replacement himself. He could still diagnose where the fight was happening. That division of labor is the whole game.

And his verdict, in the same commit: “Is this much better than I could do by hand? Sure is.”

Fingerprint #2: The tests stop exactly where the AI starts

The tests/ directory contains two files: lfo.c and sincos.c — numerical verification for the hand-written C primitives. Commit messages like "Add LFO sinewave verification test" and "Add verification of fastsincos() results" show Torvalds checking his own math within days of writing it.

The 608-line AI-written visualize.py ? Zero tests. Zero type hints. One try/except in the entire file.

That asymmetry isn’t laziness, it’s a map. Testing effort tracks confidence, and confidence tracks competence. He verifies the code he understands and eyeballs the code he doesn’t. Which would be fine, except eyeballing is precisely the review mode that misses what came next.

Fingerprint #3: the dead function and where it actually came from

Here’s what’s sitting in visualize.py on main, today:

def update_slider_text(self, val):
    """Helper to update slider texts (Width and End Point)."""
    start_val, end_val = val
    width = end_val - start_val

def update_slider_text(self, val):
    """Helper to update slider texts (Width and End Point).",""
    start_val, end_val = val
    width = end_val - start_val

    if self.x_mode == 'Time':
        self.slider.valtext.set_text(...)

The same method is defined twice, back to back. The first is a truncated stub; Python silently discards it when the second definition loads. It’s like writing two wills, only the last one counts, but the first one is still in the drawer, confusing your heirs.

A sharp-eyed DEV.to writer spotted this duplicate in late January and folded it into the “Accept All culture” narrative around the famous January 7 session. Reasonable guess. Wrong, though, and git log -L proves it:

git clone https://github.com/torvalds/AudioNoise.git
cd AudioNoise
git log -L 342,352:visualize.py --oneline
# → 1d00ac1  Refactor visualize.py to use native
#            sample units and improve slider

Commit 1d00ac1 landed on Saturday morning, January 17, ten days after the viral merge, at the peak of the "should Linus be doing this" discourse. Its sibling commit from the same morning credits the tool explicitly: "Speed up plotting (courtesy of antigravity)." Whether the stub came from that same Antigravity session or from Torvald's own hands, one thing the timeline settles: the dead code arrived during the debate, not before it, and while the internet argued whether he should keep vibe-coding, his commit messages show he was.

The uncomfortable part: it survived six months

Since January 17, the repo has taken roughly twenty more commits, new effects, interface refactors, and even an external contributor’s patch. The last one landed on May 7. The repo has 4,400 stars and 207 forks.

The duplicate is still there.

Jan 6   C framework (hand-written)
Jan 7   antigravity merge  ← the headlines
Jan 13  C verification tests added
Jan 17  refactor introduces dead function  ← nobody noticed
Feb–May ~20 commits, new effects, refactors
Jul 6   duplicate still on main  ← you are here

Thousands of people starred this repo because of the AI-code story. A measurable fraction presumably opened visualize.py looking for exactly this kind of thing. One person blogged about the duplicate. And through all of it, across two subsequent edits to that very file, the stub survived.

The README got quoted; the diff got ignored. That’s the finding. Not that AI writes dead code, linters have caught duplicate definitions for decades (ruff flags this as F811 out of the box). The finding is that vibe-coded files don't get read, even in the most scrutinized hobby repo on Earth, even by their owner. Dead code doesn't crash; it waits.

When none of this matters (and when it does)

Let’s be fair to Torvalds, because he’s been fair with us. AudioNoise’s README calls the effects toys you shouldn’t take seriously. If visualize.py breaks, a graph fails to render. No pager goes off. For throwaway visualization glue, "it renders correctly" is the test suite, and demanding type hints here is cosplay rigor. If your AI-generated code lives in that category, close this tab guilt-free.

The pattern stops being cute at three boundaries. First, when the file outlives the session, this “throwaway” is now a six-month-old public dependency of a learning project. Second, when the competence gap means review can’t happen, the celebrated “use AI where you’re weakest” advice has a corollary nobody quotes: you’re weakest at reviewing exactly there. Third, when volume scales, Torvalds himself drew that line in May, saying that lasting projects require developers to deeply understand the generated code, not just the prompts, and separately noting the kernel’s patch sizes have jumped in the AI era. Same man, same tool, opposite policies, because the blast radius differs.

Takeaways

• Read the diffs, not the coverage. The primary source (git log, 5 minutes) contradicted the popular timeline of this story in one command.
• Vibe-coded fingerprints are real and checkable: duplicate/stub definitions, zero type hints, docstrings on trivial helpers, a test suite that stops at the human/AI boundary.
• Lint the code you didn’t write, precisely because you won’t read it. A default ruff run (F811) catches this class in milliseconds, cheaper than the review you're not going to do.
• Asymmetric testing is a confession. If your repo tests hand-written modules and not generated ones, you’ve documented where review actually happens.
• Copy the RectangleSelector move: when an agent fights a framework built-in, don’t debug its output, change the instruction, and have it build the small custom piece.

I write weekly about DevOps, backend engineering, and security — follow so you don’t miss it.