Kontinuierliche Evaluierungen: Das Betriebssystem von Coding-Agenten

Der alte Deal mit Coding-Assistenten war einfach: Er schlug eine Zeile vor, du hast die Augen zusammengekniffen, und vielleicht wurde niemand verletzt. Heute können Coding-Agenten Tools aufrufen, Zustände verändern und durch ein Repository stolpern wie ein sehr selbstbewusster Praktikant mit Root-Zugriff. Bauchgefühl ist keine QA-Strategie mehr. Es ist eine Duftkerze im Windkanal.

Der hilfreiche Denkrahmen von LetsLearnGenAI ist: Evals werden zum Betriebssystem des KI-gestützten Codings. Nicht die glänzende App-Ebene, nicht die Bestenlisten-Tapete, sondern die Steuerfläche, die Teams zeigt, was sich geändert hat, was kaputtging und ob der Agent weiterarbeiten sollte oder ob man ihm ein Saftpäckchen gibt und ihn aus der Build-Pipeline begleitet.

Anthropic liefert die langweilige Definition, die wir brauchen

Anthropic definiert ein Eval als einen Test für ein KI-System: Man gibt eine Eingabe vor und wendet dann Bewertungslogik auf die Ausgabe an, um den Erfolg zu messen. In seinem Engineering-Beitrag vom 09. Jan. 2026 sagt Anthropic, dass gute Evaluationen Teams helfen, Agenten mit mehr Vertrauen auszuliefern, indem sie Fehler und Verhaltensänderungen sichtbar machen, bevor sie bei Nutzerinnen und Nutzern ankommen. Das Unternehmen erklärt auch, warum Agenten schwerer zu messen sind als Chatbots: Sie arbeiten über viele Runden hinweg, rufen Tools auf, verändern Zustände und passen sich anhand von Zwischenergebnissen an.

@title Evaluationsstruktur
@source Demystifying evals for AI agents

  Input
    │
    ▼
  AI system
    │
    ▼
  Output
    │
    ▼
  Grading logic
    │
    ▼
  Success measure

@caption Anthropic beschreibt Evals als Eingabe, Ausgabe, Bewertungslogik und Erfolgsmessung.

Diese Definition klingt fast beleidigend schlicht, und genau deshalb ist sie wichtig. Repository-Agenten sagen nicht nur das nächste Token voraus, sie führen Handlungen in Umgebungen voller fragiler Tests, unheimlicher Abhängigkeiten und einer Datei namens final_final_really.py aus. Wenn du eine Aufgabe nicht erneut abspielen und das Ergebnis konsistent bewerten kannst, führst du keinen Agenten ein. Du beschwörst einen.

Der Aufgabentyp ist die heimliche Variable

Eine aufgabengeschichtete arXiv-Studie verglich OpenAI Codex, GitHub Copilot, Devin, Cursor und Claude Code anhand von 7.156 Pull Requests aus dem AIDev-Datensatz. Die Studie fand heraus, dass der Aufgabentyp einen großen Einfluss hatte: Dokumentationsaufgaben erreichten eine Akzeptanzrate von 82,1 %, während neue Features 66,1 % erreichten, eine Lücke von 16 Prozentpunkten, die bei den meisten Aufgaben größer war als die typische Varianz zwischen Agenten. Außerdem berichtete sie, dass Devin als einziger Agent einen durchgehend positiven Trend bei der Akzeptanzrate zeigte, mit 0,77 % pro Woche über 32 Wochen, während die anderen Agenten weitgehend stabil blieben.

Das ist der Teil, den Teams sich auf die Innenseite ihres CI-Dashboards tätowieren sollten. Einen Coding-Agenten nach durchschnittlichem Benchmark-Score auszuwählen, ist wie ein Restaurant nach der Anzahl der Gabeln in der Schublade auszuwählen. Eure lokale Eval-Suite sollte Aufgaben nach der Arbeit aufteilen, die ihr wirklich erledigt: Dokumentation, Bugfixes, Refactorings, Migrationen, Tests und neue Features. Sonst kann der Agent, der bei einfachen Wartungsaufgaben brillant aussieht, still und leise eure Architektur auffressen wie ein Waschbär im Serverraum.

