ProgramDistill: Coding-Agenten an Referenz-Apps testen

ProgramDistill untersucht eine praktische Lücke bei der Bewertung von Coding-Agenten: In vielen Modernisierungs- und Migrationsprojekten existiert keine vollständige Spezifikation. Stattdessen gibt es eine funktionierende Anwendung, deren Verhalten ein Team durch Bedienung, Beobachtung und Tests erschließen muss. Der Benchmark lässt Agenten genau das tun und anschließend entdeckte Funktionen in einer unvollständigen Web-App rekonstruieren.

Die automatisierte Pipeline identifizierte laut Studie 1.975 reproduzierbar geprüfte Verhaltensweisen in 26 Anwendungen und erzeugte daraus 4.063 Aufgaben. Damit bewertet ProgramDistill nicht nur, ob ein Agent Code zu einer schriftlichen Anforderung erzeugt, sondern ob er eine Referenzanwendung systematisch erkundet, relevantes Verhalten erkennt und dieses prüfbar nachbildet.

Was ProgramDistill anders misst

Issue-basierte Benchmarks geben das gewünschte Verhalten meist als Text vor. Das ist sinnvoll für Fehlerberichte und klar definierte Änderungen, bildet aber einen anderen Arbeitsmodus ab. Bei einer Referenz-App muss der Agent zuerst herausfinden, welche Zustände, Eingaben, Übergänge und Ausnahmen überhaupt relevant sind. Erst danach beginnt die Implementierung.

Dieser Modus ist für Unternehmen bei Framework-Wechseln, internen Neuimplementierungen, der Ablösung alter Frontends oder schlecht dokumentierten Eigenentwicklungen interessant. Er ersetzt keine fachliche Anforderungserhebung. Er kann aber sichtbar machen, ob ein Coding-Agent Verhalten zuverlässig beobachtet, in überprüfbare Einheiten zerlegt und über mehrere abhängige Schritte konsistent wiederherstellt.

Die Studie berichtet bei vollständiger Rekonstruktion kumulativer Arbeitsabläufe 49,2 Prozent Erfolg für den stärksten getesteten Coding-Agenten und 28,8 Prozent für einen weiteren Frontier-Agenten. Diese Werte sind keine allgemeine Rangliste für Coding-Qualität. Sie gelten für die konkrete Benchmarkkonfiguration und zeigen vor allem, wie stark Leistung bei verketteten Funktionen hinter überzeugenden Einzelschritten zurückbleiben kann.

Die richtige Testmatrix für Referenzanwendungen

Ein Unternehmenspilot sollte nicht mit einer vollständigen Anwendung beginnen. Besser ist eine gestaffelte Matrix, die Beobachtung, Implementierung und kumulative Abhängigkeiten trennt. So wird erkennbar, ob Fehler aus unvollständiger Exploration, falscher Zustandslogik oder mangelnder Codequalität entstehen.

• Tiefe 1: eine sichtbare Aktion mit eindeutigem Ergebnis, etwa ein Filter oder eine Validierung.
• Tiefe 2 bis 3: kurze Abläufe mit Zustandsübergang, beispielsweise Anlegen, Bearbeiten und Speichern.
• Tiefe 4 bis 8: verkettete Nutzerreise mit Rollen, Navigation, persistentem Zustand und Fehlerfällen.
• Vollständiger Workflow: mehrere Funktionen in definierter Reihenfolge mit gemeinsamem Datenzustand.
• Querschnittstest: Barrierefreiheit, Sicherheit, Performance, responsive Darstellung und Protokollierung unabhängig von der Funktionskette.

Für jede Stufe braucht es getrennte Messwerte: entdeckte relevante Verhaltensweisen, korrekt rekonstruierte Funktionen, bestandene End-to-End-Abläufe, neu eingeführte Regressionen, menschliche Nacharbeit, Laufzeit und Kosten. Eine hohe Zahl erzeugter Dateien oder erledigter Teilaufgaben ist kein Ersatz für einen funktionierenden Gesamtprozess.

Fünf Schritte für einen kontrollierten Unternehmenspilot

