7. 8. 2026

LSP místo grepu: coding agent nemusí číst repozitář naslepo

Realistický cover: vývojář naviguje velkou codebase pomocí symbolů a vztahů v LSP

Grep není špatně. Pro textové hledání, logy, konfiguraci nebo rychlé „kde se tenhle řetězec vyskytuje?“ je přesně správně. Pro coding agenta nad větším repozitářem ale často řeší špatný problém.

Agent obvykle nepotřebuje najít stejné znaky. Potřebuje vědět, co daný symbol znamená, kde je definovaný, kdo ho používá a co se bezpečně změní při refaktoru. To je rozdíl mezi textovým vyhledáváním a sémantickou navigací přes Language Server Protocol (LSP).

V AI Mastermind 34 ukázal Jirka Herník dvě větve stejného úkolu: přejmenovat jednu property a přesně vypsat, co je potřeba změnit. V jeho konkrétním testu se větev s grepem několik minut prokousávala soubory, zatímco větev s LSP dostala reference přímo. Výsledek byl stejný. Číslo 81× z videa ale neberu jako univerzální benchmark. Je to dobrá ukázka mechaniky: největší úspora nevzniká tím, že LSP „nahradí grep“, ale tím, že model nemusí tokeny a čas utrácet za zjišťování kontextu, který už zná IDE.

Co přesně ukázalo Jirkovo demo

Na snímku ze stejného zadání „vypiš přesně, co se musí změnit při přejmenování JournalEntry.Amount“ jsou vedle sebe dva celé agentní běhy. Nejde tedy o mikrobenchmark samotného grepu: grep našel kandidáty rychle, ale agent pak musel číst a vyhodnocovat soubory. LSP vrátil symbolové reference v jediném kroku.

Metrika z dema grep větev LSP větev
Čas od zadání k výsledku 7 min 20 s 5,4 s
Tool cally 54 1
Přečtené soubory 20+ 0
Tokeny zpracované modelem 12 868 604 přibližně 2 000
Nové tokeny mimo cache 392 599 přibližně 250
Výsledek správně správně

Poměr času vychází zhruba na 81×. To ale není slib výkonu Serény, Claude Code ani LSP obecně. Je to jedna ukázka, kde byl úkol téměř ideální pro referenční dotaz nad symbolem. U změny napříč dynamickým kódem, šablonami, SQL, konfigurací nebo externím API bude rozdíl menší — a někdy se bez grepu vůbec neobejdete.

Jak tyto hodnoty ověřit u sebe

Pro férové srovnání dejte oběma běhům stejné zadání, stejný model, stejný limit contextu a stejnou výchozí větev. Zapisujte door-to-door čas, počet tool callů, přečtené soubory, cache a nové tokeny, diff a výsledek testů. Pak nepřepínejte „grep versus LSP“ na spor víry: u každé třídy úloh si změřte median alespoň z pěti běhů.

Pro firmu je nejzajímavější poslední řádek tabulky s novými tokeny. Cache tokeny také mají provozní cenu a latenci, ale nově zpracovaný kontext nejlépe ukáže, kolik zbytečného čtení repozitáře agent skutečně odstranil.

Co LSP agentovi skutečně dává

Language Server Protocol je standard pro komunikaci editoru s nástrojem, který rozumí konkrétnímu programovacímu jazyku. Jazykový server umí například najít definici symbolu, jeho reference, implementace nebo diagnostiku.

To je přesně vrstva, která v editoru udělá z kliknutí na název funkce přechod na definici a z přejmenování symbolu řízený refaktor. Když stejnou vrstvu dostane přes MCP coding agent, nemusí předstírat IDE pomocí grep, globů a postupného čtení souborů.

Praktická otázka pak nevypadá „ve kterých souborech je JournalEntry.Amount?“, ale spíš:

  • Kde je deklarace tohoto pole?
  • Které symboly na něj odkazují?
  • Je některý výskyt jen stejný text, ale jiný význam?
  • Která změna je renamování a která už je změna API nebo databázového kontraktu?

To je podstatné hlavně v TypeScriptu, Javě, C#, Pythonu nebo PHP projektech, kde stejný řetězec může být ve třídě, DTO, validátoru, SQL migraci, testu, dokumentaci i frontendu. Grep je najde všechny. Sémantická navigace má šanci rozlišit, které z nich jsou skutečné reference na programový symbol.

