Ob ein Auto fährt, lässt sich testen. Ob ein Programm korrekt arbeitet, ebenfalls. In Informatik und Ingenieurwissenschaften haben wir es häufig mit Systemen zu tun, die Menschen selbst entworfen haben. Mit klaren Funktionen, definierten Schnittstellen und vergleichsweise eindeutigen Kriterien für Erfolg oder Fehler. Ein eindeutiges Signal.
Ganz anders sieht es bei hochkomplexen offenen Systemen aus, etwa in der Biologie, Psychologie, Medizin oder Ernährungswissenschaften: Dort ist Verifikation aufwändiger, indirekter und meist nur statistisch möglich.
Mit dieser Komplexität geht die Gesellschaft sehr unterschiedlich um.
Die Medizin ist zum Beispiel streng reguliert und ein Medikament wird nur nach Jahren der Studien zugelassen wenn die Wirkung wirklich bestätigt wurde. Die Ernährungswissenschaft ist zwar auch reguliert, aber dagegen deutlich schwerer sauber abzugrenzen. Hier vermischen sich wissenschaftliche Erkenntnisse, Lifestyle-Trends, persönliche Erfahrungsberichte und kommerzielle Interessen viel stärker. Dadurch entsteht ein Umfeld, in dem Halbwissen, überzogene Heilsversprechen und missverstandene Studien besonders leicht zirkulieren können.
Zudem besteht häufig in diesen komplexen Systemen eine enorme Asymmetrie zwischen Erzeugung, Behauptung und Überprüfung: Ein Glas Wasser hinzustellen und zu behaupten, es helfe gegen Haarausfall, ist leicht. Sauber nachzuweisen, ob das stimmt oder nicht, ist dagegen extrem aufwändig.
Nun befinden wir uns seit rund dreieinhalb Jahren in der Ära der KI-Sprachmodelle. Die Systeme waren zwar von Anfang an komplex, ließen sich in den ersten Jahren aber noch vergleichsweise einfach evaluieren. Schon nach wenigen gezielt ausgewählten Fragen bekam man ein gutes Bild ihrer Fähigkeiten. Selbst im ersten halben Jahr der Coding-Agenten 2025 zeigte sich oft bereits nach den ersten Codezeilen ein deutliches Signal für Fehlverhalten. Man musste dem Agenten dann Dinge explizit als Anweisung mitgeben, die für uns offensichtlich waren.
Diese Zeiten scheinen aber endgültig vorbei, wir kommen auch hier in den Bereich der hochkomplexen offenen Systeme. Und die Folgen davon sind unübersehbar.
Je länger der Zeithorizont, in dem Agenten arbeiten, desto schwieriger wird ihre Evaluation. Die Fehlerbalken neuer Modelle zeigen, wie schwer belastbare Messungen sind.
Bestes Beispiel dafür ist der definierende Benchmark 2025 für Coding Agenten: SWE-Bench, ein automatisch laufender Benchmark, bei dem Modelle reale GitHub-Issues in echten Software-Repositories lösen müssen. Also eine Evaluation, die möglichst realistisch sein sollte.
Aber schon der ursprüngliche Datensatz war so fehleranfällig, unterspezifiziert und technisch fragil, dass er mit SWE-Bench Verified erst in aufwendiger Handarbeit bereinigt werden musste. Doch selbst danach begann die eigentliche Arbeit erst: Weitere Forschungsarbeiten zeigten, dass auch die bereinigte Version noch problematische Aufgaben, unzureichende Tests und fragwürdige Erfolgskriterien enthielt. Parallel dazu wuchs der Aufwand, überhaupt noch zu klären, ob hohe Ergebnisse echte Generalisierung zeigen oder ob Modelle Teile des viel diskutierten Benchmarks schlicht auswendig kennen. Dass selbst OpenAI und Anthropic den Benchmark inzwischen nicht mehr für vollständig vertrauenswürdig hält, ist deshalb mehr als eine Randnotiz.
Auch die Bewertung der Coding Agenten durch den einzelnen Entwickler wird zunehmend schwieriger.
Im November letzten Jahres gab es Updates der Coding Agenten von OpenAI und Anthropic. Die Benchmarks haben wie üblich einen Schritt nach vorne gemacht. Nichts besonderes. Aber es hat mehrere Wochen gedauert, bevor die Community bemerkt hatte, dass sich qualitativ was geändert hatte und in diesem Satz hier von Andrew Karpathy seinen Höhepunkt fand.
never felt this much behind as a programmer
Die Coding Agenten haben plötzlich angefangen zu funktionieren. Kein Benchmark hatte das gemessen. Und es gibt bis heute auch keine objektive Metrik darüber, was sich überhaupt geändert hatte.
Nun gab es vor wenigen Wochen genau das Gegenteil: negative Stimmen zu Anthropics Claude Code. Der Agent sei plötzlich schlechter geworden. Zunächst nur wochenlange subjektive Schreie aus der Community. Kein Beweis. Irgendwann gab es jedoch echte Messwerte und Anthropic hatte daraufhin wirklich Fehler eingeräumt. Eine Ursache war, dass Anthropic den System-Prompt von Claude Code angepasst hatte, um die Ausführlichkeit zu reduzieren. Opus neigte offenbar zu längeren Antworten, was bei schwierigen Aufgaben durchaus hilfreich sein kann, aber eben auch mehr Output-Tokens kostet. Also fügte Anthropic sinngemäß eine Anweisung hinzu: Text zwischen Tool-Aufrufen solle höchstens 25 Wörter lang sein, finale Antworten höchstens 100 Wörter, außer die Aufgabe erfordere mehr Details.
Das klingt zunächst völlig harmlos. Sogar vernünftig. Wer einen Coding-Agenten benutzt, will schließlich nicht unbedingt Romane lesen. Aber genau dieser eine zusätzliche Satz im System-Prompt hatte messbare Nebenwirkungen. Nach internen Tests ohne erkennbare Regressionen wurde die Änderung produktiv gesetzt. Erst spätere Tests, bei denen einzelne Zeilen des System-Prompts gezielt entfernt wurden, zeigten: Diese Längenbegrenzung reduzierte die Coding-Qualität in einer breiteren Evaluation um etwa drei Prozent.
Und genau das ist der Punkt. Nicht ein großer Architekturumbau, kein neues Modell, kein offensichtlicher Bug in der Inferenzschicht, sondern ein einzelner Satz im System-Prompt reichte aus, um die Qualität eines Coding-Agenten spürbar zu verschieben. Noch bemerkenswerter: Die Änderung war nicht absurd. Sie war plausibel. Sie hatte ein klares Ziel. Sie wurde getestet. Und trotzdem fiel der Effekt erst später auf.
An dieser Stelle könnte ich die Liste beliebig fortsetzen. Open AI hatte zum Beispiel mit Gremlins in ihren Agenten zu kämpfen. Ebenfalls, ein Problem, was sich erst in der Community zeigte und dessen Analyse Wochen benötigte.
Wir haben es hier mit sehr komplexen, nichtlinearen Systemen zu tun, deren Verhalten oft schwer vorhersehbar ist. Jede Änderung, sei es auch nur ein einzelner Satz, kann zu unerwünschten Nebeneffekten führen. Eine Evaluation kann diese Nebeneffekte leicht übersehen, weil gar nicht so detailliert getestet werden kann. Eine automatische Evaluation funktioniert nur dann, wenn überhaupt definiert werden kann, was gut oder schlecht ist. Und selbst dann ist eine Evaluation möglicherweise so aufwendig, dass es eigene Teams braucht, um sie zu bauen und kontinuierlich anzupassen.
Das alles ist ein relativ neues Symptom in der Entwicklung von Agenten. Neue Versionen werden für Menschen zunehmend schwer messbar, weil das „Signal“, anhand dessen sie einfach bewertet werden könnten, kaum noch klar erkennbar ist. Vielleicht zeigt es sich erst nach Wochen, und dann auch nicht bei einzelnen Nutzern, sondern nur als Ergebnis der gesamten Community. Neue Modellversionen oder angepasste Agentensysteme werden in dieser Hinsicht für uns Menschen kaum noch klar unterscheidbar sein.
Das sieht jetzt aus wie eine kleine Krise in der Informatik. Ist es aber nicht. Es ist einfach eine Tatsache über diese neue Welt. Und wir müssen lernen, damit umzugehen. Sobald man Agentensysteme selbst entwickelt oder um die Agenten Tooling baut, um Workflows zu verbessern, arbeitet man nicht mehr primär mit schnell messbaren Ergebnissen, sondern mit plausiblen Annahmen, Indizien und Hypothesen.
Die Agentenentwickler, und damit sind derzeit hauptsächlich Softwareentwickler gemeint, werden für nicht triviale Agenten oft keine vollständige automatische Evaluierung mehr durchführen können. Zumindest nicht mit realistischem Aufwand. Vollständige, belastbare Evaluationen sind zunehmend nur noch unter massivem Ressourceneinsatz möglich, also unter Bedingungen, wie sie praktisch nur Frontier Labs leisten können.
Bereits eine etwas älteren Umfrage zu Agenten in Produktion, abseits von Coding-Agenten, zeigte: 75 Prozent der Agenten gehen ohne automatisierte Benchmarks in Produktion. Stattdessen findet die eigentliche Evaluierung aktiv durch den Nutzer im laufenden Betrieb statt. Das ist vertretbar, denn laut derselben Umfrage gibt es bislang kein Produktivsystem, in dem der Nutzer nicht das letzte Wort hat.
Eine Möglichkeit sind zum Beispiel A/B-Tests. Das heißt: Dem Nutzer werden zwei Lösungen präsentiert, und er muss die bessere auswählen. Oder ganz klassisch: Daumen hoch oder runter, zusammen mit einem Feedbackformular.
Das sind also Konzepte der Art:
I know it when I see it.
Man kann also nicht klar definieren, was gut oder schlecht ist, aber man erkennt es, wenn man ein falsches Ergebnis vor sich sieht oder vergleichen kann.
Diese Informationen müssten zurückfließen, um den Agenten zu optimieren. Dass das sogar automatisch funktionieren kann, zeigen Prompt-Optimierer mit Feedback-Option, zum Beispiel in DSPy.
Und dann gibt es ganz neue Wege. Das Transkript des Chatverlaufs ist ja immer vorhanden. Hier wird zum Beispiel auch jede Korrektur des Menschen geloggt. Dieses Wissen langfristig zu verwenden, ist genau die Aufgabe der sogenannten „Memory“-Funktionen einiger Agenten. Im einfachsten Fall machen sie sich Notizen über den Nutzer, aber eben auch über wiederkehrende Korrekturen. Genau diese Informationen könnten gesammelt und später ausgewertet werden.
Die Lösung für Entwickler von Agentensystemen sieht also iterativ aus und erstreckt sich über einen relativ langen Zeitraum. Und sie wird nur für diejenigen funktionieren, die einen langen Atem haben. Auch die Nutzer müssen mitspielen, kräftig Feedback geben und nicht sofort aufgeben, wenn es in den ersten Monaten schlecht funktioniert.
Für Entwickler bedeutet das ein Umdenken, denn die Hürden sind wesentlich größer als bei klassischer Software. Es ist schlecht abschätzbar, wie lange es dauert. Es ist aber wohl ein notwendiges Übel, wenn niemand genau weiß, was eigentlich gut oder schlecht ist.
Das Gute daran: Das iterative Vorgehen verspricht eigentlich immer Fortschritt. Die Zeit arbeitet für einen. Die Modelle werden besser. Die Probleme werden nach und nach identifiziert. Die Nutzer passen sich an. Vielleicht wird sogar der Prozess selbst angepasst, wenn der Nutzen klar wird. Bei einem zunächst schlecht funktionierenden Proof of Concept aufzuhören, ist daher der falsche Weg. Nicht bei dem Potenzial, das Agenten liefern können.
Für die Community da draußen, die gerade mit Agentensystemen arbeitet, würde ich mir mehr Transparenz und Ehrlichkeit wünschen. Jede Aussage, die einen „Best Way“ für Agenten verspricht, und jedes neue AI-Tool sollte eigentlich ein Sternchen bekommen:
Ich habe es nicht konsequent evaluiert. Meine Argumente basieren vollständig auf Indizien. Mein Tool hat für mich, in meinem Projekt, mit meiner Vorgehensweise und mit diesem Modell subjektiv zu besseren Ergebnissen geführt. Eine belastbare Evaluation für euer eigenes Projekt dürfte x Wochen dauern.
Das wäre keine Schwäche, sondern ein Fortschritt. Es würde die Tools und Projekte hervorheben, die tatsächlich den langen Weg gegangen sind und mehr vorweisen können als ein gutes Bauchgefühl. Und es würde sichtbar machen, wo in Zukunft vielleicht ein eigener Markt entsteht: nicht nur für Agenten, Frameworks und Tools, sondern für deren Evaluation.
Denn genau hier liegt die eigentliche Asymmetrie: Etwas für die AI-Welt zu bauen, ist drastisch einfacher geworden. Zu wissen, ob es wirklich besser ist, nicht.