Der Linux-Kernel gilt als eines der am strengsten organisierten Softwareprojekte der Welt: Jeder Patch, also jede einzelne Codeänderung, durchläuft ein öffentliches Review durch sogenannte Maintainer, die für einzelne Teilbereiche verantwortlich sind. Umso aufmerksamer wird verfolgt, wie dieses Projekt mit KI-unterstützter Programmierung umgeht.

Aktuell zeichnet sich dort eine Entscheidung ab, die auf den ersten Blick überrascht: Die Kennzeichnung für Beiträge, die mit Hilfe von KI-Werkzeugen entstanden sind, soll wieder entfallen. Der dafür vorgesehene Tag Assisted-by – eine Zeile in der Commit-Beschreibung, die den Einsatz eines Hilfsmittels dokumentiert – wird nach Einschätzung der Maintainer schlicht zu selten gesetzt.

Eine Kennzeichnung, die kaum jemand nutzt

Das Argument ist pragmatisch. Eine Markierung, die nur ein kleiner Teil der Einreichenden verwendet, erzeugt kein verlässliches Bild. Im Gegenteil: Sie kann in die Irre führen. Wer den Tag setzt, erscheint als Sonderfall, obwohl der Einsatz von Assistenzwerkzeugen längst verbreitet sein dürfte. Wer ihn weglässt, fällt nicht auf. Eine Datenlage, aus der sich Schlüsse über Qualität oder Herkunft von Code ziehen ließen, entsteht so nicht.

Hinzu kommt ein Abgrenzungsproblem, das sich mit jeder Werkzeuggeneration verschärft. Wo beginnt KI-Unterstützung? Bei der vollständig generierten Funktion? Bei der Autovervollständigung im Editor? Bei der Suche nach einer passenden Kernel-API in einem Chat-Fenster? Je tiefer Sprachmodelle in alltägliche Entwicklungsumgebungen einziehen, desto schwerer lässt sich eine Trennlinie ziehen, die sich sauber in einer einzigen Metadatenzeile abbilden ließe.

Auch Torvalds arbeitet mit Sprachmodellen

Dass selbst Linus Torvalds, der Initiator und bis heute zentrale Verantwortliche des Kernels, inzwischen mit großen Sprachmodellen (LLMs) arbeitet, unterstreicht diese Entwicklung. Der Einsatz solcher Werkzeuge ist in professionellen Entwicklungsteams kein Randphänomen mehr und auch kein Indikator für mangelnde Erfahrung.

Damit verliert die Frage „Wurde hier KI eingesetzt?“ an Trennschärfe. Interessanter wird die Frage, die in Projekten wie dem Kernel ohnehin im Mittelpunkt steht: Ist die Änderung korrekt, verständlich, wartbar – und steht jemand mit Namen dafür ein?

Verantwortung bleibt bei den Menschen

Genau hier liegt der entscheidende Punkt für die Praxis. Der Kernel-Prozess kennt seit Langem Signaturzeilen, mit denen Entwickelnde und Maintainer die Verantwortung für eine Änderung übernehmen. Diese Verantwortung verschiebt sich nicht, nur weil ein Modell beim Formulieren geholfen hat. Wer einen Patch einreicht, haftet fachlich für das Ergebnis – unabhängig davon, welches Werkzeug am Anfang stand.

Für Unternehmen lässt sich daraus eine nüchterne Haltung ableiten: Nicht die Herkunft einer Codezeile entscheidet über ihre Qualität, sondern das Verfahren, das sie passieren muss. Ein Review, das KI-generierten Code zuverlässig prüft, prüft auch handgeschriebenen Code zuverlässig. Ein Review, das nur auf Plausibilität schaut, wird in beiden Fällen Fehler durchlassen – bei KI-Code allerdings mit höherer Wahrscheinlichkeit, weil generierte Abschnitte oft sprachlich sauber wirken und dadurch weniger Misstrauen wecken.

Was in Projekten jetzt sinnvoll ist

Aus dem Kernel-Beispiel lassen sich einige Ableitungen für die eigene Organisation ziehen, ohne dessen Entscheidung eins zu eins zu übernehmen:

  • Reviewtiefe statt Herkunftsetikett: Prüfen Sie, ob Ihre Code-Reviews tatsächlich Logik, Randfälle und Sicherheitsaspekte abdecken – oder vorrangig Formalien.
  • Automatisierte Absicherung ausbauen: Tests, statische Analyse und Abhängigkeitsprüfungen wirken unabhängig davon, wer oder was den Code geschrieben hat.
  • Verantwortlichkeiten klären: Legen Sie fest, wer eine Änderung fachlich verantwortet und freigibt. Diese Rolle lässt sich nicht an ein Werkzeug delegieren.
  • Lizenz- und Rechtsfragen separat behandeln: Fragen zu Urheberrecht und Lizenzkonformität lassen sich nicht über eine freiwillige Kennzeichnung lösen, sondern über verbindliche Regeln im Entwicklungsprozess.
  • Kennzeichnung nur dort, wo sie Konsequenzen hat: Eine Markierung, die niemand auswertet und die niemand einfordert, erzeugt Aufwand ohne Nutzen.

Kennzeichnung ist kein Selbstzweck

Die Debatte im Kernel-Umfeld zeigt, dass gut gemeinte Transparenzregeln scheitern können, wenn sie freiwillig sind und der gekennzeichnete Zustand zum Normalfall wird. Das spricht nicht grundsätzlich gegen Dokumentation von KI-Einsatz – wohl aber dafür, sie an konkrete Zwecke zu koppeln: an Audits, an regulatorische Anforderungen, an Nachvollziehbarkeit in sicherheitskritischen Bereichen. Wo ein solcher Zweck fehlt, bleibt vor allem zusätzlicher Prozessballast.

Für Web- und Softwareprojekte heißt das: Der Nachweis von Qualität verlagert sich weiter weg von der Frage nach dem Werkzeug und hin zu belastbaren Prüfprozessen. Wer heute in Tests, Reviewkultur und klare Verantwortlichkeiten investiert, ist gegen die nächste Werkzeuggeneration besser abgesichert als mit jeder Kennzeichnungspflicht. Und in Ausschreibungen oder Abnahmen lohnt es sich, nicht nach dem KI-Anteil zu fragen, sondern danach, wie eine Änderung geprüft wurde und wer sie verantwortet.

Quellen