Warum KI-Coding-Assistenten lieber flicken als neu bauen – und wie Sie gegensteuern

Ein Bug wird gemeldet: Ein Rabatt-Berechnungsmodul liefert bei einer bestimmten Kombination aus Kundentyp und Produktkategorie ein falsches Ergebnis. Sie öffnen einen KI-Coding-Assistenten, beschreiben den Fehler, und Sekunden später kommt der Fix – eine zusätzliche if-Bedingung, sauber eingerückt, mit einem Kommentar, der den Sonderfall erklärt. Der Test wird grün. Das Problem ist gelöst. Was niemand sieht: Es ist bereits die sechste solche Sonderfall-Bedingung in dieser Funktion, und die eigentliche Ursache – eine Rabattlogik, die nie für die heutige Zahl an Kundentypen konzipiert wurde – bleibt unangetastet. Der Assistent hat nicht gelogen und nichts falsch gemacht im engeren Sinne. Er hat exakt das getan, worum er gebeten wurde: den Bug beheben. Nur eben nicht das, was die Situation eigentlich gebraucht hätte.

1. Das Phänomen: Patch statt Struktur

Das Beispiel oben ist kein Einzelfall, sondern ein Muster, das sich in praktisch jedem Team wiederholt, das KI-Assistenten wie Claude, GitHub Copilot oder Codex im Alltag einsetzt. Es zeigt sich immer nach demselben Schema: Eine Funktion wird über Monate mit einzelnen if-Zweigen, zusätzlichen Parametern und kleinen Sonderfall-Behandlungen erweitert. Jede einzelne Änderung ist für sich betrachtet vernünftig und minimal-invasiv. In Summe entsteht daraus aber eine Funktion, die niemand mehr vollständig überblickt – ein Flickenteppich, bei dem die zehnte Änderung riskanter ist als die erste, weil die Wechselwirkungen zwischen den Sonderfällen nicht mehr überschaubar sind.

Dazu kommt ein zweites, eng verwandtes Muster: Statt eine bestehende Funktion wiederzuverwenden oder zu einer gemeinsamen Abstraktion zu erweitern, wird an drei verschiedenen Stellen im Code fast derselbe Block kopiert und leicht angepasst. Das Ergebnis funktioniert – bis jemand die Geschäftsregel ändert und nur zwei der drei Kopien aktualisiert. Beide Muster haben denselben Kern: Der Assistent wählt die kleinste Änderung, die das aktuelle Problem löst, nicht die Änderung, die das System langfristig einfacher macht.

2. Was die Daten zeigen: die GitClear-Studie

Dass es sich dabei nicht um einen Eindruck aus Einzelbeobachtungen handelt, sondern um einen messbaren Trend, zeigt die Studie «AI Copilot Code Quality: 2025 Look Back» von GitClear. Die Analyse wertete 211 Millionen geänderte Code-Zeilen aus Repositories von Google, Microsoft, Meta und weiteren Enterprise-Firmen im Zeitraum Januar 2020 bis Dezember 2024 aus – also über den Zeitraum, in dem KI-Coding-Assistenten von einer Nischenerscheinung zum Standardwerkzeug wurden.

Zwei Kennzahlen aus dieser Studie zeichnen ein klares Bild:

