KI-Coding: Der Export funktioniert. Wer hat die Architektur entschieden?
Der Auftrag klingt klein: „Ergänze einen CSV-Export für die gefilterten Aufträge.“ Ein Coding-Agent setzt ihn um. Der Button erscheint, die Datei lässt sich herunterladen, die Tests laufen durch. Dann öffnest du den Diff und findest einen Worker, eine Queue und einen zusätzlichen Speicher für fertige Exporte.
Nehmen wir diese Änderung als Gedankenbeispiel. Sie wurde hier nicht mit einem Agenten ausgeführt. Sie zeigt eine Frage, die beim Review von AI-assisted Development leicht zwischen funktionierenden Tests und lesbarem Code verschwindet: Welche Entscheidungen über das System sind mitgeliefert worden?
Eine Prüfung der Architektur betrachtet neue Abhängigkeiten, Datenwege, Berechtigungen und Fehlerfälle. Dafür braucht es einen bekannten Ausgangspunkt und Kriterien für die Änderung. Ein präziser Auftrag hilft; die tatsächliche Implementierung bleibt ein eigener Prüfgegenstand.
Aus einer Funktion ist ein Betriebsablauf geworden
Die Umsetzung lässt sich begründen. Ein großer Export kann länger dauern. Ein Hintergrundprozess hält die Webanwendung frei. Ein gespeichertes Ergebnis lässt sich später herunterladen. All das kann für euren Fall sinnvoll sein.
Mit der Lösung kommen aber weitere Fragen ins System. Wo läuft der Worker? Wer erkennt festgefahrene Aufträge? Wie lange bleiben die Dateien liegen? Mit welcher Berechtigung liest der Hintergrundprozess die Daten, und wer darf das fertige Ergebnis herunterladen?
Vielleicht besitzt eure Plattform bereits eine geeignete Verarbeitung für Hintergrundaufgaben. Vielleicht ist eine neue Queue tatsächlich nötig. Um das zu entscheiden, musst du den Vorschlag gegen die vorhandenen Möglichkeiten und Anforderungen prüfen. Die neue Infrastruktur darf eine bewusste Folge dieser Abwägung sein.
Im Diff sind diese Entscheidungen auf mehrere Dateien verteilt: Konfiguration, Bibliotheken, Startskripte und Anwendungscode. Wer nur die Exportfunktion liest, sieht lediglich einen Ausschnitt der Änderung.
Die Forschung beschreibt genau diese Verschiebung
Das Positionspapier „Architecture Without Architects: How AI Coding Agents Shape Software Architecture“ von Konrad und Kollegen untersucht, wie Coding-Agenten Architekturentscheidungen mitprägen. Sein illustratives Beispiel verwendet unterschiedlich formulierte Chatbot-Aufgaben. Daraus lässt sich keine allgemeine Fehlerquote ableiten; auch die Anforderungen unterscheiden sich zwischen den Varianten.
Ein Begriff des Papers ist Prompt-Architecture Coupling: Anforderungen in Prompts und die entstehende Architektur hängen zusammen. Dabei unterscheidet es auch Prompts innerhalb einer LLM-Anwendung von Aufträgen an einen Agenten, der Software erstellt. Unser Exportbeispiel betrifft die zweite Situation. Die Exportanwendung muss dafür selbst kein Sprachmodell enthalten.
Für dein Review ist daran eine konkrete Überlegung hilfreich: Wenn du Arbeit delegierst, können in den Umsetzungsschritten Entscheidungen stecken, die im Auftrag offenblieben. Du musst sie im Ergebnis wiederfinden und beurteilen können.
Der zweite Versuch macht die Architektur sichtbar
Gehen wir einen Fehlerfall durch. Der Worker hat die CSV-Datei geschrieben. Bevor er die Queue-Nachricht bestätigen kann, bricht der Prozess ab. Nach einer Wartezeit wird der Auftrag erneut zugestellt.
Nun reicht die Frage „Kann der Code eine CSV erzeugen?“ nicht mehr aus. Entsteht beim zweiten Lauf eine weitere Datei? Wird ein bereits fertiges Ergebnis überschrieben? Erhält der Nutzer zwei Benachrichtigungen? Falls sich die Quelldaten inzwischen geändert haben, könnten die beiden Dateien sogar unterschiedliche Inhalte besitzen.
Hier wird Idempotenz relevant: Eine Wiederholung desselben Auftrags soll keine unerwünschte zusätzliche Wirkung erzeugen. Dafür muss überhaupt feststehen, was „derselbe Auftrag“ bedeutet. Eine stabile Auftragskennung kann helfen. Zusätzlich braucht ihr eine konsistente Regel dafür, wann das Ergebnis als fertig gilt und wie ein weiterer Versuch damit umgeht.
Auch die fachliche Erwartung gehört dazu. Soll der Export den Datenstand zum Zeitpunkt des Klicks oder zum Zeitpunkt seiner Verarbeitung wiedergeben? Beide Varianten sind möglich. Die Entscheidung beeinflusst, welche Daten gespeichert werden müssen und wie spätere Wiederholungen behandelt werden.
Ein Test für den erfolgreichen Download deckt diesen Fehlerfall nicht automatisch ab. Ihr braucht Prüfungen, die die Wiederholung an der relevanten Stelle auslösen und das vereinbarte Verhalten kontrollieren. Welche davon isoliert und welche mit realen Infrastrukturkomponenten sinnvoll sind, hängt von der Umsetzung ab.
Der nächste Auftrag bekommt einen klareren Rahmen
Vor einer weiteren Umsetzung beschreibst du den relevanten Ausschnitt eures Systems. Welche Hintergrundverarbeitung existiert? Welche Datenquelle ist maßgeblich? Welche Berechtigungen müssen auch beim späteren Download gelten? Welche neuen Betriebsbausteine bedürfen einer eigenen Entscheidung?
Solchen Kontext gezielt bereitzustellen, gehört zum Context Engineering. Für unseren Export kann schon eine kurze, aktuelle Beschreibung helfen: Vorhandene Infrastruktur soll zuerst auf Eignung geprüft werden; zusätzliche Dienste werden als begründeter Vorschlag vorgelegt. Das gewünschte Verhalten bei Wiederholung und die Bedeutung des Datenstands werden ausdrücklich genannt. Wenn eine Vorgabe die Anforderung verhindert, muss dieser Konflikt sichtbar werden.
Architecture Guardrails machen aus einem Teil dieser Vorgaben überprüfbare Grenzen. In einem Java-Projekt kann ArchUnit beispielsweise Abhängigkeiten zwischen Paketen und Klassen prüfen. Eine Regel könnte sicherstellen, dass das Exportmodul nur über eine festgelegte Schnittstelle auf ein anderes Modul zugreift. Das Werkzeug untersucht dafür Java-Bytecode.
Damit ist noch nicht geprüft, ob eine CSV-Datei nach einem Rechteentzug weiterhin abrufbar ist. Dafür braucht es passende Berechtigungsprüfungen und Tests. Auch eine neu angelegte Queue oder ein Speicherdienst verlangt eine Prüfung der Konfiguration und des Betriebs. Jede Kontrolle hat einen erkennbaren Gegenstand und eine Grenze.
So lässt sich Architectural Drift, die schleichende Abweichung von einer vereinbarten Architektur, konkret untersuchen: Welche relevante Beziehung sieht nach der Änderung anders aus? Ist diese Abweichung gewollt und begründet? Dafür genügt es nicht, dass die Vorgabe irgendwo im Repository steht; sie muss mit dem Ergebnis verglichen werden.
Du kannst die mitgelieferten Entscheidungen erklären
Wenn der neue Worker und die Queue tatsächlich die passende Lösung sind, haltet ihr ihre Gründe und Folgelasten als Architekturentscheidung fest. Wenn die vorhandene Infrastruktur reicht, wird der Entwurf entsprechend angepasst. Beides kann ein gutes Ergebnis des Reviews sein.
Die dafür nötige Arbeit an Zusammenhängen und Änderungsfolgen kannst du in THINK FIRST Individual vertiefen. Der Kurs vermittelt die Arbeit mit einem Systemmodell als Grundlage für Entscheidungen. Hier übertragen wir diese Arbeitsweise auf KI-gestützte Entwicklung; ein KI- oder Agententraining ist damit nicht verbunden.
Am Ende steht wieder ein Export. Du kannst jetzt erklären, wo seine Daten herkommen, was bei einem abgebrochenen Versuch geschieht und wer das Ergebnis abrufen darf. Die Tests liefern dafür passende Belege. Für verbleibende Unsicherheiten kennt ihr den nächsten Prüfschritt.
Der Agent hat weiterhin einen großen Teil der Umsetzung übernommen. Welche Architektur ihr damit betreiben wollt, ist inzwischen eine nachvollziehbare Entscheidung geworden.