Ein erfahrener Entwickler der Speicherverwaltung des Linux-Kernels zieht Konsequenzen aus der wachsenden Zahl KI-erzeugter Patches: Lorenzo Stoakes hat am 10. November 2026 auf der Kernel-Mailingliste eine vierteilige Patch-Serie eingereicht, mit der er sich aus fünf Reviewer-Einträgen in der Datei MAINTAINERS streicht. Seine Begründung fällt knapp aus – und trifft einen Nerv, wie die Antworten seiner Kollegen zeigen.

Was Stoakes abgibt – und was nicht

Die Datei MAINTAINERS im Kernel-Quelltext legt fest, wer für welchen Teil zuständig ist. Sie unterscheidet zwei Rollen: Unter M: stehen die Maintainer, an die Patches zu schicken sind. Unter R: stehen benannte Reviewer, die bei Patches für diesen Bereich in Kopie gesetzt werden sollen. Ein Reviewer-Eintrag bedeutet also vor allem eines: viel Post.

Stoakes entfernt seine R:-Zeile aus diesen Abschnitten:

  • MEMORY MANAGEMENT – CORE
  • MEMORY MANAGEMENT – MISC
  • MEMORY MANAGEMENT – RECLAIM
  • MEMORY MANAGEMENT – RUST
  • RUST [ALLOC]

Er tritt damit nicht als Maintainer zurück. Im Kernel-Baum von Linus Torvalds stand er am 12. November 2026 weiterhin als Maintainer in den Abschnitten für Reverse Mapping (RMAP), Memory Mapping, das zugehörige Locking und madvise. Die Serie selbst war zu diesem Zeitpunkt dort noch nicht eingepflegt. Im Anschreiben formuliert Stoakes die Grenze selbst: Er könne Reviews nur noch in den Bereichen anbieten, die er betreut.

Es ist der zweite Schritt dieser Art. Am 26. August 2026 hatte Stoakes bereits die Rolle als Co-Maintainer für Transparent Huge Pages (THP) niedergelegt – damals mit dem Hinweis, seine Arbeitslast lasse ihm nicht mehr die Zeit, die das Thema verdiene, und „zumindest vorübergehend“. Der vierte Patch der neuen Serie trägt ihn für diese Zeit in die Datei CREDITS ein.

Symbolbild: ein DDR4-Speichermodul mit rotem Kühlkörper vor hellem Hintergrund

Symbolbild: Arbeitsspeicher – um dessen Verwaltung kümmert sich das Kernel-Subsystem „mm“. Foto: ElooKoN, CC BY-SA 4.0, via Wikimedia Commons

Die Begründung im Wortlaut

Im Anschreiben zur Serie heißt es (Übersetzung der Redaktion):

„Angesichts des derzeitigen Durchsatzes im Kernel, der aus KI-generierten Patch-Serien resultiert, fehlt mir leider die Kapazität, generell Reviews anbieten zu können, außer in den Bereichen, die ich betreue. […] Ich bitte um Entschuldigung dafür, aber angesichts der aktuellen Entwicklung möchte ich etwas tun, um meinen Posteingang ein wenig handhabbarer zu machen.“

In einer Antwort an Andrew Morton, den langjährigen Maintainer der Speicherverwaltung, wird Stoakes deutlicher (Übersetzung der Redaktion):

„Natürlich war die KI-Welle furchtbar, und sie wird deutlich schlimmer. Anfangs sah ich nur hin und wieder ‚Slop‘. Dann mindestens einmal pro Woche. Dann alle paar Tage. Inzwischen ist es so ziemlich die Hälfte dessen, was ich sehe, wenn nicht mehr.“

„Slop“ ist im Englischen der abschätzige Begriff für massenhaft erzeugte, minderwertige KI-Inhalte. Stoakes relativiert seinen Schritt aber im selben Atemzug: Es gehe vor allem darum, das Rauschen in seinem Posteingang zu verringern. Vermutlich werde er trotzdem weiter alles Mögliche begutachten, wolle sich aber weniger leicht in Reviews hineinziehen lassen, die nichts mit seinen eigenen Bereichen zu tun haben. In der Speicherverwaltung gebe es weiterhin viele großartige Leute. Als zweiten Grund nennt er, dass ihn inzwischen die Arbeit an KVM stark beanspruche.

Reaktionen: Bedauern und Verständnis

