# Clean Code im KI-Zeitalter: welche Prinzipien bleiben und welche sich verschieben *Quelle: https://www.provimedia.de/blog/clean-code-prinzipien-ki-zeitalter · Stand: 2026-07-27* > Wenn eine Maschine den Code schreibt, wird Lesbarkeit nicht unwichtiger, sondern wichtiger. Welche der alten Regeln jetzt zählen. **Clean Code bezeichnet Quelltext, der beim Lesen verständlich ist: sprechende Namen, kleine Einheiten, klare Zuständigkeiten, wenig Wiederholung. Mit KI-Assistenz gewinnt dieses Ziel an Bedeutung statt zu verlieren — denn Code, den niemand liest, weil er generiert wurde, ist genau der Code, der verständlich sein muss, sobald zum ersten Mal etwas schiefgeht.** ## Was ist Clean Code? Der Begriff wurde durch Robert C. Martins gleichnamiges Buch populär und beschreibt eine Haltung, keine Norm: Code wird deutlich öfter gelesen als geschrieben, also ist Lesbarkeit die wichtigste Eigenschaft nach Korrektheit. Daraus folgen die bekannten Regeln — aussagekräftige Namen, kleine Funktionen mit einer Aufgabe, keine überflüssigen Kommentare, keine Wiederholung, Fehler behandeln statt verschlucken. Keine davon ist messbar, und das ist der übliche Einwand. Der Einwand geht am Zweck vorbei: Sie sind Heuristiken für eine Frage, die man nur beim Lesen beantworten kann. ## Gelten Clean-Code-Regeln noch, wenn die KI den Code schreibt? **Sie gelten stärker, weil sich der Adressat verändert hat.** Früher schrieb man lesbar für den Kollegen. Heute schreibt man lesbar für drei Leser, von denen zwei neu sind. - **Der Mensch im Review.** Er hat weniger Zeit pro Zeile, weil mehr Zeilen ankommen. Unklarer Code wird nicht länger geprüft, sondern durchgewinkt. - **Das Modell bei der nächsten Änderung.** Ein Sprachmodell liest Ihren Bestand als Kontext und setzt fort, was es dort vorfindet. Klare Struktur und eindeutige Namen wirken damit doppelt: auf den Menschen und auf die nächste Generierung. - **Der Mensch im Störungsfall.** Um drei Uhr nachts, ohne Zugriff auf den Chatverlauf, in dem der Code entstanden ist. ## Welche Prinzipien werden wichtiger? **Vier, und alle vier adressieren belegte Muster generierten Codes.** - **Keine Wiederholung.** Das wichtigste Prinzip der Gegenwart, weil Duplikate seit dem Einzug der KI-Assistenz messbar zunehmen ([die Zahlen dazu](/blog/technische-schulden-ki-code)). Wo dupliziert wird, ohne dass jemand es bemerkt, ist die Regel keine Stilfrage mehr. - **Explizit vor implizit.** Ein Modell rät bei Mehrdeutigkeit. Eindeutige Typen, klare Signaturen und benannte Konstanten reduzieren, worüber geraten werden kann. - **Fehler behandeln, nicht verschlucken.** Der leere Catch-Block ist ein klassischer Clean-Code-Verstoß und seit 2025 eine eigene OWASP-Kategorie (A10). - **Kleine, prüfbare Einheiten.** Was in einem Zug lesbar ist, wird im Review tatsächlich gelesen. Eine 400-Zeilen-Funktion wird überflogen, unabhängig von der Sorgfalt des Reviewers. ## Welche Prinzipien verschieben sich? **Drei, bei denen die alte Begründung nicht mehr trägt — auch wenn die Regel bleibt.** - **Kommentare.** Die alte Regel lautete: Guter Code braucht keine Kommentare. Das stimmt weiterhin für das Was. Für das *Warum* hat sich das Gewicht verschoben: Bei generiertem Code fehlt die Person, die die Entscheidung erklären könnte. Ein Satz, warum diese Lösung gewählt wurde, ist heute wertvoller als früher. - **Selbstgeschriebene Hilfsfunktionen.** Früher galt: nicht selbst bauen, was es als Bibliothek gibt. Heute kommt eine Abwägung hinzu, denn jede zusätzliche Abhängigkeit ist eine Lieferketten-Entscheidung — seit 2025 eigene OWASP-Kategorie (A03). Für zwanzig Zeilen ein Paket aufzunehmen ist nicht mehr automatisch die sparsamere Wahl. - **Vorzeitige Verallgemeinerung.** Die Regel „baue nicht für Fälle, die es nicht gibt" ist unverändert richtig, wird aber häufiger verletzt: Modelle bauen gern Konfigurationsschalter und Abstraktionsschichten auf Vorrat mit ein. ## Wie setze ich Clean Code durch, wenn viel Code generiert wird? **Nicht über Schulungen, sondern über die drei Stellen, an denen Code entsteht.** - **Vor der Erzeugung:** Projektkonventionen dort hinterlegen, wo das Werkzeug sie liest. Namensschemata, Verzeichnisstruktur, Fehlerbehandlung, vorhandene Hilfsfunktionen. Ein Modell hält sich an Konventionen, die es kennt. - **Nach der Erzeugung:** Was maschinell prüfbar ist, wird maschinell geprüft — Formatierung, Komplexität, Duplikate, tote Importe. Siehe [statische Codeanalyse](/blog/statische-codeanalyse-tools-vergleich). - **Im Review:** Genau die Fragen stellen, die kein Werkzeug beantwortet. Gibt es das schon? Ist der Name richtig? Ist die Entscheidung nachvollziehbar? Siehe [Code Review für KI-Code](/blog/code-review-ki-generierter-code). ## Häufige Fragen zu Clean Code ### Ist Clean Code nicht Geschmackssache? Die konkreten Regeln teilweise ja — Zeilenlänge, Klammersetzung, Namenskonventionen. Der Kern nicht: Ob eine Funktion in einem Satz ohne „und" beschreibbar ist, lässt sich ohne Geschmacksurteil beantworten, und diese eine Frage deckt einen großen Teil der Regeln ab. ### Schreibt KI sauberen Code? Formal oft ja: konsistente Benennung, konventionelle Struktur, Kommentare vorhanden. Strukturell häufig nicht, weil dem Modell der Überblick fehlt — es dupliziert, was es nicht kennt, und verallgemeinert, was niemand gefordert hat. Sauber im Kleinen, unsauber im Ganzen. ### Lohnt sich das Buch von Robert C. Martin noch? Als Denkschule ja; einzelne Beispiele sind gealtert und Teile werden fachlich kontrovers diskutiert. Wer nur eine Sache mitnimmt, sollte es die Frage sein, wie oft dieser Code gelesen werden wird. ### Wie überzeuge ich ein Team, das schnell liefern will? Nicht mit Ästhetik, sondern mit der Reviewzeit. Unklarer Code kostet in jedem Review erneut Zeit, und bei steigendem Codevolumen wird das der Engpass — nicht das Schreiben. > **Konventionen wirken nur, wenn das Werkzeug sie kennt, bevor es schreibt.** [Code Guardian](/code-guardian) arbeitet genau so: erst nachsehen, was es im Projekt schon gibt, dann bauen — und danach ein Audit, das Redundanz im Diff benennt. ## Quellen - Robert C. Martin, *Clean Code* (Prägung des Begriffs und der Regelsammlung). - GitClear, *The Maintainability Gap: 2026 AI Code Quality Research*. - OWASP Top 10:2025, Kategorien A03 und A10. *Stand: 27. Juli 2026. Allgemeine fachliche Einordnung.* --- Kanonische Version: