Kiedy się opłaca

Część 1 obramowała problem. Część 2 wypchnęła silnik i benchmark. Część 3 to post, który warto przeczytać przed decyzją o adopcji - bo uczciwa odpowiedź na pytanie “czy mam wdrożyć jarvis-brain u siebie” brzmi “zależy od twojego codebase’u, i tutaj jest sposób, żeby to ocenić”.

Plus warstwa V0.5 - jak ten sam silnik wygląda, gdy jednostką pracy przestaje być repo, a staje się design system org z wieloma konsumenckimi frontami.

Liczby z benchmarku wczoraj były uśrednione po pięćdziesięciu pytaniach na monorepo z pięcioma repo. To słowo - monorepo - robi tu prawdziwą robotę. Brain wygrywa największą marginesem na pytaniach o architekturę i cross-repo, gdzie graf niesie informację, którą natywne narzędzia muszą rekonstruować od zera za każdym razem.

Konkretnie, sygnały które mówią “ten silnik się opłaci na twoim codebase”:

Trzy lub więcej repo ze współdzielonym kodem. Core package konsumowany przez wiele aplikacji. Design system używany przez kilka frontów. Mikroserwisy importujące ze wspólnego toolkitu. Warstwa federacji to miejsce, gdzie brain zarabia na swoją obecność.
Dziesiątki tysięcy plików albo więcej. Poniżej pięćdziesięciu plików Glob jest szybki, a model trzyma całość w pamięci roboczej. Przy pięćdziesięciu tysiącach model robi exploration burn przy każdym przekrojowym pytaniu.
Design system albo współdzielone prymitywy, które są nadpisywane per konsument. Jeśli twoi konsumenci robią :root { --color-brand: ... } na tokenach zdefiniowanych w shared library, masz klasę problemu, dla której brain_ffcss został zbudowany specifically.
Wielu inżynierów zadaje pytania architektoniczne o ten sam codebase. “Gdzie siedzą god-nody”, “co od tego zależy”, “co się zepsuje jak zmienię ten kontrakt”. Te pytania zajmują pięćdziesiąt trzy procent mniej wall time z brain niż bez.
Długo żyjące projekty, gdzie exploration burn się kumuluje. Jeśli twoje sesje AI konsekwentnie spędzają pierwsze pięć minut re-odkrywając layout projektu, to jest dokładnie ta rzecz, która zostaje wyeliminowana.

Brain nie eliminuje pracy LLM. Eliminuje tę część, gdzie LLM musi re-derywować strukturalne fakty z surowego źródła przy każdym pytaniu.

Kiedy Grep już wystarcza

Uczciwy odpowiednik. Sygnały, które mówią “jeszcze tego nie potrzebujesz”:

Pojedyncze repo poniżej pięćdziesięciu plików. Glob i Grep są tu już optymalne. Benchmark wyłapał to wprost - pytania code discovery działały dwadzieścia procent wolniej z brain niż bez.
Solo developer pracujący na projekcie, który sam napisał. Masz strukturę w głowie. LLM pomaga z wykonaniem, nie nawigacją. Marginalna wartość pre-komputowanych grafów jest mała.
Throwaway scripts, prototypy, exploratory notebooks. Wszystko, co możesz skasować za dwa tygodnie. Koszt budowy i utrzymania grafu przekracza koszt exploration burn.
Codebases zmieniające kształt co tydzień. Graf staleness staje się obciążeniem utrzymaniowym sam w sobie. Trzymaj się czytania źródła przy każdym zapytaniu.
Brak cross-repo problemu. Jeśli twoja praca jest ograniczona do jednego repo i nie potrzebujesz nic śledzić przez granice, warstwa federacji dodaje komplikacji bez opłacalności.

Pułapka do uniknięcia: adopcja narzędzia, bo robi wrażenie w benchmarku, a potem płacenie maintenance kosztów za coś, czego nie potrzebowałeś. Inżynierska ocena tutaj wygląda jak “gdzie faktycznie idzie mój czas, gdy pracuję z AI” - jeśli odpowiedź to głównie “pisanie kodu”, a nie “tłumaczenie codebase’u modelowi”, to prawdopodobnie nie potrzebujesz graf-backed context. Jeśli jest odwrotnie - prawdopodobnie potrzebujesz.

Daily use case - multi-brand commerce setup

Żeby to było konkretne, oto kształt pracy, w której brain zarabia codziennie.

Setup: jeden współdzielony core package - komponenty, composables, typy, design tokeny, prymitywy routingu. Na tym - pięć brand-variant frontendów. Ta sama rodzina produktów, różne tożsamości wizualne, różne gating featur, różne flow checkout per market. Każdy konsument nadpisuje design tokens, dodaje brand-specific routes, podłącza market-specific integracje płatnicze.

Typowe pytanie: “Jeśli zmienię kontrakt na useBaseCart w core, co się zepsuje w tych pięciu frontach i gdzie trzeba zaktualizować testy?”

Bez brain: otwierasz core, znajdujesz useBaseCart, czytasz signature. Grepujesz useBaseCart przez wszystkie sześć repo. Otwierasz każdy hit. Czytasz wystarczająco kontekstu, żeby zrozumieć call site. Decydujesz, czy się zepsuje. Przechodzisz do następnego hita. Realistycznie: czterdzieści pięć minut context-switchingu dla średnio złożonej zmiany.

Z brain: brain_explain na węźle useBaseCart zwraca krawędzie inbound - każdy konsument, który od tego zależy, z plikiem i linią call site, plus wnioskowany kontrakt użycia. Jedno wywołanie narzędzia. Model ma cały impact surface zanim dotknie pojedynczego pliku źródłowego. Odpowiedź “co się zepsuje” przychodzi w pięć minut zamiast czterdziestu pięciu. Pozostały czas idzie na faktyczne pisanie zmiany i aktualizację testów.

