Architektur als Constraint: den Lösungsraum der AI verkleinern

In vielen Projekten, in denen ich in den vergangenen Jahren gearbeitet habe, fiel irgendwann ein Satz, der in unterschiedlichen Varianten immer dasselbe bedeutete:

„Wir brauchen keinen Architekten.“

Manchmal war damit tatsächlich die Rolle gemeint. Manchmal ging es eher um die Vorstellung, Architektur entstehe ohnehin durch das Team und brauche deshalb keine besondere Aufmerksamkeit. Und häufig funktionierte das zunächst erstaunlich gut. Features wurden umgesetzt, Releases ausgeliefert, technische Entscheidungen dort getroffen, wo sie gerade notwendig waren.

Das Problem zeigte sich selten am nächsten Tag, sondern entstand über Jahre.

Ein Service griff direkt auf etwas zu, das eigentlich hinter einer anderen Grenze lag. Eine Ausnahme war für einen dringenden Use Case nachvollziehbar und wurde später zur Referenz für die nächste Ausnahme. Neben einem bestehenden Pattern entstand ein zweites, dann ein drittes. State bekam mehrere Owner. Features begannen, Interna anderer Features zu verwenden. Neue Entwickler fanden für fast jede strukturelle Entscheidung irgendein bestehendes Beispiel, das sie rechtfertigte.

Irgendwann war nicht mehr klar, welcher Weg eigentlich der gewollte war.

Das ist keine neue Geschichte der AI-Ära. Software Engineering beschäftigt sich seit Jahrzehnten mit Modularisierung, Information Hiding, Cohesion, Coupling, stabilen Schnittstellen, Dependency Direction und klaren Verantwortlichkeiten. David Parnas veröffentlichte seine grundlegende Arbeit zur Modulzerlegung 1972. Stevens, Myers und Constantine beschrieben 1974 in Structured Design Prinzipien zur Reduktion von Komplexität durch funktionale Module. Foote und Yoder gaben Ende der 1990er-Jahre einem besonders weit fortgeschrittenen Gegenbild den Namen Big Ball of Mud.

Coding Agents haben diese Probleme nicht erfunden. Was sich verändert, ist der Durchsatz.

Ein Coding Agent kann Code, Tests, Konfiguration und Dokumentation in einer Geschwindigkeit verändern, die für ein rein menschliches Team kaum erreichbar wäre. OpenAI beschreibt in einem Praxisbericht von Februar 2026 beispielsweise ein internes Projekt, dessen Code vollständig von Codex erzeugt wurde und bei dem ein kleines Team innerhalb weniger Monate ungefähr 1.500 Pull Requests zusammenführte. Diese Zahlen sind kein allgemeiner Produktivitätsbenchmark. Sie zeigen aber, wie stark sich die mögliche Änderungsrate verschieben kann.

Damit wird ein altes Problem plötzlich dringlicher.

Viele Probleme agentischer Softwareentwicklung sind alte Softwareprobleme unter höherem Durchsatz.

Wenn lokale strukturelle Entscheidungen früher zehnmal pro Monat getroffen wurden und künftig hundertmal, verändert sich nicht zwangsläufig ihre Art. Aber inkonsistente Entscheidungen können sich schneller vervielfältigen, schneller zu neuen Vorbildern werden und schneller die Struktur verändern, aus der der nächste Agent wiederum seine Evidenz bezieht.

Genau deshalb interessiert mich Architektur im Zusammenhang mit Agentic Work aus einem sehr spezifischen Grund: nicht, weil „gute Architektur wichtig“ eine besonders neue Erkenntnis wäre, sondern weil:

Architektur reduziert den Entscheidungsraum eines Coding Agents.

Requirements waren nur die erste Grenze

Der vorherige Artikel hat Requirements als Grenze beschrieben. Ein Coding Agent darf unterschiedliche Lösungswege konstruieren, aber nicht jedes Ergebnis ist deshalb akzeptabel.

Requirements beantworten Fragen wie:

Was muss fachlich gelten?

Welche Zustände sind erlaubt?

Was bedeutet Erfolg?

Welche Fehlerfälle müssen behandelt werden?

Was gehört nicht zum Scope?

Damit verkleinern sie den fachlichen Ergebnisraum.

Aber nehmen wir an, all diese Fragen seien perfekt beantwortet. Der Agent weiß exakt, was das Feature am Ende tun muss. Trotzdem bleiben möglicherweise zahlreiche strukturelle Möglichkeiten offen, um dieses Ergebnis zu erreichen.

Genau dort beginnt Architektur.

Requirements begrenzen den fachlichen Ergebnisraum. Architektur begrenzt den strukturellen Lösungsraum.

Vereinfacht:

alle denkbaren Lösungen
↓
Requirements
↓
fachlich zulässige Lösungen
↓
Architecture Constraints
↓
strukturell zulässige Lösungen
↓
kleinerer Entscheidungsraum

Das ist keine Vorstellung davon, dass Architektur eine vollständige Bauanleitung für jeden einzelnen Task liefern sollte.

Ein Agent soll weiterhin lokale Entscheidungen treffen können. Er darf eine Hilfsfunktion anders schneiden, eine Schleife anders formulieren oder innerhalb eines Moduls entscheiden, welche konkrete Implementierung am besten zu dem aktuellen Problem passt.

Architektur definiert vielmehr Entscheidungen, die ich nicht bei jedem Feature erneut treffen möchte.

Darf Presentation direkt auf Infrastructure zugreifen?

Darf Feature A Interna von Feature B importieren?

Wer besitzt einen bestimmten State?

Über welchen Contract darf ein Modul angesprochen werden?

Welche Dependency Direction gilt?

Das sind strukturelle Entscheidungen mit einem deutlich größeren Folgeradius als die Frage, wie eine lokale Funktion implementiert wird.

Gute Architektur nimmt einem Agenten nicht jede Entscheidung ab. Sie nimmt ihm vor allem Entscheidungen ab, die nicht bei jedem Feature neu getroffen werden sollten.

Wenn das Repository sechs richtige Antworten liefert

Betrachten wir eine fachlich einfache Änderung. Eine Komponente benötigt neue Daten.

In einem gewachsenen Repository findet ein Agent vielleicht folgende Varianten:

Component → API

Component → Shared Service → API

Component → Store → API

Component → Feature Service → API

Component → fremdes Feature → API

Component → historisches Utility → API

Das Problem ist nicht zwingend, dass alle sechs Varianten offensichtlich schlecht wären.

Vielleicht existieren sie tatsächlich alle.

