AI Coding macht Code schneller. Diese Fehler dürfen Sie jetzt nicht machen

Einfach gesagt: AI Coding verschiebt aktuell den Schwerpunkt in der Softwareentwicklung massiv. Code lässt sich schneller erzeugen und verändern. Dadurch wird gutes Software Engineering aber nicht weniger relevant, im Gegenteilt. AI Coding verändert Softwareentwicklung nicht einfach, weil Maschinen plötzlich programmieren können, sondern weil es viel niedrigschwelliger geworden ist. Damit verschiebt sich der bisherige Engpass. Die eigentliche Herausforderung ist nicht mehr, Code zu produzieren, sondern zu entscheiden, welcher Code in ein System gehört, wie er strukturiert sein sollte und ob wir ihn in sechs Monaten noch verändern wollen. Aus unserer Sicht macht AI deshalb gutes Software Engineering nicht überflüssig: Sie macht es wichtiger. 

Der Engpass verschiebt sich 

Wer heute mit guten Coding Agents arbeitet, merkt schnell, wie stark sich der eigene Arbeitsmodus verändert. Ein Feature, für das früher erst mehrere Dateien durchsucht, bestehende Patterns nachvollzogen und anschließend Code geschrieben werden musste, kann ein Agent in kurzer Zeit implementieren. Das ist eine enorme Zeitersparnis, aber noch kein Beleg dafür, dass im gleichen Maß bessere Software entsteht. 

Eine 2026 in Empirical Software Engineering veröffentlichte Untersuchung von Borg und Kolleg:innen beobachtete bei AI unterstützter Entwicklung eine mediane Reduktion der Bearbeitungszeit um 30,7 Prozent. Klingt erstmal beeindruckend. Beim späteren Weiterentwickeln des entstandenen Codes zeigte sich dagegen kein statistisch signifikanter Unterschied bei Zeit oder Codequalität. Die Studie macht damit eine wichtige Unterscheidung sichtbar. Schnellere Implementierung und bessere Wartbarkeit sind nicht dasselbe. Zur Studie 

Noch deutlicher wird diese Verschiebung in einer Untersuchung von Demirer, Musolff und Yang mit Daten von mehr als 100.000 GitHub Entwickler:innen. Neuere Generationen von Coding Tools erhöhten die Coding Aktivität erheblich. Je näher die Messung allerdings an tatsächlich veröffentlichten Releases lag, desto kleiner wurde der Effekt. Mehr erzeugter Code übersetzt sich also nicht eins zu eins in mehr ausgelieferte Software. Zum NBER Working Paper 

Genau das halte ich für einen der wichtigsten Punkte in der aktuellen Diskussion. Wir sollten Produktivität nicht mit Codeproduktion verwechseln. 

Erste Fehlannahme: Funktionierender Code ist guter Code 

AI-Systeme sind sehr gut darin geworden, eine klar beschriebene Aufgabe in funktionierenden Code zu übersetzen. Genau darin liegt aber auch eine Gefahr für die Bewertung ihrer Ergebnisse. 

Grüne Tests beantworten zunächst eine enge Frage. Tut die Software gerade das, was wir von ihr erwarten? 

Für ein langlebiges System kommen jedoch diverse weitere Fragen hinzu. Passt die Lösung zur bestehenden Architektur? Entstehen neue Abhängigkeiten? Wird bestehende Logik wiederverwendet oder noch einmal implementiert? Ist klar, welche Komponente welche Verantwortung trägt? Lässt sich die nächste Änderung lokal umsetzen oder zieht sie Anpassungen durch mehrere Teile des Systems nach sich? 

Nehmen wir zwei AI generierte Lösungen für dasselbe Feature. Beide bestehen alle Tests. Die erste integriert sich in bestehende Komponenten und hält Verantwortlichkeiten klar getrennt. Die zweite enthält zusätzliche Sonderlogik, dupliziert bestehendes Verhalten und koppelt mehrere Module stärker miteinander. Beide Lösungen funktionieren, beim nächsten Feature bilden sie aber zwei vollkommen unterschiedliche Ausgangssituationen. 

