Warum gute Software auch AI-freundliche Software ist

Vor einigen Jahren stand ich vor einem Architekturproblem, das mit AI überhaupt nichts zu tun hatte.

Ein Produkt musste multitenant- und whitelabel-fähig werden. Am Ende sollten ungefähr sieben Clients entstehen. Fachlich und technisch waren sie eng miteinander verwandt und besaßen gleichzeitig gezielte Unterschiede. Die einfachste Beschreibung dafür war:

same, but different.

Ich hatte damals bereits recht klare Vorstellungen davon, wie ich Angular-Anwendungen modularisieren wollte. Was mir fehlte, war eine tragfähige Struktur für mehrere Anwendungen, gemeinsame Fähigkeiten und bewusst getrennte Besonderheiten, ohne daraus sieben weitgehend unabhängige Kopien oder ein kaum noch durchschaubares Konfigurationsmonster entstehen zu lassen.

Bei dieser Suche bin ich eher zufällig bei Nx gelandet. Nicht, weil ich unbedingt ein Monorepo haben wollte, und selbstverständlich nicht, weil ich ein Repository für Coding Agents optimieren wollte. Die heutigen Coding Agents existierten in dieser Form noch gar nicht.

Mich interessierte zunächst ein konkretes Produktproblem. Erst danach entdeckte ich die allgemeineren Eigenschaften, die ein gemeinsamer Workspace mitbrachte: Anwendungen, Libraries und ihre Beziehungen waren an einem Ort auffindbar. Tooling ließ sich vereinheitlichen. Abhängigkeiten wurden sichtbarer. Gemeinsame technische Fähigkeiten konnten bewusst geteilt werden.

Die Betonung liegt für mich bis heute auf bewusst.

Ich halte wenig von der Vorstellung, ein Monorepo sei vor allem eine Einladung zu maximaler Wiederverwendung. Eine gemeinsame Codebasis macht Wiederverwendung einfacher. Ob eine zusätzliche gemeinsame Abhängigkeit architektonisch sinnvoll ist, ist damit noch lange nicht beantwortet.

Rückblickend interessiert mich heute ohnehin etwas anderes stärker:

Viele Eigenschaften, die für Coding Agents interessant werden, haben wir ursprünglich für Menschen gebaut.

Monorepos sind dafür nur ein Beispiel. Sichtbarkeit, gemeinsame Toolchains, reproduzierbare Builds, klar definierte Abhängigkeiten und automatisierte Tests waren zunächst klassische Developer-Experience-Themen. Mit Coding Agents bekommen sie einen zweiten Konsumenten.

Das heißt allerdings nicht, dass jedes große gemeinsame Repository automatisch agentenfreundlich wäre.

Alles an einem Ort ist noch keine Architektur.

Vom Repository zum ausführbaren Arbeitsraum

Der für mich spannendere Entwicklungsschritt kam später.

Im beruflichen Umfeld kannte ich lange eine sehr klassische Trennung: Frontend hier, Backend dort, jeweils eigene Repositories, eigene Build-Prozesse und eigene Entwicklungsumgebungen. Beide Teile kommunizierten über definierte Contracts miteinander.

Das ist zunächst vollkommen legitim. Ich konnte das Frontend lokal testen, das Backend lokal testen und anhand des Contracts nachvollziehen, wie beide Seiten miteinander sprechen sollten.

Bei einem Fehler über den vollständigen Systemfluss entstand trotzdem eine zusätzliche Grenze. Vielleicht begann das Problem in der Datenhaltung, wurde in einem Service falsch transformiert, über eine API weitergereicht und im Client schließlich nur sichtbar. Technisch gehörte das alles zu einem einzigen Fehlerbild. Für die Analyse lagen die relevanten Teile aber in mehreren Arbeitsräumen.

Irgendwann wurde mir an Nx deshalb etwas wichtiger als die reine Repository-Organisation. Nx kennt Projekte und ihre Beziehungen über den Project Graph. Targets beziehungsweise Tasks beschreiben ausführbare Fähigkeiten dieser Projekte. Task Pipelines und dependsOn erlauben es, Abhängigkeiten zwischen Tasks auszudrücken, und run-many kann dieselben standardisierten Tasks über mehrere Projekte hinweg ausführen.

Der entscheidende Gedanke ist für mich nicht an eine bestimmte Nx-Version gebunden:

Wenn ein Workspace seine Abhängigkeiten kennt, kann er mehr als Dateien organisieren. Er kann Teile des Systems orchestrieren.

Das war zunächst wieder klassische Developer Experience. Weniger manuelle Startreihenfolgen, weniger projektspezifisches Wissen darüber, welcher Befehl wo ausgeführt werden muss, und weniger selbst geschriebene Orchestrierungslogik für Beziehungen, die der Workspace bereits kennt.

Privat habe ich diese Idee in meinem eigenen SCS-System konsequenter weitergeführt. Dort liegen zentrale Teile mehrerer fachlicher Systeme in einer gemeinsamen Codebasis. Je nach Bereich gehören dazu Client, API, Service, Datenbank-nahe Infrastruktur, Libraries, Contracts, Container-Konfiguration, Tests und Infrastructure as Code.