Tak właśnie odczuwa się w produkcji liczba z kategorii architecture benchmarka. Pięćdziesiąt trzy procent mniej wall time na pytaniach, które wcześniej odczuwało się jak archeologia.

Warstwa V0.5 - federacja w skali

Publiczne repo to silnik. Prywatna wersja silnika zawiera multi-tenantowe rusztowanie. Warstwa V0.5 to silnik plus inny rodzaj capability na wierzchu - ten, który ma znaczenie, gdy jednostką analizy nie jest już “to repo”, tylko “design system tej organizacji i wszystko, co go konsumuje”.

Trzy rzeczy, które dodaje V0.5:

Deduplikacja cross-repo. Uruchom audyt WCAG, design tokenów albo kontraktów przez dziesięć konsumenckich repo naraz. Findingi są klastrowane: problem z aria-label, który pojawia się w dziewięciu z dziesięciu repo, to jeden finding z dziesięcioma manifestacjami, nie dziesięć findingów. Klaster raportuje kanoniczny fix raz, a affected consumers jako listę. To zmienia ekonomię review o rząd wielkości, gdy zarządzasz design systemem jak produktem.

Federacja design tokens. Tokeny zdefiniowane w core library, nadpisane w konsumentach, czasem nadpisane znowu w feature flagach. Warstwa federacji śledzi kanoniczną definicję, każdą krawędź override, każdego konsumenta, który całkowicie obchodzi system (naruszenie DRY). brain_ffcss już ci to pokazuje dla jednej grupy; V0.5 robi to query’owalne w skali organizacji.

Trzy tryby audytu. --scope component audytuje pojedynczy komponent przez wszystkich konsumentów. --scope page audytuje slice routingowy (stronę checkout, przez pięć frontów, porównując implementacje). --scope full robi org-wide pass. Ten sam silnik, różne strategie traversalu, różne kształty wyników. Sens jest taki, że pytasz w kształcie, który pasuje do pracy, a nie w kształcie, który narzędzie akurat obsługuje.

To jest wersja, która uzasadnia commercial engagement. Multi-tenantowy production deployment, optymalizacja kosztów przy setkach audytów, integracja z whatever ticketing i design tool org już używa. Kształt jest open-source educational; warstwa operacyjna nie.

Trzy poziomy

Żeby surface oferty był ostry:

graph LR
    A[jarvis-brain-core<br/>Public AGPL-3.0] --> B[jarvis-brain<br/>Private full<br/>multi-tenant prod]
    B --> C[V0.5 Enterprise<br/>Cross-repo dedup<br/>Token federation<br/>3 audit modes]

Tier 1 - jarvis-brain-core (public, AGPL-3.0). Silnik. Klonuj, odpalaj, ucz się. Buduj swoje na tym, jeśli chcesz.
Tier 2 - jarvis-brain (private, commercial). Production deployment. Multi-tenant, auth, webhook orchestration, cost tracking, alerting. Nie open-source. Dostępny jako commercial engagement.
Tier 3 - V0.5 Enterprise (commercial + design system focus). Tier 2 plus cross-repo federation, design system token tracking w skali organizacji, trzy tryby audytu. Wersja, która ma sens dla design system orgs z pięcioma plus konsumenckimi frontami.

Jeśli prowadzisz setup pasujący do listy “kiedy się opłaca” - szczególnie jeśli masz współdzielony design system albo core library konsumowany przez wiele frontów - produktywna rozmowa jest na poziomie tier 2 i tier 3. Publiczne repo wystarcza do oceny, czy metoda jest prawdziwa. Nie wystarcza do uruchomienia produkcyjnego.

DM jest otwarte. Brief, który pomaga mi najbardziej: ile repo, co dzielą, gdzie exploration burn obecnie zżera ci czas. Jeśli masz te trzy liczby, mogę w rozmowie powiedzieć, czy brain jest wart pościgu dla twojego kontekstu, czy twoje wąskie gardło jest gdzieś indziej.

sdet.it/services dla dłuższej wersji oferty.

Wrap serii

Trzy dni. Jedna klasa problemu. Jeden silnik. Jeden benchmark. Jedna warstwa enterprise.

Co próbowałem zrobić w tej serii: pokazać faktyczny proces decyzyjny, nie polerowany wynik. Część 1 miała moment, w którym prawie shipnąłem naive RAG i skasowałem. Część 2 miała kategorię benchmarka, gdzie brain przegrywa z Grep o dwadzieścia procent. Część 3 miała przypadki, w których w ogóle nie powinieneś tego adoptować. Uczciwa wersja każdej historii architektonicznej zawiera części, które nie zadziałały.

Jeśli spędziłeś czterdzieści pięć minut na tej serii, oto co mam nadzieję, że zostaje: graf-backed context nie jest magicznym upgrade’em twojego AI workflow. To konkretne rozwiązanie konkretnej klasy problemu - strukturalna eksploracja na codebase’ach na tyle dużych albo rozproszonych, że LLM nie utrzyma ich w pamięci roboczej. Jeśli masz ten problem, silnik się opłaca mierzalnie. Jeśli nie masz - Grep nadal jest właściwą odpowiedzią.

Co za tydzień

Series #03 ląduje we wtorek: context-first QA. Założenie: większość contentu AI-in-QA mówi “niech AI pisze twoje testy”. Ja robię odwrotnie - AI nigdy nie pisze testów, ale robi prawie wszystko inne wokół nich. Dlaczego ta dystynkcja ma znaczenie, jak wygląda w praktyce i jakie są failure modes.

#FromTheField - nowa seria wtorek rano.