4-Agenten-Code-Review als Open-Source-MCP-Server für KI-Entwicklungstools

Die Grenzen zwischen menschlicher und maschineller Softwareentwicklung verschwimmen zunehmend. Doch wer überprüft eigentlich die Arbeit von KI-Codeagenten, wenn diese in Sekunden tausende Zeilen Code generieren? Eine innovative Open-Source-Lösung setzt hier an: Ein adversarisches Vier-Agenten-Team, das als MCP-Server fungiert und jeder KI-Entwicklungsumgebung strukturierte Code-Reviews liefert.

Die kürzlich veröffentlichte Lösung basiert auf der heym-Plattform und ermöglicht es beliebigen KI-Coding-Agenten – von Cursor über Claude Code bis hin zu benutzerdefinierten Python-Skripten – eine zweite Meinung zu ihrem eigenen Code einzuholen. Das System setzt auf vier spezialisierte Agenten, die gemeinsam eine kritische Prüfung der Codequalität durchführen, ohne dass menschliches Eingreifen erforderlich ist.

Git als zentrales Steuerungselement für KI-Agenten

Moderne KI-Entwicklungstoolketten wie die von Andrej Karpathy entwickelte Autoresearch oder die GitHub-Actions-Integration von Claude Code nutzen bereits Git als zentrales Steuerungselement. Entwicklungsagenten arbeiten direkt mit Branches, Diffs und Pull Requests – genau wie menschliche Entwickler. Dieser Ansatz hat sich bewährt, da er eine vertraute und etablierte Review-Infrastruktur nutzt, die seit Jahrzehnten in der Softwareentwicklung Standard ist.

Doch während menschliche Entwickler diese Workflows natürlich verstehen, fehlt KI-Agenten oft die Fähigkeit, die Qualität ihrer eigenen Arbeit objektiv zu bewerten. Die naheliegende nächste Stufe besteht daher darin, automatisierte Systeme einzusetzen, die diese Aufgabe übernehmen.

Warum herkömmliche KI-Code-Reviews oft unzureichend sind

Viele bestehende Lösungen wie CodeRabbit, Greptile oder Qodo bieten KI-gestützte Code-Reviews an. Allerdings handelt es sich dabei meist um vertikale SaaS-Dienste, die menschliche Pull Requests auf GitHub analysieren. Sie sind nicht als programmierbare Primitive konzipiert, die von anderen KI-Agenten direkt aufgerufen werden können.

Ein zentrales Problem herkömmlicher Ansätze ist die mangelnde Objektivität: Ein einzelner LLM-basierter Reviewer kann sich selbst bestätigen oder durch geschickte Prompts eine Schein-Objektivität vortäuschen. Um dies zu vermeiden, setzt die neue Lösung auf ein adversarisches Vier-Agenten-Team, das strukturell verhindert, dass ein einzelner Agent die Bewertung manipuliert.

Die Architektur: Vier spezialisierte Agenten in einer kontrollierten Umgebung

Das System besteht aus vier Agenten, die jeweils eine spezifische Rolle innerhalb des Review-Prozesses einnehmen:

• Deritekt (Architekt): Dieser Agent hat keine eigenen Bewertungskompetenzen, sondern fungiert ausschließlich als Orchestrator. Er sammelt die Bewertungen der anderen Agenten und erstellt daraus ein finales Urteil. Seine Hauptaufgabe besteht darin, die Ergebnisse zu synthetisieren, ohne eigene Bewertungen hinzuzufügen.

• Reasoner (Analyst): Dieser Agent analysiert den Code und identifiziert potenzielle Problemstellen. Er nutzt dabei eine spezielle kognitive Scaffold-Struktur, die ihm hilft, systematisch vorzugehen.

• Implementer (Tester): Dieser Agent schreibt automatisierte Tests, um die Funktionalität des geänderten Codes zu überprüfen. Besonders wichtig ist hier die Prüfung von Randfällen und die Sicherstellung, dass der Code die ursprüngliche Spezifikation erfüllt.

• Reviewer (Prüfer): Dieser Agent konzentriert sich auf die Framing-Problematik. Er stellt sicher, dass die Änderungen nicht nur technisch korrekt sind, sondern auch die ursprüngliche Problemstellung adressieren. Ein häufiger Fehler bei KI-generiertem Code besteht darin, dass die Änderungen zwar syntaktisch korrekt sind, aber die eigentliche Aufgabenstellung verfehlen.