Auch die CI nutzt diese Systemkenntnis. Sie ermittelt über Nx die betroffenen deploybaren Projekte, baut nur die relevanten Docker-Targets und ordnet diese anschließend den konkreten Stacks und Services zu.

Damit verändert sich die Bedeutung des Repositories. Es enthält nicht mehr nur den Code eines Systems, sondern zunehmend auch die Mechanismen, mit denen wesentliche Teile dieses Systems gebaut, gestartet, geprüft und betrieben werden können.

Das System selbst wird zu einem ausführbaren Arbeitsraum.

Diese Entwicklung hatte für mich zunächst nichts mit Agentic Work zu tun. Genau deshalb finde ich sie heute so interessant.

Systemweit verstehen, lokal verändern

Ein ausführbarer Arbeitsraum bedeutet ausdrücklich nicht, dass ich einem Coding Agent einen einzigen Auftrag gebe, der von der Datenbank bis zur View durch das gesamte System schneidet.

Bei ausreichend klaren Requirements könnte ein Agent einen solchen Durchstich vermutlich sogar umsetzen. Ich versuche trotzdem eher das Gegenteil: Die eigentlichen Arbeitsaufträge sollen möglichst klein bleiben.

Das gemeinsame System verändert vor allem die Analyse.

Wenn ein Fehler aus der View bis in einen Backend-Service oder zur Datenhaltung verfolgt werden muss, möchte ich möglichst wenig künstliche Grenzen in der Sicht des Agenten haben. Wenn ein Contract verändert wird, soll der abhängige Code erreichbar sein. Wenn ein E2E-Test scheitert, soll die Analyse nicht deshalb enden, weil die nächste relevante Schicht zufällig in einem anderen Repository liegt, auf das der aktuelle Arbeitsraum keinen Zugriff besitzt.

Für die Umsetzung gilt anschließend eine andere Regel.

Weite Sicht, enger Eingriffsraum: Für die Analyse soll der Agent den relevanten Flow systemweit verstehen können, während die eigentliche Umsetzung auf einen kleinen autonomen Arbeitsraum begrenzt bleibt.

Darin steckt für mich kein Widerspruch.

Der Agent darf systemweit verstehen, ohne systemweit verändern zu müssen.

Artikel 10 dieser Serie hat den offenen Entscheidungsraum betrachtet: Wo brauchen wir Exploration, wo müssen Entscheidungen fallen und wann soll die Umsetzung möglichst langweilig werden? Hier geht es um eine verwandte, aber andere Frage. Ein kleiner Umsetzungsauftrag muss nicht bedeuten, dass wir dem Agenten künstlich jede Sicht auf das umgebende System nehmen. Gerade für Analyse und Verifikation kann die größere Sicht wertvoll sein.

Gleichzeitig wird ein riesiger Implementierungsauftrag nicht dadurch besser, dass der Agent theoretisch das gesamte System erreichen kann.

Die Architektur sollte beides ermöglichen: große Sichtweite und kleinen Eingriffsraum.

Das Wissen, das nicht im Repository steht

Diese Sichtweite löst allerdings ein anderes Problem nicht: Ein Repository enthält nie automatisch alles Wissen, das ein Team über sein System besitzt.

Menschen kompensieren das erstaunlich gut. Ein Entwickler arbeitet vielleicht seit fünf Jahren in einem System und weiß, dass eine bestimmte Klasse zwar wie der richtige Einstiegspunkt aussieht, für neue Funktionen aber nicht mehr verwendet werden sollte. Er weiß, dass ein Service historisch an der falschen Stelle liegt. Er kennt die Abhängigkeit, die im Code kaum sichtbar ist. Und er weiß, welches von zwei vorhandenen Patterns zwar häufiger vorkommt, aber längst nicht mehr fortgeführt werden soll.

Manchmal lautet die ehrlichste Beschreibung schlicht:

Das steht nirgendwo. Das wissen wir einfach.

Softwareentwicklung ist eine wissensintensive Tätigkeit, und Forschung zu Software Maintenance, tacit knowledge und Architecture Decision Knowledge beschreibt seit Langem, dass relevantes Wissen über Domäne, Architektur und historische Entscheidungen häufig nur unvollständig dokumentiert ist. Coding Agents ändern an diesem Grundproblem nichts.

Sie besitzen nur nicht automatisch die organisationsspezifische Geschichte, die über Jahre in den Köpfen eines Teams entstanden ist.

Ihnen steht zunächst das zur Verfügung, was erreichbar und interpretierbar ist: Code, Repository-Struktur, Dokumentation, Contracts, Tests, Build-Konfiguration, Agent Files, statische Regeln, Versionshistorie, Logs und ausführbare Tools.