1. Geeignete Referenz wählen: eine intern kontrollierte, rechtlich zulässige Web-App mit überschaubarem Umfang und repräsentativen Nutzerabläufen auswählen.
2. Verhalten inventarisieren: Fachteam und QA definieren vorab Kernfunktionen, versteckte Zustände, Fehlerpfade und nichtfunktionale Anforderungen. Diese Liste bleibt für den Agenten zunächst verborgen und dient als Prüfgrundlage.
3. Agent explorieren lassen: Beobachtungen, Screenshots, Eingaben, Netzwerkzugriffe und abgeleitete Annahmen protokollieren. Externe Aktionen und Produktivdaten bleiben gesperrt.
4. Rekonstruktion staffeln: erst einzelne Verhaltensweisen, danach kurze Ketten und zuletzt vollständige Workflows implementieren lassen. Nach jeder Stufe automatisierte Tests und menschliche Stichproben ausführen.
5. Wirtschaftlich entscheiden: Agentenkosten, Entwicklungszeit, Nacharbeit, Regressionen und spätere Wartbarkeit gegen den aktuellen manuellen Prozess vergleichen.

Der Pilot sollte mindestens zwei Baselines enthalten: ein Entwickler oder Team mit derselben Ausgangslage sowie der Coding-Agent mit einer schriftlichen Spezifikation. Dadurch lässt sich unterscheiden, ob ein Problem aus der Verhaltensentdeckung oder aus der eigentlichen Implementierung stammt. Ohne diese Trennung kann ein gutes oder schlechtes Gesamtergebnis kaum erklärt werden.

Wo der Ansatz geschäftlich sinnvoll ist

Der stärkste Nutzen liegt bei Anwendungen, die das Unternehmen selbst besitzt oder ausdrücklich nachbauen darf. Dazu zählen interne Legacy-Systeme, Prototypen, Testumgebungen und kontrollierte Migrationen zwischen Frameworks. Auch für die Wiederherstellung fehlender Dokumentation kann die Exploration helfen: Der Agent schlägt beobachtete Verhaltensregeln vor, die Fachleute anschließend bestätigen oder korrigieren.

• Geeignet: interne Migration mit verfügbarer Referenz, Testdaten und fachlichem Abnahmeteam.
• Bedingt geeignet: Drittsoftware mit dokumentierter Integrations- oder Migrationsberechtigung.
• Ungeeignet: Nachbau fremder Produkte ohne Rechte oder Nutzung von Daten, Marken und Inhalten außerhalb der Lizenz.
• Ungeeignet: sicherheitskritische Prozesse ohne unabhängige Spezifikation und manuelle Freigabe.
• Abbruchsignal: der Agent erzeugt scheinbar passende Oberflächen, kann Zustände und End-to-End-Verhalten aber nicht reproduzierbar erklären.

Eine laufende Referenz ist außerdem nicht automatisch korrekt. Bestehende Bugs, veraltete Geschäftsregeln und zufälliges UI-Verhalten können sonst als Sollzustand übernommen werden. Das Fachteam muss deshalb zwischen zu bewahrendem Verhalten, bewusst zu ändernden Regeln und bekannten Fehlern unterscheiden. ProgramDistill liefert ein Evaluationsmuster, keine fachliche Wahrheit.

Freigabegates für den produktiven Einsatz

Vor einer produktiven Migration sollte kein Agentenergebnis allein aufgrund bestandener Happy-Path-Tests übernommen werden. Erforderlich sind deterministische End-to-End-Tests, Rollen- und Berechtigungsprüfungen, Datenmigrationstests, Sicherheitsanalyse, Barrierefreiheit und ein manueller Review der Architektur. Zusätzlich muss der neue Code verständlich genug sein, dass das eigene Team ihn ohne den ursprünglichen Agenten warten kann.

ProgramDistill legt damit einen wichtigen blinden Fleck offen: Coding-Agenten können bei klar beschriebenen Einzelaufgaben stark wirken und bei längeren Funktionsketten dennoch scheitern. Für Beschaffung und Rollout heißt das: Modelle nicht nur an Tickets testen, sondern an den eigenen kumulativen Nutzerabläufen. Erst wenn der Agent Verhalten korrekt entdeckt, über mehrere Schritte rekonstruiert und dabei Nacharbeit sowie Gesamtkosten senkt, entsteht ein belastbarer Business Case.