CodeGrep verschiebt bei Coding Agents einen bislang erstaunlich teuren Arbeitsschritt in einen eigenen, darauf trainierten Agenten: die Suche nach den richtigen Dateien. Das am 6. August auf arXiv veröffentlichte Paper berichtet auf SWE-bench Verified bei unveränderter Downstream-Agentenlogik von 27,0 % statt 25,8 % gelösten Aufgaben – zugleich mit 15 % weniger Runden und 19 % weniger Tokens bei gelösten Instanzen.
Der Engpass liegt oft vor dem Patch
Die Diagnose der Autoren ist pragmatisch: Moderne Coding Agents verbringen einen großen Teil ihres Budgets nicht mit dem Ändern von Code, sondern mit grep, glob und dem Lesen von Dateien. Für einen 30B-OpenHands-Agenten nennen sie im Mittel 23 Runden und 631.000 Tokens pro gelöstem SWE-bench-Verified-Issue. Das ist kein Modell-Intelligenzproblem im engeren Sinn, sondern ein Retrieval- und Steuerungsproblem.
CodeGrep ist deshalb als separater 14B-Agent angelegt. Er erhält Repository-Exploration als eigene Aufgabe, führt mehrstufige und parallele Such- sowie Leseaufrufe aus und gibt Kandidatendateien an einen eingefrorenen Coding Agent weiter. Trainiert wurde er end-to-end mit GRPO; als Trainingsmaterial dienten laut Paper 67.000 Open-Source-Agenten-Trajektorien.
Retrieval ist hier nicht bloß Kontextbeigabe. Es wird zum eigenständigen Runtime-Worker, dessen Qualität direkt über Kosten und Erfolg des Patch-Agenten entscheidet.
Die interessante Zahl ist 0,677
Besonders nützlich ist die im Paper sichtbare Schwelle: Bei einer Retrieval-Precision von 0,375 verschlechterte BM25 den Downstream-Agenten, bei 0,445 war Jina neutral. Erst CodeGrep mit 0,677 Precision senkte die Rollout-Kosten. Die Lehre für Teams ist unbequem, aber klar: Ein Retriever vor einem Coding Agent ist nicht automatisch Optimierung. Schlechte Treffer lenken den Agenten nur in zusätzliche Lese- und Denkpfade.
| Messpunkt im Paper | Ergebnis | Praktische Bedeutung |
|---|---|---|
| Resolve Rate | 27,0 % vs. 25,8 % Baseline | Effizienzgewinn ging in dieser Evaluation nicht zulasten der Lösungschance. |
| Gelöste Instanzen | 15 % weniger Runden, 19 % weniger Tokens | Repository-Aufklärung ist ein konkreter Hebel für Latenz und Inferenzkosten. |
| Retrieval-Precision | 0,677 bei CodeGrep | Qualität des Kandidatensets ist wichtiger als das bloße Vorschalten eines Suchsystems. |
Was Engineering-Teams daraus ableiten sollten
- Exploration separat messen: Tool-Calls zur Dateisuche, gelesene Dateien, Recall/Precision der Kandidaten und Patch-Erfolg gehören in dieselbe Trace.
- Kein Retrieval ohne Ablation: Gegen einen Agenten ohne vorgeschalteten Retriever testen – inklusive Tokens, Runden und Erfolgsrate, nicht nur Retrieval-Metriken.
- Schnittstelle klein halten: Der Retriever sollte Kandidatendateien und begründete Evidenz liefern, nicht unkontrolliert einen zweiten Planungskanal in den Patch-Agenten öffnen.
Die Resultate sind zunächst ein Preprint und an das getestete OpenHands-/SWE-bench-Setup gebunden; sie sind keine allgemeine Zusage für beliebige Repositories. Dennoch trifft die Architektur einen realen Produktionspunkt: Wenn Agenten in großen Codebasen teuer werden, ist der nächste sinnvolle Optimierungsschritt oft nicht ein größerer Modellaufruf, sondern ein besser begrenzter Weg zur richtigen Datei.
Quelle
Wuya Chen et al., „CodeGrep: An RL-Trained Retrieval Agent for LLM Coding Agents“, arXiv:2608.05886, eingereicht am 6. August 2026. Die Kennzahlen in diesem Beitrag stammen aus dem Paper und wurden nicht unabhängig reproduziert.
Leave a Reply