Aktuelle Forschung zu Coding Agents macht bereits sichtbar, dass selbst das Auffinden des richtigen Repository-Kontexts eine eigenständige Schwierigkeit ist. Der Agent Retrieval Bench isoliert genau diese Phase und zeigt unter anderem, dass aufgezeichnete Agent-Trajektorien in einem erheblichen Teil der Fälle sämtliche als relevant markierten Dateien verfehlen. ContextBench untersucht denselben Mechanismus aus einer anderen Richtung und findet messbare Lücken zwischen exploriertem und tatsächlich genutztem Kontext.

Daraus folgt nicht, dass jedes Erfahrungswissen dokumentiert werden sollte. Das wäre weder realistisch noch sinnvoll. Es folgt aber, dass ein System für einen Agenten umso weniger rätselhaft wird, je mehr relevante Regeln und Zusammenhänge aus dem System selbst ableitbar sind.

Hidden Knowledge versus explizites Systemwissen: Wissen, das nur im Kopf des Teams existiert, ist für den Agenten nicht automatisch verfügbar; Contracts, Tests, Boundaries und dokumentierte Entscheidungen sind erreichbar und teilweise mechanisch prüfbar.

Explizite Contracts helfen einem neuen Entwickler. Sie helfen auch dem Agenten. Architekturregeln helfen dem Team. Sie helfen auch dem Agenten. Ein reproduzierbarer Build hilft dem Entwickler, der am Montagmorgen einen neuen Laptop eingerichtet hat. Er hilft auch einem Agenten, der seine eigene Änderung überprüfen soll.

Genau hier erhalten alte Software-Engineering-Ideen einen neuen Adressaten.

Einheitlichkeit, Standards und maschinenlesbare Struktur

Ich habe einen ausgeprägten Hang zu Konsistenz. Oder weniger diplomatisch formuliert:

Einheitlichkeit ist mein Mantra.

Wenn ich fachliche Domains schneide, möchte ich, dass sie sich strukturell ähnlich lesen. Nicht identisch – unterschiedliche Fachlichkeit kann unterschiedliche Lösungen benötigen. Aber bekannte Layer sollten dieselbe Bedeutung besitzen. Wiederkehrende Patterns sollten wiedererkennbar sein. Commands sollten sich nicht ohne Grund unterscheiden. Lint-Regeln sollten zentral gelten. Tooling-Konfiguration sollte möglichst wenig lokale Überraschungen produzieren.

Das war schon meine Haltung als Tech Lead, lange bevor ich ernsthaft mit Coding Agents gearbeitet habe.

Interessanterweise bin ich vorsichtiger mit der Behauptung, ein Agent brauche diese Konsistenz genauso wie ein Mensch. Ein Mensch orientiert sich stark über Wiedererkennung. Wenn zehn fachliche Bereiche ähnlich aufgebaut sind, sinkt die kognitive Einstiegshürde in den elften. Ein Agent kann unter Umständen problemlos einen Bereich analysieren, ohne jemals die anderen neun gesehen zu haben.

Und genau das ist sogar wünschenswert.

Ein Agent muss nicht das ganze Repository verstehen, wenn die Architektur dafür sorgt, dass er es nicht verstehen muss.

Konsistenz bleibt trotzdem wertvoll. Sie stabilisiert Erwartungen innerhalb des relevanten Bereichs, ermöglicht generische Prüfungen, reduziert Sonderwissen in Build- und Testlogik und erhöht die Wahrscheinlichkeit, dass eine explizite Regel tatsächlich systemweit durchsetzbar ist.

Dazu gehört für mich ein zweites Mantra:

Stick to the standards.

Ich habe bei Nx selbst erlebt, was passiert, wenn Strukturen unnötig weit von den vorgesehenen Mechanismen abweichen. Eigene Executor-Logik, Sonderkonfigurationen und individuelle Projektstrukturen können kurzfristig clever wirken. Bei späteren Updates muss dieses Sonderwissen jedoch mitmigriert werden.

Das ist kein Plädoyer dafür, jeden Default ungeprüft zu akzeptieren. Framework- und Tooling-Standards sind keine Naturgesetze. Die interessantere Engineering-Regel lautet:

Jede unnötige Abweichung erzeugt zusätzliches Sonderwissen.

Für Menschen, für Tooling und zunehmend auch für Agents.

Deshalb darf an dieser Stelle auch ein kleines Plädoyer für Nx stehen. Nicht dafür, jedes Softwaresystem in ein Nx-Monorepo zu verwandeln, und schon gar nicht für die Behauptung, Nx sei eine AI-Plattform.

Mich interessiert Nx als konkretes Beispiel dafür, wie klassische Software-Engineering-Ideen explizit, abfragbar und ausführbar werden können. Der Workspace besteht aus Projects. Der Project Graph beschreibt ihre Beziehungen. Tags können semantische Kategorien ausdrücken. Targets beziehungsweise Tasks beschreiben ausführbare Fähigkeiten. Task Pipelines beschreiben Abhängigkeiten zwischen diesen Tasks. run-many führt standardisierte Tasks über mehrere Projects aus. affected verbindet einen Git-Diff mit dem Project Graph und bestimmt daraus den Teil des Workspaces, der potenziell betroffen ist.

