grep schlägt LSP? Warum Coding-Agents die schicken Tools ignorieren

Diese Woche bin ich über eine Studie von agentconnect.md gestolpert, auf die ich ehrlich gesagt nicht vorbereitet war: Coding-Agents ignorieren das LSP so gut wie komplett. Und bleiben bei grep. Das klingt erstmal nach „ach, die Tools sind doof“ – aber das Ergebnis ist deutlich interessanter als das.

Kurzer Kontext, falls LSP nicht dein Ding ist: Das Language Server Protocol ist die „schlaue“ Navigation im Editor – Referenzen, Definitionen, Document Symbols. Genau die Art von Werkzeug, die Coding-Agents meiner Meinung nach lieben sollten. Das AgentConnect-Team hat genau das getestet: drei Claude-Modelle (Opus 4.8, Sonnet 4.6, Haiku 4.5), Python- und TypeScript-Repos, lexikale grep-Suche gegen semantische LSP-Tools – für Code-Find- und Code-Edit-Tasks.

Und hier wird’s peinlich. Bei einfachen Code-Lokalisierungs-Tasks wählten die Modelle das semantische Tool nur in 0 bis 6 Prozent der Fälle, obwohl beide Tools verfügbar waren. Noch blöder finde ich den zweiten Befund: Erzwangen die Autoren einen semantic-first-Pfad, sank die Task-Erfolgsquote von 100 auf 89 Prozent. Das Modell ignoriert das fancy Tool also nicht einfach – es macht die Aufgabe sogar schlechter, wenn man es zwingt.

Es wird aber differenziert. Bei Reference-Completeness-Tasks – also „finde alle Caller“ – nutzten die Modelle die Navigation in 45 bis 57 Prozent der Fälle. Und da hat LSP klar die Nase vorn: Precision 1.00 mit LSP gegen 0.76 mit grep, während Recall bei beiden Armen nahe 0.66 lag. Das Modell ist also nicht komplett blöd – es verteilt seine Tool-Entscheidungen einfach anders, als man es von einem guten Engineer erwarten würde.

Noch spannender war der Repo-Zustand. In einem sauberen TypeScript-Repo brachte LSP keinen einzigen F1-Vorteil und verbrannte 16 Prozent mehr Tokens. Im noisy Repo dagegen: +0.246 F1 und 12 Prozent weniger Tokens. Ob das Codebase-Geflecht sauber oder kaputt ist, macht also offensichtlich einen riesigen Unterschied – ich hab da erstmal „wow“ gesagt, weil ich das nicht vorhergesehen hätte.

Die Kernaussage laut der Meldung: Die LLM-Friendliness des Tool-Interfaces – wie Dinge benannt sind und wie das Output-Format aussieht – zählt so viel wie die reine Capability. Modell und Harness müssen zusammen evaluiert werden, nicht getrennt. Das ist der Satz, den ich mir für die nächsten Tool-Diskussionen in der Team-Chat-Fenster-Leiste kleben würde.

Die Caveats nennt die Quelle selbst, und ich bin dankbar dafür: präliminärer Pilot, kleine Task-Sets, nur 2–3 Rollouts pro Zelle, und textDocument/rename, Diagnostics und Code-Actions wurden gar nicht getestet. Das ist ein interessantes Signal, kein Endurteil. Wer tiefer einsteigen will: Das komplette Setup liegt offen auf GitHub (agentconnect-md/lsp-vs-grep-token-study).

Das Wichtigste: Diese Woche erschien eine AgentConnect-Studie, die zeigt, dass Coding-Agents LSP-Tools bei einfachen Lokalisierungs-Tasks nur in 0–6 Prozent der Fälle wählen, bei Caller-Suche aber in 45–57 Prozent – und dass Interface-Design mindestens genauso zählt wie Tool-Logik. Fazit für uns alle: Nicht davon ausgehen, dass das Modell das beste Tool nur deshalb nimmt, weil es verfügbar ist. Und manchmal ist die dümmste Option echt die beste. Das ist völlig okay.