🤖 machine learning

Probe-and-Refine Tuning of Repository Guidance for Coding Agents

Dieses Paper führt „Probe-and-Refine Tuning“ ein, eine Methode, die Repository-Leitdateien (AGENTS.md) iterativ mithilfe von synthetischen Bugfix-Proben optimiert, um die Leistung von Coding-Agenten auf SWE-bench Verified signifikant zu verbessern, indem die Abdeckung evaluierbarer Patches erweitert wird, anstatt die Präzision pro Patch zu erhöhen.

Ursprüngliche Autoren: Asa Shepard, Jeannie Albrecht

Veröffentlicht 2026-06-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Asa Shepard, Jeannie Albrecht

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen einen brillanten, aber unerfahrenen Lehrling ein, um eine riesige, alte Bibliothek (das Code-Repository) zu reparieren. Der Lehrling ist klug genug, um Bücher zu lesen und kaputte Seiten zu flicken, aber er kennt die geheimen Regeln der Bibliothek nicht: welches Regal die seltenen Karten enthält, wie man den Bibliothekar um Hilfe bittet, ohne die schlafenden Katzen zu wecken, oder welche Leitern sicher zu erklimmen sind.

Ohne dieses „lokale Wissen“ wandert der Lehrling ziellos umher, klettert auf die falsche Leiter oder versucht, ein Buch in einem falschen Bereich zu reparieren, wobei er oft Dinge beschädigt.

Dieses Paper stellt eine Methode namens „Probe-and-Refine Tuning“ vor, um dieses Problem zu lösen. So funktioniert es, unter Verwendung einfacher Analogien:

Das Problem: Das „Einheits-Handbuch“

Ingenieure schreiben oft ein „Spickzettel“ (wie eine AGENTS.md-Datei) für ihre KI-Coding-Agenten.

Der alte Weg (Statisches Wissen): Sie bitten eine kluge KI, ein generisches Handbuch zu schreiben: „Prüfe immer den Index, bevor du etwas reparierst“ oder „Suche nach dem Haupteinstiegspunkt“. Das ist, als würde man dem Lehrling eine Karte von jeder Bibliothek der Welt geben. Es ist hilfreich, aber es sagt ihm nicht, wo sich der spezifische Geheimvorrat dieser einen Bibliothek versteckt.
Das Ergebnis: Der Lehrling macht zwar okay, verliert sich aber trotzdem oft.

Die Lösung: Der „Versuch-und-Irrtum“-Coach

Die Autoren entwickelten einen neuen Prozess namens Probe-and-Refine. Anstatt ein Handbuch einfach nur einmal zu schreiben, behandeln sie das Handbuch wie ein lebendiges Dokument, das durch Fehler lernt.

Man kann sich das wie einen Coach vorstellen, der einen neuen Spieler trainiert:

Die Probes (Die Übungen): Der Coach erstellt 10 künstliche, fiktive Probleme (Probes), die spezifisch für diese Bibliothek sind.
Der Versuch: Der Lehrling versucht, diese fiktiven Probleme mithilfe des aktuellen Handbuchs zu lösen.
Die Diagnose: Der Coach beobachtet den Versuch. „Oh, du hast versucht, die Rohrleitungen in der Küche zu reparieren, aber die Rohre sind eigentlich im Keller. Und du hast vergessen, zuerst die Baupläne zu prüfen.“
Die Verfeinerung: Der Coach aktualisiert das Handbuch sofort mit einer spezifischen Regel: „Für diese Bibliothek liegen die Rohrleitungen im Keller, und prüfe immer zuerst die Baupläne.“
Wiederholung: Dies wird 3 bis 5 Mal durchgeführt. Das Handbuch entwickelt sich von einem generischen Leitfaden zu einem hyper-spezifischen „Insider“-Leitfaden.

Entscheidend ist: Dieser gesamte Trainingsprozess findet statt, ohne dass der Agent tatsächlich echte Bugs behebt. Es ist eine Simulationsschleife, in der die KI das Handbuch schreibt, es an fiktiven Problemen testet und das Handbuch basierend auf den Ergebnissen korrigiert.

Was sie herausfanden

Die Forscher testeten dies auf einem berühmten Coding-Benchmark (SWE-bench) in vier verschiedenen Durchläufen. Das passierte:

Kein Leitfaden: Der Lehrling löste 25,5 % der Probleme.
Generischer Leitfaden: Der Lehrling löste 28,3 % der Probleme.
Probe-and-Refine Leitfaden: Der Lehrling löste 33,0 % der Probleme.

Das große Geheimnis: Es geht darum, die richtige Tür zu finden, nicht darum, besser zu reparieren
Man könnte denken, das verbesserte Handbuch habe den Lehrling schlauer gemacht oder besser darin, Dinge zu reparieren. Das tat es nicht.