Auch der Graph selbst ist nicht nur eine Visualisierung. Nx kann Project- und Task-Graph-Daten exportieren beziehungsweise für konkrete Ausführungen sichtbar machen. Damit wird ein Teil der Repository-Topologie maschinenlesbar.

Ich mag Nx nicht deshalb, weil jedes System ein Monorepo sein sollte. Ich mag die Idee, dass wesentliche Teile der Repository-Topologie explizit, abfragbar und überprüfbar werden.

Für Menschen ist das gute Developer Experience. Für Agents wird daraus zugängliche Struktur.

Architektur, die zurücksprechen kann

Module Boundaries verwende ich in Nx praktisch seit Beginn. Auch hier hatte AI mit der ursprünglichen Motivation nichts zu tun.

Ich wollte beispielsweise verhindern, dass UI-spezifische Libraries plötzlich im Business-Layer verwendet werden. Fachliche Domains sollten nicht beliebig ihre Interna gegenseitig importieren können. Dependency Directions sollten nicht nur als Diagramm existieren.

Für JavaScript- und TypeScript-Projekte stellt Nx dafür @nx/enforce-module-boundaries bereit. Projects lassen sich über Tags klassifizieren, und Dependency Constraints können festlegen, auf welche Kategorien ein Bereich zugreifen darf beziehungsweise welche Abhängigkeiten verboten sind. Für sprachübergreifende Regeln auf dem Project Graph bietet Nx zusätzlich Conformance-Regeln.

In Artikel 8 ging es darum, warum solche Mechanismen den strukturell zulässigen Lösungsraum begrenzen. Hier interessiert mich ein anderer Effekt: Sie liefern Feedback.

Ein Agent verändert Code. Danach läuft Lint. Und die Architektur kann auf einen konkreten Verstoß antworten.

Dieser Import ist nicht erlaubt.

Der Agent benötigt an dieser Stelle keine perfekte Interpretation meiner Architekturabsicht. Er bekommt maschinelles Feedback über das Ergebnis seiner Änderung.

Mechanisch ausführbare Architektur kann einem Agenten über seine eigene Arbeit zurückmelden, wo er eine Grenze verletzt hat.

Das ist der Unterschied zwischen einer Regel, die ausschließlich auf einer Wiki-Seite steht, und einer Regel, die beim Verstoß einen fehlgeschlagenen Task produziert. Die Dokumentation erklärt die Absicht. Die ausführbare Regel prüft einen Teil des Ergebnisses. Beides hat seinen Platz.

`affected`: Scope wird ausführbar

Eines der Konzepte, die ich an Nx besonders stark finde, ist affected.

Die Funktionsweise ist im Kern geradlinig: Nx bestimmt über Git die geänderten Dateien, ordnet sie mithilfe des Project Graph den Projekten zu und berücksichtigt anschließend auch abhängige Projekte. Tasks wie Test, Lint oder Build können dadurch auf diese Teilmenge begrenzt werden.

Genau dort wird affected für mich architektonisch interessant.

Wenn alles auf alles zugreift, ist auch ständig alles betroffen. Dann existiert formal noch ein Project Graph, sein praktischer Wert als Scope-Begrenzer sinkt aber erheblich.

Damit affected wirklich stark wird, braucht ein System Eigenschaften, die ohnehin wünschenswert sind: Autonomie, saubere Dependencies, begrenzte Change Radii und bewusste Boundaries.

In meinem privaten System ist affected inzwischen nicht nur eine CI-Optimierung. Die Pipeline bestimmt die betroffenen Projekte mit einem docker:build-Target und beschränkt Build und Deployment anschließend auf die daraus resultierenden Services beziehungsweise Stacks.

Für Agentic Work entsteht daraus noch eine weitere Interpretation.

Affected als Verifikationsscope: Eine kleine Änderung führt bei sauber geschnittenen Abhängigkeiten zu einem kleinen betroffenen Graph und damit zu einem kleineren Verifikationsraum.

Das ist ausdrücklich keine universelle Architekturmetrik. Eine zentrale Library darf zu Recht viele Consumers besitzen. Manche Änderungen sind fachlich systemweit. Und ein fehlerhafter Dependency Graph kann Sicherheit nur vortäuschen.

Als Engineering-Signal finde ich den Scope trotzdem interessant.

Ein kleiner affected-Scope ist nicht nur schneller. Er kann ein Hinweis darauf sein, dass eine Änderung lokal verstanden und lokal verifiziert werden kann.

Damit wird affected für mich gleichzeitig zu CI-Optimierung, Scope-Detektor und Verifikationshelfer.

Wiederverwendung ohne Shared-Code-Festival

An diesem Punkt lauert ein klassischer Monorepo-Reflex: Wenn alles gemeinsam erreichbar ist, können wir doch endlich alles wiederverwenden.

Technisch stimmt das. Architektonisch halte ich diese Schlussfolgerung für gefährlich.

