CodeMidas: RL-Aufgaben direkt aus dem Quellcode

Einen Coding-Agenten zu trainieren, der tatsächlich brauchbare Arbeit leistet, war noch nie allein eine Frage von größeren Modellen oder mehr GPUs. Reinforcement Learning braucht Aufgaben, und zwar solche, bei denen die Ausgabe eines Agenten automatisch und zuverlässig als richtig oder falsch geprüft werden kann, also Aufgaben mit Verifizierern.

Ohne Verifizierer ist jede Menge an Trainingsverläufen nicht mehr als Rauschen. Genau das ist der Engpass, den ein neues Paper, „CodeMidas: Scaling Agentic Coding RL Environments from Code Itself“ (arXiv:2609.22068), angeht: nicht zu wenig Rechenleistung, sondern zu wenig von der Ressource, die den Fortschritt wirklich begrenzt, nämlich überprüfbare Coding-Aufgaben.

Warum Issues und Commits nicht ausreichten

Vor CodeMidas bestand die übliche Methode, Open-Source-Repositories in RL-Trainingsaufgaben zu verwandeln, darin, Entwicklungsartefakte auszuwerten: Issues, Commits und Pull Requests, wobei ein Bugreport mit dem Commit gepaart wird, der ihn behoben hat, um eine Aufgabe samt Prüfbedingung zu erzeugen. Dieser Ansatz funktioniert, aber seine Obergrenze ist niedrig, weil die überwältigende Mehrheit des weltweit bereits funktionierenden, implementierten Codes über keinerlei verknüpftes Issue oder Pull Request verfügt.

Sich nur auf von Entwicklern hinterlassene Metadaten zu verlassen bedeutet, den größten Teil des Erzes in der Mine wegzuwerfen, bevor überhaupt gegraben wird. CodeMidas dreht dies um: Es verwendet ausschließlich den Quellcode selbst als Eingabe, ganz ohne Abhängigkeit von Issues, Commits oder Pull Requests. Jedes Stück Code, das bereits eine Funktionalität implementiert, wird im Prinzip als Aufgabe extrahierbar, wodurch sich der adressierbare Aufgabenpool von „Repositories mit Papierspur“ auf praktisch „jede lauffähige Open-Source-Codebasis“ erweitert.

Agentische Rechenleistung in jeder Konstruktionsphase

CodeMidas setzt agentische Rechenleistung über die gesamte Pipeline zur Umgebungskonstruktion hinweg ein, nicht nur beim Training. Zunächst erkunden Agenten die bereits implementierte Funktionalität einer Codebasis und formulieren eine Verhaltensspezifikation, die beschreibt, was dieser Code eigentlich leisten soll.

Danach konstruieren sie Testfälle, die in der tatsächlichen Ausführung des Originalcodes verankert sind, statt aus der Luft gegriffener Annahmen. Schließlich durchlaufen Kandidatenaufgaben eine Validierung und Filterung mittels Ausführungsprüfungen und wiederholter Lösungsrollouts, wobei alles ausgesiebt wird, dessen Spezifikation vage ist, dessen Tests unzuverlässig sind oder das sich nicht stabil reproduzieren lässt. Diese Bereitschaft, die Ausführung selbst zu nutzen, um die Verlässlichkeit einer Aufgabe zu prüfen, ist der Grund, warum die gesamte Pipeline skalieren kann, ohne die Qualität still und leise zu verschlechtern.

Warum Breite der Hebel für Generalisierung ist

Der entstandene Datensatz umfasst 5.545 Trainingsaufgaben aus 3.185 Open-Source-Codebasen, über 23 Programmiersprachen und 15 technische Domänen hinweg. Diese Breite ist kein kosmetisches Detail, sie macht den Unterschied zwischen einem Agenten, der auf einem engen Benchmark lediglich kompetent wirkt, und einem, der übertragbare Coding-Fähigkeiten erworben hat.

Training auf einem schmalen Ausschnitt von Sprachen oder Projektformen begünstigt Überanpassung an eine bestimmte Syntax, ein bestimmtes Bug-Muster oder eine bestimmte Repository-Konvention. Aufgaben über 23 Sprachen und 15 Domänen zu verteilen zwingt die zugrunde liegende gelernte Fähigkeit dazu, allgemeiner zu werden: sich in einer unbekannten Codebasis zurechtzufinden und die eigene Arbeit zu überprüfen, statt nur ein einziges Korpus per Mustererkennung zu bedienen.

Was die Benchmark-Gewinne wirklich zeigen

Das Team trainierte das Modell MiMo-V2.5 mit GRPO auf diesen Aufgaben und evaluierte es auf fünf Benchmarks, wobei drei konkrete Steigerungen berichtet wurden: DeepSWE, ein Benchmark für Issue-Reparatur, verbesserte sich um 11,7 %; ProgramBench, ein Benchmark für die Konstruktion ganzer Programme, um 17 %; und Terminal-Bench v2.1, das Terminalarbeit abdeckt, um 8,5 %. ProgramBench zeigt den größten Sprung, und das passt genau dazu, wie CodeMidas seine Aufgaben von Anfang an konstruiert: Weil die Pipeline darauf ausgelegt ist, vollständig implementierte Funktionalität zu verstehen und zu reproduzieren, statt nur einen eng begrenzten Bug zu flicken, überrascht es wenig, dass der resultierende Agent am meisten beim Bauen von Dingen von Grund auf zulegt statt bei engerer Reparaturarbeit.

Ablationsstudien zeigten außerdem, dass eine wachsende Zahl hochwertiger Trainingsaufgaben die Leistung weiter verbesserte, was darauf hindeutet, dass dieser Ansatz, Verifizierer im großen Maßstab aus Code selbst herzustellen, noch Spielraum nach oben hat. Die Trajektorienanalyse ergab zudem, dass der RL-trainierte Agent mehr Erkundung der Codebasis und vielfältigeres Selbstverifikationsverhalten zeigte, was bedeutet, dass das Modell nicht nur gelernt hat, richtig zu antworten, sondern etwas, das eher der Gewohnheit eines Ingenieurs ähnelt: sich zuerst orientieren, dann handeln, und danach prüfen.