KI und der Big Ball of Mud

Ein Big Ball of Mud ist schwer zu verstehen. User Flows verteilen sich über Komponenten, Services und globale Zustände. Seiteneffekte entstehen an Stellen, die aus der sichtbaren Struktur kaum abzuleiten sind. Vererbung verbindet Bereiche, die fachlich wenig miteinander zu tun haben. Eine scheinbar lokale Änderung kann Abhängigkeiten durch mehrere Domains hindurch berühren.

Für Menschen wird diese Form der Analyse irgendwann schlicht teuer. Nicht unbedingt deshalb, weil eine einzelne Stelle besonders kompliziert wäre. Das Problem ist die Menge potenziell relevanter Zusammenhänge, die gleichzeitig verfolgt werden muss.

Und dann kommt ein Coding Agent.

Er durchsucht das Repository, verfolgt Referenzen, öffnet Services, Base Classes und Tests, rekonstruiert Call Chains, sucht nach Schreibzugriffen auf einen Zustand und liest die nächste Datei, wenn die vorherige auf eine weitere Abhängigkeit verweist.

Der Mensch fragt irgendwann: „Warum genau bin ich jetzt eigentlich in dieser Datei?“ Der Agent öffnet einfach die nächste.

Das ist keine triviale Verbesserung. Gerade in stark gekoppelten Systemen können heutige Coding Agents Analysearbeit übernehmen, die für Menschen außerordentlich anstrengend ist. Repository-Level-Benchmarks und aktuelle Forschung beschäftigen sich deshalb längst nicht mehr nur mit der Generierung einzelner Funktionen, sondern mit Navigation, Suche, Multi-File-Reasoning, Tool-Nutzung und der Auswahl relevanten Kontexts.

Stand: August 2026. Dieser Artikel beschreibt den heutigen Stand von Coding Agents, ihren Kontextmechanismen und ihren wirtschaftlichen Rahmenbedingungen. Niemand kann seriös sagen, was solche Systeme in fünf oder zehn Jahren leisten werden. Vielleicht lautet der Auftrag irgendwann tatsächlich nur noch: „Schmeiß weg, mach neu.“ Stand August 2026 ist das keine belastbare Architekturstrategie.

Die interessante Frage lautet deshalb nicht, ob KI bei einem Big Ball of Mud helfen kann. Das kann sie bereits heute.

Die interessantere Frage lautet: Was genau verbessert sie eigentlich?

Kein Problem. Dafür haben wir jetzt KI.

Coding Agents besitzen für die Arbeit in großen Codebasen einige Eigenschaften, die hervorragend zu einem Big Ball of Mud passen. Sie können repository-weit suchen, viele Dateien untersuchen, Symbole und Referenzen verfolgen, Tests ausführen, Logs interpretieren und nach einem fehlgeschlagenen Ansatz einen anderen Pfad ausprobieren.

Vor allem müssen sie die Ergebnisse einer Analyse nicht auf dieselbe Weise dauerhaft im menschlichen Arbeitsgedächtnis halten. Ein Agent kann Kontext erneut laden, Suchschritte wiederholen, Zwischenergebnisse verdichten oder einen bereits untersuchten Pfad neu rekonstruieren.

Das bedeutet nicht, dass er das gesamte System „verstanden“ hätte. Diese Formulierung wäre zu stark. Aber ein Agent kann sehr viel expliziten Codekontext maschinell durchsuchen und schneller durch einen großen Suchraum navigieren.

Dass Repository Exploration einen erheblichen Teil heutiger Agent-Runs ausmachen kann, lässt sich inzwischen auch empirisch beobachten. Die 2026 veröffentlichte FastContext-Arbeit analysierte 300 Coding-Agent-Trajektorien auf SWE-bench Multilingual. Lesen und Suchen machten dort zusammen 56,2 Prozent der Tool-Use-Turns und 46,5 Prozent der Tokens des Hauptagenten aus. Durch das Auslagern und Verdichten dieser Exploration sank der Tokenverbrauch des Hauptmodells in den Experimenten je nach Benchmark deutlich, im besten Fall um rund 60 Prozent. Die Arbeit liegt zum Zeitpunkt dieses Artikels als Preprint vor; ihre konkreten Werte sind deshalb weder universell noch mit einer abgeschlossenen breiten Evidenzbasis gleichzusetzen. Sie zeigt aber anschaulich, dass das Auffinden relevanten Codes selbst ein messbarer Teil der Arbeit eines Coding Agents ist.

Ähnliche Ergebnisse finden sich in anderer aktueller Forschung. ContextSniper reduziert in seinen Pilotexperimenten den Tokenverbrauch bei Repository-Level-Repair deutlich, allerdings bei leicht niedrigeren Submitted-Resolution-Raten. SWE-ContextBench zeigt wiederum, dass korrekt ausgewählte und verdichtete Erfahrungen Tokenkosten und Laufzeit senken können, während unselektierter oder falsch ausgewählter Kontext wenig hilft oder sogar schadet. Auch diese Arbeiten sind noch jung; beide liegen im August 2026 als Preprints vor.

Das Grundproblem ist damit keineswegs hypothetisch:

Bevor ein Agent Code ändern kann, muss er zunächst herausfinden, welcher Code überhaupt relevant ist.

Ein Big Ball of Mud macht genau diese Frage schwierig.

Analysefähigkeit ist keine Architektur

Nehmen wir an, ein Agent rekonstruiert für ein Ticket folgenden Ablauf:

A ruft B.

B verändert C.

C löst einen Seiteneffekt in D aus.

Zusätzlich überschreibt eine gemeinsame Base Class das Verhalten und führt dadurch noch E aus.

