Mam 5-repo monorepo. Shared core, cztery brand-variant fronty, jeden moduł admina. Codziennie zadaję Claude Code pytania w stylu “gdzie jest konsumowany useBaseCart przez całą platformę” albo “co nadpisuje cart button w BrandA w stosunku do BrandB”. I codziennie Claude Code robi to samo.

Puszcza Glob żeby znaleźć pliki. Potem Grep żeby znaleźć referencje. Potem czyta top trzy wyniki. Potem zastanawia się, czy to wystarczyło. Potem znowu Glob. Potem znowu Grep.

Czternaście tool calli. Czterdzieści sekund. Kilka tysięcy fresh input tokenów. Za każdym razem.

Jest OK przy jednym pytaniu. Nie jest OK kiedy to trzecie cross-repo pytanie tego dnia i patrzysz, jak tokeny się palą na eksplorację, której model mógłby się raz nauczyć i pamiętać na zawsze. Dzisiejszy post jest o tym, jak mi się to znudziło, co próbowałem najpierw, co skasowałem i czemu jarvis-brain wygląda tak jak wygląda.

Jak konkretnie wygląda “burning tokens”

Puściłem benchmark. Pięćdziesiąt pytań w pięciu kategoriach - code discovery, usage tracing, cross-repo, dependency path, architecture. Po dziesięć w każdej. Dwa przebiegi: Claude Code native (tylko Glob, Grep, Read) versus Claude Code plus jarvis-brain jako MCP tool.

Headline który mnie dzisiaj interesuje to baseline. Bez braina, na tych samych pięćdziesięciu pytaniach:

  • 4 145 fresh input tokenów spalonych na eksplorację
  • 14 tool calli przy najtrudniejszych cross-repo pytaniach
  • 44 sekundy średnio dla architecture-deep pytań, 189 sekund dla najgorszego pojedynczego
  • Total wall time przez całe pięćdziesiąt: 36 minut

Cache pomaga. Anthropic prompt cache jest agresywny i dolarowy koszt zostaje niski przez niego. Ale fresh input tokeny - te, które model musi przeczytać po raz pierwszy przy każdym wywołaniu - skalują się z tym, jak często Claude Code re-eksploruje ten sam kod. A re-eksploruje stale, bo tool results nie stają się trwałą pamięcią.

To nie jest bug Claude Code. Glob i Grep to właściwe prymitywy, kiedy nie masz innej mapy kodebase’u. Są uniwersalne. Działają na każdym repo bez setupu. Koszt to płacenie tokenami za eksplorację za każdym razem.

Use case, o którym nikt nie mówi

Ból skaluje się z tym, jaki masz kod. Mój ból to coś, co - ze zmienionymi nazwami - nazwę multi-brand commerce platform.

Jeden core - shared engine. Composable’y, base components, business logic, około osiemdziesiąt procent faktycznego kodu. Cztery brand-variant fronty na wierzchu - ten sam engine, inny design system per brand, inny content, sporadyczne override’y komponentów tam, gdzie marka potrzebuje czegoś, czego core nie daje. Plus moduł admina, który konsumuje parę z tych brandów.

To wzorzec V-commerce. White-label e-commerce działa w ten sposób. Multi-tenant SaaS frontendy działają w ten sposób. Test suite’y dla spójnych aplikacji działają w ten sposób - jeden test harness, N wariantów tego samego flow. Agencje, które forkują core pod każdego klienta, działają w ten sposób.

Jeśli kiedykolwiek pytałeś Claude Code “czy jest lokalny override AddToCart.vue w BrandA”, znasz kształt problemu. To nie jest “znajdź plik”. To jest “znajdź plik, sprawdź trzy inne repo pod warianty, sprawdź który wygrywa przez priorytet Nuxt layers, sprawdź kto go woła, sprawdź czy są brand-specific composable’y po drodze”. To nie jest to, do czego jest Glob. Glob znajdzie ci dziesięć plików AddToCart.vue w pięciu repo i zostawi cię z myśleniem, który z nich ma znaczenie.

Co próbowałem najpierw i skasowałem