Das ist für mich der entscheidende Unterschied zwischen Codegenerierung und Software Engineering. Code muss nicht nur entstehen. Er muss in einem System leben können. 

Zweite Fehlannahme: Sauberer Code ist für Coding Agents unnötig  

Man könnte argumentieren, dass Wartbarkeit an Bedeutung verliert, sobald Agents selbst große Teile zukünftiger Änderungen übernehmen. Wenn die AI den unübersichtlichen Code später ebenfalls lesen kann, warum sollten wir noch viel Energie in saubere Strukturen investieren? 

Die ersten empirischen Ergebnisse sprechen gegen diese einfache Schlussfolgerung. 

Trivedi und Schmitt verglichen 2026 in einer kontrollierten Studie funktional identische, aber unterschiedlich saubere Varianten derselben Codebasen. Über 660 Versuche hinweg änderte sich die Erfolgsquote des untersuchten Coding Agents kaum. Auf sauberem Code benötigte er allerdings rund 7 bis 8 Prozent weniger Tokens und griff 34 Prozent seltener erneut auf bereits besuchte Dateien zu. Bei Aufgaben über mehrere Module hinweg war der Unterschied noch ausgeprägter. Zum Preprint 

Das finde ich besonders interessant, weil sich dadurch die wirtschaftliche Bedeutung von Codequalität erweitert. 

Klare Strukturen helfen nicht mehr nur Menschen dabei, ein System zu verstehen. Sie helfen auch Agents dabei, effizient durch eine Codebasis zu navigieren. Architektur, Modulgrenzen und konsistente Konventionen werden damit zu einem Teil der technischen Infrastruktur für AI gestützte Entwicklung. 

Ein Agent kann sich auch durch schlechten Code arbeiten. Die Frage ist, wie viel Kontext, Rechenaufwand und Iteration er dafür benötigt. 

Dritte Fehlannahme: Bessere Modelle lösen Architektur ab 

Eine weitere verbreitete Annahme lautet, dass wir diese Probleme einfach mit der nächsten Modellgeneration lösen werden. Modelle werden besser, also werden sie irgendwann automatisch gute Architektur erzeugen. 

Möglich ist das. Darauf verlassen würde ich mich heute noch nicht. 

Zhu, Tsantalis und Rigby untersuchten 2026 Code Smells und Architekturprobleme in LLM und Agent generierter Software. Ihr Preprint kommt zu einem unbequemen Ergebnis. Funktional korrekter Code war nicht automatisch strukturell besser. Bei komplexeren Systemen beobachteten die Forschenden unter anderem stärkere Kopplung, redundante Implementierungen und problematische Verantwortungsverteilungen. Auch detailliertere Prompts beseitigten diese Effekte nicht zuverlässig. Zur Studie 

Der Befund passt zu einem grundsätzlichen Problem. Architektur ist keine rein syntaktische Eigenschaft von Code. Eine gute Architektur hängt davon ab, welche Änderungen wir für wahrscheinlich halten, welche fachlichen Grenzen stabil sind, welche Sicherheitsanforderungen gelten und welche Kompromisse wir bewusst eingehen. Ein Agent sieht davon nur das, was im Code, im Kontext und in seinen Instruktionen verfügbar ist. 

Je mehr Implementierungsarbeit wir an AI delegieren, desto wichtiger wird deshalb die Frage, welche technischen Entscheidungen wir bewusst vorgeben. 

Vierte Fehlannahme: Mehr generierter Code bedeutet weniger Verantwortung 

Der gefährlichste Umgang mit AI Coding ist aus unserer Sicht, den zusätzlichen Output einfach als Produktivitätsgewinn zu verbuchen. 

Wenn ein Team doppelt so viel Code produzieren kann, hat es zunächst einmal doppelt so viel Code, der potenziell verstanden, getestet, reviewed, betrieben und später verändert werden muss. Das ist erstmal kein Problem.  

Kleine, klar abgegrenzte Änderungen können durch AI erheblich günstiger werden. Automatisierte Tests können schnelle Rückmeldung geben. Agents können selbst Reviews, Refactorings und Dokumentation unterstützen. 