Vielleicht funktioniert jede davon irgendwo in Produktion. Vielleicht besitzt jede eine nachvollziehbare Entstehungsgeschichte. Der direkte API-Aufruf stammt aus der Anfangszeit. Später wurde ein Shared Service eingeführt. Ein neues Team verwendete Stores. Ein anderes Feature besitzt einen eigenen Application Service. Für einen dringenden Sonderfall wurde schließlich ein vorhandener Flow aus einem benachbarten Feature wiederverwendet.

Was soll ein Coding Agent daraus lernen?

Ein häufig verwendeter Auftrag lautet:

Folge dem bestehenden Pattern.

Das klingt präzise, solange wir nicht in das Repository schauen. Doch welchem Pattern soll der Agent folgen? Er kann verschiedene Dateien öffnen und für mehrere gegensätzliche Varianten jeweils lokale Evidenz finden. Die Codebase selbst sagt ihm gleichzeitig:

So machen wir es hier.

und:

Nein, so machen wir es hier.

An dieser Stelle ist die Varianz nicht mehr allein eine Eigenschaft des Modells. Das Repository enthält einen mehrdeutigen strukturellen Lösungsraum.

„Folge dem bestehenden Pattern“ funktioniert nur, wenn ein System tatsächlich erkennbare Patterns besitzt.

Ein Agent kann versuchen, aus Häufigkeit, Aktualität, räumlicher Nähe oder Naming abzuleiten, welches Beispiel relevanter ist. Er kann zusätzliche Dokumentation suchen oder weitere Dateien öffnen. Vielleicht trifft er am Ende sogar die richtige Entscheidung.

Aber jede dieser Aktivitäten ist zusätzliche Interpretation.

Die globale Architekturentscheidung wurde nicht vorher getroffen. Also muss der Agent sie während eines lokalen Features rekonstruieren.

Architektur beseitigt unerwünschte Varianz

Nehmen wir stattdessen ein System, in dem für diesen Bereich verbindlich gilt:

Presentation
↓
Application
↓
Domain
↓
Infrastructure

Dieses Layering ist kein universeller Architekturvorschlag. Ein anderes System kann mit vertikalen Slices, Ports and Adapters, einem modularen Monolithen, Self-contained Systems oder einer vollkommen anderen Struktur sinnvoller aufgebaut sein.

Entscheidend ist nicht dieses konkrete Diagramm.

Entscheidend ist, dass die Struktur eine Aussage trifft.

Wenn Presentation keinen direkten Infrastructure-Zugriff besitzen darf, verschwindet eine ganze Klasse struktureller Lösungen aus dem akzeptablen Raum. Wenn ein fachliches Modul ausschließlich über seinen Public Contract angesprochen werden darf, verschwinden weitere Varianten. Wenn State einen eindeutigen Owner besitzt, muss ein Agent nicht bei jedem Feature neu entscheiden, wo eine zweite Wahrheit bequem wäre.

Der Agent bleibt probabilistisch und kann innerhalb der erlaubten Struktur weiterhin unterschiedliche Lösungen produzieren. Genau das ist erwünscht.

Architektur beseitigt Varianz nicht. Sie beseitigt unerwünschte Varianz.

Genau darin liegt für mich eine der wichtigsten Verbindungen zwischen klassischer Softwarearchitektur und agentischer Entwicklung.

Wir versuchen nicht, aus einem Coding Agent einen deterministischen Compiler zu machen. Wir definieren vielmehr, wo Freiheit wertvoll ist und wo sie strukturelles Risiko erzeugt.

Wenige Kanten sind mehr als ein schönes Diagramm

„Modularität“ bleibt schnell abstrakt. Interessanter wird die Frage, wenn wir auf Abhängigkeiten schauen.

Stellen wir uns ein fachliches Modul vor, das eine klar definierte Responsibility besitzt, seinen State selbst kontrolliert, wenige Dependencies benötigt und nur über einen kleinen öffentlichen Contract verwendet werden kann.

Sein struktureller Nachbarschaftsraum ist begrenzt.

Für eine Änderung darin sind möglicherweise fünf Dateien, zwei Contracts und ein externer Adapter relevant. Der Agent kann selbstverständlich trotzdem weitere Bereiche untersuchen. Aber die Architektur liefert bereits eine starke Vermutung darüber, wo relevante Information überhaupt liegen sollte.

Die Intuition ist einfach:

wenige erlaubte Kanten
↓
weniger strukturelle Alternativen
↓
weniger Repository-Bereiche potenziell relevant
↓
kleinerer Entscheidungsraum

Das ist keine mathematische Gesetzmäßigkeit. Ein kleines Modul kann fachlich außerordentlich kompliziert sein. Ein System mit wenigen Dependencies kann schlecht dokumentiert sein. Und geringe Kopplung garantiert weder korrekte Requirements noch korrekten Code.

Aber die Architektur verändert die Anzahl plausibler struktureller Pfade.

Ein stark gekoppelter Bereich besitzt dagegen viele Eingänge und viele Ausgänge. Änderungen können State, Services, Utilities, andere Features und globale Mechanismen berühren. Selbst wenn am Ende nur drei Dateien geändert werden müssen, ist zunächst eine wesentlich größere Umgebung plausibel relevant.

Der Agent muss mehr davon ausschließen.

Gerade für Agentic Work finde ich deshalb Loose Coupling mindestens so interessant wie Modularität als abstraktes Ziel. Geringe Kopplung reduziert nicht nur Change Radius und Koordinationsaufwand für Menschen. Sie begrenzt zugleich die Menge struktureller Beziehungen, über die ein Agent während seiner Exploration nachdenken muss.

Die klassische Forschung hat diese Richtung lange vor LLMs untersucht. Stevens, Myers und Constantine beschrieben bereits 1974 Structured Design als Ansatz, Programmkomplexität durch funktionale Module zu reduzieren und dadurch unter anderem Coding, Debugging und Modifikation zu vereinfachen. Cohesion und Coupling wurden daraus zentrale Begriffe des Software Designs.

Auch hier wäre es ahistorisch zu behaupten, diese Autoren hätten Prinzipien für Coding Agents entwickelt.

Sie entwickelten Prinzipien für Software. Gerade deshalb ist die heutige Beobachtung interessant: Eigenschaften, die Menschen helfen, Systeme lokal zu verstehen und kontrolliert zu verändern, können auch für Agents relevant werden.

SCS als anschauliches Beispiel

Ein Self-contained System ist dafür ein gutes Gedankenmodell.

Die SCS-Architektur beschreibt fachlich geschnittene, weitgehend autonome Systeme, die ihre eigene Datenhaltung und Business Logic besitzen, ihre Funktion möglichst eigenständig erfüllen können und Kopplung zu anderen Bereichen bewusst reduzieren. Gemeinsame Business Logic soll vermieden und synchrone Abhängigkeiten sollen soweit sinnvoll begrenzt werden.

