„Die Hälfte ist Slop“: KI-Patchflut vertreibt Linux-Kernel-Entwickler aus der Code-Prüfung

Lorenzo Stoakes, ein erfahrener Entwickler des Linux-Kernels, gibt mehrere Reviewer-Rollen ab. Als Grund nennt er die Masse an KI-generierten Patches, die er inzwischen auf mindestens die Hälfte seiner Prüfarbeit schätzt. Der Fall zeigt, was Open-Source-Projekten zu schaffen macht: Code lässt sich mit KI schnell schreiben, aber Menschen müssen ihn weiterhin prüfen.

Branche 11. Nov. 2026 6 Min. Lesezeit Quelle: Bing News (fr-CA)
Symbolbild, KI-generiert

Worum es geht

Lorenzo Stoakes arbeitet seit 2014 am Linux-Kernel mit, ist Ingenieur beim Chipdesigner Arm und hat das Fachbuch The Linux Memory Manager geschrieben. Am Dienstag, dem 10. November 2026, reichte er auf der offiziellen Kernel-Mailingliste LKML eine Serie von vier Patches ein. Mit ihnen trägt er sich mit sofortiger Wirkung als Reviewer für mehrere zentrale Bereiche aus. So berichtet es das französische Portal goodtech.info. Als Grund nennt er die Flut an Code-Vorschlägen, die mit künstlicher Intelligenz erzeugt wurden.

Reviewer prüfen fremde Code-Änderungen, bevor diese in den Kernel aufgenommen werden. Stoakes gibt diese Aufgabe für folgende Bereiche ab:

  • den Kern der Speicherverwaltung (Memory Management, kurz MM),
  • die Speicherrückgewinnung (Reclaim), die bei knappem Arbeitsspeicher entscheidet, welche Speicherseiten freigegeben werden,
  • die zugehörigen Komponenten in der Programmiersprache Rust,
  • verschiedene sonstige Abschnitte.

Seine Rollen als Maintainer behält er. Ein Maintainer ist hauptverantwortlich für einen Bereich und entscheidet am Ende, welche Änderungen aufgenommen werden. Laut goodtech.info betrifft das unter anderem das Umfeld von KVM, der Virtualisierungstechnik des Kernels. Die Betreuung der Transparent Huge Pages (THP) übergibt er an den Entwickler Zi Yan. THP ist ein Mechanismus, der Arbeitsspeicher in besonders großen Blöcken verwaltet, um Rechenzeit zu sparen.

„Ich habe nicht mehr die Kapazität“

Seine Nachricht richtete Stoakes an prägende Figuren des Projekts. Dazu gehören Andrew Morton, der seit Langem die Speicherverwaltung betreut, David Hildenbrand und die Verantwortlichen von Rust for Linux. Die Begründung ist deutlich:

„Angesichts der aktuellen Menge an KI-generierten Patch-Serien, die im Kernel ankommen, habe ich leider nicht mehr die Kapazität, allgemein Reviews zu übernehmen, außer in den Bereichen, für die ich Maintainer bin.“

Nach seiner Schätzung besteht inzwischen mindestens die Hälfte der Patch-Serien, die er prüfen muss, aus „AI Slop“. So nennt man in der Szene minderwertige, ohne Sorgfalt automatisch erzeugte Inhalte. Vor einigen Monaten sei ihm so etwas nur gelegentlich begegnet. Dann sei es wöchentlich passiert, schließlich täglich, bis die Einreichungen seine gesamte Warteschlange füllten. Das Aussortieren fremder Vorschläge koste ihn so viel Zeit, dass seine eigene Entwicklungsarbeit darunter leide.

Überraschend kommt der Schritt nicht. Schon im Juli hatte Stoakes vor diesem Problem gewarnt und es so zusammengefasst:

„Was das Projekt umbringt, sind 1.000 schlampige Beiträge, um die sich zwei oder drei Leute kümmern müssen.“

Das Nadelöhr Mensch

