In Dev-Team in Roo Code beschrieb ich den erzwungenen Wechsel von JetBrains zu VSCode – ein Wechsel, den ich nicht freiwillig gemacht hätte. Dann ging es in Agile Team in Roo Code um das ausgeklügelte Handover-System, Quality Gates und die Regel-Hierarchie. Und in Probleme, Learnings und 36% Refactoring schloss sich ein erster narrativer Bogen: Dank RunVSAgent konnte ich zurück zu meinen geliebten JetBrains IDEs.
Jetzt schließt sich ein größerer Bogen: Das Roo Code Agile Software Development Team hat sein Ende erreicht. Aber wie so oft in der Softwareentwicklung ist ein Ende auch ein Neubeginn.
Kurze Unterbrechung: KI, die sich rechnet – und nicht nur beeindruckt.
Entwicklung von AI-Lösungen
Wir unterstützen Unternehmen dabei, KI sinnvoll und sicher in bestehende IT-Landschaften zu integrieren.
Die Entscheidung für Claude Code
Ende September erreichte mich eine Nachricht meines Chefs. Das Thema: die API-Kosten. In den drei Monaten seit dem Start des Projekts hatte ich rund 6.000 Dollar an API-Kosten verursacht – allein im August waren es über 3.200 Dollar. Das Multi-Agent-System mit seinen 15 spezialisierten Modi verbrauchte erheblich mehr Tokens als ein einzelner Agent. Jeder Handover, jede Quality Gate-Prüfung, jede Kontext-Übergabe – alles kostete.
Der Vorschlag meines Chefs war pragmatisch: Claude Code mit einer Team Subscription und Premium-Seat. Die Firma würde die Kosten übernehmen, und ich könnte weiterarbeiten – nur auf einer anderen Plattform. Bereits am nächsten Tag war ich freigeschaltet.
Es gab kein langes Zögern, keine Diskussionen über „aber ich habe so viel investiert“. Die Entscheidung war schnell und pragmatisch. Wenn eine bessere Alternative bereitsteht und die Firma sie anbietet – warum nicht?
Was bleibt: Eine Retrospektive
Bevor ich zu den Limitationen komme, möchte ich würdigen, was das Projekt gebracht hat. Die vielen Stunden Entwicklungsarbeit, die 118 Commits in drei Tagen, die 36,4% Refactoring – das war kein verschwendeter Aufwand.
Technische Learnings
Die wichtigsten technischen Erkenntnisse sind nicht an Roo Code gebunden. Sie sind übertragbar auf jedes System, in dem mehrere KI-Agenten zusammenarbeiten sollen.
Handover-Patterns haben sich als essentiell erwiesen. Ohne strukturierte Kontext-Übergabe zwischen Agenten geht Information verloren. Ein Agent weiß nicht, was der vorherige getan hat, welche Entscheidungen getroffen wurden, welche Constraints gelten. Das Template-basierte Handover-System – mit klarem Ziel, Constraints und Erfolgskriterien – war einer der größten Erfolge des Projekts.
Quality Gates verhindern, dass Fehler weitergereicht werden. Statt am Ende einer langen Kette einen Haufen Probleme zu haben, fängt man sie früh ab. Der Code Reviewer prüft, bevor der QA Engineer testet. Der Security Engineer schaut drüber, bevor es in Produktion geht. Diese Checkpoints kosten Zeit – aber sie sparen mehr, als sie kosten.
Die Rule Hierarchy löst Konflikte eindeutig: System Integrity vor Task Continuity vor Mode Boundaries vor Quality Gates vor Efficiency. Wenn Sicherheit und Geschwindigkeit kollidieren, gewinnt Sicherheit. Wenn eine Aufgabe die Modi-Grenzen sprengt, wird eskaliert statt improvisiert. Diese klare Priorisierung macht das Verhalten des Systems vorhersagbar.
Spezialisierung schlägt Generalisierung – das war vielleicht die überraschendste Erkenntnis. Ein Team aus 15 Spezialisten, die jeweils eine Sache gut können, funktioniert besser als ein „Alles-Könner“, der alles mittelmäßig macht. Der Backend Developer schreibt keine UI. Der QA Engineer fixt keine Bugs. Der Documentation Writer programmiert nicht. Diese klaren Grenzen führen zu besseren Ergebnissen.
Persönliche Entwicklung
Über die technischen Learnings hinaus hat das Projekt mein Verständnis von Multi-Agent-Orchestrierung fundamental vertieft. Ich habe gelernt, dass KI-Agenten einen eingebauten „Perfektionismus-Bias“ haben. Sie wollen nicht nur das Problem lösen, sondern das bestmögliche Ergebnis liefern. Das klingt gut – ist aber gefährlich. Ein einfacher Bug-Fix wird zur umfassenden Refactoring-Session. Eine kleine Änderung wächst zu einem Feature-Paket. Man muss einer KI aktiv beibringen, weniger zu tun.
Und ich habe gelernt, dass Einfachheit Komplexität schlägt. Mein ursprünglicher 8-Step Mode-Drift-Algorithmus mit Similarity Scoring und Circuit Breaker Pattern war „akademisch interessant“. Die 3-Case Decision Matrix, die ihn ersetzte, war verständlich, debuggbar und funktionierte besser.
Konkrete Artefakte
Neben den Learnings bleiben konkrete Artefakte, die ich weiterverwenden kann. Die universellen Handover-Templates. Die drei Policies gegen Over-Engineering: Minimal Code Changes, Feature Addition Control, Scope Expansion Control. Das Priority-Framework für Issue-Tracking mit den vier Stufen P1 bis P4. Diese Werkzeuge sind nicht plattformgebunden – sie funktionieren überall dort, wo mehrere Agenten koordiniert werden müssen.
Diese Beiträge könnten dich auch interessieren:
Die Limitationen: Herausforderungen, keine Showstopper
Trotz dieser Erfolge stieß das Projekt an Grenzen. Nicht alle waren unüberwindbar – aber in Summe stellte sich die Frage, ob weitere Iteration in Roo Code der richtige Weg war.
API-Kosten
Die Kosten waren der offensichtlichste Faktor: rund 6.000 Dollar in drei Monaten, mit einer Spitze von über 3.200 Dollar allein im August. Das Multi-Agent-System verbraucht mehr Tokens als ein einzelner Agent. Jeder Handover transportiert Kontext. Jede Quality Gate-Prüfung braucht Verständnis des Gesamtzustands. Die Architektur ist inhärent teurer als ein monolithischer Ansatz.
War das ein Showstopper? Nicht wirklich – die Firma hätte die Kosten weiter getragen. Aber es war ein Faktor, der die Frage aufwarf: Gibt es einen besseren Weg?
Context-Overflow
15 Modi bedeuten 15 whenToUse-Sektionen, die Roo Code automatisch in den System-Kontext schreibt. Selbst die 8 Standard-Modi des Teams waren bereits ein Schwergewicht. Je mehr Kontext für Modi-Beschreibungen verwendet wird, desto weniger bleibt für die eigentliche Aufgabe – den Code, die Dateien, die Konversationshistorie.
Ich versuchte verschiedene Workarounds: kürzere whenToUse-Beschreibungen, temporäres Deaktivieren nicht benötigter Modi, optimierte Kontext-Komprimierung. Es half – aber nur begrenzt. Ein Feature-Request für selektives Aktivieren und Deaktivieren von Modi existiert, ist aber noch nicht implementiert. Mit diesem Feature wäre das Problem lösbar gewesen.
Keine Parallelisierung
Dies war die einzige echte architektonische Grenze – nicht durch Iteration lösbar.
Roo Code arbeitet strikt sequentiell: ein Modus nach dem anderen, eine Konversation nach der anderen. Meine ursprünglichen Parallel-Patterns – Boomerang Tasks, koordinierte Checkpoints, Merge-Strategien für parallele Ergebnisse – waren damit Makulatur. Der Backend Developer kann nicht parallel zum Frontend Developer arbeiten. Der QA Engineer muss warten, bis der Code fertig ist.
Der Umbau von Parallel auf Sequential war ein Workaround. Er machte das System vorhersagbarer und einfacher zu debuggen – aber er war keine Lösung. Die Effizienzgewinne, die echte Parallelisierung gebracht hätte, blieben unerreichbar.
Das Orchestrator-Problem
Ein Problem, das ich nie vollständig lösen konnte: Wenn ein Spezialist während seiner Arbeit auf ein Problem außerhalb seiner Expertise stößt, wird ein neuer Team Lead gestartet, anstatt zum ursprünglichen zurückzukehren. Der gesamte bisherige Kontext geht verloren.
Mit Zeit und weiterer Iteration hätte ich das lösen können. Aber der „sanfte Zwang“ zu Claude Code kam zuerst. Die Arbeit am Framework wurde nicht abgebrochen – sie wurde verlagert.
Das Fazit zu den Limitationen
Diese Limitationen sind keine Bugs, die Roo Code fixen müsste. Sie sind Eigenschaften der Plattform. Mit weiteren Iterationen und neuen RooCode-Features hätten sich die meisten Probleme lösen oder umgehen lassen – mit Ausnahme der fehlenden Parallelisierung.
Für mein Multi-Agent-Framework war Roo Code der richtige Startpunkt – aber nicht das richtige Zuhause.
Lessons Learned: Sechs Prinzipien für Multi-Agent-Systeme
Unabhängig von der Plattform: Was habe ich gelernt, das auf jedes Multi-Agent-System übertragbar ist?
- Starte einfach, iteriere schnell. Die 36,4% Refactoring-Commits waren kein Zeichen von schlechter Planung – sie waren der Weg zum Ziel. Das erste System baut man, um zu lernen. Das zweite, um es zu nutzen. Lieber früh starten und iterieren als ewig planen.
- KI-Agenten haben einen Perfektionismus-Bias. Sie wollen mehr tun als gefragt. Das klingt gut, ist aber gefährlich. Explizite Policies gegen Over-Engineering sind notwendig. „Weniger tun“ muss man einer KI aktiv beibringen.
- Strukturierte Übergaben sind nicht optional. Ohne standardisierte Handover-Templates geht Kontext verloren. Jede Übergabe braucht drei Dinge: Ziel, Constraints, Erfolgskriterien. Einheitlichkeit schlägt Spezialisierung bei Templates.
- Einfachheit schlägt Cleverness. Der 8-Step Mode-Drift-Algorithmus war akademisch interessant. Die 3-Case Decision Matrix funktionierte besser. Wenn du es nicht in drei Sätzen erklären kannst, ist es zu kompliziert.
- Prüfe die Plattform-Grenzen früh. Parallelisierung war eine architektonische Grenze, die ich erst spät erkannte. Bevor du ein Framework baust: Was kann die Plattform wirklich? Workarounds funktionieren – bis sie es nicht mehr tun.
- Kosten skalieren anders als erwartet. Multi-Agent-Systeme verbrauchen exponentiell mehr Tokens als einzelne Agenten. Jede Qualitätsschicht kostet Kontext. Plane Budget-Reviews ein, bevor die Rechnung kommt.
Diese Prinzipien gelten unabhängig davon, ob du Roo Code, Claude Code, LangChain oder etwas Eigenes verwendest. Multi-Agent-Orchestrierung ist ein Handwerk – und wie jedes Handwerk lernt man es durch Machen.
Kurze Unterbrechung – es geht gleich weiter im Artikel!
Du suchst den Austausch?
Wenn Du den Austausch suchst oder jemanden benötigst, der dieses Thema bei Dir implementieren kann, bist du bei uns richtig. Schreibe uns eine kurze Nachricht und wir machen finden einen kurzen, unverbindlichen Termin, in dem wir uns Deine Herausforderung gemeinsam ansehen.
Deal?
Der Neubeginn: Claude Code
Die Arbeit wurde nicht abgebrochen – sie wurde verlagert. Und Claude Code bietet einiges, was Roo Code nicht konnte.
Skills statt Modi. Claude Code hat ein anderes Erweiterungskonzept. Skills sind leichtgewichtiger, kontextschonender. Keine 15 whenToUse-Sektionen, die den Kontext füllen.
Echte Parallelisierung mit dem Task-Tool. Subagenten können parallel arbeiten. Das, was bei Roo Code architektonisch unmöglich war, ist hier eingebaut. Boomerang Tasks und koordinierte Checkpoints werden wieder möglich.
Plugins für die Agenten-Persönlichkeit. Die Erweiterungslogik lebt in Plugins, nicht in Tool-Settings. Die projekt-spezifische Konfiguration liegt in der CLAUDE.md direkt im Repository – versionierbar, teilbar, nachvollziehbar.
Wo stehe ich gerade? Roo Code wird nicht mehr genutzt – Claude Code ist jetzt das einzige Werkzeug. Ich lerne noch die umfangreichen Features kennen und analysiere, was sich für welchen Teil des Frameworks eignet. Ein Grundkonzept existiert als Entwurf. Die „richtige“ Entwicklung muss erst noch beginnen.
Das Framework wird nicht kopiert – es wird neu gedacht. Was in Roo Code funktioniert hat, kommt mit. Was nicht funktioniert hat, bleibt zurück. Und was in Claude Code neu möglich ist, wird genutzt.
Übrigens … Claude Code bietet ein sehr spannendes Ökosystem. Die Best Practices – von Plugins bis hin zu Tipps & Tricks für die Anwendung – habe ich hier zusammengefasst. Vielleicht ist ja etwas Spannendes für dich dabei?
Die Reise geht weiter
Was als erzwungener Wechsel von JetBrains zu VSCode begann, führte zu einem der lehrreichsten Projekte meiner Entwicklerkarriere. Vier Artikel, von der chaotischen Entstehung über die orchestrierte Symphonie, durch Probleme und Learnings, bis zum Ende – und Neubeginn.
Der narrative Bogen der Serie ist vollständig: JetBrains → VSCode → JetBrains → Claude Code. Jeder Wechsel war eine Chance, etwas Neues zu lernen. Jede Plattform hatte ihre Stärken und Grenzen. Das Wichtige ist nicht, wo man anfängt – sondern dass man weitermacht.
Roo Code war der richtige Startpunkt. Claude Code ist der nächste Schritt. Die Reise geht weiter.Wer die nächsten Schritte verfolgen möchte, findet sie hier auf dem Mayflower Blog.
Schreibe einen Kommentar