Roo-Code-AI-Team in Schräglage

In meinem Beitrag Dev-Team in Roo Code habe ich beschrieben, wie aus einer chaotischen Sammlung von AI-Tools ein strukturiertes Entwicklungsteam mit 15 spezialisierten Modi entstand. Im Beitrag Agile Team in Roo Code ging es dann um das ausgeklügelte Handover-System, Quality Gates und die theoretischen Grundlagen.

Doch die Realität sieht oft anders aus als die Theorie. In diesem Teil der Reihe teile ich die Probleme, die während der intensiven Entwicklungsphase auftraten, und die Learnings, die daraus entstanden. Spoiler: 36,4 % aller Commits waren Refactoring-Commits – und das aus gutem Grund. Die Entwicklung eines Multi-Agent-Systems ist ein iterativer Prozess, bei dem man mehr durch das Lösen von Problemen lernt als durch das initiale Design.

Kurze Unterbrechung – wo wir unsere Erfahrung sammeln

Mayflower Labs

Wir arbeiten nicht nur intensiv an KI-Projekten, sondern setzen auch massiv auf R&D. Unsere R&D-Projekte werden aber nicht in Schubladen verstaut. Sie lösen echte Kundenprobleme und fließen direkt in produktionsreife Lösungen ein.

Wirf einen Blick in den Maschinenraum

Bevor wir in die Problemanalyse einsteigen, eine erfreuliche Entwicklung: Kurz nach dem Schreiben der ersten beiden Artikel entdeckte ich das RunVSAgent-Plugin für JetBrains IDEs. In meinem ersten Beitrag hatte ich beschrieben, wie der Wechsel von JetBrains zu VSCode für mich ein notwendiges Übel war – ich war seit Jahren überzeugter JetBrains-Nutzer und der Umstieg fühlte sich wie ein Verlust an. Mit RunVSAgent konnte ich nun wieder in meinen geliebten IDEs arbeiten – PyCharm, PHPStorm, WebStorm – und trotzdem Roo Code nutzen. Der narrative Bogen schließt sich: JetBrains → VSCode → JetBrains. Manchmal lösen sich Probleme auf unerwartete Weise, wenn man ihnen Zeit gibt.

Die größte Architektur-Änderung: Von Parallel zu Sequential

Eine der fundamentalsten Erkenntnisse kam Anfang August, einem Tag, den ich intern als „kritischen Erkenntnistag“ markiert habe. Manchmal gibt es diese Tage in Projekten, an denen sich grundlegende Annahmen als falsch herausstellen. Dieser Tag war so einer.

Plattformgrenze: Keine Parallelität in Roo Code

In der ursprünglichen Architektur hatte ich parallele Handover-Patterns vorgesehen. Die Idee war elegant und auf dem Papier überzeugend: Der Team Lead delegiert mehrere Aufgaben gleichzeitig an verschiedene Spezialisten, die parallel arbeiten. Der Backend Developer implementiert das API, während der Frontend Developer gleichzeitig das UI baut. Der QA Engineer schreibt parallel Tests. In der Theorie sollte das die Durchsatzzeit drastisch reduzieren – schließlich arbeiten echte Teams auch parallel.

Das Problem war fundamental und nicht zu umgehen: Roo Code unterstützt keine parallele Verarbeitung. Die Plattform arbeitet sequenziell – ein Modus nach dem anderen, eine Konversation nach der anderen. Meine schönen Parallel-Workflows waren damit Makulatur. Es war frustrierend, weil ich viel Zeit in das Design der Parallel-Patterns investiert hatte. Boomerang Tasks, koordinierte Checkpoints, Merge-Strategien für parallele Ergebnisse – alles umsonst.

Architektur-Umbau: Coordinated Sequential Pattern

Der Umbau war entsprechend umfangreich und zog sich durch das gesamte System. Ich musste die Parallel Handover Patterns aus README und Global Instructions entfernen, die QA Automation Strategy von parallel auf sequential execution umstellen, das parallel_tasks Tracking durch sequential_tasks ersetzen und alle Parallel Handover Templates samt Validation Tests entfernen. Die Standardisierung erfolgte auf das coordinated_sequential Pattern, bei dem der Team Lead nach jeder abgeschlossenen Spezialistenaufgabe die Kontrolle zurückerhält.