Für unsere Argumentation ist nicht wichtig, ob ein konkretes Projekt tatsächlich SCS verwendet.

Interessant ist die Form der Grenze:

┌───────────────────────────────┐
│          fachlicher Bereich   │
│                               │
│  UI                           │
│  Business Logic               │
│  State / Data                 │
│  technische Adapter           │
│                               │
└───────────────┬───────────────┘
                │
        wenige explizite Contracts
                │
                ▼
         andere Systeme

Ein solcher Bereich bietet einem Agenten intuitiv einen relativ klaren Arbeitsraum. Die fachliche Responsibility besitzt einen Ort. Die Datenhoheit besitzt einen Ort. Externe Beziehungen sind begrenzt und sichtbar.

Ich kenne keine belastbare Studie, die daraus ableiten würde, Self-contained Systems seien wissenschaftlich nachgewiesen „besser für LLMs“. Das wäre eine viel zu starke Behauptung.

SCS ist hier ein Architekturbeispiel für etwas Allgemeineres: lokale Verantwortlichkeit und wenige explizite Kanten.

Dasselbe Prinzip kann innerhalb eines modularen Monolithen ebenso gut gelten.

Der Big Ball of Mud liefert widersprüchliche Evidenz

Das Gegenbild habe ich auf dieser Website bereits ausführlich behandelt: den Big Ball of Mud.

Foote und Yoder beschrieben damit ein System, dessen Struktur nur lose beziehungsweise beiläufig entstanden ist und stärker von kurzfristiger Zweckmäßigkeit als von einem konsistenten Entwurf bestimmt wird. Sie beschreiben unreguliertes Wachstum, wiederholte pragmatische Reparaturen, weitreichend geteilte oder duplizierte Information und eine Struktur, die entweder nie klar war oder über Zeit erodiert ist.

Für Agentic Work interessiert mich daran eine besondere Eigenschaft:

Das Repository selbst wird zu widersprüchlicher Evidenz.

alles kennt alles

viele mögliche Pfade

widersprüchliche Patterns

historische Sonderfälle

unklare Ownership

implizite Dependencies

Ein Agent findet dort möglicherweise nicht zu wenig Beispiele, sondern zu viele.

Für einen API-Zugriff gibt es fünf Wege. Für State drei Modelle. Zwei Features greifen über ihre öffentlichen Contracts aufeinander zu, vier andere importieren Interna. Ein neues Pattern wurde eingeführt, ohne das alte vollständig abzulösen. Einige Ausnahmen sehen inzwischen häufiger aus als die ursprüngliche Regel.

Das verschiebt die Aufgabe vom Implementieren zum Interpretieren.

Welcher Code ist Vorbild?

Welche Datei ist historischer Ballast?

Ist eine Abweichung Absicht oder Zufall?

Ist das häufigste Pattern das gewünschte oder nur das älteste?

Artikel 6 hat bereits beschrieben, wie plausible lokale Entscheidungen zu Drift beitragen können. Hier müssen wir diesen Mechanismus nicht erneut herleiten. Die neue Konsequenz lautet:

Architektur ist ein Mechanismus, mit dem wir den Raum reduzieren, in dem Drift überhaupt stattfinden kann.

Wer den Zusammenhang mit dem Big Ball of Mud vertiefen möchte, findet ihn in meiner bestehenden Big-Ball-of-Mud-Serie im Artikel KI und der Big Ball of Mud.

Die Idee ist älter als die meisten unserer Programmiersprachen

Die zeitliche Klammer dieser Diskussion finde ich bemerkenswert.

1972 betrachtete David Parnas zwei unterschiedliche Möglichkeiten, ein System in Module zu zerlegen. Seine zentrale Beobachtung war nicht einfach „Module sind gut“. Entscheidend war das Kriterium, nach dem sie entstehen. Modularisierung sollte Flexibilität und Verständlichkeit verbessern; Information Hiding sollte Designentscheidungen, insbesondere schwierige oder wahrscheinlich veränderliche Entscheidungen, hinter geeigneten Modulgrenzen verbergen.

Die Idee dahinter ist heute noch erstaunlich modern:

Eine Änderung sollte nicht verlangen, dass das gesamte System erneut verstanden werden muss.

Bestimmtes Wissen sollte einen Owner besitzen.

Andere Bereiche sollten möglichst wenig über interne Entscheidungen wissen müssen.

Schnittstellen sollten stabile Annahmen transportieren, nicht beliebige Implementierungsdetails.

Zwei Jahre später formulierte Structured Design verwandte Ziele mit funktionaler Bindung innerhalb von Modulen und möglichst kontrollierten Beziehungen zwischen ihnen. Die Terminologie und Methoden haben sich seitdem mehrfach verändert. Objektorientierung, Komponentenmodelle, Services, Domain-Driven Design, Microservices, modulare Monolithen und zahlreiche weitere Architekturansätze haben andere Abstraktionen hinzugefügt.

Der grundlegende Wunsch ist erstaunlich stabil geblieben:

lokal verstehen
lokal verändern
globale Folgen begrenzen

Coding Agents bringen nun neue technische Randbedingungen hinzu: begrenzten Context, Repository Retrieval, Tool Calls, probabilistische Lösungswege und die Notwendigkeit, aus vorhandenem Code strukturelle Regeln abzuleiten.

Aber sie treffen dabei auf ein Systemproblem, das viel älter ist.

Die Eigenschaften, die Menschen seit Jahrzehnten helfen, große Systeme zu verstehen und sicher zu verändern, sind auch für Agents interessant.

Nicht weil Parnas AI vorhergesehen hätte.

Sondern weil ein Repository auch für einen Agenten leichter zu bearbeiten ist, wenn seine Struktur relevante von irrelevanten Beziehungen trennt.

Architekturarbeit verschwindet nicht ohne Architekten

An dieser Stelle könnte man aus meiner persönlichen Projekterfahrung eine bequeme Rollenargumentation bauen.

„Siehst du? Deshalb braucht jedes Projekt einen Software Architect.“

Das wäre mir zu einfach.

Ein Projekt braucht nicht zwingend einen Menschen mit genau diesem Jobtitel. Architekturverantwortung kann bei einem Tech Lead liegen, in einem Team gemeinsam getragen werden, über Plattformverantwortung verteilt sein oder durch klare Engineering-Prozesse und technische Constraints institutionalisiert werden.

Was allerdings nicht funktioniert, ist die Vorstellung, Architekturentscheidungen verschwänden, weil niemand offiziell für Architektur zuständig ist.

