Article
Bessere Tools machten Copilot Code Review schlechter – und wie GitHub das Problem löste
Das Problem: Bessere Tools, schlechtere Ergebnisse
Wenn man einem Agenten bessere Tools gibt, sollte er bessere Arbeit leisten. Das ist zumindest die Intuition. Aber GitHub musste eine überraschende Lektion lernen, als sie die Code-Exploration-Tools von Copilot Code Review auf die Unix-inspirierten Tools des Copilot CLI migrierten: Die Review-Kosten stiegen und weniger Issues wurden gefunden.
Das Problem waren nicht die Tools – es waren die Instructions. Nachdem GitHub die Workflows an die Art anpasste, wie ein Reviewer wirklich einen Pull Request liest, wurde die Regression zu einem Gewinn: rund 20% niedrigere durchschnittliche Review-Kosten bei gleicher Qualität.
Der technische Kontext: Von SWE-Agent zu Unix-Tools
Früher nutzte Copilot Code Review eigene Code-Exploration-Tools, inspiriert von SWE-agent-Style Repository Navigation:
| Old Copilot Code Review | GitHub Copilot CLI | Purpose |
|---|---|---|
list_dir | glob | Dateien/Verzeichnisse entdecken |
search_file/search_dir | grep | Code durchsuchen |
read_code | view | Dateiinhalte lesen |
Die ursprünglichen Tools waren für ältere Modelle konzipiert, die weniger Tool-Calls machten und schlechter darin waren, notwendigen Kontext automatisch zu ziehen. Deshalb gaben die Tools zusätzlichen Kontext mit zurück – was Token-Kosten verursachte, aber den damaligen Modellen half.
Die Diagnose: Ein Browsing-Loop
Die internen Benchmarks zeigten nicht nur einen Score, sondern den Pfad des Agents: Welche Tools er aufrief, wie viel Output zurückkam, wo Fehler auftraten, und ob er sich auf Evidence verengte oder die Suche ausweitete.
Mit den neuen CLI-Tools verhielt sich der Agent so, als würde er ein Repository browsen statt einen Pull Request zu untersuchen:
- Breite Suche
- Wahrscheinliche Pfade raten
- Breites Lesen
- Mehr Dinge zum Suchen finden
- Zusätzlichen Kontext mitführen
Das führte zu ineffizienten Workflow-Pfaden und höheren Kosten.
Die Lösung: Instructions für echte Review-Workflows
Die Fix-Methode: Instruktionen anpassen, nicht Tools. Ein Reviewer liest einen PR anders als jemand, der ein Repository erkundet:
- Start beim Diff – nicht bei Verzeichnissen
- Verfolgung von References – Was wurde geändert? Wo wird es verwendet?
- Enger Fokus auf Evidence – Nur relevante Bereiche lesen
Nach der Anpassung der Instruktionen an diesen Review-orientierten Workflow sanken die Kosten signifikant, während die Qualität der Reviews erhalten blieb.
Takeaways für Agent-Entwickler
- Tools sind nicht universell – Was für einen Use Case funktioniert, kann für einen anderen schaden
- Instruktionen > Tools – Oft liegt das Problem in den Prompts, nicht in den Tools
- Traces analysieren – Benchmarks zeigen mehr als Scores: Sie zeigen Pfade
- Workflow-Mismatch erkennen – Browsing vs. Investigating sind verschiedene Paradigmen
Original-Artikel: Better tools made Copilot code review worse
Autor: Napalys Klicius (@Napalys)
Datum: 10. Juli 2026