Was zunächst wie ein Rückschritt wirkte, entpuppte sich als Verbesserung: Die sequenziellen Workflows sind vorhersagbarer. Die Feedback-Loops sind klarer, weil immer nur ein Modus aktiv ist. Die Debugging-Fähigkeit verbesserte sich dramatisch – wenn etwas schiefgeht, weiß ich genau, welcher Modus verantwortlich ist. Es gibt keine Race Conditions, keine Merge-Konflikte zwischen parallel arbeitenden Agenten. Die erzwungene Sequenzialisierung machte das System paradoxerweise robuster und einfacher zu verstehen.

Diese Beiträge könnten dich auch interessieren:

---

Der Kampf gegen Over-Engineering: Wenn KI zu viel des Guten tut

Ein Muster, das sich durch die gesamte Entwicklungsphase zog, war die Tendenz des Systems zum Over-Engineering. Dieses Problem ist tückisch, weil es aus einer positiven Eigenschaft entsteht: KI-Agenten neigen dazu, mehr zu tun als gefragt – und das ist nicht immer eine gute Sache.

Konkret sah das so aus: Das System neigte dazu, bei einer einfachen Bug-Fix-Anfrage gleich noch umliegenden Code zu „verbessern“, Tests hinzuzufügen, die niemand gebraucht hat, und Dokumentation zu erweitern. Ein simples „Fix den Null-Pointer in Zeile 42“ wurde zu einer umfassenden Refactoring-Session. Modi fügten Features hinzu, die zwar „nett zu haben“ waren, aber niemand angefordert hatte. „Du könntest hier noch Error-Handling hinzufügen“ – ja, könnte ich, aber ich wollte nur den Bug fixen. Eine Aufgabe wie „Fix den Login-Bug“ wurde zu „Fix den Login-Bug und refactore die gesamte Auth-Schicht und füge Logging hinzu und dokumentiere alles“.

Das Problem dabei ist nicht, dass die Verbesserungen schlecht wären. Sie sind oft sogar sinnvoll. Aber sie kosten Zeit, erzeugen unerwartete Änderungen, die reviewed werden müssen, und lenken vom eigentlichen Ziel ab. Wenn ich einen Bug fixen will, will ich einen Bug fixen – nicht das System revolutionieren.

Policies gegen Over‑Engineering

Die Lösung bestand aus drei zusammenhängenden Policies, die sich gegenseitig verstärken.

1. Minimal Code Changes Policy
   • Die erste war die „Minimal Code Changes Policy“ – eine explizite „Surgical Precision“ Guideline, die nur notwendige Änderungen für die eigentliche Aufgabe erlaubt, strikte Verhinderung von Scope Creep fordert, das bestehende funktionierende System bewahrt, Test-Kontinuität durchsetzt und jede Änderung begründen lässt. Die Begründungspflicht war besonders effektiv … wenn ein Agent erklären muss, warum er eine Änderung macht, überlegt er zweimal.
2. Feature Addition Control
   • Die zweite Policy war „Feature Addition Control“. Bevor ein Modus ein neues Feature implementiert, muss er über ask_followup_question explizit nachfragen: „Soll ich zusätzlich X implementieren?“ Das klingt nach Overhead und unterbricht den Workflow. Aber es verhindert stundenlanges Rückbauen von ungewollten Features. In der Praxis hat sich gezeigt, dass die meisten „spontanen“ Feature-Ideen der Agenten nicht benötigt werden. Und die wenigen, die sinnvoll sind, werden durch die explizite Frage sogar besser implementiert, weil der Kontext klar ist.
3. Scope Expansion Control
   • Die dritte Policy war „Scope Expansion Control“ – ein 5-Step Scope Expansion Process mit verpflichtender User-Zustimmung. Scope-Erweiterungen für Features, Optimierungen und Enhancements müssen explizit genehmigt werden. Die Quality Gates wurden um Scope Validation Requirements erweitert, und die Scope Boundaries werden jetzt im Handover Context dokumentiert. Das macht transparent, was zur Aufgabe gehört und was nicht.