Wenn der Lehrling tatsächlich etwas repariert hat, war die Qualität der Reparatur mit beiden Handbüchern exakt gleich (etwa 5 9 % Erfolgsquote).
Die wahre Magie war die „Abdeckung“ (Coverage). Das verbesserte Handbuch half dem Lehrling, viel häufiger die richtige Datei zu finden, die zu reparieren war.
- Analogie: Das generische Handbuch ließ den Lehrling an 100 Türen klopfen, aber nur 40 davon waren die richtigen. Das verfeinerte Handbuch ließ ihn an 100 Türen klopfen, und 56 davon waren die richtigen. Sobald er die richtige Tür gefunden hatte, war seine Fähigkeit, das Schloss zu reparieren, dieselbe.

Die „Schritt-Budget“-Falle

Das Paper entdeckte auch, dass der Leitfaden nur funktioniert, wenn man dem Lehrling genug Zeit gibt.

Wenn man dem Lehrling nur 25 Schritte gibt, um ein Problem zu lösen, hilft das schicke Handbuch nicht. Er hat keine Zeit, die komplexen Anweisungen zu befolgen.
Wenn man ihm 200 Schritte gibt, glänzt das schicke Handbuch. Es gibt ihm einen Workflow vor (Reproduzieren -> Verfolgen -> Reparieren), der Zeit benötigt, aber funktioniert. Oh ohne das Handbuch hetzt er einfach nur und scheitert.
Analogie: Wenn man jemandem sagt: „Nimm die malerische Route, um den Verkehr zu umgehen“, aber man gibt ihm nur 5 Minuten Zeit, um zur Arbeit zu kommen, wird er einfach nur die Orientierung verlieren. Man muss ihm genug Zeit geben, um die malerische Route tatsächlich nehmen zu können.

Die Warnung vor dem „Modell-Mismatch“

Die überraschendste Erkenntnis war, dass dieser Leitfaden nicht universell ist.

Sie versuchten, den Leitfaden, der mit einem bestimmten KI-Modell (Qwen) trainiert wurde, mit einem anderen, etwas schwächeren KI-Modell (Nemotron) zu verwenden.
Ergebnis: Das zweite Modell stürzte ab. Es war durch die spezifischen Anweisungen so verwirrt, dass es komplett aufhörte zu funktionieren.
Analogie: Es ist, als würde man einem Fahrer in einem langsamen, alten Sedan ein detailliertes High-Speed-Rennhandbuch geben. Die Anweisungen sind zu komplex für das Auto, und der Fahrer erstarrt. Der Leitfaden muss spezifisch auf das „Gehirn“ (das Modell) abgestimmt sein, das ihn lesen wird.

Zusammenfassung

Dieses Paper beweist, dass es mehr darauf ankommt, wie man die Anweisungen schreibt, als nur darauf, überhaupt Anweisungen zu haben.
Indem man eine einfache Schleife aus „erstelle ein fiktives Problem, versuche es zu lösen und korrigiere die Anweisungen basierend auf dem Scheitern“ nutzt, kann man einen generischen Leitfaden in ein spezialisiertes Expertenhandbuch verwandeln. Dies macht die KI nicht schlauer beim Reparieren von Code; es verhindert lediglich, dass sie an der falschen Stelle sucht, und ermöglicht es ihr so, ihr volles Potenzial zur Lösung von Problemen auszuschöpfen.

Technisches Resümee: Probe-and-Refine-Tuning von Repository-Anleitungen für Coding-Agenten

Problemstellung

LLM-basierte Coding-Agenten scheitern oft an Software-Engineering-Aufgaben, nicht aufgrund mangelnder Denkfähigkeit, sondern weil ihnen das übergeordnete operationale Wissen über ein spezifisches Code-Repository fehlt. Dieses implizite Wissen – wie etwa Subsystem-Grenzen, Testausführungs-Workflows und historische Debugging-Muster – ist im Code selbst selten dokumentiert. Während Ingenieure Kontextdateien (z. B. AGENTS.md) pflegen, um diese Informationen bereitzustellen, präsentiert die jüngere Literatur widersprüchliche Belege zu deren Wirksamkeit: Einige Studien deuten darauf hin, dass sie die Effizienz verbessern, während andere zeigen, dass sie die Erfolgsraten senken können, wenn die Anleitung generisch oder kontraproduktiv ist. Das Kernproblem besteht darin, dass unklar bleibt, ob das Scheitern am Konzept der Anleitung selbst liegt oder an der Art und Weise, wie diese Anleitung erzeugt wird. Aktuelle Methoden verlassen sich oft auf eine einmalige LLM-Generierung, was eher generische Ratschläge als die spezifischen, durch Fehlgeschlagen-informierten operationalen Strategien liefert, die Agenten benötigen.