Der Linux-Kernel funktioniert über eine strenge Vertrauenspyramide. Jeder darf Änderungen vorschlagen, doch nur wenige menschliche Fachleute prüfen jede Zeile, bevor sie aufgenommen wird. Diese aufwendige Handarbeit hält den Kernel stabil, der auf Servern, Android-Smartphones, Routern und unzähligen weiteren Geräten läuft. Ein Fehler in der Speicherverwaltung kann Abstürze, Datenverlust oder Sicherheitslücken verursachen.

KI-Programmierassistenten wie Claude oder ChatGPT setzen dieses Modell unter Druck. Mit ihnen kann praktisch jeder in kurzer Zeit Code erzeugen, der auf den ersten Blick sauber aussieht. Laut goodtech.info enthält er aber oft subtile Halluzinationen, also erfundene Annahmen, die plausibel klingen. Dazu kommen Regressionen, das heißt Änderungen, die an anderer Stelle etwas kaputtmachen, das vorher funktioniert hat. Die Zahl der Personen, die das prüfen können, ist dagegen nicht gewachsen. Das Fachportal XDA Developers bringt es auf den Punkt: KI habe es jedem ermöglicht, Code zu schreiben, aber die Kapazität der Menschen, die ihn prüfen, habe sie nicht erhöht.

Laut goodtech.info stellten sich mehrere erfahrene Entwickler der Speicherverwaltung hinter Stoakes, darunter Mike Rapoport und David Hildenbrand. Einige bestätigten, dass die derzeitige Arbeitslast nicht mehr zu bewältigen sei.

Das Problem betrifft nicht nur Linux. XDA verweist auf die Open Home Foundation, die hinter der Smart-Home-Software Home Assistant steht. Auch sie kämpft mit einer Welle von KI-unterstützten Einreichungen.

Keine Kennzeichnungspflicht für KI-Code

goodtech.info sieht eine Lücke in der Organisation des Projekts. Linus Torvalds, Erfinder und oberste Instanz des Kernels, steht KI-Werkzeugen als Hilfe für Entwickler grundsätzlich offen gegenüber. Die Einreichungsregeln verlangen aber keine ausdrückliche Kennzeichnung, wenn ein Patch von einem Sprachmodell erzeugt oder mitgeschrieben wurde. Reviewer prüfen solche Beiträge deshalb „blind“: Sie wissen oft nicht, ob ein Mensch den Code wirklich verstanden hat oder ob sie gerade das Ergebnis eines Chatbots vor sich haben. Diese versteckten Kosten tragen bezahlte wie ehrenamtliche Prüfer. Laut goodtech.info treiben sie gerade die besten Fachleute zum Rückzug.

Was die Kernel-Leitlinien für KI-Agenten verlangen

Die Kernel-Gemeinschaft hat das Problem erkannt. XDA Developers beschreibt eine Anleitung der Kernel-Maintainer zum Umgang mit KI-Coding-Agenten. Das sind KI-Programme, die selbstständig Code lesen, ändern und testen können. XDA nennt die Anleitung einen der besten Leitfäden zu dem Thema, den die Redaktion bisher gelesen habe. Aus dem Bericht geht nicht eindeutig hervor, welchen Status die Anleitung hat. Die Kernpunkte nach XDA:

  • Prozess zuerst: Der Agent soll die gesamte Dokumentation zum Entwicklungsprozess und weitere relevante Unterlagen lesen, statt nur nach Stichworten zu suchen. Die Materialien gehören von Anfang an ins Kontextfenster, also in den Textbereich, den das Modell gleichzeitig im Blick hat. Ein Repository enthält nicht nur Code, sondern auch Architektur, Konventionen, Testregeln, Release-Abläufe, Einreichungsrichtlinien und Zuständigkeiten.
  • Belege statt Vermutungen: Einem Modell nur den Fehlerbericht zu geben, reicht nicht. Ein Sprachmodell kann eine plausible Erklärung für etwas liefern, das gar nicht existiert, oder eine Ursache benennen, die mit den Fehlerprotokollen nichts zu tun hat. Der Agent soll deshalb Belege vorlegen.
  • Lokale Testschleife: Fehlersuche, Korrektur und Tests sollen in einer lokalen Schleife ablaufen, bevor überhaupt jemand an eine Einreichung denkt. Wer den Agenten steuert, muss selbst prüfen, dass der Fehler wirklich behoben ist und nichts anderes kaputtgeht. So sollen weniger Menschen mit unfertigem Code belastet werden.
  • Herkunft dokumentieren: Die Leitlinien behandeln auch die Provenienz, also die Herkunft des Codes. Gemeint ist zum Beispiel, welche Dateien der Agent untersucht hat, welche Aufgabe er bekam, welche Dokumentation im Kontext lag und welche Tests bestanden oder fehlgeschlagen sind.
  • Menschliche Verantwortung: Die Bestätigung per Sign-off, mit der ein Entwickler die Herkunft und Rechtmäßigkeit eines Beitrags bescheinigt, muss immer von einem Menschen kommen. Wer einreicht, übernimmt damit die volle Verantwortung, auch wenn ein Agent den Code geschrieben hat.