Learning: Perfektionismus‑Bias und Goldplating

Das übergreifende Learning hier ist bemerkenswert: KI-Agenten haben einen eingebauten Perfektionismus-Bias. Sie wollen nicht nur das Problem lösen, sondern das bestmögliche Ergebnis liefern. Das klingt gut, führt aber zu „Goldplating“ – dem Überziehen mit unnötigem Gold. Die Policies mussten diesen Bias explizit begrenzen. Es ist interessant und ein wenig ironisch, dass man einer KI beibringen muss, weniger zu tun. Die natürliche Tendenz ist Maximierung, nicht Optimierung.

Mode Drift und Orchestrator-Probleme: Wenn Modi durcheinander kommen

Manchmal wurde der falsche Modus aktiviert oder blieb aktiv, obwohl die Aufgabe einen anderen Spezialisten erforderte. Der Backend Developer versuchte UI-Probleme zu lösen – und produzierte dabei fragwürdiges CSS. Der QA Engineer begann Code zu schreiben statt zu testen. Der Documentation Writer versuchte, Bugs zu fixen. Dieses „Mode Drift“ genannte Phänomen entsteht, wenn die Aufgabengrenzen nicht klar sind oder wenn ein Modus in einen Bereich „abdriftet“, der eigentlich nicht seiner ist.

Das Problem ist subtil: Oft merkt man den Drift erst, wenn das Ergebnis seltsam aussieht. Warum hat der Backend Developer plötzlich React-Komponenten geschrieben? Weil die Aufgabe „API-Endpoint mit Frontend-Integration“ hieß und er interpretiert hat, dass die Integration auch seine Aufgabe sei. Diese Interpretationsspielräume mussten geschlossen werden.

Meine erste Implementierung war typisch Over-Engineered – ein 8-Step-Prozess mit Drift Detection Algorithm und Context Similarity Scoring, einer Decision Matrix für Mode Correction vs. Delegation, Circuit Breaker Pattern mit Attempt Limits und Cooldown sowie Graceful Fallback Strategies für Edge Cases. Auf dem Whiteboard sah das beeindruckend aus. In der Praxis war es viel zu kompliziert, schwer zu debuggen und erzeugte selbst neue Probleme.

3‑Case Decision Matrix

Die vereinfachte Lösung reduzierte die 8 Schritte auf eine 3-Case Decision Matrix, die jeder verstehen kann:

• Erstens, wenn der falsche Modus aktiv ist aber die richtige Kategorie (z.B. ein anderer Developer statt der richtige Developer), korrigiere intern – der Code-Modus erkennt, dass er eigentlich Backend-Aufgaben macht und ruft den Backend Developer.
• Zweitens, wenn der falsche Modus aktiv ist und die falsche Kategorie (z.B. QA statt Developer), delegiere an Team Lead – das ist ein größerer Kontextwechsel, der Koordination braucht.
• Drittens, wenn unsicher, frage den User – lieber einmal zu viel nachfragen als falsch abbiegen.

Das Learning war klar und übertragbar auf viele Engineering-Entscheidungen: Einfachheit schlägt Komplexität. Der 8-Step-Prozess war „academically interesting“ aber praktisch unwartbar. Die 3-Case Matrix ist verständlich, debuggbar und funktioniert besser. Sie löst 95% der Fälle, und die restlichen 5% werden durch die „frag den User“ Option aufgefangen.

Orchestrator‑Rücksprung: Kontextverlust und Workaround

Ein verwandtes Problem, das ich nicht vollständig lösen konnte, betrifft den Rücksprung zum Original-Orchestrator. Das Problem trat mitten in einem Task auf: Wenn Roo Code während der Arbeit auf ein Problem traf, das nicht dem aktuellen Mode entsprach, wurde ein neuer Orchestrator gestartet, anstatt das Problem an den ursprünglichen Orchestrator zurückzugeben.