Architekturarbeit verschwindet nicht dadurch, dass niemand die Rolle „Architekt“ trägt. Architekturentscheidungen werden dann lediglich an anderer Stelle getroffen – häufig lokal, implizit und inkonsistent.

Jeder neue Import trifft eine Architekturentscheidung.

Jeder zusätzliche Writer auf State trifft eine.

Jede neue Shared Library trifft eine.

Jeder direkte Zugriff über eine eigentlich vorhandene Boundary hinweg trifft eine.

Die einzige Frage ist, ob diese Entscheidungen bewusst in einem gemeinsamen Rahmen entstehen oder zufällig über einzelne Tickets verteilt werden.

Architektur braucht deshalb für mich keine bestimmte Stellenbezeichnung, aber sie braucht Verantwortung.

Architektur ist Risikomanagement

Ich habe einen vergleichsweise strengen persönlichen Anspruch an Konsistenz. Das ist in meinen Projekten wahrscheinlich schnell sichtbar.

Mich stört es, wenn ein Feature anders strukturiert ist als alle anderen. Mich stört ein Layer, der keine eindeutige Responsibility mehr besitzt. Mich stört State ohne klaren Owner und eine Dependency, die „nur dieses eine Mal“ eine Grenze überschreitet.

Das kann leicht wie architektonischer Perfektionismus wirken. Für mich steckt inzwischen etwas anderes dahinter.

Architektur ist Risikomanagement, kein Perfektionswettbewerb.

Eine Architekturregel ist wertvoll, wenn sie einen problematischen zukünftigen Zustand unwahrscheinlicher macht oder vollständig ausschließt.

Zum Beispiel:

Feature A darf Feature B nicht intern importieren.

Diese Regel garantiert keine gute Software. Sie reduziert aber das Risiko, dass über Jahre schleichend Cross-Feature-Coupling entsteht.

Presentation darf Infrastructure nicht direkt aufrufen.

Auch diese Regel garantiert nichts über die Qualität der Business Logic. Sie reduziert aber die Zahl der Stellen, an denen UI-Orchestrierung, technische Zugriffslogik und fachliche Entscheidungen miteinander vermischt werden können.

Oder:

State besitzt einen eindeutigen Owner.

Damit lösen wir nicht jedes State-Management-Problem. Aber wir reduzieren konkurrierende Wahrheiten und die Zahl möglicher Schreibpfade.

Das ist der Maßstab, an dem ich Architekturregeln interessanter finde als Diagramme.

Welches Risiko reduzieren sie?

Wenn ich darauf keine Antwort habe, ist möglicherweise auch die Regel nicht besonders wertvoll.

Architektur ist die Grammatik einer Codebase

Im vorherigen Artikel habe ich meinen persönlichen Grundsatz formuliert:

Das Projekt soll sich lesen, als hätte ein Entwickler es geschrieben.

Aus Architekturperspektive würde ich ihn heute noch etwas genauer fassen.

Architektur ist die Grammatik einer Codebase.

Eine Sprache verlangt nicht, dass jeder Satz identisch ist. Autoren können unterschiedliche Inhalte formulieren, unterschiedliche Wörter wählen und Probleme unterschiedlich ausdrücken. Aber die Sprache besitzt Regeln: Bestimmte Konstruktionen gehören zu ihr, andere nicht.

Übertragen auf eine Codebase bedeutet das: Zwei Agents müssen nicht dieselbe lokale Implementierung erzeugen. Agent A darf eine kleine Hilfsfunktion anders schreiben als Agent B. Agent C darf innerhalb seines Moduls einen anderen Algorithmus wählen, wenn beide Varianten die gleichen Invarianten erfüllen.

Was ich vermeiden möchte, ist, dass jedes Modell eine neue Systemgrammatik erfindet.

               Architecture
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     Agent A     Agent B     Agent C
        ↓           ↓           ↓
      unterschiedliche lokale Lösungen
                    ↓
         gleiche strukturelle Grammatik

Genau hier hilft Architektur beim Umgang mit Modellvarianz.

Unterschiedliche Generierung muss nicht zu unterschiedlicher Systemstruktur führen.

Invarianten statt Micromanagement

Die Grenze ist wichtig, weil Architecture Constraints sonst schnell in eine andere problematische Richtung kippen.

Wenn ich einem Agenten jeden Methodenaufruf, jede Hilfsfunktion, jede Zwischendatei und jeden Implementierungsschritt vorgebe, habe ich seinen Lösungsraum zwar ebenfalls reduziert.

Aber dann verwende ich einen Agenten hauptsächlich als sehr teure Tastatur.

Die interessantere Form von Constraint lautet:

Invariant:
Presentation darf Infrastructure nicht direkt aufrufen.

offen:
Wie eine lokale Hilfsfunktion innerhalb
der erlaubten Schicht implementiert wird.

Oder:

Invariant:
Ein fachliches Modul darf nur über
seinen Public Contract verwendet werden.

offen:
Wie das Modul diesen Contract intern erfüllt.

OpenAI beschreibt in seinem agent-first Praxisbericht eine sehr ähnliche Trennung: Invarianten werden fest vorgegeben und mechanisch durchgesetzt, während konkrete Implementierungsdetails bewusst offenbleiben. Das Team verlangt beispielsweise das Parsen von Datenformen an Systemgrenzen, schreibt aber nicht vor, welche konkrete Library dafür verwendet werden muss.

Das ist für mich die richtige Abstraktionsebene.

Architektur legt die teuren Entscheidungen fest und lässt lokale Entscheidungen offen.

„Teuer“ bedeutet hier nicht zwingend finanziell. Gemeint sind Entscheidungen mit hohem strukturellem Folgerisiko: Dependency Direction, Ownership, Modulgrenzen, Contracts oder die Frage, wo eine bestimmte Art von Verantwortung überhaupt liegen darf.

Diese Dinge jedes Mal neu zu entscheiden, produziert wenig Nutzen und viel Varianz.

Architektur erklären, sichtbar machen, erzwingen

Architektur erklären

Damit kommen wir zu einem praktischen Problem.

Eine Architektur kann existieren und für einen Agenten trotzdem nahezu unsichtbar sein.

Die erste Stufe ist deshalb Dokumentation:

Architecture Docs
ADRs
Agent Files
Layering-Beschreibungen
Dependency Rules

Dokumentation ist wichtig. Sie kann begründen, warum eine Grenze existiert, welche Trade-offs berücksichtigt wurden und welche Fälle bewusst anders behandelt werden.

Aber Text besitzt Grenzen. Er kann übersehen werden, veralten oder missverstanden werden. Und er kann im großen Context zwischen Taskbeschreibung, Code, Tool-Ausgaben und anderer Dokumentation untergehen.