Maintainer dürfen bei KI-unterstützten Beiträgen außerdem zusätzliche Tests verlangen, genauer hinsehen oder Erklärungen zu den Änderungen fordern. Kann jemand nicht erklären, was sein eingereichter Code tut, ist das laut XDA ein klares Warnsignal.

Einordnung

Der Rückzug ist ein deutliches Signal, weil er keinen Neuling betrifft. Stoakes kennt einen der heikelsten Bereiche des Kernels so gut, dass er das Standardbuch darüber geschrieben hat. Wenn ausgerechnet solche Fachleute die Prüfarbeit einschränken, wird die Speicherverwaltung insgesamt langsamer betreut. Das gilt dann auch für sinnvolle Beiträge von Menschen, die mit oder ohne KI sorgfältig arbeiten.

Das Problem ist strukturell. KI senkt die Kosten, Code zu erzeugen, nahezu auf null. Die Kosten, ihn verantwortungsvoll zu prüfen, bleiben gleich oder steigen sogar, weil fehlerhafter KI-Code oft gepflegt aussieht und Fehler deshalb schwerer auffallen. Leitlinien wie die von XDA beschriebenen setzen bei den Einreichern an: Sie sollen Belege liefern, die Herkunft offenlegen und persönlich haften. Ob das gegen eine Masse an Beiträgen hilft, deren Autoren sich um solche Regeln nicht kümmern, ist offen. Eine verpflichtende Kennzeichnung von KI-Patches gibt es laut goodtech.info bisher nicht.

Einschränkend gilt: Die Schätzung, mindestens die Hälfte der Patches sei Slop, ist Stoakes' persönliche Einschätzung für seine eigene Warteschlange und keine Messung für den gesamten Kernel. Eine offizielle Reaktion von Linus Torvalds auf den Rückzug nennen die Quellen nicht.

Quellen

#linux#open source#ki-code#softwareentwicklung#coding-agents
Originalquelle lesen

Frag den KI-Assistenten

Fragen zu diesem Artikel, zur Installation oder zu Hintergründen? Unser Assistent kennt diese Seite und läuft auf unserem eigenen Rechner, nicht in einer fremden Cloud.

Verbinde …

Der Assistent ist eine KI (Gemma 4) und kann sich irren – wichtige Angaben bitte in der Quelle prüfen. Fragen werden nur zum Beantworten genutzt und nach einer Stunde gelöscht. Bitte keine persönlichen Daten eingeben.

Kommentare

Was meinst du dazu? Schon ausprobiert? Schreib es hier, ohne Anmeldung.

  1. Kommentare werden geladen …

Kommentare sind öffentlich. Links sind nicht erlaubt, beleidigende Beiträge löschen wir. Deinen eigenen Kommentar kannst du in diesem Browser jederzeit wieder löschen. Mehr dazu in der Datenschutzerklärung.