Konkret: Der Backend Developer stößt während seiner Arbeit auf ein Security-Problem. Statt zum Team Lead zurückzukehren (der dann den Security Engineer rufen könnte), startet das System einen komplett neuen Team Lead. Der gesamte bisherige Kontext ist weg – der neue Team Lead weiß nicht, was die ursprüngliche Aufgabe war, welche Schritte bereits erledigt wurden, welche Entscheidungen getroffen wurden.

In der Praxis sah das so aus: Team Lead A startet und delegiert an Backend Developer. Backend Developer arbeitet, trifft auf ein Problem außerhalb seiner Expertise. Statt zurück zu Team Lead A zu gehen, wird ein neuer Team Lead B gestartet. Context und Wissen von Team Lead A gehen verloren. Team Lead B muss sich den Kontext mühsam rekonstruieren – falls er überhaupt erkennt, dass er nicht der erste ist. Das führte zu Inkonsistenzen, Duplikaten und verlorener Arbeit.

Die implementierte Lösung war „Team Lead Exklusivität“ – nur ein Team Lead gleichzeitig aktiv, Loop Protection mit maximal 3 Delegations-Ebenen. Es half, die Auswirkungen zu begrenzen, war aber nur ein Workaround. Eine saubere architektonische Lösung hätte tiefgreifende Änderungen an der Mode-Switching-Logik erfordert – mehr Aufwand als der erwartete Nutzen rechtfertigte.

Context-Overflow und Template-Evolution: Die Grenzen der Plattform

15 Modi klingen nach viel Flexibilität und Spezialisierung. In der Praxis bedeutet das: 15 whenToUse-Sektionen, die Roo Code automatisch in den System-Kontext schreibt. Jede dieser Sektionen beschreibt, wann der jeweilige Modus verwendet werden sollte, welche Fähigkeiten er hat, welche Einschränkungen gelten. Selbst die 8 Standard-Modi des „Standard Teams“ sind bereits ein Schwergewicht im Kontext.

Das Ergebnis ist ein klassisches Trade-Off-Problem: Der verfügbare Kontext für die eigentliche Aufgabe schrumpft dramatisch. LLMs haben eine maximale Kontextlänge, und wenn ein großer Teil davon für Mode-Beschreibungen verwendet wird, bleibt weniger für den Code, die Aufgabenbeschreibung und die Konversationshistorie. Bei komplexen Projekten mit langen Code-Dateien wird der Kontext zum Flaschenhals. Der Agent kann nicht mehr alle relevanten Dateien gleichzeitig „sehen“.

Versuche zur Entschärfung

Ich versuchte verschiedene Lösungsansätze mit unterschiedlichem Erfolg. Die whenToUse-Sektionen wurden gekürzt und optimiert – jedes unnötige Wort raus. Nicht benötigte Modi wurden temporär deaktiviert – aber das erforderte manuelles Management. Die Kontext-Komprimierungsprompts wurden angepasst, um wichtige Informationen zu priorisieren. Aber die fundamentale Architektur von Roo Code sieht vor, dass alle Modi-Beschreibungen im System-Kontext verfügbar sein müssen. Es gibt einen Feature-Request für selektives Aktivieren/Deaktivieren von Modes, aber bis dieser implementiert ist, bleibt das Problem bestehen.

Diese Limitation führt dazu, dass das Framework bei größeren Projekten an seine Grenzen stößt. Bei kleineren, fokussierten Aufgaben funktioniert es gut – aber sobald mehrere lange Dateien gleichzeitig relevant sind, wird der Kontext zum Flaschenhals. Das Framework selbst ist nicht schlecht, aber die Kombination aus vielen Modi und komplexen Projekten erfordert sorgfältiges Kontext-Management.

Handover-Templates: Von Vielfalt zur Standardisierung

Parallel zu diesen Herausforderungen entwickelte sich das Handover-System weiter, und hier gab es positive Entwicklungen. Ursprünglich hatten einige Modi eigene, angepasste Handover-Templates. Der Documentation Writer hatte ein Dokumentations-fokussiertes Template mit Feldern für Zielgruppe und Dokumentationstyp. Der Git Specialist hatte ein Commit-fokussiertes Template. Der QA Engineer hatte ein Test-fokussiertes Template mit Feldern für Testabdeckung und Teststrategien. Der Team Lead hatte ein Koordinations-Template mit Projektübersicht.

