Domain-Driven Agents: Warum KI-Modelle an technischer Schuld scheitern und wie Code für Agenten optimiert wird

Die wichtigsten Punkte

• Produktivitätsunterschiede: LLMs bieten enorme Vorteile in neuen (Greenfield) Projekten, scheitern aber oft an der Komplexität gewachsener Legacy-Systeme.
• Das Muster des Scheiterns: In Brownfield-Projekten erfinden Modelle oft redundante Begriffe oder wählen falsche architektonische Ansätze, da das System keine eindeutigen Antworten liefert.
• Zwei Ebenen der Problematik: Unter der offensichtlichen technischen Schuld liegt eine tiefere Schicht aus Verwirrung, fehlender Bedeutung und dem Mangel an einer gemeinsamen Sprache.
• Code-Readiness statt Modell-Upgrade: Nicht die KI-Modelle müssen verbessert werden, sondern die Codebasis muss schrittweise für den Einsatz von Agenten vorbereitet werden.
• Inkrementelle Verbesserung: Die Vorbereitung des Codes auf KI-Agenten kann stückweise erfolgen, um die Bedeutungslücken im System zu schließen.

Analyse

Die Herausforderung der Brownfield-Projekte

In den letzten Jahren hat der Einsatz von Large Language Models (LLMs) im Software-Engineering, insbesondere beim Coding, stark zugenommen. Die Erfahrung zeigt jedoch eine deutliche Trennung zwischen verschiedenen Projekttypen. In „Greenfield“-Projekten – also Neuentwicklungen auf der grünen Wiese – sowie in kleinen Projekten funktionieren LLMs hervorragend und sorgen für einen spürbaren Produktivitätsschub.

Die Realität des Arbeitsalltags sieht jedoch meist anders aus. Entwickler müssen KI-Agenten in bestehende „Brownfield“-Codebasen integrieren. Diese zeichnen sich oft durch schwere Abhängigkeitsbäume, starke Kopplung und einen umfangreichen Backlog an technischer Schuld aus. In diesem Umfeld sinkt die Qualität der von LLMs gelieferten Arbeit rapide ab. Das Modell stößt an Grenzen, die nicht durch seine Rechenleistung, sondern durch die Beschaffenheit des vorliegenden Codes definiert werden.

Das spezifische Fehlermuster von KI-Agenten

Das Scheitern von KI-Modellen in komplexen Systemen folgt einem spezifischen Muster. Wenn ein Entwickler in einem neuen Repository nach einem neuen Feld wie einem „Job-Status“ fragt, liefert das Modell in der Regel ein korrektes Ergebnis. In einem System, das jedoch bereits seit mehreren Jahren in Betrieb ist, zeigt sich ein anderes Bild: Das Modell erfindet beispielsweise eine vierte Schreibweise für ein Konzept, das im Code bereits in drei verschiedenen Varianten existiert. Dies geschieht, weil die Codebasis selbst keine klare Entscheidung darüber trifft, welche Definition die „echte“ ist.

Zudem treffen Modelle oft falsche architektonische Entscheidungen. Sie schreiben beispielsweise einen Adapter, wo ein direkter Aufruf angemessen gewesen wäre, oder sie rufen Funktionen direkt auf, obwohl ein Adapter zwingend erforderlich gewesen wäre. Jede dieser Fehlentscheidungen resultiert aus einer Frage an das System, die das System selbst an keiner Stelle eindeutig beantwortet. In Ermangelung klarer Strukturen beginnt das Modell zu raten – und rät oft falsch.

Die tiefere Ebene: Fehlende Bedeutung und Sprache

Die Analyse verdeutlicht, dass technische Tiefe nur die erste Schicht des Problems darstellt. Darunter liegt eine zweite, kritischere Ebene: Verwirrung und das Fehlen einer geteilten Sprache. Wenn ein System keine konsistente Bedeutung vermittelt, hat das Modell keine Grundlage für logische Schlussfolgerungen.

Der Autor argumentiert, dass in solchen Fällen nicht das KI-Modell das Problem ist, das ein Upgrade benötigt. Stattdessen ist der Code schlichtweg nicht „bereit“ für die KI. Diese „Readiness“ ist jedoch nichts Statisches, sondern etwas, das aktiv und schrittweise aufgebaut werden kann. Anstatt das gesamte System auf einmal zu sanieren, kann die Bedeutungsebene des Codes Stück für Stück verbessert werden, um eine solide Basis für den Einsatz von KI-Agenten zu schaffen.

Bedeutung für die KI-Branche

Die Erkenntnisse aus der Praxis der „Domain-Driven Agents“ markieren einen wichtigen Wendepunkt in der Diskussion um KI-gestützte Softwareentwicklung. Bisher lag der Fokus stark auf der Verbesserung der Modelle (LLMs) selbst – etwa durch größere Kontextfenster oder bessere Reasoning-Fähigkeiten. Die vorliegende Analyse verschiebt den Fokus auf die Qualität und Struktur der Datenquelle, in diesem Fall den Quellcode.

Für die KI-Branche bedeutet dies, dass der Erfolg von KI-Agenten in Unternehmen weniger von der Wahl des Modells abhängt, sondern vielmehr von der internen Software-Architektur. Unternehmen, die KI-Agenten effektiv nutzen wollen, müssen in die Bereinigung ihrer Legacy-Systeme investieren und eine „geteilte Sprache“ (Shared Language) im Code etablieren. Dies rückt Konzepte wie Domain-Driven Design (DDD) wieder stärker in den Fokus, da sie die notwendige semantische Klarheit schaffen, die KI-Modelle benötigen, um präzise und fehlerfrei zu arbeiten.

Häufig gestellte Fragen

Warum funktionieren LLMs in neuen Projekten besser als in alten?

In neuen Projekten (Greenfield) gibt es weniger widersprüchliche Informationen und keine gewachsene technische Schuld. Das Modell kann klare Strukturen ohne Altlasten aufbauen. In alten Projekten (Brownfield) führen Inkonsistenzen dazu, dass das Modell raten muss, was zu Fehlern und Redundanzen führt.

Was ist mit der „zweiten Ebene“ der technischen Schuld gemeint?

Neben der rein technischen Komplexität (Abhängigkeiten, Kopplung) beschreibt die zweite Ebene den Verlust von Bedeutung und Klarheit. Wenn im Code nicht mehr ersichtlich ist, welche Konzepte wie zusammenhängen oder welche Begriffe aktuell sind, fehlt dem KI-Modell die semantische Basis für korrekte Entscheidungen.

Kann man eine alte Codebasis für KI-Agenten optimieren?

Ja, der Prozess der „Readiness“ kann laut Originalmeldung inkrementell erfolgen. Es ist nicht notwendig, das gesamte System sofort zu refactoren. Stattdessen kann man Stück für Stück Klarheit schaffen und eine geteilte Sprache im Code etablieren, um die Arbeitsgrundlage für Agenten zu verbessern.