Wenn AI mehr Code produziert, wird Architektur wichtiger – nicht unwichtiger

AI-gestützte Entwicklung verändert die Ökonomie der Softwareproduktion. Ein Service, ein Adapter, ein Mapper oder eine Testsuite entstehen heute oft deutlich schneller als noch vor wenigen Jahren.

Das ist kein Argument gegen Architektur. Es ist ein Argument dafür, Architektur ernster zu nehmen.

Denn AI senkt nicht nur die Kosten für guten Code. Sie senkt auch die Kosten für Code, der technisch plausibel aussieht, lokal funktioniert und trotzdem nicht in das System passt. Wenn Teams schneller produzieren, können sie auch schneller falsche Abstraktionen einführen, Geschäftslogik duplizieren, Grenzen zwischen Modulen verwischen und neue Varianten bestehender Schnittstellen etablieren.

Die knappe Ressource verschiebt sich damit: Nicht das Schreiben einzelner Zeilen Code begrenzt die Entwicklung, sondern die Fähigkeit, konsistente Entscheidungen über viele Änderungen, Menschen und AI-Interaktionen hinweg durchzusetzen.

Code ist kein Engpass mehr – Kohärenz schon

In vielen bestehenden Systemen war Implementierung nie vollständig der Engpass. Anforderungen verstehen, Entscheidungen abstimmen, Auswirkungen analysieren, Betrieb absichern und Änderungen in eine gewachsene Struktur einordnen kosteten häufig mehr Zeit als die Syntax.

Mit AI wird dieser Unterschied sichtbarer.

Ein Entwickler kann innerhalb weniger Minuten mehrere plausible Implementierungen erzeugen lassen:

• eine neue REST-Route,
• ein Datenmodell,
• eine Validierungsschicht,
• eine Datenbankmigration,
• Integrations- und Unit-Tests,
• einen Client für ein Fremdsystem.

Jede dieser Änderungen kann für sich genommen vernünftig aussehen. Die entscheidende Frage lautet aber nicht: Kann das Modell diesen Code erzeugen? Sie lautet: Soll diese Verantwortung an dieser Stelle im System entstehen?

Ohne klare Antwort produziert ein Team nicht einfach mehr Code. Es produziert mehr Variationen. Zwei Teams modellieren denselben fachlichen Begriff unterschiedlich. Drei Services greifen direkt auf dieselben Daten zu. Ein neuer API-Endpunkt umgeht eine bestehende Domänenschicht, weil der direkte Weg im Prompt nahelag. Für jede Integration entsteht ein eigener Fehlerbehandlungsstil.

Das Ergebnis ist zunächst produktiv wirkende Geschwindigkeit. Die Rechnung kommt später: bei Änderungen, Incident-Analyse, Onboarding, Migrationen und der Frage, welche Regel eigentlich gilt.

AI optimiert lokale Aufgaben, Architektur schützt globale Eigenschaften

Sprachmodelle arbeiten gut mit einer lokal formulierten Aufgabe: „Ergänze einen Endpunkt“, „extrahiere diese Logik“, „schreibe Tests“, „baue einen Kafka-Consumer“. Sie nutzen den Kontext, der ihnen gegeben wird, und erzeugen eine wahrscheinliche Lösung.

Architektur beantwortet dagegen Fragen, die nicht lokal sind:

• Wo liegt die fachliche Quelle der Wahrheit?
• Welches Modul darf einen bestimmten Datensatz verändern?
• Welche Abhängigkeiten sind erlaubt, welche verboten?
• Welche Schnittstelle ist stabil und welche bewusst intern?
• Welche Konsistenzgarantie gibt es über Prozessgrenzen hinweg?
• Wie werden Fehler, Retries, Idempotenz und Berechtigungen behandelt?
• Welche Daten dürfen ein System oder eine AI-gestützte Entwicklungsumgebung überhaupt sehen?

Diese Fragen lassen sich nicht zuverlässig aus einer einzelnen Datei ableiten. Selbst ein Modell mit Zugriff auf ein Repository erkennt nicht automatisch, welche frühere Entscheidung absichtlich getroffen wurde, welche Konvention verbindlich ist oder welcher technische Kompromiss nur temporär sein sollte.

