Grep schlägt LSP: Warum Coding-Agents Ihre ausgefeilteren Tools ignorieren
Grep beats LSP? Why coding agents ignore your fancier tools
Eine kleine Studie vergleicht, wie Coding-Agents Code mit grep (lexikalische Suche) oder mit LSP-gestützter semantischer Navigation finden. Überraschend: Bei einfachen Lokalisierungsaufgaben wählen selbst starke Modelle fast immer grep, obwohl LSP präziser ist. Der Grund: Tools müssen LLM-freundlich sein – sie müssen genug Kontext in einem vertrauten Format liefern. Bei Rauschen im Code zahlt sich LSP aus, aber die Ausgabeform ist entscheidend: Inline-Kontext statt bloßer Pfadangaben verbessert die Ergebnisse deutlich. Die Studie zeigt, dass die Tool-Umgebung (Harness) die Fähigkeiten des Agents maßgeblich beeinflusst.
Ein Tool ist für ein Modell nicht allein deshalb freundlich, weil seine Ergebnisse präzise sind – es muss genug Kontext für den nächsten Schritt liefern und diesen in einer Form präsentieren, die das Modell direkt nutzen kann.
- tonyarkles
Es gab eine interessante Koevolution, die ich mit Claude Code erlebt habe. Ich bitte es, eine Aufgabe zu erledigen, ich schaue zu, was es tut (oft viel find und grep und ripgrep) und nach Abschluss der Aufgabe frage ich es, ob es Tools gegeben hätte, die die Arbeit erleichtert hätten. Das hat zu Tools wie fzf und anderen geführt (zum Beispiel notmuch zum Indizieren von E-Mails). Diese Tools habe ich dann genommen und herausgefunden, wie ich sie in meinen eigenen Workflow einbauen kann, sowohl in der CLI als auch in Emacs.
Wir haben auch an einigen Python-Tools zusammengearbeitet, die ein ziemlich langsames Datenformat verarbeiten und analysieren, das ich oft verarbeiten muss, den gesamten Korpus indizieren, und für die Analyse kann ich (oder Claude Code) eine einmalige Konvertierung nach Parquet durchführen, das dann mit DuckDB abfragbar ist. Dieses Tool hat meine Bearbeitungszeit für einmalige Analyseaufgaben drastisch verbessert, und als Python-CLI-Tool mit Typer ist die Schnittstelle auch für LLM-Harnesses gut auffindbar.
- nomilk
Randnotiz, aber meine LSP-Konfiguration bricht alle paar Monate. Ich mache mir nicht mehr die Mühe, sie zu reparieren, ich öffne ein LLM in ~/dotfiles und beschwere mich, bis es wieder funktioniert, meistens in ein paar Minuten.
Interessant ist zu beobachten, wie viel Arbeit das kostet. (Es gibt mir viel mehr Empathie für mein früheres Ich; wie hätte ein unbeholfener Mensch diese Dinge wissen und durchdenken sollen!?, besonders wenn ich die Konfigurationen seit ein paar Monaten nicht angefasst hatte und sie fast vollständig vergessen hatte.)
Meistens arbeiten 10-20 sehr kleine Programme zusammen, um das gewünschte Erlebnis zu bieten. Die Anzahl an Minuten und Tokens, die benötigt wird, um scheinbar einfache Probleme wie „Mein LSP funktioniert nicht“ zu lösen, ist manchmal viel höher als erwartet.
- the_duke
Ich hatte großen Erfolg mit einem Tool, das ich geschrieben habe und das spärliche ASTs für Code ausgeben kann.
https://github.com/theduke/smartedit
Mit installierter Fähigkeit nutzt GPT 5.6 es normalerweise automatisch, und es reduziert die Zeit für die Code-Erkundung und den Token-Verbrauch erheblich, zum Beispiel indem es nur die Typen und Funktionen in einer Datei ohne Körper ausgibt und nur bei Bedarf erweitert.
(Hinweis: Es hat auch Bearbeitungsfunktionen, die nicht so gut funktionieren, da die Modelle im Post-Training stark auf gängige Bearbeitungswerkzeuge ausgerichtet sind.)
- x-complexity
Die Einrichtung eines LSP hängt von zwei Anforderungen ab, damit es ordnungsgemäß funktioniert:
(a) Die Werkzeuge des LSP müssen kompetent gebaut und konsistent sein, und
(b) das LLM, das es verwendet, muss ordnungsgemäß darauf trainiert sein, LSPs im Allgemeinen zu verwenden.
Die Verwendung eines nativen Tools wie grep hat dieselben zwei Annahmen, aber
(a) ist erfüllt, weil die Kernfunktionen von grep verknöchert sind (eine gute Sache), und
(b) ist zusätzlich erfüllt, weil das LLM darauf trainiert werden kann, grep speziell richtig zu verwenden, und nicht die „20. Variation von grep, die hinter einem LSP versteckt ist, aber gerade anders genug, um Kurven zu werfen“.
Darüber hinaus ist grep in Standard-Linux-Umgebungen fast immer vorhanden, sodass seine Präsenz angenommen werden kann und man sich bei Bedarf darauf verlassen kann.
- brunoborges
Was bei mir gut funktioniert hat, ist eine SKILL, die anweist, das LSP öfter als nicht zu verwenden.
LSP funktioniert am besten, wenn Abhängigkeiten verwendet werden, die bereits lokal kompiliert sind, aber wenn der gesamte Quellcode verfügbar ist, ja ... ich habe immer noch keine fundierte Antwort darauf, welches am besten ist.
Aber nochmal, für bereits kompilierte Abhängigkeiten (denken Sie an Java-Bytecode) wird der Agent ohne LSP-Konfigurationen wahrscheinlich versuchen, Binärdateien aus JAR-Dateien zu extrahieren, grep und javap zu verwenden und möglicherweise zu versuchen, die .class-Dateien zu dekompilieren.