Dein Team arbeitet mit Coding-Agenten, aber die Ergebnisse schwanken. Ein Pull Request lässt sich zügig prüfen, beim nächsten fehlt eine Anforderung oder der Agent hat die falschen Tests ausgeführt, um „alle Tests grün“ zu melden, dafür schlägt CI fehl. Für eure KI-Coding-Strategie steht damit eine Frage an: Würde ein anderes Modell helfen, oder fehlt etwas im Ablauf?
Ich würde mit dem letzten misslungenen Auftrag anfangen. An ihm lässt sich untersuchen, welche Informationen und Werkzeuge der Agent hatte und woran das Ergebnis gescheitert ist. Daraus kann ein begründeter Modellvergleich entstehen. Vielleicht findet ihr aber auch einen Fehler, den ihr in eurem bestehenden Setup beheben könnt.
Modell und Harness gemeinsam betrachten
Ein Agent besteht aus dem Modell und dem Harness: der Software drumherum, die Werkzeuge bereitstellt, Kontext zusammenstellt und die Arbeitsschritte steuert. Die Grundlagen habe ich in Agent = Modell + Harness beschrieben.
Für die Planung ist entscheidend, welche Teile ihr selbst beeinflussen könnt. Bei einem fertigen Coding-Tool kontrolliert ihr nicht den gesamten Harness. Ihr könnt aber euren Projektkontext pflegen, Werkzeuge zugänglich machen und festlegen, wie ihr Änderungen überprüft. Je nach Tool lassen sich zusätzlich Skills, Hooks oder eigene Erweiterungen einbinden.
Das Modell bleibt dabei relevant. Wenn es eine Aufgabe trotz brauchbarem Kontext und passenden Werkzeugen nicht zuverlässig löst, kann ein Wechsel sinnvoll sein. Nur würde ich vor dem Wechsel wissen wollen, was genau besser werden muss.
Was ein Harness-Vergleich tatsächlich zeigt
LangChain hat im Februar 2026 einen Versuch mit seinem Coding-Agenten dokumentiert. Auf Terminal Bench 2.0 stieg dessen Ergebnis von 52,8 auf 66,5 Prozent, also um 13,7 Prozentpunkte. Das Modell blieb GPT-5.2-Codex; verändert wurden der System-Prompt, Werkzeuge und Middleware.
Unter anderem untersuchte das Team Agentenläufe, in denen die Verifikation ausblieb, und ergänzte Hinweise und Mechanismen zum Prüfen der Ergebnisse. Der Bericht beschreibt zugleich, dass ein Harness auf das verwendete Modell abgestimmt werden muss.
Das ist ein Herstellerbericht über einen einzelnen Benchmark. Er belegt weder einen erwartbaren Produktivitätsgewinn für dein Team noch, dass der Harness grundsätzlich wichtiger ist als das Modell. Er zeigt, dass sich die Leistung in diesem Versuchsaufbau bei unverändertem Modell verbessern ließ. Für mich ist das ein guter Grund, die Umgebung bei der Fehlersuche mitzubeurteilen.
KI-Coding-Strategie am letzten Fehler prüfen
Nehmt einen abgeschlossenen Agent-Auftrag, dessen Ergebnis ihr nacharbeiten musstet. Legt den Auftrag, den Verlauf, den Diff und die tatsächlich ausgeführten Prüfungen nebeneinander. Falls ihr den Verlauf nicht mehr habt, fangt beim nächsten vergleichbaren Auftrag damit an, ihn aufzubewahren.
Ich würde vier Fragen durchgehen:
- War der Auftrag prüfbar? Welche Änderung war verlangt, und woran hätte der Agent erkennen können, dass sie fertig ist? Wenn eine Anforderung erst im Review auftauchte, gehört sie beim nächsten Versuch früher in den Auftrag.
- War der nötige Kontext erreichbar? Konnte der Agent die relevante Fachregel, eine ähnliche Implementierung oder die Projektanleitung finden? Eine Information im Kopf des Entwicklers hilft ihm erst, wenn sie im Arbeitskontext landet.
- Konnte er die passenden Werkzeuge nutzen? Waren Build und Tests ausführbar? Hat der Agent die Ergebnisse gelesen? Ein erfolgreicher Aufruf der falschen Tests ist noch kein Nachweis für die verlangte Änderung.
- Wo blieb die Prüfung an euch hängen? Musste jemand den Entstehungskontext rekonstruieren, einen zu großen Diff zerlegen oder eine unbelegte Annahme suchen? Haltet fest, welche Information bei der Übergabe gefehlt hat.
Ein denkbares Beispiel: Ein Agent ändert eine Berechnung, führt nur die Unit-Tests aus und übersieht eine bestehende Integrationsprüfung. Bevor ihr daraus auf ein zu schwaches Modell schließt, schaut nach, ob diese Prüfung in der Projektanleitung auffindbar war und in der Umgebung überhaupt lief. Ein nächster Versuch könnte genau dort ansetzen.
Ändert zunächst eine Sache und probiert sie an vergleichbaren Aufgaben aus. Ein einzelner erfolgreicher Lauf reicht mir noch nicht, um eine neue Regel zum Teamstandard zu erklären. Vergleicht, ob derselbe Fehler seltener auftritt und ob Kontrolle und Nacharbeit insgesamt weniger Aufwand kosten.
Zur Größe und Übergabe solcher Änderungen findet ihr im Beitrag über reviewbare Diffs weitere Ansatzpunkte.
Aus einer Korrektur eine Teamroutine machen
Wenn eine Änderung hilft, sollte sie für die anderen im Team auffindbar werden. Das kann eine ergänzte Projektanleitung sein, ein verlässlicher Testaufruf oder ein Skill für eine wiederkehrende Aufgabe. Haltet dazu fest, welches Problem ihr damit behebt und wer die Regel pflegt.
Solche Artefakte würde ich beim Modell- oder Toolwechsel mitprüfen. Eine Anweisung kann weiterhin nützlich sein, Anpassung brauchen oder überflüssig werden. Ihr behaltet dabei immerhin die dokumentierte Erfahrung: welcher Fehler auftrat, wie ihr ihn erkannt habt und was dagegen half.
Plant deshalb neben Toolvergleichen auch Zeit ein, um fehlgeschlagene Aufträge gemeinsam anzusehen und das Setup nachzuführen. Das kostet Entwicklungszeit. Ob sich der Aufwand lohnt, müsst ihr an euren Aufgaben und an der verbleibenden Nacharbeit beurteilen.
Wenn ihr anschließend Modelle vergleicht, habt ihr dafür konkrete Kriterien: Besteht das neue Modell an den bisherigen Fehlerfällen? Wie viel Prüfung braucht das Ergebnis? Welche eurer Regeln müssen angepasst werden? Damit lässt sich eine Entscheidung im Team besser begründen als mit einem Ranglistenplatz allein.
Wenn ihr für diese Entscheidung Unterstützung braucht: Im CTO Briefing besprechen wir eure Ausgangslage und die möglichen nächsten Schritte. Ihr bekommt ein Entscheidungsmemo für euren Führungskreis. Dazu kann auch die Empfehlung gehören, vorerst beim bestehenden Setup zu bleiben.