Softwarearchitektur im AI-Zeitalter: Was trotz Codegenerierung explizit bleiben muss

Wenn das Schreiben von Code billiger wird, verliert die Frage „wie implementieren wir das?“ an Gewicht – und die Frage „wie schneiden wir das?“ gewinnt. Architektur war nie unwichtig, aber sie war lange durch den Implementierungsaufwand geschützt: Wer eine falsche Struktur wählte, merkte es, weil es weh tat. Dieser Schutz fällt weg.

1. Die verschobene Wertschöpfung

Ein Modell erzeugt Code, der zu dem passt, was es sieht. Es erzeugt nicht die Entscheidung, was zusammengehört, wo eine Grenze verläuft und welche Annahme in zwei Jahren teuer wird. Genau diese Entscheidungen bestimmen aber, ob ein System wartbar bleibt.

Hinzu kommt ein zweiter, praktischer Effekt: Alles, was explizit vorliegt, ist zugleich der Kontext, aus dem ein Agent arbeitet. Architekturarbeit zahlt damit doppelt – auf die Wartbarkeit und auf die Qualität dessen, was erzeugt wird.

2. Grenzen sind die erste Entscheidung

Die folgenreichste Architekturentscheidung ist selten die Technologiewahl, sondern der Schnitt: Welche Teile eines Systems dürfen sich gegenseitig kennen? Ein Modell wird ohne Vorgabe den kürzesten Weg wählen – also direkt auf die Datenstruktur zugreifen, die es gerade sieht.

Wirksame Mittel dagegen sind unspektakulär:

• Modulgrenzen, die im Verzeichnisbaum sichtbar sind, nicht nur im Konzept.
• Abhängigkeitsregeln, die geprüft werden – ein Test, der unerlaubte Importe scheitern lässt, ist mehr wert als jedes Diagramm.
• Eine benannte Richtung. Fachlogik kennt Infrastruktur nicht; die Umkehrung ist erlaubt.

3. Verträge statt Absprachen

Überall dort, wo zwei Teile unabhängig entstehen – Frontend und Backend, Dienst und Dienst, System und Fremdsystem –, sollte ein maschinenlesbarer Vertrag stehen: OpenAPI, JSON Schema, ein Ereignisschema. Der Vertrag hat drei Eigenschaften, die eine Absprache nicht hat: Er ist prüfbar, er ist versionierbar, und er ist für Werkzeuge lesbar.

Der Deep Dive OpenAPI als Vertrag behandelt den wichtigsten Einzelfall im Detail, inklusive Contract-Tests und Umgang mit Breaking Changes.

4. Das Datenmodell explizit halten

Das Datenmodell ist der langlebigste Teil eines Systems. Anwendungen werden umgeschrieben, Oberflächen ersetzt, Frameworks gewechselt – die Daten bleiben. Trotzdem entsteht es in vielen Projekten als Nebenprodukt: erst der Code, dann die Tabelle.

Explizit heißt hier konkret:

• Entitäten, Felder und Relationen benannt und dokumentiert,
• Pflichtfelder, Wertebereiche und Validierungsregeln als Teil des Modells, nicht verstreut über Controller,
• Mandanten- und Organisationskontext von Anfang an mitgedacht – nachträglich ist er extrem teuer,
• Historisierung dort, wo Nachvollziehbarkeit gefordert ist.

Ein explizites Modell ist prüfbar, vergleichbar und gegen eine Anforderung stellbar. Eine über zwanzig Klassen verteilte Konvention ist das nicht – weder für Menschen noch für Werkzeuge.

5. Rechte gehören ins Modell

Die häufigste Schwachstelle in generiertem Code ist nicht die Authentifizierung, sondern die feingranulare Autorisierung: Darf diese Person diesen Datensatz sehen oder ändern? Wenn diese Regel nicht modelliert ist, wird sie pro Endpunkt neu erfunden – und irgendwo vergessen.

