Torvalds: Die KI wollte aufgeben, er nicht

Am 20.08.2026 hat Linus Torvalds einen Einzeiler in den Mainline-Kernel committet. Aus round_up() wurde round_down(), 18 geänderte Zeilen im Intel-xe-Grafiktreiber. Interessant ist nicht der Fix, sondern was er in eckigen Klammern darunter geschrieben hat.

Der Bug

get_flat_ccs_offset() liest die Basis des Kompressionsspeichers aus der Hardware und rundet das Ergebnis auf 128K auf. Alles unterhalb dieser Grenze bekommt der VRAM-Allokator als benutzbaren Speicher. Torvalds beschreibt das Problem im Commit so: Eine Grenze, die "usable memory ends here" bedeutet, nach oben zu runden, gibt genau den Bereich zwischen echter und gerundeter Basis als frei aus, und der gehört der Kompressions-Hardware.

Auf einer Battlemage G21 mit 16 GiB landete dort bei jedem Kaltstart die Seitentabelle einer Mesa-VM. Die Kompressions-Hardware überschrieb sie, dem Compositor fehlte damit der Eintrag für seinen Batch-Buffer, gdm startete ihn endlos neu. Schwarzer Bildschirm auf einer intakten Maschine. Nach einem Neustart von gdm war es weg, weil die nächste VM ihre Tabellen woanders anlegte. Ein Fehlerbild, das sich also selbst wegräumt, sobald man hinschaut.

Der Nachsatz, um den es geht

Torvalds hängt an solche Commits gelegentlich einen persönlichen Absatz an. Dieser hier steht im Original so im Kernel-Repository:

"And this was a debug session from hell, enormously helped by an AI doing much of the grunt-work.

I'd like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it.

I suspect those things have been trained by people who may not be quite as stubborn as I am.

But while the AI was ready to give up several times, it did keep adding debug code and analyzing it faithfully when I pushed. So credit where credit is due and I let the AI write the commit message above."

Und die Zahlen dazu, ebenfalls im Wortlaut:

"This is basically a one-liner fixing a bogus "round_up()" to a "round_down()", but there were 24 patches adding more and more debug information to this, and 18 kernel boot to finally narrow it down to this."

Was daran lehrreich ist

Hier wirbt niemand für ein Produkt. Der Kernel-Maintainer beschreibt eine Arbeitsteilung, und sie fällt genau so aus, wie viele es aus dem Alltag kennen, nur wird es selten so nüchtern aufgeschrieben.

Die KI hat die Fleißarbeit gemacht: Debug-Code schreiben, Ausgaben auswerten, wieder von vorn. 24 Patches und 18 Bootvorgänge sind eine Menge stumpfe Wiederholung, und genau dort war sie nützlich. Was sie nicht geliefert hat, ist das Durchhalten. Mehrfach erklärte sie das Problem für unlösbar und schlug vor, stattdessen einen Bericht zu schreiben. Torvalds' Erklärung dafür ist bissig, aber der Mechanismus dahinter ist real: Ein Modell, das auf Abbruchsignale trainiert wurde, bricht ab, wenn die Signale kommen. Der Mensch, der weiterschiebt, ist in dieser Konstellation kein Beiwerk, sondern die Bedingung dafür, dass die Sache überhaupt fertig wird.

Das ist die ehrlichere Antwort auf die Frage, wofür Agenten im Debugging taugen, als jede Benchmark-Zahl. Nicht für die Einsicht, sondern für die Iterationen davor.

Die zweite Sache: Transparenz

"I let the AI write the commit message above." Dieser Satz steht nicht in einem Blogpost, sondern in der Commit-Message selbst, dauerhaft in der Kernel-Historie. Wer in fünf Jahren git log liest, sieht, welcher Teil wie entstanden ist.

Das ist bemerkenswert schlicht gelöst, und es beantwortet eine Frage, die in vielen Teams offen herumliegt: Wie kennzeichnet man den KI-Anteil an Code, ohne einen Prozess daraus zu machen. Torvalds' Antwort ist ein Absatz in eckigen Klammern, geschrieben von dem Menschen, der unterschreibt. Kein Metadatenfeld, kein Trailer, keine Policy. Für Teams, die sich mit der Kennzeichnung von KI-Inhalten herumschlagen, ist das ein brauchbares Muster: dort dokumentieren, wo es später jemand sucht, und in ganzen Sätzen statt in Häkchen.

Eine Frage lässt der Commit offen: Welches Modell er benutzt hat, steht nirgends, weder im Commit noch in seinen sonstigen Äußerungen dazu. Wir raten nicht.

Was das für euch heißt

Drei Dinge lassen sich mitnehmen, ohne dass man am Kernel arbeitet:

1. Setzt Agenten auf die Wiederholung an, nicht auf die Einsicht. Debug-Code einbauen, Logs auswerten, Varianten durchprobieren: Das ist die Arbeit, die Menschen ermüdet und Modelle nicht.
2. Rechnet mit dem Abbruch. "Das ist nicht lösbar" ist bei einem hartnäckigen Bug oft keine Diagnose, sondern ein Verhalten. Wer dann nachschiebt statt aufzugeben, bekommt die Fleißarbeit trotzdem.
3. Schreibt den KI-Anteil dorthin, wo der Code liegt. Eine Zeile in der Commit-Message kostet nichts und beantwortet später eine Frage, die sonst niemand mehr beantworten kann.

Wie man das im Team verlässlich aufsetzt, statt es dem Einzelnen zu überlassen, steht in Coding-Agenten im Team sicher betreiben.