Der Agent findet diese Kette. Er kann möglicherweise sogar erklären, weshalb sie für das Ticket relevant ist. Vielleicht ergänzt er anschließend einen Test und setzt die Änderung an der richtigen Stelle um.

Das ist wertvoll.

Aber danach existiert noch immer:

A → B → C → D → E

Die fachlichen Grenzen sind dadurch nicht klarer geworden. Verantwortlichkeiten wurden nicht neu zugeschnitten. Abhängigkeiten verlaufen nicht plötzlich gerichtet. Ein globaler Zustand ist weiterhin global. Eine Base Class, die mehrere fachliche Bereiche miteinander koppelt, koppelt sie auch nach der erfolgreichen Analyse weiterhin miteinander.

KI kann fehlende Architektur durch Analyse kompensieren. Analyse ist aber kein Ersatz für Architektur.

Einen Abhängigkeitsweg rekonstruieren zu können ist nicht dasselbe wie dafür zu sorgen, dass dieser Abhängigkeitsweg sinnvoll begrenzt ist.

Das führt zurück zu einem Mechanismus, der in dieser Serie bereits eine wichtige Rolle gespielt hat. Ein Big Ball of Mud kann erstaunlich lange funktionieren, weil Organisationen seine strukturellen Defizite kompensieren. Spezialisten kennen gefährliche Stellen. Reviews fangen Risiken ab. Regressionstests schützen kritische Pfade. Release-Prozesse werden vorsichtiger. Einzelne Personen wissen, welche scheinbar harmlose Änderung besser nicht durchgeführt wird.

Coding Agents können zu einer neuen und ausgesprochen leistungsfähigen Form dieser Kompensation werden.

Das System wird dadurch nicht unbedingt einfacher. Wir werden lediglich besser darin, trotzdem darin zu arbeiten.

Wenn die Geschichte nicht im Repository liegt

Ein zweites Problem wird gerade in alten Systemen schnell übersehen: Nicht alles, was für eine Änderung relevant ist, steht im aktuellen Code.

Warum existiert diese Sonderbehandlung? War sie die Folge eines Produktionsfehlers von 2019? Gab es damals eine technische Einschränkung, die heute nicht mehr existiert? Ist der merkwürdige zusätzliche Request ein Workaround für ein längst abgeschaltetes Backend? Bildet das if eine reale fachliche Regel ab oder lediglich eine historische Ausnahme? War diese Abhängigkeit bewusst gewählt oder das Ergebnis eines Releases unter Zeitdruck?

Ein Agent kann den vorhandenen Code analysieren. Er kann auch Git-Historie, Issues, ADRs, Dokumentation, Logs oder alte Pull Requests untersuchen, sofern ihm diese Informationen zur Verfügung stehen. Gerade darin können Agents wiederum sehr hilfreich sein: Sie können große Mengen solcher Artefakte durchsuchen und Beziehungen herstellen.

Aber die entscheidende Einschränkung lautet: Die Information muss noch irgendwo existieren.

Wenn eine Entscheidung nie dokumentiert wurde, das Ticket nicht mehr vorhanden ist, der damalige Entwickler das Unternehmen verlassen hat und nur noch der daraus entstandene Code übrig ist, kann ein Agent Hypothesen bilden. Er kann Muster erkennen und plausible Erklärungen entwickeln.

Er kann verlorene Geschichte aber nicht zuverlässig aus dem Nichts rekonstruieren.

Ein großes Context Window kann verlorene Geschichte nicht zurückholen, wenn diese Geschichte nirgends mehr gespeichert ist.

Das ist kein spezielles KI-Problem. Ein neuer menschlicher Entwickler besitzt dieselbe Grenze. Agenten verschieben lediglich die Menge an vorhandenem Material, die wirtschaftlich ausgewertet werden kann.

Und gerade deshalb wird Architektur im Agentic Coding interessant: nicht nur als Struktur des Codes, sondern als Struktur des benötigten Wissens.

Architektur als Context Compression

Gute Architektur wird häufig über Begriffe wie Wartbarkeit, Separation of Concerns, Information Hiding oder klare Verantwortlichkeiten beschrieben. Für Coding Agents lässt sich ein weiterer Blickwinkel ergänzen:

Architektur begrenzt den relevanten Suchraum.

Angenommen, eine Änderung betrifft den fachlichen Bereich planning.

In einem sauber geschnittenen System besitzt planning einen erkennbaren Slice. Seine öffentlichen Schnittstellen sind definiert. Abhängigkeiten zu anderen Bereichen verlaufen über wenige kontrollierte Grenzen. Innerhalb des Slices existieren wiederum nachvollziehbare Layer und Verantwortlichkeiten.

Ein Agent muss für eine lokale Änderung vielleicht den Planning-Slice, einige angrenzende Modelle, seine öffentlichen Schnittstellen und die relevanten Tests untersuchen. Er muss dagegen nicht sämtliche Implementierungsdetails von billing, Benutzerverwaltung, Reporting oder irgendeinem anderen unabhängigen Bereich verstehen.

Das Entscheidende an der Grenze ist deshalb nicht nur, was sie einschließt. Es ist, was sie ausschließt.

Architektur ist auch eine Ausschlussmaschine.

Sie sagt nicht nur:

Hier findest du Planning.

Sie sagt gleichzeitig:

Wenn du dich an diese Grenzen hältst, musst du für diese Änderung große Teile des restlichen Systems nicht kennen.

Das ist Information Hiding in einer für Agents unmittelbar ressourcenrelevanten Form. Modularisierung erzeugt Bereiche, deren interne Details für andere Bereiche zuverlässig irrelevant sein können. Dieses Prinzip ist wesentlich älter als LLMs. Agentic Coding gibt ihm lediglich eine zusätzliche Ressourcenperspektive.

Man kann deshalb von einer Form von Context Compression sprechen.