Bei fachlicher Wiederverwendung möchte ich sehr genau hinschauen. Wenn zwei Bereiche tatsächlich dasselbe fachliche Konzept mit derselben Verantwortung und demselben Änderungsgrund besitzen, kann ein gemeinsamer Owner sinnvoll sein.

Bei rein technischer Wiederverwendung bin ich deutlich zurückhaltender. Ein OAuth-Guard, der eine echte gemeinsame technische Capability darstellt, kann eine eigene Library verdienen. Zwei Mapper, die zufällig fast gleich aussehen, sind für mich noch kein Grund, ansonsten autonome Bereiche miteinander zu koppeln.

Lieber einen Mapper zweimal schreiben, als für drei gesparte Zeilen eine neue Kopplung zwischen zwei autonomen Bereichen einzuführen.

Das ist keine pauschale Regel gegen Wiederverwendung. Es ist eine Priorisierung von Autonomie gegenüber reflexhaftem DRY.

Vaughn Vernon weist in diesem Zusammenhang darauf hin, dass DRY leicht mit dem bloßen Vermeiden identischer Codezeilen verwechselt wird, obwohl der zugrunde liegende Gedanke stärker auf dupliziertes Wissen zielt. Für meine Argumentation reicht ohnehin die vorsichtigere Ableitung: Ähnlich aussehender Code ist nicht automatisch dasselbe Modell und nicht automatisch ein guter Grund für eine neue Dependency.

Ein Monorepo ist kein Shared-Code-Festival. Die gemeinsame Codebasis macht Wiederverwendung möglich. Architektur entscheidet weiterhin, wann daraus eine sinnvolle gemeinsame Capability und wann nur neue Kopplung entsteht.

Von Developer Experience zu Agent Infrastructure

Bis hierhin könnte der Eindruck entstehen, der Artikel handele hauptsächlich von Monorepos und Nx. Das wäre zu kurz gegriffen. Nx ist nur ein besonders anschauliches Beispiel.

Der eigentliche Gedanke wird sichtbar, wenn wir die gesamte Entwicklungsumgebung betrachten.

Über Jahre haben wir Aufwand in reproduzierbare lokale Umgebungen, Container, einheitliche Startkommandos, Unit Tests, Integration Tests, E2E, Lint, Formatting, Type Checks, Build Targets, Dependency Graphs, Architecture Rules, Infrastructure as Code und CI-Pipelines gesteckt.

Der ursprüngliche Adressat war der Entwickler.

Eine gute lokale Umgebung sollte verhindern, dass ein neues Teammitglied erst drei Tage lang handgeschriebene Setup-Anleitungen interpretiert. Ein standardisierter Build sollte reproduzierbar sein. Tests sollten Feedback liefern. Lint sollte triviale Fehler und Regelverletzungen automatisiert erkennen. Container sollten Umgebungsunterschiede reduzieren. CI sollte relevante Prüfungen zuverlässig wiederholen.

Das alles war Developer Experience.

Und dann kam ein neuer Konsument dieser Infrastruktur hinzu.

Ein Coding Agent kann dieselben Mechanismen heute selbst verwenden.

Developer Experience wird Agent Infrastructure: Der Agent führt Änderungen durch, nutzt Build, Lint und Tests, startet relevante Services, führt E2E aus, liest Fehler, korrigiert und verifiziert erneut.

Das ist nicht nur eine theoretische Produktidee. Software-Engineering-Benchmarks und Agenten-Umgebungen wie SWE-agent, SWE-Gym und SWE-bench bauen genau auf der Möglichkeit auf, Repositories zu navigieren, Dateien zu bearbeiten und erzeugte Änderungen gegen ausführbare Runtime- und Testumgebungen zu prüfen.

Daraus folgt keine allgemeine Produktivitätsaussage für mein eigenes Repository. Der grundlegende Mechanismus ist trotzdem klar: Ein Coding Agent wird erheblich nützlicher, wenn er nicht nur Text erzeugen, sondern mit einer ausführbaren Softwareumgebung interagieren kann.

Was früher Developer Experience war, wird zunehmend Agent Infrastructure.

Agent-readable reicht nicht

Für mich ist das wahrscheinlich die stärkste Konsequenz daraus.

Wenn wir über AI-freundliche Repositories sprechen, landen wir schnell bei Context: gute Dokumentation, Agent Files, klare Dateinamen, Repository Maps und Architekturübersichten. Das alles ist wichtig. Ein Agent muss relevante Information finden können.

Ein Repository kann aber hervorragend lesbar sein und trotzdem eine schlechte agentische Arbeitsumgebung darstellen.

Stellen wir uns ein System mit sauberer Dokumentation vor. Der Agent versteht die Architektur, findet den richtigen Service, identifiziert den relevanten Contract und schreibt einen plausiblen Patch.

Und dann?

Der Build funktioniert nur auf dem Rechner eines Kollegen. Tests existieren praktisch nicht. Der lokale Backend-Stack lässt sich seit Monaten nicht mehr starten. E2E bedeutet, dass jemand manuell fünf Klicks in einer Testumgebung ausführt. Lint-Regeln unterscheiden sich zwischen Teilprojekten. Die wichtigste Architekturregel existiert ausschließlich in einem Diagramm.

