Das Format software-architektur.tv widmet eine Folge der Frage, wie Software im Zeitalter generativer KI gebaut werden muss. Zu Gast ist Randy Shoup im Gespräch mit Ralf D. Müller. Inhaltlich liegt dazu bislang nur die Ankündigung vor – der Anlass ist aber gut geeignet, um eine Frage zu sortieren, die derzeit in vielen Projekten auf dem Tisch liegt: Was ändert sich tatsächlich, wenn Entwicklungsteams mit KI-Assistenz arbeiten, und was bleibt unverändert?

Der Engpass verschiebt sich

Wenn Codegenerierung schneller wird, verschwindet der Aufwand nicht, er wandert. Er wandert in die Entscheidung darüber, welche Bausteine überhaupt entstehen sollen, wie sie zusammenhängen und wie man später erkennt, ob das Ganze noch funktioniert. Genau das ist Architekturarbeit – und sie lässt sich schlecht delegieren, weil sie fachliche Zusammenhänge, Betriebsrealität und Budget gegeneinander abwägt.

Praktisch heißt das: Teams, die vorher schon saubere Schnitte hatten, profitieren spürbar. Teams, deren Systeme historisch gewachsen und schwach dokumentiert sind, produzieren mit Assistenz vor allem schneller mehr von demselben. Die Werkzeuge verstärken die vorhandene Struktur, sie ersetzen sie nicht.

Review wird wichtiger, nicht unwichtiger

Beim Code-Review – der systematischen Durchsicht von Änderungen durch eine zweite Person – ändert sich der Charakter der Arbeit. Klassisch prüft man vor allem, ob jemand einen Denkfehler gemacht hat. Bei generiertem Code kommt eine zweite Frage dazu: Ist diese Lösung überhaupt die passende für dieses System, oder ist sie nur eine plausible Standardlösung aus einem anderen Kontext?

Generierter Code sieht typischerweise gut aus. Er ist konsistent formatiert, benennt Dinge nachvollziehbar und enthält oft Kommentare. Das erschwert das Review, weil die oberflächlichen Signale für Qualität nicht mehr trennscharf sind. Nützlich sind deshalb Prüffragen, die auf den Kontext zielen:

  • Nutzt die Änderung vorhandene Bausteine des Projekts oder baut sie eine parallele Lösung daneben?
  • Sind Fehlerfälle, Berechtigungen und Grenzwerte tatsächlich behandelt oder nur erwähnt?
  • Passt der Zuschnitt zu den bestehenden Modulgrenzen?
  • Existieren Tests, die den fachlichen Kern prüfen – und nicht nur die generierte Implementierung bestätigen?

Der letzte Punkt ist heikel. Wenn Implementierung und Test aus derselben Quelle stammen, prüfen sie unter Umständen dieselbe Fehlannahme. Tests behalten ihren Wert vor allem dann, wenn sie aus der fachlichen Anforderung abgeleitet sind.

Verantwortung bleibt bei Menschen

Für Auftraggeber ist das der zentrale Punkt: Die Haftung für ein System, seine Datenverarbeitung und seine Sicherheit lässt sich nicht an ein Werkzeug abgeben. Wer eine Änderung freigibt, verantwortet sie – unabhängig davon, wer oder was den ersten Entwurf geschrieben hat. Daraus folgt eine schlichte Regel: Nichts geht in Produktion, das im Team niemand erklären kann.

Das hat Konsequenzen für die Projektplanung. Wenn die Erstellung eines Features schneller geht, das Verstehen und Prüfen aber gleich lange dauert, sinkt die Gesamtdauer weniger stark als erhofft. Realistischer ist die Annahme, dass sich der Anteil der Zeit für Konzeption, Review und Test am Gesamtaufwand erhöht.

Was jetzt an Struktur zahlt

Einige Prinzipien werden durch KI-Unterstützung nicht abgelöst, sondern wichtiger:

  • Klare Grenzen zwischen Modulen. Sie geben sowohl Menschen als auch Werkzeugen einen überschaubaren Kontext.
  • Automatisierte Prüfungen in der Pipeline. Statische Analyse, Abhängigkeits- und Lizenzchecks sowie Sicherheitsscans skalieren mit der Menge an Code, manuelle Sichtprüfung tut das nicht.
  • Dokumentierte Entscheidungen. Kurze Notizen darüber, warum eine Lösung gewählt wurde, sind die einzige Quelle, aus der sich Absicht rekonstruieren lässt.
  • Beobachtbarkeit im Betrieb. Logging und Metriken zeigen, ob eine Änderung sich im echten Lastfall so verhält wie gedacht.

Hinzu kommen organisatorische Fragen, die früh geklärt gehören: Welche Werkzeuge dürfen eingesetzt werden, welche Daten dürfen dabei das Unternehmen verlassen, und wie wird die Herkunft von Code dokumentiert? Diese Punkte gehören in Verträge und in die Definition of Done, also in die verbindliche Liste dessen, was eine Aufgabe als abgeschlossen gelten lässt.

Nicht Werkzeugfrage, sondern Reifefrage

Der Nutzen generativer Werkzeuge korreliert weniger mit dem gewählten Modell als mit der Reife der Entwicklungsumgebung darum herum. Ein Projekt mit reproduzierbaren Builds, aussagekräftigen Tests und einem funktionierenden Review-Prozess kann Vorschläge zügig annehmen oder verwerfen. Ein Projekt ohne diese Grundlagen verliert die Kontrolle über den eigenen Codebestand schneller als vorher.

Für Web- und Softwareprojekte bedeutet das: Investitionen in Teststrategie, Deployment-Automatisierung und dokumentierte Architekturentscheidungen zahlen sich jetzt doppelt aus – sie sichern Wartbarkeit und sie machen KI-Unterstützung überhaupt erst produktiv nutzbar. Wer ein Angebot bewertet, sollte deshalb weniger danach fragen, welche Assistenzwerkzeuge zum Einsatz kommen, und mehr danach, wie Review, Tests und Übergabe geregelt sind. Die Geschwindigkeit einzelner Arbeitsschritte entscheidet selten über den Erfolg eines Projekts; die Frage, ob das System in drei Jahren noch veränderbar ist, dagegen fast immer.

Quellen