Trotzdem verschwindet die Kontrollaufgabe nicht. Sie verschiebt sich. 

Software Engineers werden weniger Zeit darauf verwenden müssen, jede einzelne Implementierung selbst zu schreiben. Dafür steigt der Wert der Fähigkeiten, die Richtung vorgeben. Gute Engineers erkennen, wann eine lokal elegante Lösung global die falsche ist. Sie entscheiden, welche Abstraktion sinnvoll ist. Sie wissen, wann zusätzlicher Code das Problem löst und wann er nur die Oberfläche vergrößert. 

Diese Entscheidungen werden durch schnellere Codegenerierung nicht weniger relevant. Sondern ganz im Gegenteil, diese Entscheidungen haben heute bereits stark an Bedeutung gewonnen. 

Was Unternehmen bei AI Coding anders messen müssen 

Wenn Unternehmen AI Coding einführen, darf der Erfolg deshalb nicht primär an erzeugten Codezeilen, Commits oder der Geschwindigkeit einzelner Tickets gemessen werden. 

Interessanter sind Fragen, die näher an der eigentlichen Software liegen. 

Wie schnell gelangen Änderungen zuverlässig in Produktion? Wie häufig müssen AI generierte Lösungen im Review grundlegend überarbeitet werden? Entstehen neue Abhängigkeiten oder redundante Implementierungen? Wie gut können andere Entwickler:innen den Code später verändern? Werden Agents in der bestehenden Codebasis mit der Zeit effizienter oder benötigen sie immer mehr Kontext? 

Damit verändert sich auch die Rolle technischer Leitplanken. 

Klare Architekturprinzipien, automatisierte Tests, kleine Pull Requests, statische Analysen und verbindliche Reviews sind keine Relikte aus einer Zeit vor AI. Sie schaffen den Rahmen, in dem AI Coding sinnvoll skalieren kann. 

Nicht jedes Projekt braucht denselben Qualitätsanspruch 

Zugleich wäre es genauso falsch, jeden AI generierten Prototypen nach Enterprise Maßstäben zu bewerten. 

Wenn eine Anwendung für einen kurzfristigen Versuch gebaut wird, kann Geschwindigkeit wichtiger sein als perfekte Wartbarkeit. Bei einem einmaligen Skript ist zusätzliche Architektur schnell Overengineering. 

Anders sieht es bei Software aus, die mehrere Jahre betrieben und regelmäßig erweitert werden soll. Dort wird jede unnötige Kopplung irgendwann zur Rechnung. Je häufiger sich ein System verändert, desto stärker zahlt sich eine verständliche Struktur aus. 

Die entscheidende Frage ist deshalb nicht, ob AI Coding guten oder schlechten Code produziert. Sie lautet, welcher Qualitätsanspruch für dieses System angemessen ist und wie wir sicherstellen, dass Agents ihn tatsächlich einhalten. 

Je leichter Code entsteht, desto wichtiger wird es, guten Code nicht mit viel Code zu verwechseln. Das wird auch in einer sich rasant verändernden Zeit so bleiben. Wie sich KI-gestützte Softwareentwicklung in den kommenden Monaten und Jahren entwickeln wird, können selbst Expert:innen und Brancheninsider heute nur mutmaßen. 

Was bedeutet AI Coding für Ihre Entwicklungsorganisation? 

AI Coding sinnvoll einzuführen heißt nicht nur, Entwickler:innen ein neues Tool bereitzustellen. Codebasis, Architektur und Entwicklungsprozess bestimmen mit, wie viel Nutzen daraus langfristig entsteht. Wenn Sie einordnen möchten, welche technischen Leitplanken Ihre Teams für AI gestützte Entwicklung brauchen, sprechen Sie mit uns. Gemeinsam schauen wir auf Ihre bestehende Entwicklungsorganisation und darauf, wo AI Coding tatsächlich einen Unterschied macht. 

Über den Autor: Als ISB der the consulting GmbH fokussiert sich Benedict Blümel auf die sichere und zugleich performante Implementierung von KI-Lösungen in mittelständischen Unternehmen.