Die Methode führt Probe-and-Refine-Tuning ein, ein leichtgewichtiges Verfahren, das darauf ausgelegt ist, die Anleitungsdatei eines Repositories iterativ mithilfe von synthetischen Bugfix-Proben zu diagnostizieren und zu patchen. Das Verfahren unterscheidet sich von Standard-Agenten-Schleifen dadurch, dass es sich vollständig auf Single-Shot-LLM-Aufrufe stützt, ohne Tool-Nutzung oder Reinforcement Learning während der Tuning-Phase.

Die Tuning-Schleife

Der Prozess transformiert eine statische, generische Wissensbasis in spezialisierte operationale Anleitung durch 3–3–5 Iterationen:

Proben generieren: Das System generiert einen Stapel von 10 synthetischen Bugfix-Aufgaben aus dem Codebase des Repositories, die auf diverse Subsysteme abzielen.
Fix versuchen: Für jede Probe versucht ein Single-Shot-LLM-Aufruf, einen Patch unter Verwendung des aktuellen Anleitungs-Artefakts zu generieren.
Versuch bewerten: Ein separater Single-Shot-Aufruf bewertet den versuchten Lösungsansatz gegenüber den erwarteten Verhaltensweisen (z. B. starke, partielle oder fehlende Fixes) und schlägt spezifische Edits für die Anleitung vor, sofern Mängel identifiziert werden.
Aggregieren und Anwenden: Ein finaler Aufruf aggregiert die Diagnosen aller Proben und schlägt einen konsolidierten Satz von Edits vor. Diese Edits werden mechanisch angewendet (Einfügen, Modifizieren oder Verstärken von Abschnitten) auf die Anleitungsdatei, begrenzt auf 3.000 Zeichen.

Die Schleife terminiert vorzeitig, wenn die Anleitung stabil wird (keine Änderungen zwischen aufeinanderfolgenden Iterationen). Das resultierende Artefakt wird dann verwendet, um einen Standard-ReAct-Stil Coding-Agenten während der Evaluierungsphase auf SWE-bench Verified zu leiten.

Experimentelles Setup

Die Autoren evaluierten drei Bedingungen an 500 SWE-bench Verified Instanzen über vier unabhängige Durchläufe mit dem Modell Qwen3.5-35B-A3B:

Kein Kontext: Der Agent operiert ohne repositoryspezifische Anleitung.
Statischer KB: Der Agent nutzt eine zweistufige Wissensbasis, die strukturelle Daten (geparst via tree-sitter) und generische, repositorien-agnostische Best Practices enthält.
Probe-and-Refine: Der Agent nutzt eine durch das oben beschriebene iterative Tuning-Verfahren erzeugte Anleitung.

In einem Sekundärexperiment wurde das Modell durch NVIDIA-Nemotron-3-Nano-30B-A3B ersetzt, um die modellübergreifende Generalisierung zu testen, und ein Step-Budget-Sweep (25, 50, 100, 200 Schritte) wurde durchgeführt, um die Interaktion zwischen Anleitung und Agenten-Budget zu analysieren.

Kernergebnisse

Leistungssteigerungen

Über vier Durchläufe hinweg erreichte Probe-and-Refine eine mittlere Erfolgsrate von 33,0 % und übertraf damit signifikant den Static KB (28,3 %) und die No Context Baseline (25,5 %). Die Verbesserung war statistisch signifikant ( $p < 0,001$ ) für beide Kontraste. Das Verfahren lieferte zudem 31 konsistent einzigartige Lösungen (gelöst in $\ge$ 3 von 4 Durchläufen), die keiner der anderen Bedingungen lösen konnte.

Mechanismus: Coverage vs. Precision

Das Paper dekomponiert den Leistungszuwachs, um zu bestimmen, wie die Anleitung hilft:

Coverage (Abdeckung): Der primäre Treiber der Verbesserung ist die Evaluations-Abdeckung. Die Probe-and-Refine-Anleitung ermöglichte es dem Agenten, für 56,2 % der Instanzen gut geformte, evaluierbare Patches zu produzieren, verglichen mit 41,7 % für die ungeleitete Baseline (eine Differenz von 14,5 Prozentpunkten).
Precision (Präzision): Die Korrektheit der Patches, unter der Bedingung, dass sie evaluierbar sind, blieb über alle Bedingungen hinweg statistisch konstant ( $\sim$ 59 %, $p = 0,119$ ).
Fazit: Die Anleitung verbessert nicht die Qualität der Code-Änderungen, die der Agent vornimmt; vielmehr hilft sie dem Agenten, die korrekte Datei zu erreichen und einen Patch zu produzieren, den das Evaluations-Harness akzeptieren kann. Die Anleitung reduziert effektiv die Rate von schlecht formatierten Patches oder Patches, die die Test-Suite zum Absturz bringen, bevor Assertions geprüft werden können.