Nicht, weil Architektur den Quellcode physisch komprimiert. Auch ein hervorragend modularisiertes System kann Millionen Zeilen besitzen. Sie komprimiert den für eine konkrete Entscheidung benötigten Ausschnitt des Systems.

Oder einfacher:

Gute Architektur spart Kontext, weil sie Dinge zuverlässig irrelevant machen kann.

Das sollte nicht als mathematisches Gesetz missverstanden werden. Ein modularer Codebestand garantiert keinen niedrigen Tokenverbrauch. Ein komplexes Ticket kann auch in einem hervorragenden System viel Analyse verlangen. Ebenso kann eine Änderung in einem chaotischen System zufällig vollständig lokal sein.

Als informatische Logik ist der Zusammenhang trotzdem plausibel: Je besser ein Problemraum zerlegt und seine Abhängigkeiten begrenzt sind, desto kleiner kann der für eine lokale Aufgabe relevante Suchraum sein.

Aktuelle Forschung zur Kontextselektion passt bemerkenswert gut zu diesem Gedanken, auch wenn sie damit noch keinen direkten Beweis für die Architekturthese liefert. CodexGraph nutzt explizite Codegraphen für strukturorientiertes Retrieval und Navigation. CodeMEM verwendet AST-basierte Repräsentationen, um Repository- und Session-Kontext selektiv zu erhalten. SWE-ContextBench zeigt, dass korrekt ausgewählte kompakte Erfahrungen effizienter sein können als unselektierte Historie.

Die Forschung untersucht also bereits intensiv, wie Agents relevanten Kontext finden, strukturieren und verdichten können.

Die Architektur eines Systems beantwortet dieselbe Frage auf einer anderen Ebene:

Was dürfte für diese Aufgabe überhaupt relevant sein?

Gute Architektur reduziert nicht die Menge des Codes. Sie reduziert, welchen Code eine Änderung kennen muss.

Im Big Ball of Mud fehlt genau diese Grenze

Betrachten wir dieselbe Änderung in einem Big Ball of Mud.

Sie beginnt in Datei A. A verwendet Service B. B schreibt in globalen State C. Beim Schreiben reagiert eine weitere Komponente auf C. C erbt Verhalten aus einer Base Class. Die Base Class kennt Navigation, Konfiguration und Funktionen aus mehreren fachlichen Bereichen. Ein zweiter Slice verändert denselben Zustand über einen anderen Pfad. Eine selbstgebaute Infrastruktur reagiert wiederum auf einen Teil dieser Änderungen.

Für einen Agenten ist das nicht undurchsuchbar. Genau darin liegt seine Stärke. Er kann A untersuchen, B öffnen, Schreibzugriffe auf C suchen, die Vererbung verfolgen und anschließend feststellen, wer C noch verändert.

Aber jeder neu gefundene Zusammenhang kann weitere potenziell relevante Zusammenhänge erschließen.

Der Agent kann diesen Raum durchsuchen.

Aber er muss ihn durchsuchen.

In einem modularen System läuft die Analyse idealerweise irgendwann gegen eine belastbare Grenze. Eine öffentliche API, eine gerichtete Abhängigkeit oder eine Slice-Grenze erlaubt den Schluss: Dahinterliegende Details sind für diese Änderung nicht relevant.

Im Big Ball of Mud muss der Agent diese Grenze häufig erst suchen. Und möglicherweise existiert gar keine verlässliche.

Daraus folgt nicht, dass der Explorationsaufwand mathematisch exponentiell wächst. Dafür fehlt eine entsprechende Grundlage. Er kann jedoch stark zunehmen, wenn jede neu entdeckte Abhängigkeit wiederum weitere Kandidaten in den relevanten Suchraum einführt.

Aktuelle Repository-Level-Forschung zeigt zugleich, dass größere Context Windows dieses Problem nicht einfach verschwinden lassen. RepoReasoner, veröffentlicht auf der FSE 2026, untersucht explizit Cross-File-Reasoning und Call Chains. Selbst mit bereitgestelltem Oracle-Kontext bleiben anspruchsvolle Cross-File-Aufgaben schwierig; längere Kontexte verbessern die Ergebnisse nicht durchgehend, weil zusätzliches Material auch zusätzliches Rauschen enthalten kann.

Das Problem lautet also nicht einfach:

Passt das gesamte Repository in das Context Window?

Sondern:

Welcher Teil davon hilft dem Agenten bei dieser Entscheidung?

Agentic Coding ist auch in guter Architektur teuer

An dieser Stelle wäre es verführerisch, aus hohem Tokenverbrauch direkt auf schlechte Architektur zu schließen.

Das wäre falsch.

Agentic Coding kann auch in hervorragend strukturierten Systemen sehr viele Ressourcen verbrauchen. Ein Agent liest Code, erstellt einen Plan, implementiert, kompiliert, startet Tests, analysiert Fehler, korrigiert, führt Tests erneut aus, bewertet seinen Patch und reagiert auf Review-Ergebnisse. Mehrstufige Agents können zusätzlich Unteragenten starten, verschiedene Lösungsansätze verfolgen oder einen erheblichen Teil ihres Budgets in Verifikation investieren.

Die 2026 vorgestellte Tokenomics-Untersuchung analysiert Tokenverteilung in einem Multi-Agent-Softwareentwicklungsworkflow. In den dort untersuchten 30 Aufgaben entfiel im Mittel der größte Anteil auf iterative Code-Review-Schritte. Das ist eine kleine und spezifische Untersuchung und keine allgemeine Kostenformel für Agentic Coding. Sie zeigt aber, weshalb „viele Tokens“ zunächst einmal nur bedeuten kann: Der Agent hat viel gearbeitet.

Der Architekturvergleich beginnt deshalb an einer präziseren Stelle:

Wie viel zusätzlicher Aufwand entsteht ausschließlich dadurch, dass der Agent zunächst herausfinden muss, welcher Teil des Systems für eine Aufgabe überhaupt relevant ist?

Gute Architektur minimiert nicht den Tokenverbrauch. Sie kann aber den Anteil reduzieren, der ausschließlich dafür notwendig ist, das System für eine lokale Änderung erneut zu erschließen.

Der relevante Unterschied lautet deshalb nicht billig gegen teuer, sondern eher produktiver Kontext gegen Explorationskosten.

Und trotzdem kann die KI noch ein weiteres if setzen

Jetzt kommt das nächste Ticket.

Ein bestimmter Zustand soll unter drei zusätzlichen Randbedingungen anders behandelt werden. Im bestehenden System gibt es bereits zahlreiche ähnliche Sonderfälle.

Ein Coding Agent kann diese Bedingungen suchen. Er findet die Stellen, an denen derselbe Zustand gelesen und verändert wird. Er erkennt vorhandene Konventionen. Er ergänzt den Sonderfall an der Stelle, an der er mit dem geringsten Risiko in das bestehende Verhalten passt. Anschließend erweitert er Tests.

Die Tests sind grün. Das Ticket ist erledigt.

Und möglicherweise ist im System gerade Sonderfall Nummer 38 entstanden.

Ein Agent kann sehr schnell gute lokale Lösungen finden. Genau das war historisch schon Teil des Problems.

Der vorherige Artikel dieser Serie über die Entstehung eines Big Ball of Mud hat genau diesen Mechanismus betrachtet: Niemand setzt sich morgens hin und beschließt, eine unverständliche Architektur zu bauen. Viele einzelne Entscheidungen können lokal vollkommen rational sein. Unter Zeitdruck wird die vorhandene Struktur erweitert. Die Lösung funktioniert. Ein weiterer Sonderfall kommt hinzu. Konsolidierung findet später nicht statt.

Der Coding Agent ändert daran zunächst nichts.

Das bedeutet nicht, dass er schlechte Arbeit geleistet hat. Im Gegenteil. Er kann exakt die Aufgabe erfüllt haben, die ihm gestellt wurde:

Implementiere dieses Ticket mit möglichst geringem Risiko im bestehenden System.

Wenn die lokal sicherste Änderung ein weiteres if ist, kann ein guter Agent sehr effizient genau dieses if finden.

Das Problem ist die Ebene der Optimierung. Ein lokal optimierter Patch ist keine automatische Architekturverbesserung.

Eine erfolgreiche Änderung ist noch keine strukturelle Verbesserung.

KI als neue Kompensationsschicht

Damit entsteht eine für Big-Ball-of-Mud-Systeme interessante Hypothese.

Solche Systeme konnten bisher unter anderem deshalb lange weiterentwickelt werden, weil ihre Defizite durch andere Mechanismen aufgefangen wurden: erfahrene Spezialisten kannten gefährliche Stellen, umfangreiche Regressionstests sicherten Änderungen ab, Reviews kompensierten fehlende lokale Verständlichkeit, Release-Rituale senkten Risiken, Personenwissen ersetzte Dokumentation und Workarounds überbrückten strukturelle Defizite.

Agentische Analyse kann nun als weitere Kompensationsschicht hinzukommen.

Sie beseitigt die Entgrenzung nicht. Aber sie senkt zunächst den Aufwand, trotz dieser Entgrenzung eine konkrete Änderung durchführen zu können.

Daraus ergibt sich eine wirtschaftlich interessante Möglichkeit:

KI könnte den ökonomischen Kipppunkt eines Big Ball of Mud nach hinten verschieben.

Ein System, dessen Änderungen für Menschen allein bereits unverhältnismäßig teuer geworden wären, kann mit agentischer Unterstützung möglicherweise länger produktiv weiterentwickelt werden.

Das ist derzeit eine Hypothese und kein nachgewiesenes Gesetz. Gerade der direkte Vergleich zwischen unterschiedlich strukturierten realen Codebasen ist wissenschaftlich noch unzureichend untersucht.

Als Mechanismus ist er jedoch plausibel: Wenn die Analyse des Systems teuer ist und ein neues Werkzeug diese Analyse billiger macht, sinken zunächst die Kosten einer Änderung. Das zugrunde liegende System muss dafür nicht besser geworden sein.

Der Big Ball of Mud wird dadurch nicht gesund. Er bleibt nur länger arbeitsfähig.

KI kann die Folgen fehlender Struktur kompensieren, ohne die Struktur selbst zu verändern.

Ein Monatskontingent an einem Tag

Ich habe diese Verschiebung selbst in einem besonders stark entgrenzten System erlebt.

Innerhalb eines Arbeitstags war ein Agent-Kontingent aufgebraucht, das bei meinem damaligen Windsurf-Tarif ungefähr für einen Monat vorgesehen war.

Ich hatte den Agenten nicht beauftragt, das System neu zu schreiben. Ich hatte ihn im Wesentlichen damit beschäftigt, es zu verstehen.

Er suchte, las Dateien und verfolgte Abhängigkeiten. Neue Funde führten zu weiteren Dateien. Annahmen mussten überprüft und teilweise wieder verworfen werden. Der Agent konnte diese Arbeit durchführen und war darin ausgesprochen hilfreich.

Nur war die Analyse nicht kostenlos.

Dieses Erlebnis ist keine empirische Grundlage für eine allgemeine Kostenfunktion. Daraus lässt sich weder ableiten, dass jeder Big Ball of Mud ähnlich viele Tokens benötigt, noch dass ein modularer Vergleichscodebestand einen bestimmten Faktor günstiger gewesen wäre.

