Am 27. August 2026 hat heise developer eine Ausgabe des Formats software-architektur.tv angekündigt, in der Ralf D. Müller mit Kevlin Henney spricht. Das Thema: Wie wirkt sich generative KI – also Modelle, die auf Zuruf Text und Quellcode erzeugen – auf die Softwareentwicklung aus, und inwiefern gewinnen Verständnis und Testing dabei an Bedeutung?

Die Fragestellung trifft einen wunden Punkt vieler laufender Projekte. Der Flaschenhals in der Entwicklung war selten das Tippen. Er lag beim Verstehen des Bestehenden, beim Abstimmen von Anforderungen und beim Absichern von Änderungen. Genau diese Anteile werden durch KI-Assistenz nicht kleiner – im Gegenteil.

Was sich verschiebt, wenn Code billiger wird

Wenn das Erzeugen von Code weniger Zeit kostet, entsteht mehr Code pro Zeiteinheit. Damit wächst auch die Menge an Material, die jemand lesen, einordnen und verantworten muss. Der Aufwand verschwindet also nicht, er wandert nur an eine andere Stelle im Prozess.

Drei Effekte lassen sich in der Praxis beobachten, ohne dass man dafür große Studien bemühen müsste:

  • Review wird zum Nadelöhr. Ein Pull Request – also ein Änderungsvorschlag, der vor dem Zusammenführen geprüft wird – lässt sich in Minuten erzeugen, aber nicht in Minuten seriös durchdenken.
  • Plausibel ist nicht korrekt. Generierter Code sieht in der Regel gut aus. Er folgt vertrauten Mustern, verwendet gängige Bibliotheken und kompiliert. Ob er die fachliche Regel abbildet, die im Kundengespräch besprochen wurde, steht auf einem anderen Blatt.
  • Wissen bleibt seltener im Team. Wer eine Lösung selbst durchdacht hat, kann sie zwei Jahre später erklären. Wer sie übernommen hat, ohne sie zu durchdringen, kann das unter Umständen nicht.

Der Spiegel-Gedanke

Die Formulierung „KI als Spiegel“ im Titel der Sendung deutet auf einen zweiten Aspekt hin: Modelle geben zurück, was ihnen vorgelegt wird. Eine unklare Anforderung führt zu einer Lösung, die die Unklarheit übernimmt und ihr eine saubere Oberfläche gibt. Ein Codebestand ohne Struktur liefert Kontext ohne Struktur.

Für Projektverantwortliche ist das weniger eine technische als eine organisatorische Erkenntnis. Werkzeuge, die schnell Ergebnisse liefern, machen Lücken in der Anforderungsklärung nicht sichtbarer, sondern zunächst unsichtbarer – weil früher ein zäher Umsetzungsprozess als Frühwarnsystem diente. Fragte ein Entwickler nach drei Tagen nach, war das ein Signal. Fällt diese Reibung weg, fehlt auch das Signal.

Warum Testing wieder nach vorn rückt

Tests sind in dieser Konstellation mehr als Qualitätssicherung. Sie sind die präziseste Form, in der sich eine Erwartung an Software formulieren lässt. Ein Test beschreibt, was gelten soll – unabhängig davon, wer oder was die Implementierung geschrieben hat.

Damit ändert sich die Reihenfolge der Prioritäten. Wo eine belastbare Testabdeckung existiert, ist KI-generierter Code vergleichsweise unkritisch: Fehler fallen auf, Änderungen sind rückholbar. Wo sie fehlt, wird jede zusätzliche Codezeile zu einem Stück ungeprüfter Annahme.

Für die Praxis heißt das: Investitionen in Testinfrastruktur, in automatisierte Pipelines und in aussagekräftige Testfälle zahlen sich jetzt stärker aus als vor zwei Jahren. Nicht, weil KI besonders unzuverlässig wäre, sondern weil das Verhältnis von erzeugtem zu geprüftem Code aus dem Gleichgewicht geraten kann.

Was das für die Teamarbeit bedeutet

Auch die Rollenverteilung verändert sich. Wenn weniger Zeit auf das Schreiben entfällt, wird die Fähigkeit wichtiger, fremden Code zu lesen, Architekturentscheidungen zu begründen und Anforderungen zu präzisieren. Das sind Kompetenzen, die sich schlecht abkürzen lassen und die üblicherweise über Jahre entstehen.

Gleichzeitig stellt sich die Frage, wie Berufseinsteigerinnen und Berufseinsteiger diese Erfahrung noch sammeln, wenn die Routineaufgaben, an denen man sie klassisch erwirbt, an ein Werkzeug abgegeben werden. Eine allgemeingültige Antwort darauf gibt es derzeit nicht; es lohnt sich aber, die Frage im eigenen Team bewusst zu stellen, statt sie sich durch die Werkzeugauswahl beantworten zu lassen.

Konkrete Ansatzpunkte

Wer KI-Assistenz produktiv einsetzen will, ohne technische Schulden aufzubauen, kann an mehreren Stellen ansetzen:

  1. Review-Kapazität einplanen. Wenn die Erzeugung schneller wird, muss die Prüfung mitwachsen – personell und zeitlich.
  2. Nachvollziehbarkeit einfordern. Wer einen Änderungsvorschlag einbringt, sollte ihn erklären können, unabhängig von seiner Entstehung.
  3. Testabdeckung vor Beschleunigung. In Bereichen ohne automatisierte Tests zuerst die Absicherung aufbauen, dann das Tempo erhöhen.
  4. Anforderungen schärfen. Je präziser die fachliche Vorgabe, desto weniger Interpretationsspielraum entsteht – bei Menschen wie bei Modellen.
  5. Wartbarkeit messbar machen. Kennzahlen wie Durchlaufzeit von Änderungen oder Fehlerquote nach Deployment zeigen, ob die Beschleunigung trägt oder nur verschiebt.

Einordnung

Für Web- und Softwareprojekte bedeutet das vor allem eines: Der Nutzen generativer KI entscheidet sich nicht am Umfang des erzeugten Codes, sondern an der Fähigkeit einer Organisation, diesen Code zu verstehen und abzusichern. Ein TYPO3-Projekt oder eine individuelle Fachanwendung lebt fünf bis zehn Jahre – in diesem Zeitraum ist nicht die Geschwindigkeit der ersten Umsetzung entscheidend, sondern wie teuer die zwanzigste Änderung wird. Wer heute in Tests, Review-Disziplin und saubere Anforderungsklärung investiert, schafft die Voraussetzung dafür, KI-Werkzeuge später ohne Bauchschmerzen einzusetzen.

Quellen