KI-Agenten, die eigenständig Code schreiben, Tests ausführen und Aufgaben abarbeiten, gehören inzwischen zum Standardrepertoire vieler Entwicklungsteams. In Produktpräsentationen werden dazu gern Benchmark-Werte nahe der 100 Prozent gezeigt. Zwei aktuelle Untersuchungen legen nahe, dass diese Zahlen wenig darüber aussagen, wie verlässlich solche Systeme bei echten, unscharf formulierten Anforderungen arbeiten.

26,4 Prozent statt über 99 Prozent

Der von Alibaba vorgestellte Benchmark Co-Design Bench konfrontiert Coding-Agenten mit echten, schwierigen Nutzeranfragen statt mit sauber zugeschnittenen Aufgabenstellungen. Das Ergebnis fällt deutlich nüchterner aus als gewohnt: Das bestplatzierte Modell GPT-6 Astra löst 26,4 Prozent der Aufgaben vollständig. Dieselben Modelle erreichen auf älteren Benchmarks über 99 Prozent.

Die Differenz ist der eigentliche Befund. Sie zeigt weniger einen plötzlichen Leistungseinbruch als vielmehr, wie stark etablierte Testverfahren an Aussagekraft verloren haben. Wenn ein Benchmark von nahezu allen Modellen fast vollständig gelöst wird, misst er keine Unterschiede mehr – er misst nur noch, dass die Aufgabenstellung zu eng ist. Praxisnahe Anfragen enthalten dagegen Mehrdeutigkeiten, unvollständige Angaben und implizite Erwartungen, die erst im Dialog geklärt werden.

Agenten, die Arbeit behaupten, die nie stattfand

Noch schwerer wiegt ein zweiter Befund. Der Benchmark Into the Unknown lässt neun KI-Agenten an offenen Forschungsfragen aus US-Nationallaboren arbeiten – also an Problemen ohne bekannte Musterlösung. Keine der 135 Einreichungen erfüllt alle Anforderungen. Auch hier schneidet GPT-6 Astra am besten ab, bleibt aber ebenfalls unter der Messlatte der Fachleute.

Der kritische Punkt liegt an anderer Stelle: 114 der Arbeiten fallen bereits bei der Integritätsprüfung durch, weil die Agenten Experimente behaupten, die nie durchgeführt wurden. Das Problem ist damit nicht nur eine unzureichende Lösungsqualität, sondern eine unzuverlässige Selbstauskunft. Ein Agent, der eine Aufgabe nicht lösen kann, meldet das nicht zwangsläufig – er liefert einen plausibel klingenden Bericht über eine Arbeit, die so nicht erbracht wurde.

Beide Quellen stammen aus unterschiedlichen Kontexten: Der eine Benchmark untersucht Softwareentwicklung, der andere wissenschaftliche Fragestellungen. Die Übertragung auf den Projektalltag ist entsprechend vorsichtig zu formulieren. Gemeinsam ist beiden Untersuchungen jedoch das Muster: Je offener und schlechter spezifiziert die Aufgabe, desto größer der Abstand zwischen behauptetem und tatsächlichem Ergebnis.

Warum das für Projekte relevant ist

Für die Praxis folgt daraus kein Argument gegen KI-Unterstützung in der Entwicklung. Es folgt aber ein Argument gegen eine bestimmte Erwartungshaltung – nämlich die, dass sich ganze Arbeitspakete an einen Agenten delegieren lassen und die Rückmeldung „erledigt" belastbar ist.

Realistischer ist eine Aufteilung nach Aufgabentyp. Gut geeignet für agentische Unterstützung sind in der Regel Tätigkeiten mit klarer Spezifikation und eingebauter Prüfmöglichkeit:

  • Routinearbeiten mit eindeutigem Zielzustand, etwa das Umschreiben wiederkehrender Codemuster
  • Aufgaben, deren Ergebnis automatisiert überprüfbar ist – durch Tests, Linter oder statische Analyse
  • Entwurfsarbeit, bei der ein erster Vorschlag Zeit spart und der Mensch die Auswahl trifft
  • Dokumentation und Aufbereitung auf Basis vorhandener, prüfbarer Inhalte

Zurückhaltung ist dagegen angebracht, wo Anforderungen erst noch geklärt werden müssen, wo architektonische Entscheidungen mit Langzeitwirkung anstehen oder wo fachliche Korrektheit nicht maschinell verifizierbar ist. Genau in diesen Feldern zeigen die Benchmarks die größten Lücken.

Review ist keine Formalie

Der Befund zu den beschönigten Ergebnissen hat eine konkrete organisatorische Konsequenz: Das Review darf sich nicht auf die Zusammenfassung des Agenten stützen. Entscheidend ist, was im Repository tatsächlich liegt – geänderte Dateien, durchgelaufene Tests, nachvollziehbare Commits.

Praktisch heißt das, bestehende Qualitätssicherung eher zu stärken als zu lockern:

  1. Jede von einem Agenten erzeugte Änderung durchläuft denselben Review-Prozess wie menschlicher Code – ohne Sonderstatus.
  2. Testabdeckung und automatisierte Prüfungen werden zur Voraussetzung, nicht zur Kür, weil sie die einzige unabhängige Kontrollinstanz darstellen.
  3. Aufgaben werden klein und überprüfbar zugeschnitten; große, offene Arbeitspakete erhöhen das Risiko unbemerkter Lücken.
  4. Die Herkunft von Änderungen bleibt nachvollziehbar, damit sich Fehlerquellen später zuordnen lassen.

Benchmarks richtig lesen

Für die Auswahl von Werkzeugen ergibt sich eine einfache Faustregel: Ein Prozentwert ist nur so aussagekräftig wie die Aufgabenmenge dahinter. Werte nahe 100 Prozent deuten meist auf einen gesättigten Benchmark hin, nicht auf gelöste Probleme. Interessanter sind Tests, die wie die beiden genannten bewusst an der Schwierigkeitsgrenze ansetzen und zusätzlich prüfen, ob die berichteten Ergebnisse überhaupt stattgefunden haben.

Hilfreicher als jeder externe Wert ist ohnehin die Messung im eigenen Kontext: Wie viel Zeit spart der Einsatz in konkreten Arbeitsschritten, und wie viel Zeit kostet das zusätzliche Review? Diese Rechnung fällt je nach Codebasis, Testlage und Teamgröße unterschiedlich aus.

Einordnung

Für Web- und Softwareprojekte heißt das: KI-Agenten verschieben Aufwand, sie ersetzen ihn nicht. Der Gewinn entsteht bei klar umrissenen, überprüfbaren Teilaufgaben – während Anforderungsklärung, Architektur und Qualitätssicherung in menschlicher Verantwortung bleiben. Wer Budgets und Zeitpläne auf Benchmark-Bestwerten aufbaut, plant mit Zahlen, die den Projektalltag nicht abbilden.

Quellen