OpenAI berichtet beispielsweise, dass ein großes monolithisches AGENTS.md in seinem eigenen Projekt genau deshalb nicht funktionierte: Die Menge an Guidance konkurrierte mit Task, Code und relevanter Dokumentation um begrenzten Context. Stattdessen dient eine kurze Agent-Datei dort eher als Karte zu tieferer Repository-Dokumentation.

Dokumentierte Architektur ist deshalb notwendig, aber nicht die stärkste Form eines Constraints.

Architektur sichtbar machen

Die zweite Stufe ist Architektur, die bereits im Repository erkennbar ist.

Zum Beispiel:

orders/
  presentation/
  application/
  domain/
  infrastructure/

Oder:

billing/
catalog/
identity/
orders/

mit klaren Public Contracts zwischen den Modulen.

Die genaue Ordnerstruktur ist wiederum nicht der Punkt. Relevant ist, dass physische Struktur und architektonische Struktur einander nicht widersprechen.

Wenn alle Infrastructure Adapter ausschließlich technische Transformation und IO enthalten, erzeugt das Repository lokale Evidenz.

Ein neuer Adapter mit Business Rules fällt auf.

Wenn alle Features einen kleinen öffentlichen Einstiegspunkt besitzen und Interna nicht direkt importiert werden, wirkt ein direkter Deep Import ungewöhnlich.

Wenn jeder State genau einen Owner besitzt, sieht ein zweiter Writer verdächtig aus.

Konsistenz macht Abweichungen sichtbar.

Das ist einer der Gründe, warum ich „langweilige“ Layer mag.

Ein Infrastructure Layer darf langweilig sein. Ein API Adapter darf vorhersehbar aussehen. Gerade diese Vorhersehbarkeit ist wertvoll, weil ein Agent nicht aus fünfzig kreativen Varianten erst die Responsibility ableiten muss.

Je konsistenter die Codebase ihre eigene Grammatik ausdrückt, desto stärker wird vorhandener Code zu brauchbarer Evidenz.

Architektur ausführbar machen

Die dritte Stufe verändert die Qualität der Regel noch einmal.

Wir erklären nicht mehr nur:

Feature A soll Feature B nicht intern importieren.

Wir lassen einen Architecture Test diesen Import ablehnen.

Wir schreiben nicht nur:

Presentation darf Infrastructure nicht verwenden.

Eine Dependency Constraint macht diesen Zustand ungültig.

Wir hoffen nicht nur darauf, dass Contracts eingehalten werden.

Typen, Schemas, Tests und CI prüfen sie.

Dafür stehen je nach Technologie unterschiedliche Werkzeuge zur Verfügung:

• Dependency Constraints,
• Architecture Tests,
• Import Restrictions,
• Linter Rules,
• Modulgrenzen,
• Typ- und Schema-Prüfungen,
• Structural Tests,
• CI-Verifikation.

Der Mechanismus ist wichtiger als das konkrete Werkzeug.

Architektur erklären
↓
Architektur sichtbar machen
↓
Architektur ausführbar machen

Auf der letzten Stufe wird eine Architekturregel Teil der Verification Loop.

Die stärkste Architekturregel ist die, die ein Agent nicht unbemerkt verletzen kann.

Das ist qualitativ etwas anderes als eine Anweisung:

Bitte tue X nicht.

Aus Guidance wird:

X ist kein gültiger Zustand des Systems.

Ein Coding Agent darf versuchen, die Grenze zu verletzen. Der Linter widerspricht. Der Architecture Test schlägt fehl. Der Build liefert neue Evidenz. Der Agent kann korrigieren.

Architektur ist damit nicht mehr nur Context.

Sie wird ausführbares Feedback.

Ein aktuelles Praxisbeispiel aus OpenAIs agent-first Entwicklung

Genau dieser Punkt macht OpenAIs Bericht Harness engineering: leveraging Codex in an agent-first world für mich so interessant.

Der Bericht ist keine wissenschaftliche Studie und beschreibt ein einzelnes, ungewöhnlich agent-zentriertes internes Softwareprojekt. Seine Ergebnisse dürfen deshalb nicht als universelles Gesetz gelesen werden.

Als Praxisbeispiel ist er trotzdem bemerkenswert.

OpenAI beschreibt dort feste Layer innerhalb fachlicher Domains, streng validierte Dependency Directions und eine begrenzte Menge erlaubter Kanten. Cross-cutting Concerns gelangen über einen expliziten Mechanismus in die Domains; andere Dependency-Pfade sind verboten. Custom Linter und Structural Tests erzwingen diese Regeln automatisch. Gleichzeitig formuliert das Team ausdrücklich das Prinzip, Invarianten zu erzwingen, statt Implementierungen zu mikromanagen.

Der Bericht formuliert daraus eine starke praktische Erfahrung: Agents arbeiteten in Umgebungen mit strikten Grenzen und vorhersehbarer Struktur besonders effektiv. OpenAI beschreibt diese Constraints in seinem konkreten Projekt sogar als Voraussetzung dafür, hohen Durchsatz ohne strukturellen Verfall beziehungsweise Architecture Drift zu erreichen.

Ich würde daraus nicht ableiten:

OpenAI hat bewiesen:
striktes Layering = beste AI-Architektur.

Das hat der Bericht nicht bewiesen.

Was er zeigt, ist etwas Interessanteres: Ein Team, das Software konsequent agent-first entwickelt und dabei außergewöhnlich hohen Generierungsdurchsatz erzeugt, investiert sehr früh in wenige zulässige Dependency-Pfade und mechanisch prüfbare Invarianten.

Das ist bemerkenswert nah an dem Mechanismus, den wir hier hergeleitet haben.

Alte Prinzipien treffen auf neue Context-Probleme

Auch die aktuelle Forschung zu Coding Agents untersucht inzwischen genau jene Stellen, an denen Repository-Struktur relevant wird: Context Selection, Fault Localization, Repository Navigation und Dependency Reasoning.

Die Ergebnisse beweisen nicht, dass ein „sauberer“ Architekturansatz automatisch bessere Agent-Ergebnisse erzeugt.

Sie zeigen aber, dass Strukturinformation für Agents praktisch wertvoll sein kann.

Das 2026 veröffentlichte Preprint Repository Intelligence Graph beispielsweise stellt Agents eine deterministisch aus Build- und Testinformationen abgeleitete Architekturkarte zur Verfügung. In der Untersuchung mit drei kommerziellen Agents und acht Repositories stieg die mittlere Genauigkeit bei strukturellen Fragen um 12,2 Prozent relativ, während die Bearbeitungszeit um 53,9 Prozent sank. Gleichzeitig besitzt die Studie deutliche Grenzen: Sie verwendet nur acht Repositories, sieben davon synthetisch, und misst bei einigen Agents Bearbeitungszeit statt Tokenverbrauch. Sie untersucht außerdem die Darstellung vorhandener Architektur, nicht die Qualität der Architektur selbst.

