Dwie klasy narzędzi, dwie różne role. Narzędzia kontekstowe dają agentowi tanie i trafne rozumienie kodu — bez czytania repozytorium plik po pliku. Systemy autorytatywne trzymają prawdę i dowody: etap, kod, testy, projekt. A każdy system ma trzy możliwe ścieżki integracji — wybierane świadomie, per przypadek.
Agent schodzi po drabince od najtańszego trafnego narzędzia i zatrzymuje się na pierwszym, które odpowiada na pytanie. Równolegle działają dwa filtry kosztów: rtk przycina wyjście komend, zanim trafi do modelu, a caveman kompresuje samą komunikację modelu.
Lokalny graf wiedzy o kodzie: symbole, wywołania, przepływy. Jedno zapytanie zwraca źródło funkcji razem z tym, kto ją woła — z prekomputowanego indeksu, nie z czytania plików. Dostępny dla agentów jako MCP i jako CLI.
npm i -g @colbymchenry/codegraph
github.com/colbymchenry/codegraph
Wyszukiwanie semantyczne po kodzie i dokumentach: „gdzie jest logika ponawiania płatności" — bez znajomości nazw funkcji i plików. Najlepsze pierwsze wejście w obce repozytorium.
uv tool install semble
github.com/MinishLab/semble
Błyskawiczny grep nowej generacji: dokładne dopasowania, wyrażenia regularne, weryfikacja końcowa hipotez z dwóch poprzednich szczebli drabinki.
brew install ripgrep
github.com/BurntSushi/ripgrep
Proxy CLI, które filtruje wyjście komend deweloperskich (git, kompilacja, testy), zanim trafi do modelu. Hook przepisuje wywołania transparentnie — agent nie musi o nim wiedzieć.
brew install rtk
rtk-ai.app
Plugin wymuszający ultra-skompresowany styl wypowiedzi modelu — „mów jak mądry jaskiniowiec": bez ozdobników i grzeczności, z pełną treścią techniczną. Działa na raportach, statusach i przekazaniach między agentami; trzy poziomy kompresji (lite / full / ultra).
/plugin marketplace add JuliusBrussee/caveman
github.com/JuliusBrussee/caveman
Te systemy nie służą do „czytania kodu" — one trzymają stan i dowody. Agent może mieć ulotny kontekst, ale prawda o etapie, kodzie, testach i projekcie żyje w systemach autorytatywnych i daje się odtworzyć po restarcie. Wiążąca jest rola w procesie, nie nazwa produktu — poniżej nasz zestaw; u klienta wchodzą jego odpowiedniki.
Statusy cyklu życia, wpisy bramek (ANALYSIS GATE: PASS 8f3c21ab), decyzje i pełna historia audytowa każdego zgłoszenia.
Pull requesty, review, merge wyłącznie przez bramkę. CI na własnej puli runnerów buduje dowody: testy, lint, skany — przypięte do konkretnego SHA.
Wyniki testów z CI trafiają do cykli testowych — historia pokrycia i regresji nie ginie w logach buildów, tylko ma swój audytowalny rejestr.
Testy przeglądarkowe: przepływy logowania, smoke tras, porównania zrzutów ekranu. Artefakty stają się dowodem weryfikacji UI przy bramce.
Agent czyta i adnotuje projekty bezpośrednio: specyfikacje komponentów i tokeny designu zasilają Analizę i Architekturę bez ręcznego przepisywania.
Self-hosted orkiestracja przepływów: bramki zatwierdzeń, ponawianie, integracje między systemami — tam, gdzie automatyzacja nie wymaga pełnego agenta.
Cztery kategorie: skan zależności, analiza statyczna, testy dynamiczne, skan obrazów kontenerów — u nas odpowiednio cargo audit, clippy, OWASP ZAP i Trivy. Wyniki przypięte do konkretnego SHA stają się dowodem bezpieczeństwa przy bramce weryfikacji.
Do każdego systemu prowadzą trzy drogi o różnych właściwościach. Dojrzały proces nie wybiera jednej „najlepszej" — dobiera ścieżkę do charakteru pracy: deterministycznej, interaktywnej albo objętej polityką.
| Ścieżka | Kiedy | Zalety | Ograniczenia |
|---|---|---|---|
| Skrypt / CLI | tory dostawy: bramki, przejścia statusów, merge — wszystko, co musi być powtarzalne i rozliczalne | ✚ deterministyczny i fail-closed ✚ tani w tokenach ✚ działa headless i w cron |
✖ utrzymanie własnego kodu ✖ sztywny zakres operacji |
| MCP | praca interaktywna: eksploracja zgłoszeń, praca z plikiem projektowym, sesje z człowiekiem | ✚ pełne schematy operacji bez sklejania shella ✚ bogata, dwustronna interakcja |
✖ uwierzytelnianie per sesja — potrafi zniknąć w przebiegach headless ✖ narzut tokenowy schematów narzędzi |
| Skill / wrapper | gdy dostęp musi nieść politykę: preflight auth, jednolity kontrakt błędów, blokada podwójnej pracy | ✚ reguły egzekwowane w jednym miejscu ✚ spójne komunikaty błędów dla całego systemu ról |
✖ dodatkowa warstwa i latencja ✖ kolejny artefakt do utrzymania |
Zasada: ścieżka wybierana per przypadek, nie per moda. Tory dostawy jeżdżą na skryptach (determinizm + audyt), praca interaktywna na MCP, a skill wchodzi tam, gdzie potrzebna jest polityka — nie sam dostęp. Jedno jest stałe: dowody zawsze lądują w systemie autorytatywnym, nigdy w pamięci agenta.
Role procesu to definicje — wykonuje je runtime agentowy. Używamy dwóch, celowo różnych: interaktywnego do orkiestracji i decyzji oraz headless do masowej implementacji. Trzecim elementem jest drabinka modeli: proste zadania idą do najtańszego modelu, który przechodzi bramki.
Runtime interaktywny Anthropic (działa też headless). U nas: warstwa Dyrektorów — orkiestracja dostawy, decyzje, praca z operatorem — oraz subtaski agentowe tam, gdzie zadanie wymaga mocnego modelu.
npm i -g @anthropic-ai/claude-code
claude.com/claude-code
Runtime wykonawczy OpenAI. U nas: główna linia implementacyjna — Dyrektor wysyła pakiet zadania, runtime wykonuje go autonomicznie w sandboksie i oddaje gałąź z dowodami.
npm i -g @openai/codex
github.com/openai/codex
Modele o koszcie tokenów rzędy wielkości niższym, zgodne z API OpenAI. Rola w drabince: mechaniczne, dobrze zdefiniowane zadania idą do taniego modelu; eskalacja do mocniejszego następuje dopiero po porażce na bramce.
platform.deepseek.com
api-docs.deepseek.com
Podział pracy: decyzje i orkiestracja — runtime interaktywny; masowa implementacja — runtime headless; mechaniczne zmiany — najtańszy model, który przechodzi bramki. Niezależnie od runtime'u obowiązują te same bramki i te same dowody. Dodatkowo każdą rewizję PR recenzuje niezależny bot AI na GitHubie — głos spoza obu ekosystemów, traktowany jako opinia, nie jako werdykt bramki.