Der Staging-Bereich im Linux-Kernel ist so etwas wie die Übungswiese. Hier landen Treiber, die noch nicht sauber genug für den Hauptbaum sind — und hier machen traditionell Neulinge ihre ersten Schritte als Kernel-Entwickler. Einrückungen geraderücken, tote Variablen entfernen, Coding-Style anpassen. Kleine Aufgaben mit echtem Feedback von echten Maintainern.
Diese Wiese hat jetzt einen Zaun bekommen. Greg Kroah-Hartman, Maintainer des Bereichs und einer der zentralen Köpfe der Kernel-Entwicklung, nimmt dort keine von Sprachmodellen erzeugten Patches mehr an.
DER GRUND: Ein Ansturm, den keiner mehr abarbeiten kann
Kroah-Hartman beschreibt die Lage als „onslaught“ — einen Ansturm von LLM-generierten Patches, der in den vergangenen Wochen über den Staging-Bereich hereingebrochen ist.
Das Problem ist dabei nicht in erster Linie die Qualität. Es ist die Menge im Verhältnis zum Zweck: Wenn automatisch erzeugte Aufräum-Patches schneller reinkommen, als Menschen sie prüfen können, bleibt für die eigentliche Zielgruppe nichts mehr übrig. Die Anfänger-Aufgaben sind weg, bevor ein Anfänger sie sieht.
Damit verliert der Bereich genau das, wofür er da ist: seine Ausbildungsfunktion. Wer als Mensch lernen will, konkurriert mit einem Generator, der nie müde wird.
Die eine Ausnahme
Kroah-Hartman zieht die Grenze nicht absolut. Ein echter Sicherheitsfix, den ein Sprachmodell gefunden hat, darf weiterhin eingereicht werden — allerdings unter zwei harten Bedingungen:
- Der Einreichende muss den Patch auf der Hardware getestet haben, für die der Treiber gedacht ist.
- Er muss überzeugend erklären können, wie dieser Test abgelaufen ist.
Das ist die eigentliche Aussage hinter der Regel: Es geht nicht darum, welches Werkzeug einen Patch geschrieben hat. Es geht darum, ob ein Mensch dafür geradestehen kann.
NICHT DER EINZIGE: Die Drei-Sekunden-Regel im WLAN-Stack
Johannes Berg, Maintainer für 802.11, mac80211, WWAN, rfkill und die WLAN-Treiber, hat für sich eine eigene Regel formuliert: Wenn ihm bei einem Drei-Sekunden-Blick auf einen KI-generierten Patch nicht sofort klar wird, dass es sich um eine echte Fehlerbehebung handelt, ignoriert er den Patch.
Das klingt schroff, ist aber eine nüchterne Rechnung. Ein Maintainer, der pro Patch fünf Minuten Prüfung investiert, schafft am Tag vielleicht ein paar Dutzend. Ein Generator schafft Hunderte pro Stunde. Diese Asymmetrie lässt sich nicht durch mehr Fleiß auflösen — nur durch schnelleres Aussortieren.
KEIN EINHEITLICHER KURS
Bemerkenswert ist, was hier nicht passiert: Es gibt keine kernelweite Regel. Verschiedene Maintainer ziehen unterschiedliche Linien, und das ist gewollt. Jeder Subsystem-Verantwortliche entscheidet für seinen Bereich.
Torvalds selbst hat sich zuletzt eher pragmatisch geäußert und die enorm gewachsenen Merge-Fenster unter anderem auf KI-Werkzeuge in den Händen der Entwickler zurückgeführt — ohne daraus ein Verbot abzuleiten. Die gemeinsame Klammer über alle Positionen hinweg ist ein anderer Punkt: Wer einen Patch einreicht, muss ihn erklären und verteidigen können. Kann er das nicht, fliegt der Patch raus — egal, mit welchem Werkzeug er entstanden ist.
Zur Einordnung, damit hier kein falscher Eindruck entsteht: Das ist auch keine reine Kernel-Debatte. Bei Debian läuft parallel eine formale Abstimmung über den Umgang mit LLM-Beiträgen, mit einem völlig anderen Mechanismus — Projektmitglieder stimmen ab, statt dass einzelne Maintainer entscheiden. Zwei Wege, dasselbe Grundproblem.
WAS DAS FÜR DICH BEDEUTET
Für deinen Server ändert sich heute nichts. Kein Update, keine Handlung nötig. Interessant ist die Entwicklung trotzdem, und zwar aus zwei Gründen.
Erstens: Wenn du selbst Beiträge zu Open-Source-Projekten leistest — und sei es nur eine Dokumentations-Korrektur — dann gilt inzwischen fast überall dieselbe Erwartung. Erkläre, was dein Patch tut und warum. Ein „hab ich generieren lassen, sieht gut aus“ reicht nicht mehr.
Zweitens: Der Staging-Bereich war für viele der Einstieg in die Kernel-Entwicklung. Wenn diese Tür für Menschen enger wird, weil Maschinen sie verstopfen, ist das ein Nachwuchsproblem mit langem Nachhall. Kroah-Hartmans Regel ist genau der Versuch, diese Tür offen zu halten.
FAZIT
Das ist keine Anti-KI-Geste, auch wenn sich das leicht so lesen lässt. Es ist eine Kapazitätsentscheidung: Prüfzeit von Menschen ist die knappste Ressource im Kernel, und sie wird jetzt priorisiert. Ob dieser Weg trägt, wird man in ein paar Monaten sehen — an der Zahl der neuen Beitragenden, nicht an der Zahl der Patches.
Häufige Fragen
Was genau ist der Staging-Bereich im Linux-Kernel?
drivers/staging ist ein Zwischenlager für Treiber, die noch nicht die Qualitätsanforderungen des Hauptbaums erfüllen. Weil dort viele kleine, klar umrissene Aufräumarbeiten anfallen, gilt der Bereich traditionell als Einstiegspunkt für neue Kernel-Entwickler — genau diese Lernfunktion sieht Greg Kroah-Hartman durch automatisch erzeugte Patches gefährdet.