Das Problem wurde bei Modi-Übergaben sichtbar: Bei Übergaben zwischen Modi gingen Informationen verloren, weil die Templates inkompatibel waren. Der Documentation Writer übergab an den Git Specialist, aber das Dokumentations-Template hatte keine Felder für Commit-Informationen. Informationen mussten „übersetzt“ werden, und dabei ging Kontext verloren.

Die Lösung war radikal aber effektiv: Alle Custom Templates wurden entfernt. Jeder Modus nutzt jetzt dasselbe standardisierte Template mit den Sektionen Task, Mode, Context, Files, Expected Outcomes, Success Criteria und Constraints. Keine Spezialfälle, keine Ausnahmen. Das Template ist schlank genug, um nicht zu viel Kontext zu verbrauchen, aber strukturiert genug, um alle notwendigen Informationen zu übertragen. Die Standardisierung ermöglichte auch automatische Validierung – ein Handover ohne alle Pflichtfelder wird abgelehnt.

Task Chain Tracking und 100% Template Compliance

Ein weiteres Learning war die Notwendigkeit von Task Chain Tracking. Ohne Sichtbarkeit der Workflow-Progression verliert man bei komplexen Aufgaben den Überblick. Wer hat was gemacht? Wo sind wir im Prozess? Die Lösung war systematisches Tracking im Handover-Template – eine strukturierte Tabelle, die den Weg von User Request durch alle Mode-Übergaben dokumentiert. Das ermöglicht Debugging und Nachvollziehbarkeit, selbst wenn eine lange Kette von Handovers stattgefunden hat.

Die finale Eskalation war 100% Template Compliance als Ziel: Template Validation vor jeder Operation, Automatic Rejection bei Template Violations, Circuit-Breaker für wiederholte Non-Compliance und Compliance Monitoring mit messbaren Metriken. Es klingt bürokratisch, und ja, es fügt Overhead hinzu. Aber ohne diese Strenge driftet das System schnell in Chaos ab. Die Metriken zeigten, dass nach Einführung der strikten Compliance die Erfolgsrate von Handovers deutlich stieg.

Die kleinen Learnings: Anekdoten aus der Entwicklung

Nicht alle Probleme waren architektonischer Natur. Manchmal waren es die kleinen Dinge, die überraschend viel Zeit kosteten.

Eindeutige Identitäten: Namenskonflikte vermeiden

Eines Tages bemerkte ich seltsame Verhaltensweisen im System. Aufgaben wurden falsch zugeordnet, und die Logs zeigten merkwürdige Muster. Nach einiger Analyse fand ich den Grund, und er war fast peinlich simpel: Frontend Developer und Tech Educator hießen beide „Sophia“. Das System konnte nicht zuverlässig unterscheiden, welche „Sophia“ gemeint war, besonders in Kontexten, wo der Name ohne Rollenbezeichnung verwendet wurde. Die Lösung war entsprechend simpel: Frontend Developer wurde zu „Maya“ umbenannt. Das Learning ist übertragbar: Eindeutige Identitäten für alle Modi sind kritisch. Namen sind nicht nur Label, sie sind Teil der Systemarchitektur.

fileRegex: Von restriktiv zu pragmatisch

Der QA Engineer hatte anfangs ein zu restriktives fileRegex-Pattern, das definiert, auf welche Dateien der Modus Zugriff hat. Test-Infrastruktur-Dateien wurden blockiert, weil sie nicht dem Pattern entsprachen. Der QA Engineer wollte jest.config.js prüfen – durfte aber nicht. Es folgten mehrere Iterationen – von extension-based (zu restriktiv, blockierte vieles) über comprehensive Pattern mit Excludes (funktionierte besser, aber komplex) bis zur finalen Version mit test_ und spec_ Prefixes und einer großzügigeren Grundregel. Das Learning: Regex-Patterns für AI-Agenten müssen großzügiger sein als für Menschen. Menschen können „ich brauche diese Datei auch“ sagen. Agenten halten sich strikt an die definierten Grenzen – oder scheitern.

Priorisierung mit P1–P4

