Start/Praxis/Tipps/Linux-Kernel formalisiert Regeln für AI-Coding-Assistenten
10. April 2026

Der Linux-Kernel hat mit Documentation/process/coding-assistants.rst ein offizielles Dokument in den Hauptzweig aufgenommen, das regelt, wie AI-Coding-Assistenten bei Kernel-Beiträgen verwendet werden dürfen. Das ist bemerkenswert: Das größte und älteste Open-Source-Projekt der Welt, dessen Maintainer-Kultur lange als zurückhaltend gegenüber AI-Tools galt, zieht erstmals eine formale Linie. Das Dokument ist mit rund 60 Zeilen bewusst knapp gehalten und liest sich mehr wie eine Ergänzung zum bestehenden Entwicklungsprozess als wie ein separates Regelwerk. Genau darin liegt seine Stärke -- und der Grund, warum andere Projekte es als Vorlage nutzen können.

Was die Richtlinien regeln

Der Kernel-Prozess bleibt der Maßstab. Der erste Satz des Dokuments ordnet AI-Assistenz explizit in die bestehende Entwicklungspipeline ein: "AI tools helping with Linux kernel development should follow the standard kernel development process." Verwiesen wird auf drei etablierte Dokumente: development-process.rst, coding-style.rst und submitting-patches.rst. Damit wird klargestellt, dass AI-generierter Code denselben Qualitätsanforderungen unterliegt wie handgeschriebener -- keine Sonderbehandlung, weder nach oben noch nach unten.

Lizenzrechtlich gibt es keine Ausnahmen. Alle Beiträge müssen GPL-2.0-only-kompatibel sein, SPDX-Identifier sind Pflicht, und es gelten die bestehenden Lizenzregeln. Das adressiert implizit die größte offene Frage bei AI-Code: ob Modelle, die auf nicht-GPL-kompatiblem Code trainiert wurden, überhaupt GPL-kompatible Outputs liefern können. Die Antwort des Kernels ist pragmatisch: Die Verantwortung für die Lizenzkonformität liegt beim menschlichen Submitter, nicht beim Tool.

Disclosure-Pflicht

Der zentrale praktische Punkt ist die Einführung eines neuen Commit-Trailers: Assisted-by. Das Format ist exakt definiert:

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Konkret bedeutet das: Der Name des Tools, die exakte Modellversion und optional spezialisierte Analyse-Tools, die dabei im Einsatz waren. Das Beispiel aus dem Dokument lautet Assisted-by: Claude:claude-3-opus coccinelle sparse. Wichtig ist die Abgrenzung zu gewöhnlichen Entwickler-Werkzeugen -- "Basic development tools (git, gcc, make, editors) should not be listed." Es geht also nicht um eine lückenlose Werkzeugliste, sondern um die Kennzeichnung derjenigen Tools, die inhaltlich am Code mitgewirkt haben.

Die Formulierung ist bewusst maschinenlesbar. Ein git log --grep="Assisted-by" reicht, um den AI-Anteil im Kernel über die Zeit zu tracken. Das ist kein Zufall: Der Kernel will die "evolving role of AI in the development process" messbar machen, nicht nur beschreiben.

Verantwortung bleibt beim Menschen

Der kompromissloseste Abschnitt betrifft das Signed-off-by-Tag und die Developer Certificate of Origin (DCO). Der Kernel formuliert es in Großbuchstaben: "AI agents MUST NOT add Signed-off-by tags." Die Begründung ist juristisch sauber -- nur Menschen können die DCO-Zusicherung rechtlich abgeben. Ein AI-Agent kann nicht versichern, dass er den Code unter offener Lizenz einreichen darf, weil er kein Rechtssubjekt ist.

Der menschliche Submitter ist laut Dokument verantwortlich für:

Das ist die eigentliche Kernbotschaft: Ein Assisted-by-Trailer ist keine Haftungsauslagerung. Wer einen Patch einreicht, haftet weiterhin persönlich, auch wenn ein Modell 90 Prozent des Codes geschrieben hat. AI wird als Werkzeug behandelt, nicht als Co-Autor mit eigener Rechtsstellung.

Was das für andere Projekte bedeutet

Das Linux-Dokument ist kurz genug, um als Vorlage zu dienen. Für Teams, die eigene AI-Policies formulieren wollen, lassen sich vier Bausteine übernehmen:

  1. Disclosure-Format festlegen. Ein einheitlicher Commit-Trailer (Assisted-by, AI-Assisted-By, Co-Generated-By) schafft Nachvollziehbarkeit ohne Prosa in jeder Commit-Message. Wichtig ist die Pflicht zur Modellversion -- ohne sie ist das Tracking wertlos, weil "ChatGPT" in einem Jahr ein anderes Modell bezeichnet als heute.
  2. Haftung explizit beim Menschen verankern. Die Trennung zwischen Assisted-by (Maschine) und Signed-off-by (Mensch) ist das eleganteste Modell, das bisher vorliegt. Es ermöglicht Transparenz, ohne Verantwortung zu verwässern.
  3. Keine Sonderqualitätsstandards. AI-Code darf nicht leichter durch Code-Review rutschen, aber auch nicht strenger geprüft werden als menschlicher Code. Beides führt zu perversen Anreizen -- entweder zum Ausblenden der Herkunft oder zum Zurückhalten legitimer Tools.
  4. Triviale Tools ausklammern. Die Faustregel des Kernels -- Editoren, Compiler, Build-Tools nicht listen -- vermeidet Disclosure-Inflation. Was einen Copilot-Autocomplete-Snippet von einer IDE-Autocomplete-Funktion unterscheidet, bleibt eine Grauzone, die Teams intern definieren müssen.

Ein praktischer Vorschlag für interne Policies: Die Grenze bei "inhaltlich generierter Code" ziehen. Wer Autocomplete-Varianten durchklickt, muss nichts kennzeichnen. Wer ganze Funktionen, Tests oder Refactorings vom Modell vorschlagen lässt, setzt den Trailer.

Einordnung

Das Dokument ist kein Dammbruch, sondern eine formale Anerkennung eines Status quo. AI-Assistenten werden im Kernel-Umfeld längst verwendet -- die Frage war nur, wie damit umzugehen ist. Dass die Antwort so nüchtern ausfällt, ist das eigentliche Signal: Der Kernel behandelt AI nicht als existenzielle Bedrohung, aber auch nicht als Heilsbringer. Es ist ein weiteres Werkzeug, das Spuren hinterlässt, und diese Spuren sollen dokumentiert werden.

Die Knappheit des Dokuments hat zudem einen strategischen Vorteil. Je länger eine Policy ist, desto schneller veraltet sie. Ein Regelwerk, das sich auf Disclosure, DCO-Zuweisung und Lizenzkonformität beschränkt, bleibt auch dann gültig, wenn sich die Tool-Landschaft in zwei Jahren komplett verschoben hat. Für Open-Source-Projekte und Unternehmen, die noch keine eigene Richtlinie haben, ist das der wahrscheinlich schnellste Weg zu einer belastbaren Policy: das Linux-Dokument nehmen, GPL-2.0-only durch die eigene Lizenz ersetzen und den Rest so lassen.

Quellen

Nach oben