LLM Agents Can See Code Repositories, angenommen für ASE 2026, untersucht eine andere Form struktureller Unterstützung. Visuelle Repository-Graphen wurden zusätzlich zur normalen Textschnittstelle bereitgestellt. In den untersuchten Settings sank der Input-Token-Verbrauch um bis zu 26 Prozent, während die Issue-Resolution-Accuracy erhalten blieb oder stieg. Rein visuelles Arbeiten funktionierte dagegen schlechter und erhöhte die Tokenkosten. Auch hier lautet die Aussage nicht „modulare Architektur braucht 26 Prozent weniger Tokens“. Die Studie untersucht die Repräsentation von Repository-Struktur für multimodale Agents.

DyRetriever wiederum, ebenfalls für ASE 2026 angenommen, verwendet Partial Dependency Graphs, um bei Repository-Level Code Generation gezielt relevanten Context entlang von Abhängigkeiten einzusammeln. Die Autoren berichten gegenüber den untersuchten RAG-Baselines relative Pass@1-Verbesserungen von 25,63 beziehungsweise 59,73 Prozent auf CoderEval und DevEval sowie eine 7,4-fach höhere Geschwindigkeit gegenüber Baselines mit statischem Dependency-Graph-Aufbau. Das ist Evidenz dafür, dass Dependency-Struktur bei Context Retrieval helfen kann – nicht dafür, dass ein bestimmtes Softwarearchitektur-Pattern überlegen ist.

Weitere aktuelle Arbeiten passen in dasselbe Bild. Agent Retrieval Bench isoliert die Frage, ob ein Agent überhaupt die Dateien findet, die er als Nächstes benötigt. In 27 bis 35 Prozent der ausgewerteten geloggten Trajektorien wurde kein einziges Gold-File gefunden; zugleich benötigte retrieval-basierter Initial Context in einer kontrollierten Intervention weniger anschließende Exploration als zufälliger irrelevanter Context.

RepoMirage berichtet wiederum, dass Agents bei Aufgaben mit erhöhtem Repository-Context-Reasoning deutlich einbrechen können und beschreibt ein Muster, das die Autoren als exploration drift bezeichnen: Agents untersuchen mehr Repository-Kontext, verwandeln diese Exploration aber nicht zuverlässig in ein korrektes Strukturverständnis. Ein zweistufiges structure-first Verfahren verbesserte die Ergebnisse in den untersuchten Settings. Die Arbeit ist allerdings ein 2026er Preprint beziehungsweise Workshop-Beitrag und kein Nachweis für allgemeine Architekturregeln.

Die Forschung beantwortet damit noch nicht unsere Architekturfrage direkt.

Sie macht aber sichtbar, warum sie interessant ist.

Repository Navigation
Context Selection
Dependency Reasoning
Fault Localization
begrenzter Context

sind neue technische Probleme von Coding Agents.

klare Module
wenige Dependencies
Information Hiding
stabile Contracts
lokale Verantwortlichkeit

sind sehr alte Antworten des Software Engineering auf die Frage, wie viel System man verstehen muss, um einen Teil davon sicher verändern zu können.

Diese beiden Linien beginnen sich gerade zu treffen.

Bedeutet ein kleinerer Lösungsraum auch weniger Tokens?

Aus dieser Verbindung entsteht für mich eine weitere Hypothese.

Nehmen wir zwei Systeme unter möglichst vergleichbaren Randbedingungen:

gleiches Modell
gleicher Agent
gleiches Tooling
gleiche Testqualität
gleiche Linter
vergleichbarer Task

System A besitzt starke Kopplung, viele mögliche Dependency-Pfade und unklare Ownership.

System B besitzt klare Grenzen, wenige erlaubte Dependency-Pfade und eindeutige Ownership.

Meine Informatikerintuition lautet:

größerer struktureller Entscheidungsraum
↓
mehr Exploration möglich
↓
mehr relevante Kandidaten
↓
potenziell mehr Files / Tool Calls / Context
↓
mehr Fehlpfade
↓
mehr Rework

gegenüber:

kleinerer struktureller Entscheidungsraum
↓
weniger strukturelle Kandidaten
↓
potenziell weniger Exploration
↓
kleinerer relevanter Working Set
↓
weniger Fehlpfade
↓
potenziell geringere Gesamtkosten

Das erscheint mir mechanistisch plausibel. Trotzdem gilt:

Dafür habe ich bisher keine belastbare direkte Messung gefunden.

Die aktuellen Arbeiten messen angrenzende Effekte. Strukturierte Repository-Darstellungen können Exploration effizienter machen. Dependency-aware Retrieval kann relevanten Context besser auswählen. Das Paper What Context Does a Coding Agent Actually Need to Act? zeigt unter fest vorgegebener Oracle-Lokalisierung sogar, dass komprimierter Context in seinem SWE-bench-Verified-Setup mit deutlich weniger Context-Tokens die Ergebnisse ganzer Dateien erreichen konnte. Aber gerade diese Arbeit hält die Lokalisierung bewusst konstant und verändert die Code-Repräsentation. Sie untersucht deshalb ebenfalls nicht, ob eine besser modularisierte Codebase selbst den Tokenbedarf reduziert.

Die saubere Aussage lautet damit:

Ein kleinerer struktureller Entscheidungsraum könnte unter ansonsten gleichen Bedingungen weniger Exploration und damit geringere Inference-Kosten benötigen. Mechanistisch ist die Hypothese plausibel. Direkt empirisch belegt ist sie bisher nicht.

Ich würde sie gern irgendwann kontrolliert testen.

Gerade der Vergleich zweier Varianten derselben Anwendung wäre dabei interessanter als der bequeme Vergleich zwischen einem Big Ball of Mud ohne Tests und einem perfekt dokumentierten modularen System mit vollständigem Agent Harness. Sonst verändern wir gleichzeitig so viele Variablen, dass am Ende niemand weiß, was wir eigentlich gemessen haben.

Die interessantere Kostenmetrik liegt hinter dem ersten Run

Selbst wenn wir diese Hypothese irgendwann messen, würde ich nicht nur auf die Tokenzahl einer einzelnen Generierung schauen.

Ein Agent kann mit sehr kleinem Context billig und schnell eine Lösung erzeugen, die anschließend drei Reparaturdurchläufe benötigt.

Ein anderer Lauf verwendet initial mehr Context, versteht die relevanten Dependencies besser und erzeugt beim ersten Versuch eine akzeptable Änderung.