Als Beobachtung ist es trotzdem interessant. Denn ein Teil der Komplexitätskosten, der früher fast ausschließlich als menschliche Analysezeit sichtbar geworden wäre, materialisierte sich plötzlich in einer anderen Ressource: Agent-Kontingent.

Das war für mich der Moment, an dem „Architektur als Context Compression“ von einer theoretischen Überlegung zu einer ziemlich konkreten wirtschaftlichen Frage wurde.

Was die Forschung heute bereits zeigt – und was noch nicht

Die Forschung zu Coding Agents entwickelt sich derzeit so schnell, dass dieser Abschnitt wahrscheinlich früher altert als viele andere Teile dieser Serie. Stand August 2026 lassen sich trotzdem mehrere Ebenen relativ sauber auseinanderhalten.

Repository Exploration besitzt messbare Kosten

Dass Agents relevante Dateien und Codebereiche zunächst lokalisieren müssen, ist längst Bestandteil von Repository-Level-Forschung. FastContext misst einen erheblichen Anteil von Read- und Search-Aktivitäten an Tool Calls und Tokenverbrauch. ContextSniper reduziert Tokenmengen, indem Repository- und Tool-Ausgaben selektiert werden. CodexGraph verwendet explizite strukturelle Repräsentationen des Repositorys, um Navigation und Retrieval zu unterstützen.

Die konkreten Zahlen sind nicht universell übertragbar. Unterschiedliche Modelle, Agent-Harnesses, Benchmarks und Aufgaben erzeugen unterschiedliche Trajektorien.

Die grundsätzlich relevante Beobachtung bleibt aber:

Exploration ist keine kostenlose Vorstufe der eigentlichen Programmierung. Sie ist ein Teil der Agent-Arbeit.

Kontextauswahl ist wichtiger als maximale Kontextmenge

Die 2025 in den Findings of NAACL veröffentlichte RepoExec-Arbeit zeigt, dass Repository-Level-Codegenerierung stark von geeignetem Dependency-Kontext abhängt. Andere aktuelle Arbeiten untersuchen deshalb explizit, wie relevante Informationen ausgewählt, strukturiert oder über mehrere Interaktionen erhalten werden können.

SWE-ContextBench berichtet, dass korrekt ausgewählte und zusammengefasste frühere Erfahrungen Laufzeit und Tokenkosten reduzieren können, während unselektierter Kontext geringere oder negative Effekte besitzt. LoCoBench-Agent beobachtet wiederum einen Trade-off zwischen gründlicher Exploration und Effizienz: Mehr Exploration kann das Verständnis verbessern, kostet aber zusätzliche Interaktionen und Ressourcen. Beide Arbeiten liegen zum Zeitpunkt dieses Artikels als Preprints vor.

Auch ein großes Context Window hebt dieses Problem nicht auf. RepoReasoner zeigt bei komplexen Cross-File-Aufgaben weiterhin deutliche Grenzen und berichtet, dass längerer Kontext nicht konsistent bessere Ergebnisse erzeugt, wenn zusätzliches Rauschen hinzukommt.

Strukturierte Repräsentationen können helfen

Mehrere Arbeiten versuchen inzwischen, Repository-Struktur expliziter für Agents nutzbar zu machen.

CodexGraph modelliert Codebeziehungen als Graph und erlaubt strukturorientierte Abfragen. CodeMEM nutzt AST-basierte Speicherstrukturen für Repository- und Session-Kontext. Eine weitere Studie aus Juni 2026 untersuchte ergänzende visuelle Repository-Graphen; in den dort getesteten Szenarien sank der Input-Tokenverbrauch um bis zu 26 Prozent, wenn solche Graphen zusätzlich zu textuellen Werkzeugen eingesetzt wurden und die Erfolgsrate dabei erhalten blieb oder stieg. Die betreffende Arbeit liegt als Preprint vor.

Das ist noch kein Beleg für „saubere Architektur spart X Prozent Tokens“.

Es zeigt aber, dass die Strukturierung und Eingrenzung von Repository-Kontext empirisch relevant ist.

Der direkte Architekturvergleich fehlt noch

Für die zentrale These dieses Artikels muss deshalb eine Grenze gezogen werden.

Bei der Recherche für diesen Artikel habe ich keine kontrollierte Studie gefunden, die funktional vergleichbare Softwaresysteme mit deutlich unterschiedlicher innerer Architektur – etwa ein konsequent modularisiertes System gegenüber einer stark entgrenzten Big-Ball-of-Mud-Struktur – unter identischen Coding-Agent-Aufgaben untersucht und anschließend Tokenverbrauch, Tool Calls oder Explorationsaufwand vergleicht.

Das ist wichtig.

Wir können aus heutiger Forschung belastbar sagen, dass Repository Exploration Ressourcen benötigt, dass irrelevanter Kontext problematisch sein kann und dass bessere Selektion beziehungsweise strukturierte Repräsentationen messbare Effizienzvorteile erreichen können.

Wir können daraus noch keine empirisch abgesicherte Formel ableiten wie:

Ein Big Ball of Mud kostet einen Coding Agent fünfmal mehr Tokens.

Und schon gar nicht:

Big Balls of Mud verbrauchen exponentiell mehr Tokens.

Diese Evidenz liegt Stand August 2026 nicht vor.

Die These dieses Artikels bleibt deshalb auf drei Ebenen:

1. Informatische Logik: Begrenzte Abhängigkeiten können den für eine lokale Aufgabe potenziell relevanten Suchraum begrenzen.
2. Angrenzende empirische Evidenz: Repository Exploration, Kontextauswahl und lange Agent-Trajektorien besitzen messbare Token-, Laufzeit- und Tool-Kosten.
3. Offene Forschungsfrage: Wie stark sich unterschiedliche Softwarearchitekturen bei ansonsten vergleichbaren Aufgaben tatsächlich auf den Ressourcenverbrauch von Coding Agents auswirken.