Architektur ist deshalb nicht primär ein Diagramm und auch kein Ordnerlayout. Sie ist die Menge wichtiger, langfristig wirksamer Entscheidungen und Grenzen. Ihr Zweck ist, dass viele lokale Änderungen zusammen ein kohärentes System ergeben.

Je billiger lokale Änderungen werden, desto wertvoller wird diese globale Orientierung.

Billiger Code macht Fehler nicht harmloser

Ein verbreiteter Einwand lautet: Wenn AI Code schnell erzeugt, können wir Fehlentscheidungen doch ebenso schnell korrigieren.

Das stimmt nur für isolierte Fehler.

Eine falsch benannte interne Hilfsmethode ist günstig zu ändern. Eine falsche Architekturentscheidung wird teuer, sobald sie kopiert, integriert und von anderen Komponenten vorausgesetzt wird. AI kann diese Verbreitung sogar beschleunigen.

Nehmen wir eine typische Situation: Für eine neue Funktion wird ein direkter Datenbankzugriff in einem API-Service vorgeschlagen. Das funktioniert, spart zunächst Zeit und ist einfach zu testen. Wenn dieses Muster akzeptiert wird, werden weitere Funktionen wahrscheinlich ähnlich implementiert. Bald gibt es mehrere Schreibpfade auf dieselben Tabellen, unterschiedliche Validierungen und keine eindeutige Stelle mehr für fachliche Regeln.

Der spätere Umbau betrifft dann nicht eine Datei, sondern Verträge zwischen Komponenten, Datenmigrationen, Berechtigungen, Tests, Deployment-Reihenfolgen und Betriebswissen.

Die Kosten einer Entscheidung entstehen also nicht bei ihrer ersten Implementierung. Sie entstehen durch ihre Vervielfältigung.

AI reduziert die Kosten der Vervielfältigung. Genau deshalb müssen Teams früher und klarer entscheiden, welche Muster vervielfältigt werden dürfen.

Architektur muss für Menschen und Werkzeuge konsumierbar sein

Architektur, die nur im Kopf eines Staff Engineers oder in einem zwei Jahre alten Wiki-Dokument existiert, hilft einem AI-unterstützten Team kaum. Die relevanten Regeln müssen dort auffindbar sein, wo Änderungen entstehen: im Repository, in Pull Requests, in Templates und in automatisierten Prüfungen.

Dabei geht es nicht um ein hundertseitiges Architekturhandbuch. Nützlich sind kurze, konkrete und überprüfbare Vorgaben.

Ein gutes Set von Architekturguidelines beantwortet beispielsweise:

• Welche Module besitzen welche fachlichen Konzepte?
• Über welche Ports oder APIs kommunizieren Module?
• Welche Abhängigkeitsrichtung gilt?
• Welche Bibliotheken und Infrastruktur-Clients dürfen in welcher Schicht verwendet werden?
• Wie werden externe Fehler in fachliche Fehler übersetzt?
• Wo liegen Autorisierung, Audit-Logging und PII-Handling?
• Welche Patterns sind Standard, welche ausdrücklich verboten?

Für AI-Coding ist die Form besonders wichtig. Allgemeine Aussagen wie „halte den Code sauber“ oder „achte auf Clean Architecture“ sind kaum operationalisierbar. Besser sind Regeln wie:

Nur das Modul billing darf Rechnungsstatus ändern. Andere Module verwenden den Port BillingService.

HTTP-Handler enthalten keine Geschäftsregeln und greifen nicht direkt auf Repositories zu.

Ereignis-Consumer müssen idempotent sein; der Idempotenzschlüssel wird dauerhaft gespeichert.

Öffentliche Events sind versionierte Verträge. Änderungen sind nur additiv oder über eine neue Event-Version erlaubt.

Solche Aussagen helfen Entwicklern beim Review und liefern einer AI einen brauchbaren Rahmen für die Generierung.

Schnittstellen werden zum wichtigsten Multiplikator

