Coding Agents wechseln. Die Plattform bleibt.

Warum die Toolauswahl allein noch kein Betriebsmodell ergibt

Ein Coding Agent kann bei einer Änderung überzeugen und bei einer anderen Aufgabe mehr Unterstützung benötigen. Für ein Entwicklungsteam zählt deshalb, wie das Werkzeug mit dem eigenen Repository, den Testmöglichkeiten und den fachlichen Anforderungen zusammenarbeitet.

Unsere These: Der beste Coding-Agent-Ansatz kann eine Kombination mehrerer Werkzeuge sein. Das ist sinnvoll, wenn sich ihre Stärken in einer konkreten Aufgabe ergänzen, etwa bei Implementierung und Review. Die Auswahl muss dabei beweglich bleiben. Entwicklungsregeln, Zugriffsrechte und die Kriterien für eine akzeptierte Änderung sollten einen Werkzeugwechsel überdauern.

Wird dieser Kontext für jedes neue Werkzeug neu aufgebaut, entstehen Aufwand und unterschiedliche Arbeitsweisen. Eine gemeinsame Grundlage macht Wechsel und Vergleiche leichter: dieselben Anforderungen, nachvollziehbare Änderungen und dieselben Abnahmekriterien.

Modell, Agent und Orchestrierung haben unterschiedliche Aufgaben

Das Modell verarbeitet Informationen und erzeugt Vorschläge. Ein Coding Agent verbindet solche Fähigkeiten mit Werkzeugen, etwa zum Lesen von Dateien, Ändern von Code und Ausführen von Tests. Die Orchestrierung organisiert Aufgaben, Übergaben und gemeinsame Regeln zwischen diesen Beteiligten.

Der Begriff Harness bezeichnet dabei die Ausführungsumgebung des Agenten: Sie bestimmt unter anderem, wie er Werkzeuge aufruft und mit seinem Arbeitskontext umgeht. Ein Meta-Harness koordiniert mehrere solcher Umgebungen. Unterschiedliche Harnesses können dasselbe Modell nutzen; ein Wechsel des Werkzeugs bedeutet deshalb noch keine unabhängige fachliche Prüfung.

Für eine Plattformentscheidung lohnt sich diese Trennung. Ein Modellwechsel verändert andere Dinge als der Wechsel eines Agent-Werkzeugs. Und eine zusätzliche Steuerungsebene ist nur hilfreich, wenn sie die im Team tatsächlich benötigten Abläufe zuverlässig unterstützt.

Omnigent zeigt, wie eine gemeinsame Ebene aussehen kann

Omnigent beschreibt sich als Framework mit gemeinsamer Oberfläche und konfigurierbaren Policies und Sandboxen. Die Harness-Dokumentation führt unter anderem Integrationen für Claude Code, Codex und Cursor auf. Ausführungsart und Support unterscheiden sich je nach Integration.

Die Architekturidee dahinter ist für uns besonders interessant: Anforderungen und Steuerung können oberhalb einzelner Agent-Werkzeuge organisiert werden. Daraus folgt allerdings kein Anspruch, dass jede Integration dieselben Funktionen oder identisches Verhalten bietet. Ein Team sollte die tatsächlich benötigten Arbeitsabläufe mit der gewählten Version testen.

Was Cross-Review im dokumentierten Beispiel gefunden hat

Im Omnigent-Blog beschreibt Daniel Liden drei Korrekturen an einem GitHub-Client. Es ging um Pagination, das Herausfiltern von Pull Requests und den Umgang mit fehlgeschlagenen Anfragen beziehungsweise API-Limits. Implementierung und Review liefen jeweils auf unterschiedlichen Harnesses.

• Pagination: Codex prüfte eine von Claude Code geschriebene Änderung und fand eine mögliche Endlosschleife bei zyklischen Links zur nächsten Ergebnisseite.
• Wiederholungen und Limits: Ein weiteres Codex-Review zeigte, dass eine Änderung von Claude Code den HTTP-Datumswert im Retry-After-Header nicht berücksichtigte.
• Pull-Request-Filter: Diese Korrektur von Codex bestand das Review durch Pi.

Zwei der drei Reviews führten damit zu Nachbesserungen und zusätzlichen Tests. Das ist ein dokumentiertes Einzelbeispiel, keine allgemeine Erfolgsquote. Für uns zeigt es einen sinnvollen Ansatz: Reviewer erhalten einen eigenen Prüfauftrag, und gefundene Fehler werden durch reproduzierbare Tests abgesichert.

Ein Beispiel: zwei Agents an einer klar begrenzten Änderung

Das folgende Szenario ist fiktiv. Ein Team möchte die Validierung einer Importfunktion erweitern. Der Auftrag beschreibt erlaubte Eingabeformate, erwartete Fehlermeldungen und bestehendes Verhalten, das weiterhin gelten soll.