Diese Ebenen sollte man nicht miteinander verwechseln – gerade weil die Hypothese plausibel klingt.

Die Rechnung kommt zunehmend in Tokens, Context und Compute

Die Kosten schlechter Architektur sind nicht neu. Sie wurden bisher nur in anderen Einheiten sichtbar.

Entwickler benötigen länger für Analyse und Änderungen. Lead Times steigen. Fehler und Regressionen werden wahrscheinlicher. Onboarding dauert länger. Spezialisten werden zu Engpässen. Reviews werden aufwendiger. Releases benötigen zusätzliche Absicherung.

Agentic Coding fügt diesem Kostenmodell weitere Ressourcen hinzu: Input Tokens, Output Tokens, Cached Context, Retrieval, Tool Calls, Agent Runs, Compute, Laufzeit und anschließend weiterhin menschliche Reviews und Korrekturschleifen.

Nicht alle diese Ressourcen werden von jedem Anbieter separat abgerechnet. Einige werden gebündelt, andere durch Caching günstiger, wieder andere verschwinden hinter Kontingenten oder Pauschalen. Technisch verbraucht werden sie trotzdem.

Der Big Ball of Mud wird durch KI nicht kostenlos verständlich. Wir bezahlen nur zunehmend nicht mehr ausschließlich mit menschlicher Aufmerksamkeit.

Daraus entsteht eine interessante, derzeit noch hypothetische Beobachtungsgröße für Technical Debt.

Bisher ist schwer messbar, wie viel „Systemverständnis“ eine bestimmte Änderung benötigt. Coding Agents erzeugen dagegen immer detailliertere Nutzungsdaten: Tokens, Cache-Nutzung, Tool Calls, Agent-Laufzeit, Kontextgrößen und Explorationstrajektorien.

Damit könnte ein bislang sehr schwer sichtbarer Teil von Technical Debt in Zukunft zumindest teilweise messbarer werden:

Wie viel maschinellen Kontext benötigt dieses System, bevor eine lokale Änderung hinreichend sicher durchgeführt werden kann?

Das wäre keine universelle Architekturmetrik. Ein schwieriges Feature bleibt schwierig, auch wenn das System gut strukturiert ist. Modelle und Agent-Harnesses unterscheiden sich erheblich. Und ein Token ist keine standardisierte Einheit kognitiver Komplexität.

Als zusätzliche Beobachtungsgröße könnte der Wert trotzdem interessant werden.

KI beseitigt Komplexitätskosten nicht zwangsläufig. Sie kann einen Teil davon in maschinelle Verarbeitung verschieben.

Der Flat-Rate-Effekt

Dieser Zusammenhang war lange erstaunlich leicht zu übersehen.

Ein Entwickler bezahlt einen monatlichen Betrag für ein KI-Werkzeug. Er arbeitet damit an mehreren Tickets. Am Monatsende erscheint dieselbe Abogebühr.

Aus Sicht des Entwicklers sieht die Kostenfunktion deshalb zunächst sehr einfach aus:

KI kostet X Euro pro Monat.

Das sagt jedoch wenig darüber aus, wie viel maschinelle Arbeit für eine konkrete Änderung durchgeführt wurde.

Abomodelle abstrahieren den tatsächlichen Ressourcenverbrauch über inkludierte Nutzung, Credits, Session- oder Wochenlimits, Fair-Use-Regeln und unterschiedliche Modellklassen. Nach Überschreiten dieser Grenzen kann zusätzliche Nutzung begrenzt oder verbrauchsabhängig berechnet werden.

Die Entwicklung der großen Anbieter im Jahr 2026 zeigt deutlich, dass diese Trennung zwischen Pauschale und tatsächlichem Verbrauch gerade neu austariert wird.

GitHub stellte Copilot zum 1. Juni 2026 für die regulären Tarife auf eine Nutzung nach GitHub AI Credits um. Die Berechnung basiert auf Input-, Output- und Cached Tokens sowie den jeweiligen Modellpreisen. GitHub begründete die Änderung ausdrücklich damit, dass lange agentische Sessions wesentlich höhere Compute- und Inference-Anforderungen erzeugen und das bisherige Premium-Request-Modell diese Unterschiede nicht nachhaltig abgebildet habe. Für einzelne Jahresabonnements galt das alte Request-Modell vorübergehend weiter.

Gerade dieses Legacy-Modell liefert ein anschauliches Beispiel dafür, wie vorsichtig man bei Zahlen sein muss. Für GPT-5.5 weist GitHub im August 2026 für verbleibende jährliche Legacy-Tarife einen Premium-Request-Multiplikator von 57 aus.

Das bedeutet nicht, dass „GPT-5.5-Tokens 57-mal teurer geworden“ wären.

Der Faktor gehört zu einer spezifischen Abrechnungseinheit eines auslaufenden Request-Modells. Tokenpreis, Request-Multiplikator, inkludierte Credits und tatsächliche Inference-Kosten sind unterschiedliche Größen.

Dasselbe Grundmuster – inkludierte Nutzung plus stärker verbrauchsorientierte Erweiterungen – findet sich inzwischen auch anderswo.

OpenAI stellte die Codex-Abrechnung im April 2026 auf eine direkt an Input-, Cached-Input- und Output-Tokens gekoppelte Credit-Rate-Card um. Codex bleibt in mehreren ChatGPT-Tarifen enthalten; nach Erreichen inkludierter Limits können je nach Tarif zusätzliche Credits verwendet werden. Die tatsächliche Credit-Nutzung hängt damit unmittelbar vom Tokenmix einer Aufgabe ab.