Bei schneller Codeproduktion werden Schnittstellen besonders wertvoll. Sie begrenzen Kopplung und schaffen Wiederverwendung, ohne dass jedes Team den internen Aufbau anderer Komponenten verstehen muss.

Das betrifft nicht nur APIs zwischen Microservices. Schnittstellen existieren auch innerhalb eines Monolithen:

• Modulgrenzen,
• Ports für Datenzugriff oder externe Systeme,
• Domänen-Services,
• Event-Verträge,
• gemeinsame Typen und Fehlersemantik.

Eine gute Schnittstelle ist klein, fachlich benannt und stabil in ihrer Bedeutung. Sie versteckt nicht lediglich Technik hinter einem Interface.

Ein Interface namens CustomerRepository kann sinnvoll sein, wenn es eine klar definierte fachliche Aufgabe erfüllt. Ein generisches BaseRepository<T> mit beliebigen Query-Methoden verschiebt dagegen oft Datenbankwissen in alle Teile des Systems. AI wird solche generischen Muster bereitwillig verwenden und weiter ausbauen, weil sie im lokalen Kontext flexibel wirken. Die langfristige Kopplung bleibt dann unsichtbar.

Der bessere Weg ist meist: wenige explizite Operationen, eindeutige Verantwortlichkeiten und ein Vertrag, der fachliche Absicht ausdrückt.

Invarianten sind wirksamer als Stilregeln

Viele Teams investieren beim AI-Einsatz zuerst in Coding Standards: Formatierung, Namensregeln, Verzeichnisstruktur oder bevorzugte Framework-Patterns. Das ist sinnvoll, aber nicht ausreichend.

Die entscheidenden Regeln sind Invarianten: Eigenschaften, die unabhängig von einer konkreten Implementierung immer gelten müssen.

Beispiele:

• Ein Auftrag kann nur einmal bestätigt werden.
• Geldbeträge werden nie als Floating-Point-Werte gespeichert oder gerechnet.
• Eine Löschung personenbezogener Daten ist nachvollziehbar und propagiert in definierte Folgesysteme.
• Ein Benutzer kann nur Daten seines Mandanten lesen.
• Ein publiziertes Event beschreibt einen bereits persistierten Zustand.
• Jeder externe Schreibvorgang ist bei Retry sicher.

Invarianten geben AI-generiertem Code einen fachlichen und technischen Rahmen. Sie lassen sich außerdem testen, statisch prüfen oder als Contract Test absichern.

Das ist der entscheidende Unterschied zwischen einer Regel, die man hofft einzuhalten, und einer Eigenschaft, die das System aktiv verteidigt.

Architekturentscheidungen brauchen einen kurzen, auffindbaren Kontext

AI verstärkt ein altes Problem: Code erklärt das „Was“, aber selten das „Warum“. Wenn ein Modell eine bestehende Struktur sieht, kann es nicht zuverlässig unterscheiden, ob sie eine bewusste Entscheidung, ein historischer Unfall oder eine Übergangslösung ist.

Dafür brauchen Teams leichte Entscheidungsdokumentation. Architecture Decision Records (ADRs) sind weiterhin ein pragmatisches Mittel, sofern sie kurz bleiben und im Repository liegen.

Ein brauchbarer ADR enthält:

1. den Kontext und die konkrete Entscheidung,
2. die wichtigsten Alternativen,
3. die Konsequenzen und Grenzen,
4. einen Status sowie gegebenenfalls ein Ablaufdatum für Übergangslösungen.

Wichtig ist nicht das Format, sondern die Auffindbarkeit. Ein Entwickler sollte bei einer Änderung erkennen können, warum ein Modul keine direkte Datenbankverbindung erhält oder warum ein bestimmtes Event bewusst nicht synchron verarbeitet wird. Diese Information kann auch in AI-Kontextdateien, Repository-Anweisungen oder PR-Templates referenziert werden.

Technische Führung bedeutet, den Entscheidungsraum zu gestalten

AI ersetzt keine technische Führung. Sie erhöht deren Hebelwirkung.