Produktions-Evals brauchen produktionsähnliche Aufgaben

Das REAP-Paper argumentiert, dass der Produktionseinsatz von KI-Coding-Agenten schnelle, reproduzierbare Evaluationssignale braucht. Es sagt, dass Online-A/B-Tests Wochen dauern und die User Experience gefährden können, Shadow Deployment keine reproduzierbaren Signale über mehrere Durchläufe hinweg erzeugt und öffentliche Benchmarks von realen Workloads in Sprachverteilung, Prompt-Stil und Codebase-Struktur abweichen können. REAP schlägt vor, automatisch produktionsabgeleitete Benchmarks aus echten Entwickler-Agenten-Sitzungen zu kuratieren, ohne manuelles Labeling.

Das ist die Brücke von Forschungs-Evals zu operativer Disziplin. Ein nützliches Team-Eval ist kein Museum voller Rätselaufgaben, sondern eine lebendige Regressionssuite, gebaut aus dem Chaos, das eure Codebase tatsächlich produziert. Das REAP-Paper weist auch auf praktische Stolperfallen hin: nicht testbare Prompts, falsch ausgerichtete Tests und flaky Tests können die Zuverlässigkeit untergraben. Übersetzung: Wenn dein Eval einen schlechten Agenten nicht von einem schlechten Test unterscheiden kann, Glückwunsch, du hast eine Nebelmaschine mit YAML gebaut.

Benchmarks sind notwendig, aber nicht ausreichend

ProjDevBench setzt bei einer anderen Schwäche an: der End-to-End-Projektentwicklung. Laut seinem arXiv-Abstract gibt der Benchmark Coding-Agenten Projektanforderungen und bewertet die entstehenden Repositories mithilfe von Online-Judge-Tests plus LLM-gestütztem Code Review. Er umfasst 20 Programmierprobleme in 8 Kategorien, evaluiert sechs Coding-Agenten und berichtet eine Gesamtakzeptanzrate von 27,38 %.

Diese niedrige Akzeptanzrate ist kein Grund zur Panik, sondern ein Grund, verantwortungsvoll zu begrenzen. Das Paper sagt, dass Agenten grundlegende Funktionalität und Datenstrukturen bewältigen, aber mit komplexem Systemdesign, Optimierung der Zeitkomplexität und Ressourcenmanagement kämpfen. Für Builder ist der praktische Schritt offensichtlich: Fangt mit engen, aussagekräftigen Aufgaben an, bei denen Korrektheit überprüft werden kann, und erweitert erst dann, wenn eure Evals zeigen, dass der Agent besser wird. Autonomie ohne Messung ist nur Autocomplete im Trenchcoat.

Lasst den Menschen in der Schleife, idealerweise wach

Das Paper Agents That Teach ergänzt einen weicheren, aber wichtigen Fehlermodus: das Lernen von Entwicklerinnen und Entwicklern. Es argumentiert, dass beiläufiges Lernen kurzgeschlossen werden kann, wenn Entwickler umfangreiche Coding-Aufgaben an autonome Agenten delegieren, wodurch das entsteht, was die Autorinnen und Autoren Knowledge Debt nennen. Das Paper schlägt sechs Designprinzipien vor und stellt SHIELD vor, ein Multi-Agenten-System, das kontextbezogenes Lernen außerhalb des direkten Arbeitsflusses aus der eigenen Begründung des Coding-Agenten sichtbar machen soll.

Das ist wichtig, weil Evals mehr messen sollten als nur, ob die Tests grün sind. Teams müssen auch fragen, ob Entwicklerinnen und Entwickler die Änderung erklären, warten und bemerken können, wenn der Agent selbstbewusst eine winzige Kathedrale aus Unsinn erfindet. Der nächste praktische Schritt ist kein riesiges Eval-Imperium. Baut eine kleine lokale Suite, lasst sie auf echten Aufgaben laufen, schichtet nach Aufgabentyp, verfolgt Regressionen und fügt fortlaufend Fälle aus Produktionsfehlschlägen hinzu.

Wenn der Agent fahren soll, sind Evals das Lenkrad, nicht die flauschigen Würfel.