1. Kontext bereitstellen: Der ausführende Agent erhält die betroffenen Dateien, Entwicklungsregeln und relevanten Tests. Für das neue Eingabeformat werden gültige Datensätze, ungültige Werte und das erwartete Fehlerverhalten vorab beschrieben.
2. Isoliert ändern: Die Bearbeitung erfolgt in einem eigenen Arbeitsstand mit begrenzten Zugriffsrechten. Der Agent liefert eine überschaubare Änderung und Testergebnisse. Ein fehlgeschlagener Test bleibt sichtbar und gehört in die Übergabe.
3. Gezielt gegenprüfen: Ein Reviewer auf einem anderen Harness erhält Auftrag, Änderung und Testprotokoll. Er prüft beispielsweise leere Eingaben, bisher erlaubte Formate und widersprüchliche Fehlermeldungen. Die Begründung des Implementierers ersetzt diese Prüfung nicht.
4. Nachbessern und abnehmen: Aus einem gefundenen Fehler entsteht ein Test, der ihn nachvollziehbar reproduziert. Nach der Korrektur laufen die relevanten Prüfungen erneut. Ein verantwortlicher Entwickler beurteilt die Änderung und entscheidet über die Übernahme.

Parallelisierung lohnt sich hier erst, wenn Aufgaben unabhängig bearbeitbar sind. Ändern zwei Agents dieselbe Funktion mit verschiedenen Annahmen, verlagert sich die Arbeit leicht in die spätere Zusammenführung. Ein klarer Zuschnitt der Aufgaben und sichtbare Abhängigkeiten sind deshalb Teil der Orchestrierung.

Die zweite Prüfung ist ein zusätzlicher Blick auf die Änderung. Sie ist kein Beweis für Fehlerfreiheit: Beide Agents können dieselbe Anforderung missverstehen. Aussagekräftige Tests und eine klare menschliche Verantwortung bleiben deshalb Teil des Ablaufs.

Austauschbarkeit wird praktisch, wenn Anforderungen, Tests und Abnahme auch nach einem Werkzeugwechsel verständlich bleiben.

Welche Kontrolle braucht der Betrieb?

Ein Agent benötigt die Zugriffe, die seine Aufgabe verlangt. Dateibereiche, Netzwerkzugang und verfügbare Werkzeuge sollten bewusst festgelegt werden. Die Omnibox-Dokumentation beschreibt dafür eine Sandbox-Ebene. Policies können zusätzlich Aktionen steuern und Verbrauch begrenzen.

Im konkreten Projekt sollten diese Regeln überprüfbar sein. Welche Befehle sind erlaubt? Wo liegen Zugangsdaten? Welche Änderung benötigt eine Freigabe? Was geschieht, wenn sich ein Agent in Wiederholungen verliert? Die Antworten gehören in Konfiguration und Betrieb, damit ein Team sie testen und bei Bedarf ändern kann.

Zur Nachvollziehbarkeit gehört außerdem eine Verbindung zwischen Auftrag und Ergebnis: eingesetztes Modell und Harness, relevante Versionen, ausgeführte Tests, Review-Befunde und die abschließende Freigabe. So kann ein Team später untersuchen, ob ein Problem aus einer unklaren Anforderung, der Implementierung oder einer Lücke in der Prüfung entstanden ist.

Eine weitere Frage ist die Wirtschaftlichkeit. Mehr parallele Agents bedeuten zusätzliche Ausführungen und Abstimmung. Messen lässt sich beispielsweise der Gesamtaufwand bis zu einer akzeptierten Änderung, einschließlich Tests und Nacharbeit.

Budgets sollten deshalb Implementierung, Review und Korrekturschleifen gemeinsam betrachten. Bei einer erreichten Grenze braucht der Ablauf eine festgelegte Reaktion, etwa eine Unterbrechung zur menschlichen Entscheidung. Welche Aufrufe eine konfigurierte Policy tatsächlich erfasst, muss im gewählten Setup geprüft werden.

Wie lässt sich der Ansatz sinnvoll erproben?

Wir empfehlen einen klaren Aufgabentyp, etwa kleine Fehlerkorrekturen oder begrenzte Testergänzungen. Mehrere repräsentative Aufgaben werden mit denselben Abnahmekriterien bearbeitet. Erfasst werden Ergebnisqualität, Durchlaufzeit, menschliche Nacharbeit und Verbrauch.

Für einen aussagekräftigen Vergleich bearbeitet zunächst ein einzelner Agent diesen Aufgabentyp. Anschließend kommt das zusätzliche Review hinzu. Entscheidend ist, ob es relevante Fehler findet und den gesamten Aufwand bis zur Abnahme verbessert. Ein längerer Review-Bericht allein zeigt noch keinen Nutzen.

Bei Hanlea verbinden wir solche Versuche mit Plattformarchitektur und Governance. Ziel ist ein Ablauf, den das Team versteht und weiterentwickeln kann. Erst wenn der Nutzen sichtbar wird, lohnt sich die Entscheidung über eine breitere Integration.

Häufige Fragen zu Coding-Agent-Plattformen

Ist eine Orchestrierung für jedes Team nötig?

Ein einzelnes Werkzeug kann für einen überschaubaren Ablauf ausreichen. Eine gemeinsame Ebene wird interessant, wenn mehrere Werkzeuge, wiederkehrende Übergaben oder zentrale Regeln sonst viel Abstimmungsaufwand verursachen.

Macht ein zweiter Agent das menschliche Review überflüssig?

Ein zusätzlicher Agent kann Hinweise liefern. Für die fachliche Abnahme und die Auswirkungen einer Änderung braucht es weiterhin klare Verantwortung und geeignete Prüfverfahren.