nanobot: 2026-09-14 12:09:54

projects/ai/memory.md

@@ -120,3 +120,20 @@ Závěr uživatele: současný stav (modely pod 10 GB na této GPU instanci) nen
 **Pro uživatele přímo:** Prompt 1 (merge CLAUDE.md template s inventářem prostředí) a Prompt 6 (quarterly trim) použitelné v Claude Code na devlin.hell.
 
 **Odmítnuto:** kopírovat celý soubor (polovina řádků specific pro autorův stroj); článek je anekdotický, bez měření.
+- 2026-09-14: Zhodnocení článku „Frontier AI: Claude Code and Codex Still Use grep. Why?" (Stéphane Derosiaux, Level Up Coding / Medium, ~2026-09) — proč frontier agenti místo AST/LSP/grafů/embeddings používají rg, find, cat.
+
+**Hlavní zjištění autora:**
+
+- **Discovery vs. navigation vs. verification.** Klíčová myšlenka: LSP/AST je skvělý, jen když už agent ví, co hledá (symbol `PaymentRetryHandler`). Při otevřené otázce („co způsobuje duplicitní platby?") musí agent nejdřív objevit slovník problému — retry, idempotency, webhook… — a k tomu je textové hledání nejlepší nástroj. Pipeline: grep = discovery, LSP/AST = navigation, compiler/testy/runtime = verification. grep je začátek, ne celý workflow.
+- **Kód je malá část repa.** Repo = kód + YAML, Terraform, Helm, SQL, markdown, ADR, migrace, feature flags, config. Jeden `rg "PAYMENT_TIMEOUT"` najde zdroj + test + helm values + README + migration notes — jedním dotazem rekonstruuje chování + config + historii + očekávání testů. Code graph je jen jedna projekce systému.
+- **Strukturované nástroje mají model boundary.** LSP/AST vidí jen statické symbolické relace; nevidí reflection, DI, makra, dynamické importy, plugin loading, dispatch z configu, SQL stringy, Kafka topicy. `Class.forName(config.get("processor"))` — call graph je neúplný, text/config prozradí skutečnou hranu. grep ukazuje hrany, které žijí mimo model nástroje.
+- **Negative evidence.** Nula výsledků v `rg` = silný důkaz o repu. U indexované abstrakce může nula znamenat cokoli (neindexováno, nevyřešeno, generováno jinde, špatný workspace). Agent potřebuje nástroje, kde absence je signál, ne hluchá místa middlewaru.
+- **grep = univerzální fallback.** Stejné primitivy fungují v Javě, Rustu, Terraformu, SQL i mixed monorepu. LSP per jazyk (jdtls, rust-analyzer, gopls, pyright, tsserver, clangd) = instalace, indexace, udržování middlemana. Harness je lepší s primitivy se stabilní sémantikou napříč repozitáři.
+- **Kompozice > velký tool vocabulary.** Malá shell slovní zásoba (rg, find, sed, head, xargs, git log -S) se skládá do obrovského prostoru dotazů a je masivně v trénovacích datech. Oproti 20+ úzkých specializovaných toolů (find_symbol, find_references, find_callers…). Kompoziční primitivum > inteligentnější ale užší tool.
+- **Trénink je jen půl vysvětlení.** Modely jsou výborné v shellu (GitHub, Stack Overflow, tutorials), ale to nevysvětluje, proč grep zůstává *architektonicky* užitečný — to dělají výše uvedené důvody.
+- **Repo není správná jednotka.** Systém žije napříč kódem, configem, infrastrukturou, runtime chováním, datovými toky, schématy, ownershipem a business pravidly (příklad: POST /payments → PaymentService → Kafka topic → consumer → DB tabulka → PCI policy → tým). Budoucnost: kombinace lexikálního + strukturálního + runtime pohledu v jednom modelu systému („system graph"), ne file navigation „stylem 2000s".
+
+**Relevance pro nás:** článek je přesně o našem denním chodu (harness design, tool vocabulary, guard proti exec). Hlavní lessony:
+- U nanobot toolů držet primitiva kompoziční (read/grep/exec) místo trendu „20 specializovaných toolů" — potvrzuje současnou architekturu.
+- Negative evidence jako designové kritérium toolu: výsledek musí být jednoznačně interpretovatelný, žádný fallibilní middleman.
+- grep/rg nejsou legacy z tréninku, ale strukturálně správná volba pro fázi discovery — relevantní pro debaty o embeddings/indexech (náš wiki embeddings: full reindex při změně enginu, index = middleman s boundary).