AI-Agenten skalieren auch schlechte Prozesse

In vielen Engineering-Organisationen wiederholt sich derzeit ein bekanntes Muster: Statt fundamentale Probleme in der Architektur, den Schnittstellen oder der Spezifikation zu lösen, wird Technologie als Abkürzung gewählt. Der aktuelle Heilsbringer sind autonome Coding-Agenten. Die Verheißung lautet: Wenn ein Entwickler mit einem LLM produktiver ist, müssen fünf spezialisierte Agenten – von der Architektur-Planung bis zum Refactoring – ein Feature in Minuten fertigstellen.

Die Praxis in Kundenprojekten zeichnet ein anderes Bild. Teams, die zuvor unter unklaren Anforderungen, fehlenden Integrationstests und schleppenden PR-Reviews gelitten haben, sind nach der Einführung von Agenten-Frameworks nicht schneller. Sie sind schlicht überlastet. Mehr Agenten lösen keine Koordinationsprobleme. Sie skalieren vor allem die Geschwindigkeit, mit der unvollständiger oder architektonisch inkonsistenter Code erzeugt wird.

Das Koordinationsproblem im Agenten-Schwarm

Das Brooks’sche Gesetz besagt: „Adding manpower to a late software project makes it later.“ Der Grund hierfür ist der exponentiell steigende Kommunikationsaufwand zwischen Individuen. Bei LLM-Agenten existiert ein direktes Äquivalent: der Kontext- und Alignment-Overhead.

Sobald mehrere Agenten autonom agieren – etwa Agent A für das API-Design, Agent B für die Datenbank-Migration und Agent C für die Frontend-Anbindung –, vervielfachen sich die Reibungsverluste:

1. Kontext-Drift: LLMs operieren auf Wahrscheinlichkeiten, nicht auf persistentem Wissen. Wenn Agent A eine implizite Annahme über das Fehlerhandling trifft, diese aber nicht explizit in die Schnittstellendefinition schreibt, rät Agent B bei der Implementierung. Das Gesamtsystem driftet auseinander.
2. Kompensationsschleifen: Ein fehlerhafter Code-Output führt oft dazu, dass nachgelagerte Fix-Agenten den Fehler nicht an der Ursache beheben, sondern Symptombekämpfung betreiben. Aus einem falschen Typen im Data Access Layer wird dann ein undurchdringlicher Wald aus Fallbacks und Typumwandlungen im Service Layer.
3. Verlagerung des Engpasses: Der Engpass moderner Softwareentwicklung ist selten die reine Tipper-Geschwindigkeit (Tastaturanschläge). Der Engpass ist das Verstehen, Validieren und Integrieren. Wenn ein System pro Stunde zehn Pull Requests generiert, aber die Senior Engineers weiterhin 45 Minuten pro Review benötigen, steigt nicht der Durchsatz, sondern nur die Work-in-Progress (WIP).

Typische Fehlermuster aus der Praxis

In Reviews von internen Plattform- und Agenten-Initiativen begegnen mir vor allem drei Kardinalfehler:

1. Das „Blackbox-Ziel“-Muster

Einem Orchestrator wird ein Ticket übergeben: „Implementiere idempotente Webhooks für Stripe-Events.“ Ohne Zwischenzustände fängt der Orchestrator an, Code zu schreiben, Tests anzulegen und Commits zu pushen. Das Ergebnis ist meist syntaktisch korrekt, bricht aber mit internen Konventionen, nutzt veraltete Libraries oder ignoriert existierende Transaktionsgrenzen. Je größer die Codebasis, desto fataler sind solche Freifahrtscheine.

2. Fehlende maschinenlesbare Verträge

Agenten interagieren häufig über unstrukturierte Prompts („Übergib die Anforderungen an Agent B“). Natürliche Sprache ist für technische Spezifikationen jedoch zu mehrdeutig. Das Resultat sind Halluzinationen an den Schnittstellen, die erst in der Laufzeitumgebung auffallen.