Step Budget und Workflow

Die Studie fand heraus, dass die Anleitung als Moderator für die Nützlichkeit des Step Budgets fungiert.

Unguided Agenten sättigen schnell; eine Erhöhung des Step Budgets von 25 auf 200 Schritte verbesserte ihre Erfolgsrate nicht, da ihnen ein strukturierter Plan fehlt, um zusätzliche Schritte in bessere Patches umzumünzen.
Probe-and-Refine Agenten nutzen größere Budgets produktiv. Der vorgeschriebene „Reproduce-Trace-Patch“-Workflow erfordert mehr Schritte zum Abschluss. Folglich zeigte die Probe-and-Refine-Bedingung signifikante Gewinne bei höheren Budgets (100 und 200 Schritte), wo einfachere Anleitungen (Static KB) stagnierten.

Modellübergreifende Generalisierung

Bei der Anwendung auf das Nemotron-Modell verdeutlichten die Ergebnisse eine kritische Modell-Fit-Abhängigkeit:

Tuning-Fehlschlag: Die Tuning-Schleife degradierte bei Nemotron, da das Modell nicht in der Lage war, ausreichend diagnostische Ausgaben für den „Judge“-Schritt zu generieren, was die Schleife zum Stillstand brachte.
Negativer Transfer: Eine auf Qwen getunte Anleitung führte bei der Anwendung auf Nemotion zu einem aktiven Kollaps der Agentenleistung (13,2 % Erfolgsrate gegenüber 27,0 % für Nemotrons eigene Baseline). Die detaillierte, prescriptive Anleitung veranlasste Nemotron dazu, in eine „Compliance by Analysis“ zu verfallen (Prosa darüber zu schreiben, was es tun würde), an anstatt Befehle auszuführen, was eine Kaskade von Fallback-Fehlern auslöste.
Konstante Präzision: Selbst beim modellübergreifenden Kollaps blieb die Präzision der wenigen produzierten Patches konstant, was untermauert, dass der Fehler vollständig in der Coverage lag (der Agent scheiterte daran, einen Patch zu produzieren), nicht in der Qualität des Patches selbst.

Bedeutung und Ansprüche

Das Paper behauptet, dass die Instruktionsqualität eine primäre Variable für die Zuverlässigkeit von Coding-Agenten ist, vergleichbar in ihrer Größenordnung mit der Modellkapazität oder der Wahl des Step Budgets.

Operationale Kenntnisse sind lernbar: Die Autoren demonstrieren, dass operationales Wissen (welche Dateien welche Subsysteme beherbergen, wie man Tests ausführt) aus synthetischen Fehlern in ein kompaktes Text-Artefakt destilliert werden kann, ohne komplexe Agenten-Schleifen oder Tool-Nutzung.
Der Flaschenhals ist die Anleitung, nicht das Denken: Die Ergebnisse legen nahe, dass das Scheitern vieler „harter“ Instanzen nicht eine mangelnde Denkfähigkeit ist, sondern ein Versagen bei der Lokalisierung des Problems in der korrekten Datei. Die Anleitung funget als Lokalisierungshilfe, die es dem Agenten ermöglicht, die Repository-Struktur effektiv zu navigieren.
Modellspezifische Kalibrierung: Anleitung ist kein modellübergreifendes Repositorien-Wissen; sie ist modellspezifische Verhaltenskalibrierung. Eine für die Fehlermodi eines Modells getunte Anleitung kann die Leistung eines anderen Modells mit einem anderen Verhaltensprofil aktiv schädigen.
Versöhnung früherer Unstimmigkeiten: Das Paper versöhnt die widersprüchliche Literatur zu AGENTS.md-Dateien, indem es zeigt, dass die Wirksamkeit der Anleitung davon abhängt, wie sie produziert wird (iterative Verfeinerung vs. Single-Pass-Generierung) und vom verfügbaren Step Budget. Statische, generische Anleitung kann neutral oder schädlich sein, während iterativ verfeinerte, workflow-spezifische Anleitung vorteilhaft ist, sofern das Budget den Workflow abschließen lässt.

Die Autoren kommen zu dem Schluss, dass für Praktiker die Investition in iterativ verfeinerte Anleitungen für Repositories mit hohem Issue-Aufkommen wertvoll ist, vorausgesetzt, die Anleitung wird auf dem spezifischen Modell getunt, das sie konsumieren wird, und das Step Budget ist ausreichend, um den vorgeschriebenen Workflow zu unterstützen.