Jeder dieser Agenten nutzt eine spezifische Ejentum-Harness-Konfiguration, die ihm besondere Anweisungen und Kontext liefert. Die Agenten stammen zudem aus verschiedenen Modell-Laboren (Anthropic, Google, Alibaba, Zhipu), um korrelierte Fehlerquellen zu reduzieren. Selbst wenn ein Modell in einer bestimmten Richtung trainiert wurde, reduziert die Diversität der Agenten die Wahrscheinlichkeit, dass alle ähnliche Fehler machen.

Ein konkretes Beispiel: Wie das System einen Refactoring-Versuch bewertet

Stellen Sie sich vor, ein KI-Agent versucht, eine einfache Refaktorisierung durchzuführen und ersetzt raise UserNotFound(id) durch return user or default. Der Implementer-Agent erkennt sofort, dass dies ein Verhalten ändert: Statt eine Ausnahme zu werfen, wird nun ein Standardwert zurückgegeben. Der Reviewer-Agent stellt fest, dass die ursprüngliche Aufgabenstellung möglicherweise missverstanden wurde, da eine Exception nun durch einen Default-Wert ersetzt wird – was nicht der ursprünglichen Intention entspricht.

Das System erstellt daraufhin ein strukturiertes Urteil mit folgenden Elementen:

• VERDICT: request_changes (Änderungen erforderlich)
• CHANGE_CLASSIFICATION: behavioral_change (Verhaltensänderung)
• FRAMING_NOTES: Die ursprüngliche Aufgabenstellung wird zitiert, um zu zeigen, dass die Änderungen nicht den Anforderungen entsprechen.
• CONCERNS: Eine Liste der identifizierten Probleme, jeweils mit Schweregrad und Quelle (z. B. Implementer oder Reviewer).
• REVIEW_FOCUS: Die wichtigsten Punkte, die der Reasoner identifiziert hat.

Dieses strukturierte Feedback ermöglicht es dem ursprünglichen KI-Agenten, die notwendigen Anpassungen vorzunehmen, bevor der Code weiterverarbeitet wird.

heym als Plattform für Multi-Agenten-Orchestrierung

Die Lösung läuft auf der heym-Plattform, die sich als eine Art „n8n für KI-Agenten“ positioniert. Die Plattform ermöglicht native Multi-Agenten-Orchestrierung und exponiert jedes Workflow als eigenen MCP-Server. Dies bedeutet, dass der gesamte Review-Prozess nicht nur manuell ausgelöst werden kann, sondern auch direkt aus Entwicklungsumgebungen wie Cursor, Claude Code oder sogar benutzerdefinierten Python-Skripten heraus aufgerufen werden kann.

Die Integration ist denkbar einfach: Ein KI-Agent beendet seine Arbeit, ruft den MCP-Server auf und erhält ein strukturiertes Review-Ergebnis. Anschließend kann der Agent entscheiden, ob er die Änderungen übernimmt, verwirft oder weitere Anpassungen vornimmt. Diese programmatische Schnittstelle ist ein entscheidender Unterschied zu herkömmlichen KI-Code-Review-Tools, die meist nur manuell genutzt werden können.

Open Source und erste Schritte

Das Projekt ist unter der MIT-Lizenz veröffentlicht und steht auf GitHub zur Verfügung. Neben dem eigentlichen Workflow sind auch die System-Prompts, Verifikationstests und eine detaillierte Anleitung zur Einrichtung enthalten. Wer das System ausprobieren möchte, kann es über die heym-Template-Marktplatz mit einem Klick importieren.

Die Lösung adressiert eine zentrale Lücke in der aktuellen KI-Entwicklungslandschaft: Während es bereits viele Tools für die KI-gestützte Codegenerierung gibt, fehlte bisher eine offene, programmierbare Infrastruktur für automatisierte Code-Reviews. Mit diesem Projekt wird es möglich, KI-Agenten in einer Weise zu nutzen, die nicht nur effizient, sondern auch qualitativ hochwertig und überprüfbar ist.

Die Zukunft der Softwareentwicklung wird zunehmend von KI-Agenten geprägt sein – doch damit diese Tools ihr volles Potenzial entfalten können, braucht es Mechanismen, die ihre Arbeit objektiv und nachvollziehbar bewerten. Dieses Projekt könnte der erste Schritt in diese Richtung sein.