3. Der „Agent prüft Agent“-Zirkelschluss

Ein weit verbreiteter Irrglaube ist, dass man einen Review-Agenten einsetzen kann, um den Code eines Implementierungs-Agenten freizugeben. Wenn beide auf denselben Kontextdaten oder ähnlichen Basis-Modellen aufsetzen, teilen sie blinde Flecken. Ein Modell, das architektonische Randfälle bei der Codegenerierung übersieht, übersieht sie mit hoher Wahrscheinlichkeit auch im Review-Prompt.

Leitplanken für effektive Delivery-Governance

Wer Agenten sinnvoll in den Software-Lebenszyklus integrieren will, muss sie wie unzuverlässige Junior-Entwickler mit unendlicher Ausdauer behandeln: Sie benötigen engmaschige Governance, deterministische Guardrails und klare Rollen.

Deterministische Feedback-Schleifen statt Prompt-Chains

Agenten sollten Feedback primär von deterministischen Werkzeugen erhalten, nicht von anderen Prompts. Eine Pipeline, in der ein Agent Code schreibt, dieser sofort durch statische Codeanalyse (Linter, Typechecker), Unit-Tests und Architecture-Fitness-Functions (z. B. ArchUnit) gejagt wird und der Output bei Fehlern automatisiert an den Agenten zurückgeht, schlägt jedes Multi-Agent-Chat-Setup. Das spart Tokens, minimiert Kontextverlust und setzt harte Grenzen.

Kontraktbasierte Artefakte erzwingen

Ein Agent darf die nächste Phase erst anstoßen, wenn ein formales Artefakt existiert. Keine Implementierung ohne Schema. Bevor eine Zeile Implementierungscode entsteht, muss ein überprüfbares Zwischenergebnis vorliegen – beispielsweise eine OpenAPI-Spezifikation, ein JSON-Schema für Event-Payloads oder ein explizites ADR (Architecture Decision Record). Diese Artefakte müssen menschlich prüfbar sein.

Concurrency Caps und Scope-Begrenzung

Limitieren Sie die Autonomie. Sinnvolle Metriken für Agenten sind:

• Maximale Änderungstiefe: Beschränkung auf maximal N geänderte Dateien oder Zeilen pro Durchlauf.
• WIP-Limits: Ein Agent darf kein neues Ticket beginnen, solange der vorherige PR nicht durch CI und Review gelaufen ist.
• Explizite Tool-Rechte: Ein Agent, der Geschäftslogik implementiert, benötigt keinen Zugriff auf die Deployment-Infrastruktur oder Datenbank-Root-Credentials.

Review-Gates: Vertrauen ist gut, CI ist Pflicht

Der wichtigste Mechanismus bleibt die strikte Trennung zwischen Erzeugung und Integration. Kein Agenten-Code darf gemergt werden, ohne dass:

1. Die Pipeline deterministisch grün ist (inkl. Testabdeckung neuer Pfade),
2. Ein menschlicher Engineer den Entwurf verstanden hat,
3. Die Dokumentation synchron zur Code-Änderung aktualisiert wurde.

Fazit

AI-Agenten sind kein Ersatz für Disziplin in der Software-Architektur. Im Gegenteil: Sie verlangen ein weitaus höheres Maß an struktureller Klarheit als rein menschliche Teams. Wo Menschen Lücken im Prozess durch implizites Wissen, Nachfragen im Slack-Kanal oder Erfahrungswerte ausgleichen, laufen Agenten mit voller Geschwindigkeit gegen die Wand.

Wer die Produktivitätsvorteile von LLMs im Engineering heben will, muss zuerst die Hausaufgaben machen: Modularisierung, strenge Typisierung, automatisierte Test-Pipelines und klar definierte Domänen-Grenzen. Erst auf diesem Fundament werden Agenten vom unberechenbaren Rauschen zu einem echten Hebel.