Der Agent kann seine Hypothese sehr gut formulieren. Er kann sie nur kaum prüfen.

AI-freundlich bedeutet deshalb nicht nur agent-readable. Es bedeutet agent-verifiable.

Oder noch allgemeiner:

AI-freundliche Software stellt einem Agenten nicht nur Context bereit. Sie stellt ihm Feedback bereit.

Ein größeres Context Window kann zusätzliche Dateien aufnehmen. Es erzeugt keinen funktionierenden Test. Eine bessere Repository-Suche kann den richtigen Service finden. Sie macht einen kaputten lokalen Build nicht reproduzierbar. Ein exzellentes Agent File kann erklären, dass Presentation nicht auf Infrastructure zugreifen darf. Eine mechanische Boundary Rule kann den konkreten Verstoß zusätzlich ablehnen.

Damit verändert sich die Frage, wie wir einen guten agentischen Arbeitsraum beurteilen. Nicht nur: Wie viel Repository-Kontext kann der Agent sehen? Sondern auch: Wie zuverlässig kann er von „Ich glaube, diese Änderung ist richtig“ zu einem belastbaren Verifikationsergebnis gelangen?

Die Feedback-Schleife gehört zum Arbeitsraum

In meiner eigenen Arbeit lasse ich Coding Agents diese Mechanismen tatsächlich verwenden.

Nach einer Änderung soll der Agent nicht nur einen Diff präsentieren. Er führt – abhängig vom Auftrag – Unit Tests aus, lässt Lint laufen, baut die relevanten Projekte, startet bei geeigneten Features den notwendigen Stack, führt E2E aus, liest Fehler, korrigiert und verifiziert erneut.

Keiner dieser Schritte beweist vollständige fachliche Korrektheit. Ein grüner Build sagt nichts darüber aus, ob wir das richtige Feature gebaut haben. Ein Unit Test kann eine falsche Annahme perfekt absichern. Ein E2E-Test prüft nur die Szenarien, die wir tatsächlich beschrieben haben. Module Boundaries verhindern nicht jede schlechte Architekturentscheidung.

Entscheidend ist die Kombination unterschiedlicher Feedback-Kanäle. Build beantwortet andere Fragen als Lint. Architecture Rules andere als Unit Tests. E2E andere als Type Checks. Human Review andere als alle automatisierten Mechanismen.

Agentic Work wird für mich robuster, wenn der Agent möglichst viele dieser Kanäle selbst verwenden kann, bevor sein Ergebnis überhaupt bei mir landet.

Mein eigenes Review verschiebt dadurch seinen Schwerpunkt. Wenn der Agent bereits selbst gebaut, gelintet und getestet hat, kann ich mich stärker auf Fragen konzentrieren wie: Liegt die Responsibility am richtigen Ort? Entsteht neue unerwünschte Kopplung? Bleibt die fachliche Boundary erhalten? Passt die Lösung zu der Architekturentscheidung, die vorher getroffen wurde? Erzeugt der Patch strukturelle Drift? Ist die Lösung angemessen oder lediglich technisch funktional?

Der Agent verifiziert zunehmend Funktion und technische Konsistenz. Mein eigener Review verschiebt sich stärker auf Architektur und Entscheidungen.

Das Wort stärker ist wichtig. Ich reviewe weiterhin Funktion, vertraue keinem grünen Testlauf blind und gebe Architektur nicht an ein Review-Modell ab. Artikel 10 hat bereits beschrieben, warum ich zusätzlich häufig ein starkes Modell als weiteren Review-Kanal nutze. Human Review und Model Review ersetzen sich für mich nicht gegenseitig. Die ausführbare Infrastruktur ergänzt beide.

Dabei optimiere ich aktuell auch nicht primär auf minimale Laufzeit. Zwischen einem sehr schnellen grünen Signal und einem vollständigen, nachvollziehbaren Bericht wähle ich im Zweifel den Bericht.

Mich interessiert nicht nur, ob Tests grün waren, sondern welche Projekte betroffen waren, was gebaut wurde, welche Tests liefen, welche Architekturregeln geprüft wurden, was übersprungen wurde, welche Warnungen auftraten und welche Fehler gegebenenfalls zuerst korrigiert werden mussten.

Denn dieses Ergebnis besitzt anschließend eine zweite Funktion: Es wird selbst wieder zu Context. Ich kann den Report prüfen und ihn zusätzlich an ein Review-Modell geben, um beispielsweise zu hinterfragen, ob die durchgeführte Verifikation für diese Änderung ausreichend war oder welche Risiken noch nicht abgedeckt sind.

Schnelles Feedback ist angenehm. Belastbares Feedback ist entscheidend.

Saubere Boundaries und affected reduzieren den Scope ohnehin. Parallelisierung oder Subagents könnten Laufzeit weiter optimieren, würden aber andere Kostenfragen öffnen. Das gehört in einen späteren Artikel.

