// Tools & Entwicklung 16.10.2026 · 13:18 Uhr 6 Min. Lesezeit

Linux-Kernel-Projekt will KI-Hinweis in Commit-Nachrichten streichen

Mindverse News

KI-gestützt erstellt 3 Quellen Originalmeldung: heise.de Arbeitsweise

KI-generierte Illustration: Linux-Kernel-Projekt will KI-Hinweis in Commit-Nachrichten streichen — KI-generierte Illustration

Das Wichtigste in Kürze

Eine Mehrheit der Teilnehmenden des Maintainers Summit sprach sich dafür aus, den Assisted-by-Hinweis in Commit-Nachrichten abzuschaffen. [1] [2]
Sasha Levin begründet den Schritt damit, dass nur rund zehn Prozent von 18.533 untersuchten Commits den Tag trugen und fehlende Hinweise kaum nachverfolgt wurden. [1] [2]
Der Änderungsvorschlag liegt im Dokumentationszweig docs-next, ist aber noch nicht in den Mainline-Kernel übernommen. [1]
Angaben zum KI-Einsatz sollen weiterhin möglich sein, künftig jedoch im Begleitschreiben zu einem Patch statt standardisiert in der Commit-Nachricht. [1] [2]
Die persönliche Verantwortung für eingereichten Code bleibt bestehen; KI-Agenten dürfen keine Signed-off-by-Zeile setzen. [1] [2]

// Inhalt · 8 Abschnitte

Mehrheit für das Ende des standardisierten Tags
Eine erst kurz zuvor eingeführte Regel
Warum Levin die Kennzeichnung für wenig aussagekräftig hält
Transparenz soll in die Begleitmail wechseln
Die Codeverantwortung bleibt bei den Beitragenden
Torvalds nutzt ein Sprachmodell für Kernel-Arbeit
Was Unternehmen aus der Regeländerung ableiten können
Der entscheidende nächste Schritt steht noch aus
Quellen

Mehrheit für das Ende des standardisierten Tags

Die Linux-Kernel-Entwicklung steuert auf eine Änderung ihrer Regeln für KI-unterstützte Beiträge zu: Der standardisierte Assisted-by-Hinweis soll aus Commit-Nachrichten verschwinden. Dafür sprach sich eine Mehrheit der rund 30 eingeladenen Entwicklerinnen und Entwickler beim Maintainers Summit am 8. Oktober in Prag aus. Einstimmig war das Votum nicht. [1] [2]

Beschlossen und umgesetzt ist die Änderung damit noch nicht. Sasha Levin, Nvidia-Entwickler und Co-Maintainer der Stable- und LTS-Kernel, reichte am 9. Oktober einen Patch ein, der die Vorgabe aus der Kernel-Dokumentation entfernen soll. Der zuständige Maintainer Jonathan Corbet hat den Vorschlag in den Entwicklungszweig docs-next übernommen. In den Mainline-Kernel ist er zum Stand des Berichts noch nicht gelangt. Linus Torvalds und Greg Kroah-Hartman unterstützen die Änderung; auf der Mailingliste gibt es zugleich unterschiedliche Einschätzungen. [1]

Summit-Votum: Mehrheit für die Streichung, aber keine Einstimmigkeit. [1] [2]
Vorschlag: Patch zur Änderung der Dokumentation eingereicht und in docs-next aufgenommen. [1]
Status: Übernahme in den Mainline-Kernel steht noch aus. [1]

Eine erst kurz zuvor eingeführte Regel

Die geplante Streichung folgt auf eine vergleichsweise junge Richtlinie. Seit Linux 7.0 bittet das Dokument AI Coding Assistants Entwicklerinnen und Entwickler darum, einen Assisted-by-Tag in der Commit-Nachricht zu verwenden, wenn ein fortgeschrittenes Coding-Werkzeug wie ein Large Language Model an der Arbeit beteiligt war. Die Richtlinie ging auf einen Konsens beim Maintainers Summit 2025 zurück; Jonathan Corbet billigte den entsprechenden Vorschlag im Januar 2026. [1]

Der Tag sollte einen Hinweis darauf geben, dass ein Patch mit KI-Unterstützung entstanden ist. Er war damit als Metadatum gedacht, das die Entstehung eines Beitrags sichtbarer macht, nicht als technische Bewertung des Codes. Ein erster Vorschlag, diese Kennzeichnung abzuschaffen, war im Juli noch gescheitert. Damals hatte sich auch Kroah-Hartman für ihre Beibehaltung ausgesprochen; inzwischen unterstützt er den neuen Anlauf. [1] [2]

Warum Levin die Kennzeichnung für wenig aussagekräftig hält