Proč grep stojí agenta víc než vývojáře

Zkušený vývojář umí výsledky grepu číst velmi rychle. Má v hlavě architekturu, editorem proskakuje mezi definicemi a snadno pozná falešný zásah. Agent tenhle mentální model nemá automaticky. Musí si ho sestavit z textu, po jednom tool callu.

To je drahé třikrát:

  1. Tokeny. Agent načítá úseky souborů, které nakonec pro úkol nejsou relevantní.
  2. Latence. Každé hledání, čtení a rozhodnutí je další krok agentní smyčky.
  3. Riziko. Textové search-and-replace snadno změní komentář, jiný stejnojmenný symbol nebo jen část kontraktu.

U malého souboru je to zanedbatelné. U monorepa, dlouhého tasku nebo paralelních subagentů se z toho stává provozní náklad i zdroj chyb. Proto je LSP zajímavější než další trik do promptu: mění vstup, ze kterého model rozhoduje.

Serena je praktický způsob, jak LSP pustit agentovi

Serena je open-source MCP toolkit pro coding agenty. Nad language serverem nabízí symbolové vyhledávání, přehled souboru, reference, definice a nástroje pro editaci či refaktoring. Podporuje řadu jazyků; u jazykového backendu ale závisí možnosti na kvalitě konkrétního language serveru.

Důležitá hranice: Serena není model ani náhrada testů. Je to sémantický nástroj, který modelu zpřístupní informace, jež by jinak musel pracně rekonstruovat. Agent stále plánuje změnu, upravuje kód a musí spustit testy. Jen nezačíná naslepo.

To je dobrý vzor i pro interní AI nástroje. Nejdřív modelu nedávejte celý repozitář. Dejte mu kontrolované nástroje, které odpoví na konkrétní otázky o struktuře: symbol, reference, diagnostika, test, diff. A podle citlivosti projektu rozhodněte, které z nich smí agent používat automaticky.

Kde LSP nepomůže

LSP není univerzální zkratka. Grep zůstává lepší pro:

  • text v Markdownu, dokumentaci, šablonách a konfiguracích,
  • logy, chybové hlášky a neznámé identifikátory,
  • regulární výrazy a ad-hoc průzkum,
  • jazyky nebo buildy bez funkčního language serveru.

Ani symbolová reference nenahradí rozhodnutí o dopadu změny. Přejmenování entity může vyžadovat migraci databáze, úpravu API, kontrolu analytiky, regeneraci klienta nebo komunikaci s jiným týmem. LSP řekne „kde v kódu“, ne „co je správné pro produkt“.

Jak bych to nasadil bez velkého experimentu

Nezačínejte tím, že všem agentům přidáte plný přístup k refaktorům. Udělejte krátký pilot na jednom repozitáři:

  • Vyberte opakované úlohy: změna názvu, dohledání call sites, úprava DTO, rozdělení modulu.
  • Změřte počet tool callů, načtených souborů, čas do prvního správného plánu a čas do zelených testů.
  • Porovnejte běh jen se search nástroji a běh s LSP/MCP.
  • U větších změn vyžadujte diff, testy a lidské review; LSP snižuje nejistotu, neodpovědnost.
  • Oddělte read-only navigaci od nástrojů, které mohou kód měnit nebo spouštět shell.

Ve firmě je to stejný princip jako u n8n workflow: nejdřív přesně zmapovat vstup, pak pustit automatizaci k akci. Agent s dobrými nástroji nemusí být chytřejší model. Často stačí, aby nemusel hádat, co už o projektu ví vaše IDE.

Praktický závěr

Z videa bych si neodnesl slogan „LSP je 81× rychlejší než grep“. Správnější závěr je: coding agent nemá hledat význam kódu přes text, když ho language server už umí vrátit jako strukturovaný fakt.

Grep je pro agenta stále užitečný. LSP mu ale dává navigaci po symbolech a vztazích, což snižuje cenu dlouhých agentních úloh, omezuje falešné zásahy a zpřesňuje plán refaktoru. U větší codebase je to jedna z prvních infrastrukturních věcí, kterou má smysl změřit dřív, než začnete řešit další model nebo delší context window.

Zdroje