Explizit, begrenzt, verifizierbar

Wenn ich die bisherige Argumentation verdichten müsste, lande ich bei drei Eigenschaften. Nicht als neue Checkliste für „AI-ready Repositories“, sondern als Beschreibung dessen, was in meiner Praxis gut funktioniert.

Explizit: Relevante Struktur soll möglichst im System sichtbar sein. Projects, Dependencies, Contracts, Layer, Commands, Tests, Architecture Rules und dokumentierte Entscheidungen dort, wo ihre Begründung später nicht zuverlässig aus dem Code rekonstruiert werden kann. Ein Agent sollte für eine normale Änderung nicht erst jahrelange Teamgeschichte erraten müssen.

Begrenzt: Systemweite Erreichbarkeit darf vorhanden sein. Der konkrete Auftrag soll trotzdem einen kleinen Arbeitsraum besitzen. Eine fachliche Domain muss nicht deshalb Informationen über fünf andere Domains kennen, weil alle zufällig im selben Repository liegen.

Verifizierbar: Der Agent benötigt belastbares Feedback durch Build, Lint, Tests, Architecture Rules, reproduzierbare Runtime und E2E dort, wo es sinnvoll ist.

Daraus ergibt sich für mich eine recht präzise Beschreibung:

AI-freundliche Software macht relevantes Wissen explizit, hält den konkreten Arbeitsraum klein und ermöglicht dem Agenten, seine eigene Änderung zu überprüfen.

Interessanterweise wurde keine dieser Eigenschaften für AI erfunden.

Monorepo ist Infrastruktur, keine Agentenstrategie

Damit können wir zu dem Punkt zurückkehren, an dem der Artikel begonnen hat.

Ein Repository mit zwei Millionen Zeilen Big Ball of Mud wird nicht agentenfreundlich, weil alle Dateien im selben Git-Checkout liegen. Vielleicht kann der Agent jetzt alles erreichen. Das sagt aber noch nichts darüber aus, wie viel davon er verstehen muss.

Großes strukturiertes Repository versus großer Deutungsraum: Klare fachliche Boundaries, explizite Dependencies und kleine lokale Arbeitsräume ermöglichen systemweite Erreichbarkeit bei begrenztem Scope; globale Utilities, unklare Ownership, Cross-Dependencies und konkurrierende Patterns erzeugen dagegen einen großen Deutungsraum.

Ein anderes Repository kann dieselbe Größe besitzen und strukturell völlig anders aussehen. Entscheidend ist nicht die Größe des Checkouts, sondern wie viel davon für eine konkrete Änderung tatsächlich verstanden werden muss.

Deshalb würde ich nie schreiben, Monorepos machten Agents automatisch besser. Dafür gibt es weder eine saubere Kausalität noch eine universelle Architekturregel.

Meine Aussage ist kleiner:

Monorepo ist Infrastruktur. Agentenfreundlichkeit entsteht erst durch Struktur.

Ein gemeinsamer Workspace kann systemweite Analyse und Orchestrierung erleichtern. Ob daraus ein guter agentischer Arbeitsraum wird, entscheidet seine Struktur.

Und was passiert mit dem Big Ball of Mud?

Damit landen wir bei einer unangenehmen Gegenfrage.

Auf dieser Website habe ich den Big Ball of Mud bereits ausführlich als langfristiges Architektur- und Ökonomieproblem betrachtet. Coding Agents verändern daran möglicherweise etwas – nur vielleicht anders, als man zunächst erwarten würde.

Meine persönliche Hypothese lautet inzwischen: Ein Coding Agent könnte einen Big Ball of Mud erstaunlich lange produktiv bearbeiten. Vielleicht sogar länger als ein Mensch.

Ein Agent kann sehr große Mengen Code durchsuchen, repetitive Strukturen verfolgen, tiefe Call Chains rekonstruieren und dieselben Zusammenhänge immer wieder neu analysieren. Dass Menschen bei solchen Systemen irgendwann kognitiv und organisatorisch an Grenzen stoßen, bedeutet nicht automatisch, dass ein Agent an derselben Stelle scheitert.

Aktuelle Repository-Retrieval-Forschung zeigt zwar deutlich, dass große Codebasen und Context Acquisition weiterhin schwierige Probleme sind. Sie zeigt aber gerade nicht, dass Agents an unstrukturierten Systemen grundsätzlich sofort scheitern.

Deshalb wäre mir die einfache These zu bequem:

Schlechte Architektur funktioniert nicht mit AI.

Wahrscheinlich funktioniert sie erstaunlich lange.

Die interessantere Frage ist: zu welchem Preis?

Hier verlassen wir den Bereich belastbarer empirischer Aussagen und kommen zu einer Engineering-Hypothese. Ein wachsender Big Ball of Mud vergrößert den Raum potenziell relevanter Information. Mehr Abhängigkeiten müssen untersucht, mehr historische Patterns gegeneinander bewertet, mehr Ripple Effects ausgeschlossen und mehr Ergebnisse reviewed werden.