Technical Leadership heißt in diesem Kontext nicht, jeden Pull Request selbst zu entwerfen. Es heißt, den Raum zu gestalten, in dem viele Menschen und Werkzeuge gute Entscheidungen treffen können:

• Architekturziele und Qualitätsattribute priorisieren,
• zulässige Standards festlegen,
• Ausnahmen sichtbar und zeitlich begrenzt machen,
• kritische Schnittstellen aktiv betreuen,
• Architekturregeln automatisiert prüfen,
• wiederkehrende Entscheidungen in Templates und Referenzimplementierungen überführen.

Ein Team sollte nicht bei jeder Änderung fragen müssen, welche Logging-Bibliothek, welcher Authentifizierungsweg oder welches Retry-Verhalten angemessen ist. Solche Entscheidungen gehören in Plattformen, Bibliotheken, Starter-Kits und überprüfbare Standards.

Damit entsteht produktive Autonomie: Teams können schnell liefern, ohne für jede lokale Aufgabe eine neue technische Grundsatzentscheidung zu treffen.

Was Teams konkret tun können

Für den Einstieg reichen oft fünf Maßnahmen.

1. Die wichtigsten Grenzen explizit machen

Dokumentieren Sie Module, Verantwortlichkeiten, erlaubte Abhängigkeiten und Eigentümerschaft für zentrale Daten. Ein einfaches Kontextdiagramm und eine kurze Modulbeschreibung sind wertvoller als ein vollständiges, aber veraltetes Enterprise-Architekturmodell.

2. Regeln nahe am Code ablegen

Legen Sie konkrete Anweisungen im Repository ab und verlinken Sie auf ADRs, API-Verträge und Beispiele. AI-Werkzeuge erhalten so relevanten Kontext, und neue Teammitglieder finden dieselben Informationen.

3. Invarianten automatisiert absichern

Nutzen Sie Unit-, Integrations-, Contract- und Architekturtests. Prüfen Sie beispielsweise verbotene Paketabhängigkeiten, API-Kompatibilität, Mandantentrennung oder Idempotenz. Was automatisiert geprüft wird, muss nicht bei jedem Review neu erinnert werden.

4. Referenzpfade statt abstrakter Empfehlungen schaffen

Ein gut umgesetztes Beispiel für einen neuen Endpoint, einen Event-Consumer oder eine Datenmigration ist für Menschen und AI oft hilfreicher als eine lange Regelbeschreibung. Referenzimplementierungen sollten klein, aktuell und bewusst gepflegt sein.

5. Reviews auf Entscheidungen fokussieren

Wenn AI Routinecode liefert, sollte Review-Zeit nicht überwiegend in Formatierung oder offensichtliche Boilerplate fließen. Die wichtigen Fragen sind:

• Passt die Änderung in die Verantwortungsgrenze?
• Entsteht ein neuer Vertrag oder wird ein bestehender umgangen?
• Welche Invariante schützt diese Implementierung?
• Was passiert bei Ausfall, Retry und paralleler Verarbeitung?
• Erzeugt die Lösung einen Präzedenzfall, den wir künftig wollen?

Die Architekturaufgabe wird anspruchsvoller, nicht kleiner

AI kann Teams helfen, mehr Optionen schneller zu prüfen und Standardcode effizienter zu erzeugen. Das ist ein realer Produktivitätsgewinn. Aber Geschwindigkeit ohne Leitplanken erhöht die Wahrscheinlichkeit, dass ein System in viele lokal plausible Richtungen wächst.

Die Antwort darauf ist keine zentralistische Architekturpolizei und auch kein Verbot von AI-Coding. Sie ist eine Architektur, die Entscheidungen klar macht, Schnittstellen stabil hält und Invarianten technisch durchsetzt.

Je einfacher es wird, Code zu erzeugen, desto bewusster müssen Teams festlegen, welcher Code entstehen darf. Architektur ist dabei nicht der Gegenpol zu Geschwindigkeit. Sie ist die Voraussetzung dafür, dass Geschwindigkeit über die nächste Lieferung hinaus wertvoll bleibt.