Levin stützt seine Begründung auf die Verbreitung des Tags in der Kernel-Entwicklung. In einer Auswertung von 18.533 regulären Commits zwischen Linux 7.3 und dem Release Candidate 7 trugen demnach rund zehn Prozent einen Assisted-by-Hinweis; Merge-Commits waren in der Zählung nicht enthalten. Nach Levins Einschätzung ist der tatsächliche Einsatz von KI-Werkzeugen deutlich verbreiteter. [1] [2]

Als Gründe nennt Levin, dass manche Entwickler die Vorgabe nicht kennen, andere sie bewusst auslassen und Maintainer nur selten nach einem fehlenden Hinweis fragen. Das Fehlen des Tags lässt deshalb nach seiner Argumentation keinen verlässlichen Rückschluss darauf zu, ob KI beteiligt war. Umgekehrt könne ein gesetzter Tag bei Personen, die KI bei fast allen Beiträgen nutzen, ebenfalls wenig darüber aussagen, welche konkrete Arbeit das Werkzeug übernommen hat. [1]

Die Zahlen sind dabei als Begründung des Patch-Autors zu verstehen, nicht als unabhängige Erhebung des gesamten KI-Einsatzes im Kernel-Projekt. Die verfügbaren Berichte nennen die Quote der markierten Commits, liefern aber keine separate Messung, wie viele Beiträge tatsächlich mit KI erstellt oder verändert wurden. Aus dem Verhältnis von markierten zu unmarkierten Commits lässt sich daher keine belastbare Quote KI-unterstützten Codes ableiten. [1] [2]

Transparenz soll in die Begleitmail wechseln

Der Vorschlag zielt nach den vorliegenden Berichten nicht darauf, jede Offenlegung des KI-Einsatzes zu unterbinden. Statt eines knappen und standardisierten Tags in der Commit-Nachricht sollen Entwicklerinnen und Entwickler gegebenenfalls im Cover-Letter erläutern, wie sie KI-Werkzeuge beim Erstellen eines Patches oder einer Patch-Serie eingesetzt haben. [1] [2]

Das Begleitschreiben bietet nach Levins Argumentation mehr Raum, den konkreten Beitrag eines Werkzeugs zu beschreiben. Ein einzelnes Tag kann zwar eine Beteiligung signalisieren, aber nicht erklären, ob ein Modell etwa Code vorgeschlagen, Tests erstellt oder bei der Prüfung geholfen hat. Die mögliche Verlagerung schafft damit mehr Platz für Kontext, macht die Information aber weniger einheitlich und weniger direkt aus der Commit-Nachricht ablesbar. Letzteres ist eine Folge der beschriebenen Änderung, keine bereits nachgewiesene Wirkung. [1]

Für die praktische Nachvollziehbarkeit ist entscheidend, dass die neue Dokumentationsfassung noch nicht in Mainline übernommen wurde. Bis dahin beschreibt der Patch einen geplanten Wechsel; er belegt nicht, dass die bisherige Regel bereits ersetzt ist. [1]

Die Codeverantwortung bleibt bei den Beitragenden

Die geplante Änderung betrifft die Kennzeichnung des Werkzeugeinsatzes, nicht die Verantwortlichkeit für einen eingereichten Patch. Wer Code zur Aufnahme in den Kernel beiträgt, bleibt für diesen Beitrag verantwortlich. Unverändert gilt auch, dass KI-Agenten keine Signed-off-by-Zeile setzen dürfen. [1] [2]

Die Signed-off-by-Angabe ist im Kernel-Prozess mit dem Developer Certificate of Origin verbunden. Sie steht für die Erklärung der beitragenden Person zu ihrem Patch; die Quellen betonen, dass diese Verantwortung unabhängig davon gilt, ob Code von Hand oder mithilfe eines Sprachmodells entstanden ist. Die Streichung des Assisted-by-Tags ist daher nicht mit einer Freigabe ungeprüfter KI-Ausgaben gleichzusetzen. [2]

Für Unternehmen, die Änderungen aus dem Upstream-Kernel übernehmen oder eigene Beiträge einreichen, ist diese Trennung relevant: Ein Hinweis auf eingesetzte Werkzeuge ersetzt weder technische Prüfung noch die Zuordnung menschlicher Verantwortung. Das ist eine praktische Schlussfolgerung aus den unveränderten Verantwortungsregeln, keine zusätzliche Vorschrift des Kernel-Projekts. [1] [2]

Torvalds nutzt ein Sprachmodell für Kernel-Arbeit

