Wenn ein Coding-Agent die Tests bestehen lässt, ist das ein gutes Signal. Es beantwortet aber nicht, ob er die richtige Änderung gemacht, unnötig Dateien angefasst oder einen Test passend zu seinem Fehler umgeschrieben hat.
Die Quellcodestudie zu elf Coding-Harnesses untersucht die Laufzeit hinter solchen Agenten: Werkzeuge, Kontextsteuerung, Sicherheitskontrollen und Orchestrierung. Für die eigene Entwicklung folgt daraus eine praktische Frage: Was prüfen wir am gesamten Arbeitsergebnis? Dieser Beitrag ist eine methodische Einordnung zum 20. August, keine Meldung über einen an diesem Tag veröffentlichten Modellrelease.
Baut einen kleinen Satz echter Aufgaben
Nehmt fünf abgeschlossene Tickets, deren Lösung ihr kennt. Entfernt die fertige Änderung aus einer Testkopie und formuliert das ursprüngliche Problem sauber. Gute Aufgaben decken unterschiedliche Schwächen auf: einen kleinen Bug, eine Änderung über mehrere Dateien, einen Grenzfall und einen Fall mit bewusst unvollständiger Anforderung.
Vor dem Lauf werden die Kriterien festgelegt. Nachträglich die Messlatte an den Output anzupassen macht den Vergleich wertlos.
| Prüfung | Beispiel |
|---|---|
| Fachlich richtig | Rabatt gilt nur für die vereinbarte Kundengruppe |
| Umfang eingehalten | Keine neue Anmeldung für eine reine Formularänderung |
| Seiteneffekte geprüft | Bestehende Preisberechnung bleibt korrekt |
| Übergabe verständlich | Prüfer kann Änderung und offene Fragen nachvollziehen |
Was die Agentur zusätzlich messen sollte
Erfasst Umsetzungszeit, Review und Nacharbeit getrennt. Ein Agent, der viel Code liefert, kann zum Engpass werden, wenn niemand die Änderungen zeitnah versteht. Wiederholt kritische Aufgaben: Ein einzelner gelungener Lauf zeigt keine verlässliche Erfolgsquote.
Fiktives Beispiel: Zwei Werkzeuge lösen je vier von fünf Aufgaben. Beim ersten dauern Prüfung und Reparatur zusammen 90 Minuten, beim zweiten 35. Für ein kleines Team kann dieser Unterschied wichtiger sein als ein Spitzenplatz in einem öffentlichen Benchmark.
Keine eigene Benchmark-Studie: Die Beispiele hier sind ein vorgeschlagener Prüfaufbau. Wir behaupten damit keine gemessene Überlegenheit eines Produkts.
Im Enterprise wird daraus ein Freigabeprozess
Versioniert Aufgaben, Ausgangscode, Modellkennung und Einstellungen. Bei einer relevanten Modell- oder Harness-Änderung wiederholt ihr den passenden Ausschnitt. Kritische Pfade wie Berechtigungen und Abrechnung bekommen eigene Abnahmen.
Für kleine Teams muss daraus kein Testlabor werden: Eine übersichtliche Tabelle und fünf gute Aufgaben reichen für den ersten Vergleich. Mehr Aufwand lohnt sich dort, wo Fehler hohe Folgekosten hätten.
Wir entwickeln mit euch einen Abnahmeprozess für KI-gestützte Softwareentwicklung, der zu euren Projekten und zur verfügbaren Review-Zeit passt.