Deshalb interessiert mich langfristig eher:

Kosten pro verifizierter, akzeptabler Änderung.

Darin stecken nicht nur Tokens einer einzelnen Antwort, sondern Exploration, Tool Calls, Tests, Korrekturen und Rework bis zu einem Zustand, den wir tatsächlich übernehmen können.

Das verdient einen eigenen Artikel. In „Die Ökonomie von Agentic Work“ werde ich darauf ausführlicher zurückkommen.

Für diesen Artikel reicht zunächst die Hypothese: Architektur könnte nicht nur strukturelles Risiko reduzieren. Ein kleinerer Entscheidungsspielraum könnte unter vergleichbaren Bedingungen auch ökonomisch interessant werden.

Nur ist diese zweite Aussage bislang deutlich schlechter belegt als die erste.

Durchsatz macht Grenzen wertvoller

Damit landen wir wieder bei dem Problem, mit dem dieser Artikel begonnen hat.

Menschen haben Architecture Drift erzeugt, lange bevor es Coding Agents gab. Menschen haben Shared Services zu Müllhalden gemacht, Feature-Grenzen durchbrochen und drei State-Management-Patterns nebeneinander eingeführt, wobei jede Ausnahme mit einem dringenden Ticket begründet wurde.

AI erzeugt keine neue Kategorie struktureller Fehlentscheidung. Sie verändert, wie schnell solche Entscheidungen entstehen können.

hoher Änderungsdurchsatz
+
großer struktureller Entscheidungsraum
=
mehr Gelegenheiten
für inkonsistente lokale Entscheidungen

Das ist keine Untergangsthese.

Im Gegenteil: Ich bin von dem beeindruckt, was Coding Agents heute leisten können, und verwende sie intensiv. Gerade deshalb interessiert mich die Frage, wie wir ihre Geschwindigkeit in Systeme übersetzen, die auch nach tausend weiteren Änderungen noch verständlich bleiben.

Wenn die Architektur keine Grenzen setzt, kann AI neben Produktivität auch strukturelle Beliebigkeit skalieren.

Je höher der Durchsatz wird, desto weniger möchte ich darauf vertrauen, dass jeder einzelne Run dieselbe ungeschriebene Architektur intuitiv rekonstruiert.

Ich möchte, dass das System selbst sagt, was gültig ist.

Architektur ist keine Anleitung für jeden Satz

Eine wichtige Abgrenzung bleibt: Ich plädiere weder dafür, Coding Agents mit Regeln zu umgeben, bis keinerlei Entscheidung mehr übrig bleibt, noch dafür, jede Anwendung in dasselbe Layering zu pressen.

Ein System benötigt verständliche, konsistente und überprüfbare Grenzen. Welche konkrete Architektur diese Grenzen erzeugt, hängt vom Problem ab.

Ein kleiner CRUD-Service braucht möglicherweise deutlich weniger Struktur als eine Anwendung mit zwanzig fachlichen Domains. Ein modularer Monolith kann die richtige Antwort sein, ein SCS-orientierter Schnitt ebenfalls; ein Layering kann helfen oder nur zusätzlichen Ballast erzeugen. Architecture Constraints sind kein Selbstzweck.

Sie beantworten eine Risikofrage:

Welche strukturellen Entscheidungen
wollen wir nicht bei jeder Änderung
erneut verhandeln?

Dort sollten die Grenzen stark sein.

Innerhalb dieser Grenzen darf der Agent arbeiten.

Das ist auch die Verbindung zu Artikel 5: Unterschiedliche Lösungen bleiben erlaubt. Wir beschränken lediglich die Dimensionen, in denen Unterschiede keine neue Erkenntnis liefern, sondern zusätzliche Systemvarianz erzeugen.

Architektur beseitigt Varianz nicht. Sie beseitigt unerwünschte Varianz.

Der Lösungsraum wird kleiner

Die letzten Artikel dieser Serie ergeben damit ein recht klares Bild. Artikel 4 hat gezeigt, dass ein Agent nur mit verfügbarem Context arbeiten kann; Artikel 5, dass er darin unterschiedliche Lösungswege wählen kann; und Artikel 6, dass ein plausibler Weg trotzdem falsch sein kann. Architektur ersetzt weder Context noch Verifikation, kann aber den relevanten Arbeitsraum eingrenzen und bestimmte strukturelle Fehlerklassen mechanisch abfangen. Artikel 7 hat Requirements als erste Grenze eingeführt.

Jetzt kommt die zweite hinzu:

Requirements
→ Was muss gelten?

Architecture Constraints
→ Welche strukturellen Wege sind erlaubt?

Damit wird der Agent nicht determiniert.

Er bekommt einen kleineren, sinnvolleren Arbeitsraum.

Und genau das ist für mich die Funktion guter Architektur in einer agentischen Softwareentwicklung:

Architektur reduziert den Entscheidungsraum eines Coding Agents.

Sie tut das nicht, indem sie jeden Schritt vorgibt.

Sie tut es durch Module, Contracts, Ownership, Dependency Direction und Invarianten.

Durch Strukturen, die sichtbar machen, was zusammengehört.

Und im besten Fall durch Regeln, die nicht nur irgendwo beschrieben sind, sondern vom System selbst überprüft werden.

Das Projekt soll sich weiterhin lesen, als hätte ein Entwickler es geschrieben – selbst wenn Agent A, Agent B und Agent C daran gearbeitet haben.

Vielleicht wird gute Architektur in einer Welt mit immer leistungsfähigeren Coding Agents deshalb nicht weniger wichtig.

Vielleicht verschiebt sich nur, wo ihre Hebelwirkung liegt.

Weniger darin, jedem Entwickler zu erklären, wie er seinen Code schreiben soll.

Mehr darin, den Raum so zu gestalten, dass viele unterschiedliche Akteure – Menschen wie Agents – lokal arbeiten können, ohne bei jedem Feature die globale Struktur neu zu erfinden.

Architektur definiert damit eine Art Grenze dessen, was Code innerhalb eines Systems tun darf.

Im nächsten Artikel müssen wir eine andere Grenze betrachten.

Denn ein Agent kann nicht nur Code verändern. Er kann Repository-Inhalte lesen, Tools verwenden und Informationen über Systemgrenzen hinweg verarbeiten.

Dann lautet die Frage nicht mehr nur:

Welche Dependencies darf Code überschreiten?

Sondern:

Welche Informationen darf ein Agent überhaupt sehen?

Und welche Trust Boundaries
dürfen diese Informationen überschreiten?

Darum geht es als Nächstes: Datenschutz, Vertraulichkeit & Trust Boundaries.

Quellen und Einordnung