Zur Einordnung: Laut Stack Overflow Developer Survey 2024 nutzten bereits 63 % der professionellen Entwickler KI im Entwicklungsprozess, weitere 14 % planten den Einsatz. Die KI-gestützte Codeerstellung ist damit kein Randphänomen mehr, sondern in den analysierten Codebasen ein Haupttreiber von Codeänderungen. Die Kernaussage der GitClear-Studie ist entsprechend deutlich: DRY (Don't Repeat Yourself), modulare und periodisch aktiv gepflegte Systeme sind die Grundlage für langfristige Entwicklungsgeschwindigkeit – und genau diese Praxis scheint seit dem breiten Einsatz von KI-Assistenten zu erodieren. Weniger Refactoring bedeutet, dass Struktur seltener aktiv verbessert wird. Mehr geklonter Code bedeutet, dass Wissen und Logik sich unkontrolliert im System verteilen, statt an einer Stelle gepflegt zu werden.

3. Warum LLMs strukturell zum Patchen neigen

Das Muster lässt sich direkt aus der Funktionsweise heutiger Sprachmodelle erklären. Drei Punkte sind dabei zentral:

Optimierung auf die kleinste plausible Antwort

Ein KI-Coding-Assistent beantwortet eine konkrete Anfrage innerhalb eines Prompt-Fensters. Er optimiert dabei auf die kleinste Änderung, die die gestellte Aufgabe plausibel löst – nicht auf die langfristige Architekturqualität des Gesamtsystems. Das ist keine Fehlfunktion, sondern die logische Konsequenz davon, wie diese Anfrage gestellt und bewertet wird: «Behebe diesen Bug» hat als Erfolgskriterium einen grünen Test, nicht eine sauberere Codebasis.

Der Weg des geringsten Widerstands

Ohne explizite Anweisung zur Struktur wählt ein Modell die lokale Anpassung statt der globalen Umstrukturierung. Das ist auch ökonomisch nachvollziehbar aus Sicht des Modells: Ein Rewrite verlangt mehr Kontext (mehr Dateien lesen, mehr Abhängigkeiten verstehen), mehr Testaufwand und trägt pro Antwort ein höheres Risiko, etwas kaputt zu machen. Eine einzelne zusätzliche Bedingung ist demgegenüber risikoarm und schnell verifizierbar – der Pfad des geringsten Widerstands.

Kein intrinsischer Anreiz für Wartbarkeit

Ein Modell wägt nicht von sich aus langfristige Wartbarkeit gegen kurzfristige Korrektheit ab. Diese Abwägung ist keine Eigenschaft, die im Modell «eingebaut» ist – sie ist Aufgabe des Menschen, der den Prompt formuliert, und des Teams, das den Code danach reviewt. Wer nur nach einem Bugfix fragt, bekommt einen Bugfix. Wer Struktur will, muss Struktur explizit verlangen.

4. Die Folgekosten: technische Schuld, die sich unbemerkt aufbaut

Der einzelne Patch kostet praktisch nichts – das ist genau das Tückische daran. Die Kosten entstehen kumulativ und werden erst sichtbar, wenn die Funktion so unübersichtlich geworden ist, dass jede weitere Änderung überproportional lange dauert und überproportional oft neue Fehler einführt. Genau das beschreibt die GitClear-Studie strukturell: Sinkendes Refactoring plus steigende Code-Duplikation ist die Definition wachsender technischer Schuld, gemessen an echten Produktionsdaten.

Für Schweizer KMU ist dieser Effekt besonders schmerzhaft, weil die Wartungskapazität in kleinen Teams naturgemäss knapp ist. Ein Konzern kann eine unübersichtliche Codebasis mit zusätzlichen Spezialisten kompensieren; ein KMU-Team mit zwei oder drei Entwicklern hat diesen Puffer nicht. Jede Stunde, die für das Verstehen einer über Jahre gepatchten Funktion aufgewendet wird, fehlt für neue Funktionen. Und weil KI-Assistenten das Tempo der Codeerstellung insgesamt erhöhen, wächst auch die Menge an potenziell unstrukturiertem Code schneller als früher – die technische Schuld baut sich nicht langsamer auf, sondern eher schneller, wenn niemand aktiv gegensteuert.

5. Gegenmassnahmen: wie Teams aktiv gegensteuern

Die gute Nachricht: Das Patch-Muster ist kein Naturgesetz der KI-Nutzung, sondern eine Standardeinstellung, die sich mit klaren Vorgaben ändern lässt. Vier Ansatzpunkte haben sich in der Praxis bewährt.

Explizite Prompt-Strategie: «Rewrite statt Patch» aktiv verlangen

Bei struktureller Unordnung reicht «behebe den Bug» nicht aus. Wirksamer ist eine Anfrage, die das Modell explizit zur Bewertung der Struktur zwingt, bevor es patcht:

Behebe den Bug in [Funktion/Datei]. Bevor du den Fix schreibst:
1. Prüfe, ob die bestehende Struktur der Funktion den Fehler bereits mehrfach
   begünstigt hat (z. B. durch Sonderfall-Anhäufung, Duplikate).
2. Falls ja: Schlage eine saubere Restrukturierung statt eines weiteren
   Sonderfalls vor, inkl. kurzer Begründung, was sich dadurch vereinfacht.
3. Setze den Fix erst nach dieser Einschätzung um – patche nicht automatisch
   auf die minimalste Lösung.

Diese Umformulierung verändert nicht, was das Modell kann, sondern was es explizit bewerten muss – und macht den «Weg des geringsten Widerstands» aus Abschnitt 3 zu einer bewussten statt einer impliziten Entscheidung.

Review-Disziplin: gezielt nach Mustern suchen, nicht nur nach Bugs

Ein klassisches Code-Review prüft primär, ob eine Änderung funktioniert. Für das Patch-Problem braucht es eine zusätzliche Linse: eine Checkliste, die gezielt nach Duplikaten, Workarounds und Sonderfall-Anhäufungen sucht, unabhängig davon, ob der Code technisch korrekt ist. Konkrete Prüffragen dafür:

• Wurde ein bestehender Codeblock kopiert statt wiederverwendet oder extrahiert?
• Wächst eine Funktion mit dieser Änderung um einen weiteren if-Sonderfall, statt die zugrundeliegende Logik zu vereinheitlichen?
• Löst der Fix die Ursache – oder nur das an der Oberfläche sichtbare Symptom?
• Ist diese Änderung die dritte oder vierte ähnliche Anpassung an derselben Stelle in den letzten Monaten? Falls ja: Ist der Zeitpunkt für ein Refactoring erreicht?

Diese Fragen gehören in dieselbe Kategorie wie ein strukturierter Prüfprozess für Prompt-Qualität – dazu passt der Ansatz aus Prompt-Qualität messen und testen: eine wiederholbare Prüfmethode statt Bauchgefühl, nur eben angewendet auf die Struktur des generierten Codes statt auf die Textqualität einer Antwort.

Architektur-Leitplanken vorgeben

Wiederkehrende Strukturprinzipien sollten nicht bei jeder Anfrage neu formuliert werden müssen, sondern in einer projektweiten Konfigurationsdatei stehen, die der Assistent bei jeder Session automatisch liest – etwa in einer CLAUDE.md, AGENTS.md oder einem entsprechenden Systemprompt. Sinnvolle Leitplanken darin:

• «Keine Codeduplikate: Wiederverwendbare Logik wird in eine gemeinsame Funktion extrahiert, nicht kopiert.»
• «Bei mehr als zwei ähnlichen Sonderfall-Bedingungen in einer Funktion: Struktur-Alternative vorschlagen statt weiterem if-Zweig.»
• «Klare Modulgrenzen einhalten – neue Logik gehört in die dafür vorgesehene Schicht, nicht dorthin, wo der Bugfix am schnellsten geht.»

Diese Leitplanken wirken bei jeder Anfrage automatisch mit, ohne dass jedes Teammitglied sie manuell in jeden Prompt schreiben muss – ein einmaliger Aufwand mit dauerhafter Wirkung, ähnlich wie eine gepflegte Prompt-Bibliothek für wiederkehrende Textaufgaben.

Bewusste Entscheidungspunkte: wann Rewrite, wann Patch

Nicht jede Unordnung rechtfertigt einen Rewrite – hier hilft eine pragmatische Kosten-Nutzen-Abwägung statt eines pauschalen Prinzips:

Der letzte Fall ist wichtig: Unter echtem Zeitdruck ist ein schneller Patch oft die richtige Entscheidung. Entscheidend ist, dass er als bewusste, befristete Massnahme markiert wird – und nicht stillschweigend zum Dauerzustand wird, weil niemand die Folgeaufgabe einträgt.

6. Fazit und Checkliste

KI-Coding-Assistenten sind darauf optimiert, die gestellte Aufgabe mit minimalem Aufwand und minimalem Risiko zu lösen – nicht darauf, ein System langfristig einfach zu halten. Das ist keine Schwäche, die mit dem nächsten Modell-Update verschwindet, sondern eine strukturelle Eigenschaft, wie diese Werkzeuge pro Anfrage arbeiten. Die von GitClear gemessene Entwicklung – Refactoring-Anteil von 25 % auf unter 10 %, Klon-Anteil von 8,3 % auf 12,3 % – zeigt, dass sich dieses Muster branchenweit in echten Codebasen niederschlägt, wenn niemand aktiv gegensteuert.

Die Gegenmassnahme liegt nicht beim Modell, sondern beim Team: klare Prompts, die Struktur explizit einfordern, Review-Disziplin mit einem Blick für Duplikate und Sonderfälle, projektweite Architektur-Leitplanken und eine bewusste Rewrite-versus-Patch-Entscheidung statt einer automatischen Standardwahl. Für Schweizer KMU mit knapper Wartungskapazität lohnt sich dieses Gegensteuern überproportional: Wer früh Struktur einfordert, zahlt später deutlich weniger Wartungszeit.

• Verlangen Sie bei struktureller Unordnung explizit «Rewrite statt Patch» – nicht nur «behebe den Bug».
• Prüfen Sie im Review gezielt auf Duplikate, Sonderfall-Anhäufungen und Symptom- statt Ursachenfixes.
• Hinterlegen Sie Architektur-Leitplanken (DRY, klare Modulgrenzen) einmalig in CLAUDE.md/AGENTS.md, statt sie bei jedem Prompt neu zu schreiben.
• Entscheiden Sie bewusst zwischen Patch und Rewrite – und markieren Sie Notfall-Patches klar als befristet, nicht als Dauerzustand.

Wer diesen strukturierten Umgang mit KI-Coding-Assistenten im Team verankern will – von der Prompt-Strategie bis zur Review-Checkliste – findet dafür ein passendes Format in den Angeboten von CuonzTech ThinkLab. Ergänzend lohnt sich ein Blick in Top 5 Fehler im Prompt Engineering und in KI-Agenten in der Praxis, wenn KI-Assistenten bei Ihnen bereits über einzelne Prompts hinaus mit Werkzeugzugriff arbeiten.