Oczywisty ruch to był naive RAG. Zaembeddingowanie kodebase’u przez Voyage albo OpenAI, wrzucenie do vector store’a, danie Claude Code tool do search. Ludzie tak robią. Są starter repo do tego.

Zbudowałem prototyp. Skasowałem go.

Dwa problemy. Po pierwsze, embeddingi source code są słabe na strukturze kodu. Są dobre w “znajdź funkcję która robi X konceptualnie”. Są słabe w “znajdź każdego konsumenta useBaseCart w forge-core”. Pierwsze pytanie jest semantyczne. Drugie strukturalne. Vector store nie wie, że useBaseCart to nazwa, nie fraza.

Po drugie, naive RAG to kolejne narzędzie do nauczenia. Claude Code ma już Glob, Grep, Read. Są native, przewidywalne, tanie w wywołaniu. Custom search tool siedzi obok nich i wymaga prompt engineeringu żeby go używać dobrze. Każde nowe narzędzie to friction. Narzędzie, które ma naprawić “Claude Code pali tokeny na Globie”, nie powinno być “tu jest narzędzie, które Claude Code musi pamiętać żeby użyć zamiast Globa”.

Rozważałem mądrzejszy Grep wrapper. Ten sam problem w innym opakowaniu - dalej czternaście tool calli, dalej token burn, tylko z marginalnie lepszym filtrem.

To, czego potrzebowałem, to nie było lepsze retrieval tool. To była inna ścieżka dostępu. Struktura kodebase’u powinna być pre-computed raz, zachowana i serwowana Claude Code’owi jako native MCP tool, który czuje się jak Glob, ale odpowiada jak senior engineer, który przeczytał kod.

To jest pivot. Nie “zbuduj search engine”. Zbuduj mapę i wystaw ją przez protokół, którym Claude Code już mówi.

Architektura w jednym akapicie

jarvis-brain ekstraktuje graf z twojego kodu. Nody to funkcje, komponenty, composable’y, typy, pliki. Edge’e to importy, calle, override’y, parent-child layer relationship. Zbudowany raz per repo, potem zmergowany przez repo w federated master graph, który wie, który brand front nadpisuje który core component, i który design system token jest używany gdzie. Graf żyje w SQLite FTS5 indexie dla full-text query, plus JSON struktura dla traversal. Serwowany Claude Code’owi przez pięć MCP toolsów, które wyglądają i czują się jak built-in primitives - brain_query, brain_graph, brain_path, brain_explain, brain_ffcss.

Ten ostatni detal to puenta. To nie jest kolejny search interface. To MCP-native. Claude Code widzi je w tej samej liście toolsów co Glob i decyduje kiedy ich użyć na podstawie tego, czego pytanie wymaga.

Jutrzejszy post to to, jak faktycznie działa indeksowanie, FTS5 trick, który robi useBaseCart query’owalnym przez wpisanie “Base”, i benchmark breakdown przez wszystkie pięć kategorii - włącznie z kategoriami, gdzie brain nie wygrywa z Grepem.

Czym się dzisiaj pobawić

brain.sdet.it to live demo. Brain Website z przodu, jarvis-brain backend z tyłu. Zaloguj się do publicznej demo grupy, przeglądaj graf, query’uj, zobacz FFCSS token federation. Ciekawa część to brain.sdet.it/benchmark/ - pełne liczby z pięćdziesiąt-pytaniowego benchmarku, wyrenderowane jako static report.

Jutro public repo wjeżdża. Edukacyjny destylat na AGPL-3.0 - extractory, federacja, prompty, MCP tools, FTS5 query layer, benchmark methodology. Tyle, żeby nauczyć się wzorca, nie tyle, żeby postawić production multi-tenant deployment. To jest linia i Part 3 wytłumaczy, czemu linia jest tam, gdzie jest.

Na dzisiaj jedno pytanie warte przemyślenia: ile fresh input tokenów spaliła twoja wczorajsza sesja Claude Code na eksplorację, która nie musiała się wydarzyć?

#FromTheField - seria leci dalej jutro.