Ohne strukturierte Issue-Verfolgung verlor ich irgendwann den Überblick über all die Probleme, offenen Punkte und Ideen für Verbesserungen. Die Liste wuchs, aber ohne Priorisierung. Die Lösung war ein Priority-based ToDo-Framework mit vier Stufen: P1 für System Integrity (kritische Systemfunktionalität – wenn das kaputt ist, funktioniert nichts), P2 für Task Continuity (Aufgabenkontinuität durch Eskalation – wenn das kaputt ist, bleiben Aufgaben stecken), P3 für Mode Boundaries und Quality Gates (Expertenbereiche und Standards – wenn das fehlt, sinkt die Qualität) und P4 für Efficiency (Performance und Ressourcennutzung – nice to have). Dieses Framework half, den Fokus auf das Wichtige zu behalten und nicht in der Flut von Verbesserungsideen zu ertrinken.

Spracheinstellung und Language Forwarding

Ein überraschendes Problem war die Spracheinstellung. Das System antwortete manchmal auf Englisch, obwohl ich auf Deutsch arbeitete. Mitten in einer deutschen Konversation kam plötzlich eine englische Antwort. Der Grund war hardcoded German in den Prompts – „Antworte auf Deutsch“ – aber Roo Code hatte eine eigene Language-Setting, die davon unabhängig war. Die Systeme sprachen nicht miteinander. Die Lösung kam mit RooCode v3.9.1+: Language Forwarding Integration. Das System respektiert jetzt die Roo Code Spracheinstellung und gibt sie an die Modi weiter. Ein kleines Detail, aber es verbesserte die User Experience erheblich.

Fazit: Was funktioniert und was herausfordernd ist

Nach mehreren Wochen intensiver Weiterentwicklung und Iteration ziehe ich eine gemischte aber insgesamt positive Bilanz. Die vielen Refactoring-Commits – gut ein Drittel aller Änderungen – waren kein Zeichen von schlechter Planung, sondern von iterativem Lernen. Jedes Refactoring war eine Lektion.

Was funktioniert hat und übertragbar ist: Spezialisierte Modi mit klaren Verantwortlichkeiten reduzieren den Mental Load und verbessern die Qualität. Strukturierte Handovers mit einheitlichen Templates stellen sicher, dass keine Informationen verloren gehen. Quality Gates als Checkpoint-System verhindern, dass Fehler weitergereicht werden. Explizite Policies gegen Over-Engineering zwingen die KI zur Zurückhaltung und machen das Verhalten vorhersagbar.

Was herausfordernd ist: Der Context-Overflow durch zu viele Modi ist eine Plattform-Limitation, die ich nicht lösen kann – sie erfordert Änderungen an Roo Code selbst. Der Orchestrator-Rücksprung ist ein unvollendetes Problem – manchmal muss man „gut genug“ akzeptieren. Die sequenzielle Limitation von Roo Code erzwang einen kompletten Architektur-Umbau – der sich aber als Verbesserung herausstellte.

Einige Punkte sind noch offen: Die Tendenz zum Over-Engineering ist zwar durch Policies eingedämmt, aber nicht eliminiert – das System testet immer wieder die Grenzen. Mehrere implementierte Features wie Mode Drift Correction und Template Compliance wurden noch nicht systematisch unter Produktionslast getestet. Die Kontext-Komprimierung verliert manchmal wichtige Informationen wie die Original-Aufgabe oder Tool-Angaben. Und die Frage, ob ein Code-Modus Test-Dateien ändern darf oder nicht, ist noch ungeklärt. Diese offenen Punkte sind keine Bugs, sondern Bereiche für weitere Iteration.

Das übergreifende Learning für alle, die ähnliche Systeme bauen wollen: AI-Agenten-Systeme sind keine „Fire and Forget“-Lösungen. Sie erfordern kontinuierliche Iteration, klare Grenzen und den Mut, auch mal etwas wieder zu vereinfachen. Die vielen Refactoring-Commits sind keine Verschwendung – sie sind der Weg zu einem System, das tatsächlich funktioniert. Oder wie es ein Kollege treffend formulierte: „Das erste System baut man, um zu lernen. Das zweite baut man, um es zu nutzen.“