Das könnte langfristig Context Acquisition, Modell-Context, Analyseaufwand, Verifikationsscope, Review-Aufwand und variable Kosten pro Änderung erhöhen. Ich kenne keine belastbare Studie, aus der sich dafür heute eine allgemeine ökonomische Kurve ableiten ließe, und werde deshalb auch keine erfinden.

Als Engineering-Ableitung erscheint mir trotzdem plausibel:

Die technische Bearbeitbarkeit eines Big Ball of Mud durch Agents beantwortet noch nicht die wirtschaftliche oder menschliche Frage, ob seine weitere Entwicklung sinnvoll bleibt.

Pointierter formuliert:

Dem Agenten ist ein Big Ball of Mud möglicherweise erstaunlich lange egal. Dem Budget und dem Menschen, der die erzeugte Lösung noch verstehen soll, möglicherweise nicht.

Vielleicht verschiebt AI dadurch sogar den Punkt, an dem wir ein problematisches System als wirtschaftlich nicht mehr wartbar wahrnehmen. Menschen halten solche Systeme heute oft lange am Leben, weil sie Hidden Knowledge aufbauen. Coding Agents könnten einen Teil dieser Navigation automatisieren.

Gleichzeitig existiert die entgegengesetzte Dynamik: Wenn Agents Änderungen wesentlich schneller produzieren, können sie strukturelle Probleme auch schneller vermehren. Mehr Output bedeutet nicht automatisch mehr Architektur. Wenn jede schnelle Änderung eine weitere lokale Ausnahme hinzufügt, kann höhere Produktivität die strukturelle Erosion beschleunigen.

Welche dieser Kräfte langfristig überwiegt, wissen wir heute nicht.

Agentic Work beseitigt die technischen Eigenschaften eines Big Ball of Mud nicht. Es kann verändern, wie lange wir ihre wirtschaftlichen Folgen tolerieren können.

Die vollständige Rechnung gehört in den späteren Ökonomie-Artikel.

Wenn gute Schnitte billiger werden

Bei neuen Funktionen könnte sich dieselbe Kostenverschiebung in die andere Richtung auswirken.

Viele schlechte Architekturentscheidungen entstehen nicht, weil niemand eine bessere Struktur erkennen könnte. Sie entstehen, weil der kurzfristig billigere Weg attraktiv ist: noch eine Funktion in den bestehenden großen Baustein, noch ein Sonderfall im vorhandenen Service, noch ein weiterer Consumer derselben Shared Library, noch eine kleine Abhängigkeit.

Ein sauberer neuer Schnitt kostet schließlich ebenfalls Zeit.

Wenn Codeproduktion durch Agents günstiger wird, kann sich diese Rechnung verändern. Vielleicht wird es wirtschaftlich leichter, eine neue kleine autonome Einheit zu erzeugen, statt die nächste Funktion in einen ohnehin überladenen Baustein zu integrieren.

Das ist kein Argument für Microservices. Eine autonome Einheit kann ebenso gut ein fachlicher Slice oder ein Modul innerhalb eines modularen Monolithen sein.

Der interessante Gedanke lautet lediglich:

Billigere Codeproduktion kann auch die Kosten guter Schnitte verändern.

Diese Frage führt direkt zu einem späteren Thema dieser Serie: Was passiert mit Softwarearchitektur, wenn Code selbst nicht mehr der teuerste Teil der Softwareentwicklung ist?

Der neue Konsument alter Engineering-Ideen

Als ich Nx für sieben ähnliche, aber unterschiedliche Clients eingesetzt habe, wollte ich kein AI-freundliches Repository bauen. Als wir Build-Kommandos standardisiert haben, ging es um Developer Experience. Module Boundaries sollten unerwünschte Dependencies verhindern. Automatisierte Tests sollten Menschen schneller Feedback geben. Container sollten lokale Umgebungen reproduzierbarer machen. Infrastructure as Code sollte Infrastruktur nachvollziehbar und reproduzierbar machen. affected war zunächst eine Möglichkeit, CI gezielter auszuführen.

All diese Dinge besitzen heute einen zusätzlichen Nutzer: den Coding Agent.

Er kann einen Contract lesen, einen Project Graph analysieren, ein standardisiertes Target aufrufen, einen Boundary-Verstoß als Lint-Fehler zurückbekommen, einen Test ausführen, einen Container starten, den Fehler lesen, seinen Patch korrigieren und den Zyklus erneut durchlaufen.

Das verändert nicht plötzlich die Definition guter Software. Aber es verändert, wer von diesen Eigenschaften profitieren kann.

Die Qualität dieser Arbeitsumgebung hängt deshalb nicht nur davon ab, wie groß ein Context Window ist oder wie intelligent die nächste Modellgeneration wird. Ein Teil davon steckt ganz klassisch in unserem Engineering: in den Grenzen, den Contracts, der Toolchain, den Tests, der Reproduzierbarkeit und in der Frage, wie viel relevantes Wissen tatsächlich im System sichtbar ist.