Die Antworten auf der Liste fielen einhellig aus. Andrew Morton reagierte mit einem Seufzer und der scherzhaften Frage, ob auch ein „Nacked-by“ erlaubt sei – also eine förmliche Ablehnung des Patches –, gefolgt von einem „Danke, halte durch“. David Hildenbrand, einer der Maintainer der Speicherverwaltung, schrieb schlicht: „Ja, es ist verrückt“ (übersetzt). Lance Yang merkte an, bei der derzeitigen KI-Flut sei ein leerer Posteingang nicht mehr zu erreichen; Mike Rapoport schrieb, er könne den Schmerz nachfühlen. Zustimmung per „Acked-by“ kam unter anderem von Zi Yan, Baolin Wang, Barry Song, SJ Park, Kiryl Shutsemau und Danilo Krummrich – jeweils verbunden mit Dank für die bisherige Arbeit.

Widerspruch gegen die Diagnose findet sich in den bis zum 12. November 2026 archivierten Antworten nicht – und unter den Antwortenden sind mehrere Maintainer und Reviewer des Subsystems.

Welche Regeln der Kernel für KI-Beiträge kennt

Der Kernel verbietet KI-Werkzeuge nicht, hat aber inzwischen zwei Dokumente dazu im Quelltext. Die Richtlinie für werkzeuggenerierte Inhalte (Documentation/process/generated-content.rst) stellt gleich zu Beginn fest, dass solche Werkzeuge das Volumen an Beiträgen erhöhen können, während die Kapazität von Reviewern und Maintainern eine knappe Ressource ist. Sie verlangt Transparenz: Im Anschreiben und in der Änderungsbeschreibung soll stehen, welche Werkzeuge wie verwendet wurden. Wer einen Patch einreicht, muss ihn vollständig verstehen und verteidigen können. Andernfalls dürfen Maintainer eine Serie ohne eingehende Prüfung ablehnen.

Das zweite Dokument (coding-assistants.rst) richtet sich an KI-Assistenten und ihre Nutzer. Es legt fest, dass nur Menschen die Zeile Signed-off-by setzen dürfen und damit die volle Verantwortung übernehmen. Ein Zusatz vom August 2026 schreibt außerdem ein Verfahren für KI-gestützte Fehlersuche vor: Fehler nachstellen, Korrektur schreiben, bauen, testen und offen sagen, was nicht geprüft werden konnte. Die Begründung steht gleich dabei – Maintainer verschwendeten derzeit zu viel Zeit mit ungeprüften Meldungen und ungetesteten Korrekturen.

Eine verpflichtende Kennzeichnung im Patch selbst gibt es dagegen nicht mehr. Die Markierung Assisted-by wurde im Oktober 2026 wieder aus der Dokumentation gestrichen. Laut der Commit-Beschreibung von Sasha Levin trugen rund zehn Prozent der 18.533 Commits (ohne Merges) von Linux 7.3 bis zum siebten Release Candidate diese Markierung, während die tatsächliche Nutzung von Sprachmodellen weit verbreiteter sei. Das Signal, für das man sie behalten hatte, liefere sie daher nicht. Angaben zum Werkzeugeinsatz gehörten ins Anschreiben. Diese Änderung hat auch Stoakes mit einem „Acked-by“ unterstützt.

Einordnung: Nutzen und Last liegen nah beieinander

Der Fall zeigt ein Dilemma. Die Kernel-Dokumentation erkennt ausdrücklich an, dass KI-Modelle wegen ihrer gewachsenen Fähigkeiten häufig zur Fehlersuche eingesetzt werden, und will diesen Einsatz in geordnete Bahnen lenken statt ihn zu unterbinden. Gut vorbereitete, getestete Korrekturen sind willkommen, gleich mit welchem Werkzeug sie entstanden sind.

Zugleich verschieben die Werkzeuge den Aufwand: Ein Patch ist schnell erzeugt, die Prüfung bleibt Handarbeit weniger Fachleute – genau die knappe Ressource, von der die Richtlinie spricht. Linus Torvalds hatte das Merge-Fenster von Linux 7.4 als ungewöhnlich groß bezeichnet und das teils auf KI-Werkzeuge zurückgeführt, wie wir im Artikel zu Linux 7.4-rc1 berichtet haben.

Stoakes’ Schritt ist deshalb weniger ein Abschied als eine Notbremse eines Einzelnen. Für alle, die Patches einreichen, steckt darin eine praktische Botschaft: Wer ein KI-Werkzeug nutzt, sollte das Ergebnis selbst verstehen, bauen und testen und im Anschreiben offenlegen, wie es entstanden ist. Das verlangen die Regeln des Kernels ohnehin – und es entscheidet darüber, ob die knappe Zeit der Reviewer in die Sache fließt oder ins Aussortieren.

Quellen

Bildnachweis