Code Smells erkennen und beheben: die zehn, die bei KI-Code am häufigsten auftreten

Ein Code Smell ist eine Stelle im Quelltext, die funktioniert und trotzdem auf ein tieferliegendes Problem hinweist. Der Begriff stammt von Kent Beck und Martin Fowler. Bei KI-generiertem Code treten bestimmte Smells überdurchschnittlich häufig auf, weil das Modell den Ausschnitt sieht, den es ändern soll, aber nicht den Bestand, in den es hineinschreibt.

Was ist ein Code Smell?

Ein Code Smell ist ein Verdachtsmoment, kein Defekt. Der Code läuft, die Tests sind grün, und trotzdem deutet die Struktur darauf hin, dass die nächste Änderung an dieser Stelle unangenehm wird.

Wichtig ist die Abgrenzung: Ein Smell ist keine Regelverletzung, die man automatisch beheben lässt. Manche Smells sind an ihrer Stelle richtig — bewusste Duplikate zwischen zwei Modulen, die sich unabhängig entwickeln sollen, etwa. Ein Werkzeug kann den Verdacht melden; ob er zutrifft, entscheidet, wer den Zusammenhang kennt.

Welche Code Smells treten in KI-generiertem Code am häufigsten auf?

Zehn Muster, geordnet danach, wie teuer sie später werden.

• Duplizierte Logik. Dasselbe Verhalten an mehreren Stellen. Der mit Abstand häufigste und teuerste Smell, und der einzige, dessen Zunahme sich über Jahre messen lässt — siehe technische Schulden durch KI-Code.
• Parallelimplementierung. Eine neue Hilfsfunktion neben der vorhandenen, die dasselbe tut, weil das Modell die vorhandene nicht kannte.
• Überlange Funktion. Generierter Code neigt dazu, den vollständigen Ablauf in eine Funktion zu schreiben, weil das im Prompt so beschrieben war.
• Verschluckter Fehler. Leerer Catch-Block oder ein Standardwert, der einen Fehlschlag wie einen Erfolg aussehen lässt. Seit 2025 eigene OWASP-Kategorie (A10).
• Magische Werte. Zahlen und Zeichenketten direkt im Code, deren Bedeutung nur aus dem Kontext hervorgeht.
• Spekulative Verallgemeinerung. Ein Konfigurationsschalter, eine Schnittstelle, eine Abstraktionsschicht für einen Fall, den es nicht gibt. Modelle bauen gern „für später mit".
• Kommentar statt Klarheit. Ein Kommentar, der beschreibt, was die nächste Zeile tut. Er ersetzt keinen verständlichen Namen und wird beim nächsten Umbau falsch.
• Datenklumpen. Dieselben fünf Parameter wandern durch sechs Funktionen, statt zu einem Objekt zusammengefasst zu sein.
• Ungenutzter Rest. Importe, Variablen, Funktionen aus einem verworfenen Zwischenstand.
• Test ohne Zusicherung. Ein Test, der Code ausführt und nichts prüft. Erzeugt Abdeckung und keine Sicherheit — siehe Codequalität messen.

Wie finde ich Code Smells in meinem Projekt?

Sechs der zehn Muster oben findet ein Werkzeug, für die übrigen vier brauchen Sie einen Menschen. Die Trennung lohnt sich, weil sie Reviewzeit spart.

• Maschinell auffindbar: Duplikate, überlange Funktionen, verschluckte Fehler, magische Werte, ungenutzter Rest, Tests ohne Zusicherung. Das übernimmt die statische Codeanalyse.
• Nur menschlich auffindbar: Parallelimplementierung (setzt Kenntnis des Bestands voraus), spekulative Verallgemeinerung (setzt Kenntnis der Anforderungen voraus), Kommentar statt Klarheit, Datenklumpen.

Genau die vier menschlichen sind die, die bei KI-Code zunehmen — und die, die im Diff am schwersten zu sehen sind, weil die Gegenstelle in einer anderen Datei steht.

Wie behebe ich einen Code Smell, ohne etwas kaputtzumachen?

In vier Schritten, und der erste ist der, der am häufigsten übersprungen wird.

• Erst absichern. Bevor Sie eine Stelle umbauen, muss ein Test existieren, der das aktuelle Verhalten festhält. Ohne diesen Test ist jeder Umbau eine Wette.
• Eine Sache pro Schritt. Duplikat zusammenführen und Funktion aufteilen und Namen ändern ergibt einen Diff, den niemand prüfen kann.
• Verhalten unverändert lassen. Ein Refactoring, das nebenbei einen Fehler behebt, ist kein Refactoring mehr. Fehlerbehebung ist ein eigener Commit.
• Nach jedem Schritt prüfen. Testlauf grün, dann der nächste Schritt.

Wie das konkret bei generiertem Code aussieht, beschreibt der Beitrag Refactoring von KI-generiertem Code.

Lohnt es sich, jeden Smell zu beheben?

Nein — und das ist der wichtigste Satz zum Thema. Ein Smell in Code, der nie wieder angefasst wird, kostet nichts. Der Aufwand, ihn zu beheben, kostet immer.

Die sinnvolle Priorisierung verbindet zwei Größen, die beide aus dem Repository ablesbar sind: Wie oft wurde diese Datei in den letzten Monaten geändert, und wie komplex ist sie? Was oben rechts landet — häufig geändert und komplex — verdient Aufmerksamkeit. Der Rest darf riechen.

Häufige Fragen zu Code Smells

Ist ein Code Smell dasselbe wie ein Bug?

Nein. Ein Bug ist falsches Verhalten. Ein Smell ist richtiges Verhalten in einer Struktur, die künftige Änderungen erschwert. Ein Smell kann jahrelang folgenlos bleiben.

Erkennt eine KI Code Smells zuverlässig?

Bei den maschinell auffindbaren Mustern ja, oft besser als eine Regel-Engine, weil sie den Zusammenhang mitliest. Bei Parallelimplementierungen ist sie unzuverlässig, weil ihr genau der Überblick fehlt, der den Smell erst sichtbar macht — es sei denn, das Werkzeug durchsucht aktiv den Bestand, bevor es schreibt.

Wie viele Zeilen darf eine Funktion haben?

Es gibt keine normierte Grenze, und jede genannte Zahl ist eine Konvention. Belastbarer ist die Frage, ob die Funktion in einem Satz ohne „und" beschreibbar ist. Braucht die Beschreibung ein „und", macht sie zwei Dinge.

Sollte ich Smells beheben, bevor ich ein Feature baue?

Nur dort, wo das Feature hineingebaut wird. Aufräumen im Umfeld der eigenen Änderung ist günstig und wird geprüft, weil es ohnehin im Review liegt. Flächendeckendes Aufräumen als eigenes Vorhaben findet selten einen Auftraggeber.

Die vier Smells, die kein Werkzeug findet, entstehen alle an derselben Stelle: dort, wo niemand nachgesehen hat, was es schon gibt. Code Guardian stellt genau diese Frage vor der ersten Zeile — welche Funktion, welcher Helfer, welche Query existiert bereits?

Quellen

• Martin Fowler, Refactoring (Prägung und Katalog der Code Smells, gemeinsam mit Kent Beck).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research (Copy/Paste-Anteil).
• OWASP Top 10:2025, Kategorie A10 „Mishandling of Exceptional Conditions".

Stand: 27. Juli 2026. Allgemeine fachliche Einordnung.