Belastbar ist eine Struktur, in der Rollen, Berechtigungen und Sichtbarkeitsregeln als eigenständiges Modell existieren und an einer zentralen Stelle durchgesetzt werden. Das ist zugleich der Teil, der sich am besten wiederverwenden lässt – siehe Plattform statt Boilerplate.

6. Entscheidungen dokumentieren

Kurze, datierte Architekturnotizen sind das billigste Werkzeug mit der besten Wirkung. Vier Zeilen genügen: Kontext, Entscheidung, Alternativen, Konsequenzen. Entscheidend ist der Ort – im Repository, neben dem Code, nicht in einem System, das der nächste Werkzeugwechsel abräumt.

# ADR-014: Tenant isolation via row-level scoping

Context     Multi-tenant deployment, shared database, ~40 tenants.
Decision    Every tenant-owned table carries tenant_id; access goes
            through a scoped repository that always applies the filter.
Rejected    Schema-per-tenant (operational cost), database-per-tenant
            (migration cost at this scale).
Consequence No direct repository access outside the scoped layer.
            Enforced by an architecture test.

Solche Notizen beantworten die Frage, die Code nie beantwortet: warum. Sie sind für neue Teammitglieder wertvoll, für Audits nützlich und für Agents der wirksamste Kontext, den man liefern kann.

7. Architekturerosion bei hohem Tempo

Erosion entsteht nicht durch eine große falsche Entscheidung, sondern durch viele kleine Abweichungen, die einzeln vertretbar wirken. Bei höherem Änderungstempo beschleunigt sich dieser Prozess entsprechend.

Drei Gegenmittel, die im Alltag funktionieren:

1. Regeln automatisch prüfen. Abhängigkeitstests, Lint-Regeln für Schichtverstöße, Schema-Prüfungen. Was die Pipeline durchlässt, wird geschehen.
2. Änderungssätze klein halten. Große Diffs verstecken Strukturbrüche zuverlässig.
3. Bewusste Ausnahmen dokumentieren, statt sie stillschweigend zuzulassen – eine notierte Ausnahme ist eine Entscheidung, eine unnotierte ist ein Präzedenzfall.

8. Architektur als Kontext für Agents

Alles bisher Genannte hat einen praktischen Nebeneffekt: Es ist genau das Material, aus dem ein Coding Agent gute Ergebnisse erzeugt. Verträge sagen ihm, was erlaubt ist. Das Datenmodell sagt ihm, wie die Fachlichkeit aussieht. Architekturnotizen sagen ihm, warum bestimmte Wege ausgeschlossen sind. Architekturtests sagen ihm – über die Pipeline – wenn er trotzdem danebenliegt.

Das ist der eigentliche Grund, warum Architekturarbeit im AI-Zeitalter an Wert gewinnt: Sie ist nicht mehr nur Dokumentation für Menschen, sondern Steuerungsinformation für die Werkzeugkette.

Typische Fehler

• Architektur nach der Generierung festlegen wollen – der Code hat dann bereits Fakten geschaffen.
• Diagramme ohne Durchsetzung. Ein Bild, das kein Test prüft, beschreibt einen Wunsch.
• Datenmodell als Nebenprodukt der Implementierung.
• Berechtigungen pro Endpunkt statt als Modell.
• Mandantenfähigkeit vertagen – nachträglich ist sie ein Umbauprojekt.
• Entscheidungen im Chat, nicht im Repository.

Checkliste: Architektur explizit halten

Fazit

Codegenerierung entwertet Architektur nicht – sie legt offen, wie viel Architektur in einem Projekt tatsächlich vorhanden war. Wo Grenzen, Verträge, Datenmodell und Rechte explizit sind, wird ein Agent zu einem sehr schnellen, sehr geduldigen Umsetzer. Wo sie fehlen, erzeugt er schnell viel Code, der später schwer zu ändern ist.

Die Arbeit verschiebt sich damit dorthin, wo sie ohnehin am wertvollsten war: nach vorne, zur Struktur. Das ist keine neue Erkenntnis – aber sie hat selten so unmittelbare praktische Konsequenzen gehabt.