• David L. Parnas – On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15(12), 1053–1058, Dezember 1972, DOI 10.1145/361598.361623. Parnas untersucht unterschiedliche Kriterien für Modulzerlegung und begründet Modularisierung unter anderem über Verständlichkeit, Flexibilität und Information Hiding. Im Artikel dient die Arbeit als historische Grundlage für die Idee, dass gute Grenzen Wissen und Änderungsfolgen lokalisieren. Sie enthält keinerlei Aussage über LLMs oder Coding Agents; diese Verbindung ist eine heutige Ableitung.
• W. P. Stevens, G. J. Myers, L. L. Constantine – Structured Design. IBM Systems Journal 13(2), 115–139, 1974, DOI 10.1147/sj.132.0115. Die Arbeit beschreibt Techniken zur Reduktion von Programmkomplexität durch funktionale Module und gehört zu den klassischen Quellen für die spätere Diskussion um Cohesion und Coupling. Sie wird hier verwendet, um zu zeigen, dass kontrollierte Abhängigkeiten keine AI-spezifische Erfindung sind. Auch sie erlaubt keine direkte Aussage über Agent-Performance.
• Brian Foote, Joseph W. Yoder – Big Ball of Mud. PLoP ’97, Technical Report WUCS-97-34; später Kapitel in Pattern Languages of Program Design 4, Addison-Wesley, 2000. Foote und Yoder beschreiben lose beziehungsweise haphazard strukturierte Systeme, deren Organisation stärker aus pragmatischem Wachstum und Reparaturen als aus konsistentem Entwurf entsteht. Der Artikel verwendet den Big Ball of Mud als Gegenbild zu einem begrenzten strukturellen Lösungsraum. Die Arbeit selbst untersucht selbstverständlich keine Coding Agents.
• OpenAI – Ryan Lopopolo: Harness engineering: leveraging Codex in an agent-first world. 11. Februar 2026. Der Engineering-Bericht beschreibt ein internes, vollständig agent-generiertes Softwareprojekt. Besonders relevant sind feste Layer, streng validierte Dependency Directions, wenige erlaubte Edges sowie Custom Linter und Structural Tests. OpenAI formuliert daraus die Praxisregel, Invarianten zu erzwingen statt Implementierungen zu mikromanagen. Das ist ein wertvoller Praxisbeleg, aber keine kontrollierte wissenschaftliche Studie und darf nicht zu einem universellen Architekturgesetz verallgemeinert werden.
• Self-contained Systems – offizielle SCS-Architekturbeschreibung. SCS dient in diesem Artikel ausschließlich als anschauliches Beispiel für fachliche Autonomie, eigene Daten und Business Logic sowie wenige externe Abhängigkeiten. Daraus wird ausdrücklich keine wissenschaftlich belegte Überlegenheit von SCS für LLMs abgeleitet.
• Tsvi Cherny-Shahar, Amiram Yehudai – Repository Intelligence Graph: Deterministic Architectural Map for LLM Code Assistants. arXiv:2601.10112, 2026. RIG stellt Coding Agents eine aus Build- und Testinformationen abgeleitete Architekturkarte bereit. In acht untersuchten Repositories und mit drei kommerziellen Agents berichten die Autoren höhere Genauigkeit und deutlich geringere Bearbeitungszeit bei strukturellen Fragen. Sieben der acht Repositories sind synthetisch; bei einigen Agents wird Zeit als Proxy statt echter Tokenverbrauch gemessen. Vor allem untersucht die Arbeit eine explizite Architekturdarstellung, nicht die Qualität der zugrunde liegenden Softwarearchitektur.
• Dongjian Ma et al. – LLM Agents Can See Code Repositories. ASE 2026 / arXiv:2606.14061. Die Studie untersucht visuelle Repository-Graphen als Ergänzung zu Textinterfaces. In den evaluierten Settings konnte der Input-Tokenverbrauch um bis zu 26 Prozent sinken, während Accuracy erhalten blieb oder stieg; rein visuelle Nutzung war dagegen schlechter. Das stützt die Aussage, dass strukturierte Repository-Information Exploration effizienter machen kann. Es belegt nicht, dass eine modularere Architektur selbst 26 Prozent Token spart.
• Zhongxin Liu et al. – Effective and Efficient Context Retrieval via Partial Dependency Graph for Repository-Level Code Generation. ASE 2026 / arXiv:2608.01927. DyRetriever folgt Abhängigkeiten über einen on-demand aufgebauten Partial Dependency Graph, um relevanten Repository-Context auszuwählen. Die Ergebnisse auf CoderEval und DevEval unterstützen die Bedeutung dependency-aware Retrievals. Untersucht wird ein Retrieval-Verfahren, nicht der Effekt unterschiedlicher Softwarearchitekturen unter ansonsten identischen Bedingungen.
• Bowen Qin, Yi Xie – Agent Retrieval Bench: Evaluating Repository Context Retrieval for Coding Agents. arXiv:2607.24882, 2026. Der Benchmark isoliert die Context-Acquisition vor der eigentlichen Patch-Generierung. Er zeigt unter anderem, dass reale Agent-Trajektorien relevante Dateien häufig nicht vollständig finden und dass guter Initial Context anschließende Exploration reduzieren kann. Der Benchmark misst Retrieval; bessere Retrieval-Werte sind nicht automatisch gleichbedeutend mit korrekten Patches oder besserer Architektur.
• Brian Sam-Bodden – What Context Does a Coding Agent Actually Need to Act? arXiv:2607.09691, 2026. Die Arbeit hält die Lokalisierung der zu ändernden Stelle mittels Oracle konstant und untersucht anschließend unterschiedliche Context-Repräsentationen auf SWE-bench Verified. Komprimierter Context kann in diesem Setup erheblich token-effizienter sein. Gerade weil die Lokalisierung fest vorgegeben wird, liefert die Studie keine direkte Evidenz für die Hypothese „kleinerer architektonischer Entscheidungsraum verursacht weniger Tokens“. Sie ist deshalb eine angrenzende, nicht bestätigende Quelle.
• Hanyu Li et al. – RepoMirage: Probing Repository Context Reasoning in Code Agents with Perturbations. arXiv:2605.26177, 2026. Die Autoren untersuchen Repository-Context-Reasoning unter strukturverändernden, semantikerhaltenden Perturbationen und beschreiben exploration drift als beobachtetes Problem. Ein structure-first Prototyp verbessert die Ergebnisse in ihren Experimenten. Der Stand ist ein aktueller Preprint beziehungsweise Workshop-Beitrag; die Ergebnisse sollten daher als frühe Evidenz und nicht als etablierte allgemeine Gesetzmäßigkeit gelesen werden.