Anthropic kombiniert bei Claude kostenpflichtige Tarife ebenfalls mit Nutzungsgrenzen. Claude und Claude Code teilen sich bei individuellen Plänen die verfügbaren Usage Limits; nach deren Erreichen können Nutzer je nach Tarif Usage Credits aktivieren oder auf verbrauchsabhängige API-Nutzung wechseln. Anthropic weist außerdem darauf hin, dass Nutzung unter anderem von Länge und Komplexität der Interaktion, Modell und verwendeten Funktionen abhängt.

Das bedeutet nicht, dass heutige Abonnements für Anbieter zwangsläufig Verlustgeschäfte wären. Dazu fehlen uns die notwendigen internen Kosten- und Nutzungsdaten.

Es bedeutet nur:

Der Preis eines Abonnements und die tatsächlich für eine Aufgabe benötigte maschinelle Arbeit sind nicht dieselbe Größe.

Wenn die Architekturkosten im Abo verschwinden

Stellen wir uns zwei Teams vor.

Team A arbeitet in einem modularen System mit klaren fachlichen Grenzen und gerichteten Abhängigkeiten. Team B arbeitet in einem stark entgrenzten System. Beide verwenden dasselbe Coding-Agent-Produkt.

Wenn beide lediglich dieselbe monatliche Abogebühr auf der Kostenstelle sehen, sehen ihre KI-Kosten zunächst identisch aus.

Das heißt nicht, dass auch der Ressourcenverbrauch identisch ist.

Team A könnte einen großen Anteil seines Agent-Budgets für Implementierung, Tests und Review einsetzen. Team B könnte einen größeren Anteil dafür benötigen, zunächst herauszufinden, welche Dateien, Services, Zustände und Seiteneffekte überhaupt relevant sind.

Ob dieser Unterschied in realen Systemen klein oder sehr groß ist, wissen wir empirisch noch nicht.

Die wirtschaftliche Logik verändert sich jedoch, sobald Verbrauch transparenter und stärker nutzungsabhängig abgerechnet wird. Dann können zusätzliche Repository-Suchen, größere Kontextmengen, weitere Agent-Runs oder längere Compute-Zeit – je nach Produkt und Abrechnungsmodell – unmittelbar kostenrelevant werden.

Und damit könnte etwas sichtbarer werden, das vorher häufig in Entwicklerzeit, Frustration und implizitem Spezialistenwissen verborgen war.

Die Kosten schlechter Architektur verschwinden nicht. Ein pauschaler KI-Tarif kann lediglich verdecken, in welcher Einheit sie gerade bezahlt werden.

Vielleicht werden wir Technical Debt deshalb in einigen Jahren anders diskutieren. Nicht nur:

Wie lange benötigt ein Entwickler für diese Änderung?

Sondern zusätzlich:

Wie viel Kontext und maschinelle Exploration benötigt unser Entwicklungssystem, um diese Änderung überhaupt einzugrenzen?

Der Big Ball of Mud war schon immer teuer. Agentic Coding könnte dafür sorgen, dass ein Teil dieser Rechnung künftig nicht mehr nur in Stunden, sondern auch in Tokens und Compute gestellt wird.

„Der Agent kommt doch damit klar“

Genau hier liegt möglicherweise der gefährlichste Trugschluss.

Angenommen, Änderungen in einem problematischen Legacy-System dauerten früher mehrere Tage. Mit einem guten Coding Agent funktionieren ähnliche Tickets plötzlich wieder in Stunden.

Das ist ein realer Produktivitätsgewinn.

Aus Managementperspektive liegt jedoch eine verführerische Interpretation nahe:

Dann ist das Architekturproblem offenbar gar nicht mehr so relevant.

Denn die sichtbaren Symptome werden kleiner. Der Entwickler muss nicht mehr zwei Tage durch das Repository navigieren. Der Agent übernimmt einen erheblichen Teil der Navigation, findet den globalen State, entdeckt die Base Class, rekonstruiert den Seiteneffekt, erzeugt einen Test und implementiert den nächsten Sonderfall.

Das System liefert wieder schneller.

Aber dadurch wurden keine Slices wiederhergestellt, keine Layer eingeführt, Ownership geklärt, globale Abhängigkeiten reduziert, historische Workarounds entfernt oder eine Zielarchitektur geschaffen.

Dass ein Agent einen Weg durch das System findet, bedeutet nicht, dass das System wieder eine tragfähige Struktur besitzt.

Vielleicht ist sogar das Gegenteil organisatorisch denkbar. Je erfolgreicher KI die Symptome eines Big Ball of Mud kompensiert, desto geringer kann kurzfristig der wirtschaftliche Druck werden, seine strukturellen Ursachen anzugehen.

Auch das ist zunächst eine Hypothese. Aber sie folgt demselben Muster, das den Big Ball of Mud schon vorher stabilisiert hat: Solange Kompensationsmechanismen günstig genug sind, kann das bestehende System rational weiterbetrieben werden.

Coding Agents verändern deshalb womöglich nicht nur unsere Produktivität. Sie verändern den Zeitpunkt, an dem schlechte Architektur wirtschaftlich untragbar wird.

Kann KI auch beim Weg hinaus helfen?

Ja – und wahrscheinlich erheblich.

Dieselben Fähigkeiten, die einen Agenten zu einer so wirkungsvollen Kompensationsschicht machen, sind für Architekturarbeit ausgesprochen interessant. Ein Agent kann Dependency-Strukturen analysieren, Change Coupling aus Historien untersuchen, User Flows rekonstruieren, Gravitationszentren im Code identifizieren, Tests erzeugen, Refactorings absichern und bei einer schrittweisen Migration wiederholt überprüfen, welche Abhängigkeiten eine neue Grenze noch verletzen.