Linus Torvalds lehnt zusätzliche Regeln für KI-Werkzeuge grundsätzlich skeptisch ab. In der Mailingliste vertrat er die Auffassung, dass entscheidend sei, ob Entwicklerinnen und Entwickler verstehen, was sie tun; ein Verbot bestimmter Werkzeuge hält er dafür nicht für den maßgeblichen Maßstab. [1] [5]

Ein konkretes Beispiel findet sich in einem Kernel-Commit, den Torvalds nahezu zeitgleich mit dem Summit veröffentlichte. In der Commit-Nachricht schrieb er, dass unter seiner Anleitung Claude Code am Code, an Testprogrammen, an der Prüfung für eine Liste bekannter Probleme und am ersten Entwurf des Textes beteiligt war. Die Patches sollen das Lesen aus dem Page-Cache beschleunigen, wenn viele Threads gleichzeitig kleine Blöcke derselben Datei lesen. [1]

Das Beispiel dokumentiert den Einsatz eines LLM durch einen prominenten Maintainer, belegt aber für sich genommen weder die Qualität des Verfahrens in anderen Projekten noch die allgemeinen Auswirkungen KI-gestützter Beiträge. Es zeigt vielmehr, dass die Debatte im Kernel-Projekt nicht nur abstrakt über mögliche Werkzeuge geführt wird: Die Frage ist auch, wie deren Einsatz beschrieben wird und wer das Ergebnis verantwortet. [1]

Was Unternehmen aus der Regeländerung ableiten können

Für Organisationen, die den Linux-Kernel einsetzen, ist der unmittelbarste mögliche Effekt ein Verlust an standardisierter Sichtbarkeit in der Git-Historie. Wird der Assisted-by-Tag tatsächlich aus den Commit-Nachrichten entfernt, lässt sich dort künftig nicht mehr zuverlässig anhand eines einheitlichen Feldes erkennen, welche Änderungen mit KI-Unterstützung entstanden sind. Bereits heute war der Hinweis nach Levins Darstellung unvollständig; der Unterschied liegt darin, dass ein formal vorgesehener Marker wegfallen könnte. [1]

Wer für interne Prüfungen oder die eigene Software-Lieferkette nachvollziehen muss, wie Code entstanden ist, sollte den Upstream-Tag deshalb nicht als alleinige Provenienzquelle behandeln. Diese Einordnung folgt aus der von Levin beschriebenen geringen Abdeckung und der geplanten Verlagerung von Erläuterungen in Patch-Begleittexte. Die Berichte sagen nicht, dass Unternehmen auf eigene Dokumentations- oder Prüfverfahren verzichten sollen. [1] [2]

Für Beiträge aus Unternehmen kann das Cover-Letter-Modell zugleich mehr Kontext ermöglichen: Ein Team könnte dort spezifischer beschreiben, wofür ein Werkzeug eingesetzt wurde, anstatt nur seine Beteiligung zu markieren. Ob diese Angaben in der Praxis regelmäßig und ausreichend detailliert gemacht werden, ist offen. Die Quellen enthalten keine Angaben zu einer verbindlichen Mindesttiefe oder zu einer technischen Erfassung des KI-Einsatzes. [1]

Die Änderung wäre daher vor allem eine Verschiebung im Umgang mit Herkunftsinformationen: weg von einem standardisierten Hinweis in der Commit-Nachricht, hin zu einer möglichen erläuternden Angabe im Begleitschreiben. Für Unternehmen bedeutet das analytisch, dass die Informationsqualität stärker davon abhängen könnte, ob Beitragende den Einsatz freiwillig und konkret dokumentieren. Ob diese Abwägung die Transparenz insgesamt verbessert oder verringert, bleibt umstritten. [1] [2]

Der entscheidende nächste Schritt steht noch aus

Für eine abschließende Bewertung sind zwei Punkte auseinanderzuhalten: die politische Verständigung auf dem Maintainers Summit und die formale Umsetzung im Kernel-Projekt. Die Mehrheit hat sich für die Streichung ausgesprochen, und der Dokumentations-Patch liegt in docs-next. Solange er nicht in Mainline übernommen ist, bleibt die Änderung jedoch ein Vorschlag im Umsetzungsprozess. [1]

Auch danach wäre die praktische Wirkung nicht allein daran zu messen, ob der Tag aus Commit-Nachrichten verschwindet. Relevant wäre ebenso, ob Cover-Letter tatsächlich nachvollziehbare Angaben enthalten und ob die Verantwortlichkeit für eingereichte Beiträge wie bisher klar bleibt. Die verfügbaren Quellen belegen die beabsichtigte Verlagerung und die fortbestehende Verantwortung, aber noch keine Ergebnisse einer geänderten Praxis. [1] [2]