Auch Architecture Recovery ist ein naheliegendes Einsatzgebiet. Wenn ein System seine sichtbare Architektur verloren hat, können maschinelle Analysen dabei helfen, seine tatsächlich wirksamen Strukturen wieder sichtbar zu machen. Aktuelle Forschung zu Codegraphen, Repository-Repräsentationen und kontextbewusster Navigation zeigt, dass genau solche strukturellen Informationen für Agents nützlich sein können.

Der Unterschied liegt deshalb weniger im Werkzeug als im Auftrag.

„Implementiere dieses Ticket im bestehenden System.“

nutzt die Fähigkeiten des Agents primär als Kompensationsmechanismus.

„Hilf mir, die Struktur dieses Systems zu verstehen und belastbare Grenzen wiederherzustellen.“

nutzt dieselben Fähigkeiten für Architekturarbeit.

Beides kann sinnvoll sein. Es sind nur zwei vollkommen unterschiedliche Ziele.

Wie man einen Big Ball of Mud analysiert, welche Grenzen sich überhaupt wiederherstellen lassen und wann Sanierung gegenüber Ersatz wirtschaftlich sinnvoll ist, gehört deshalb in die späteren Handlungsartikel dieser Serie.

Was KI am Big Ball of Mud tatsächlich verändert

KI erzeugt beim Big Ball of Mud eine bemerkenswerte Ambivalenz.

Sie kann Systeme weiter veränderbar halten, deren Analyse für Menschen allein bereits extrem teuer geworden ist. Sie kann mehr Code in kürzerer Zeit untersuchen, Referenzen verfolgen, Randbedingungen zusammentragen und Abhängigkeiten rekonstruieren. Sie kann Tests ergänzen und lokale Änderungen mit einer Geschwindigkeit durchführen, die in manchen Legacy-Systemen vor wenigen Jahren kaum vorstellbar gewesen wäre.

Das ist viel. Und es wäre falsch, diese Fähigkeiten kleinzureden.

Gleichzeitig verschwinden die strukturellen Probleme dadurch nicht. Der Agent muss die fehlenden Grenzen weiterhin kompensieren. Er muss Kontext suchen, auswählen und verarbeiten. Er benötigt Tool Calls, Tokens, Compute und Laufzeit. Und solange das nächste Ticket wieder funktioniert, kann ausgerechnet diese erfolgreiche Kompensation den unmittelbaren Druck reduzieren, das zugrunde liegende Architekturproblem überhaupt noch anzugehen.

KI kann einen Big Ball of Mud deshalb besser bearbeitbar machen, ohne ihn dadurch weniger zu einem Big Ball of Mud zu machen.

Ob zukünftige Coding Agents große Legacy-Systeme weitgehend autonom analysieren, ihre verborgenen fachlichen Modelle rekonstruieren und sichere strukturelle Transformationen durchführen können, ist offen. Stand August 2026 sind wir nicht an diesem Punkt.

Was wir heute bereits sehen, ist subtiler:

KI könnte nicht das Ende des Big Ball of Mud bedeuten, sondern zunächst seine Lebensdauer verlängern.

Der Agent findet heute erstaunlich viele Wege durch den Schlamm. Trocken wird der Boden davon noch nicht.

Quellen und Forschungsstand

Die folgenden Arbeiten und Anbieterinformationen bilden die wesentliche Grundlage für die zeitabhängigen Aussagen dieses Artikels:

• Parnas, D. L. (1972): On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM 15(12), 1053–1058. DOI: 10.1145/361598.361623.
• Le Hai, N.; Nguyen, D. M.; Bui, N. D. Q. (2025): On the Impacts of Contexts on Repository-Level Code Generation. Findings of NAACL 2025, 1496–1524. DOI: 10.18653/v1/2025.findings-naacl.82.
• Liu, X. et al. (2025): CodexGraph: Bridging Large Language Models and Code Repositories via Code Graph Databases. NAACL 2025, 142–160. DOI: 10.18653/v1/2025.naacl-long.7.
• Wang, P.; Zhang, L.; Liu, F.; Tao, C.; Zhu, Y. (2026): CodeMEM: AST-Guided Adaptive Memory for Repository-Level Iterative Code Generation. Findings of ACL 2026, 16903–16917. DOI: 10.18653/v1/2026.findings-acl.834.
• Wang, Y. et al. (2026): RepoReasoner: Evaluating Repository-Level Code Reasoning Ability of Long-Context Language Models. FSE 2026.
• Qiu, J. et al. (2025): LoCoBench-Agent: An Interactive Benchmark for LLM Agents in Long-Context Software Engineering. arXiv:2511.13998 (Preprint).
• Zhu, J.; Hu, M.; Wu, J. (2026): SWE Context Bench: A Benchmark for Context Learning in Coding. arXiv:2602.08316 (Preprint).
• Zhang, S. et al. (2026): FastContext: Training Efficient Repository Explorer for Coding Agents. arXiv:2606.14066 (Preprint).
• Luk, C. et al. (2026): ContextSniper: AntTrail’s Token-Efficient Code Memory for Repository-Level Program Repair. arXiv:2607.01916 (Preprint).
• Ma, D. et al. (2026): LLM Agents Can See Code Repositories. arXiv:2606.14061 (Preprint).
• Salim, M.; Latendresse, J.; Khatoonabadi, S.; Shihab, E. (2026): Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering. arXiv:2601.14470 (Preprint).
• GitHub (2026): GitHub Copilot is moving to usage-based billing sowie Model multipliers for annual plans on request-based billing (legacy).
• OpenAI (Stand August 2026): Codex rate card und Dokumentation zu Credits für zusätzliche Codex-Nutzung.
• Anthropic (Stand August 2026): Dokumentation zu Claude Code usage and limits und Usage Credits für kostenpflichtige Claude-Pläne.