Jesteś szczebel niżej, niż myślisz: audyt własnego wdrożenia AI

Zapytaj dewelopera, jak głęboko wszedł w agentowe programowanie, a usłyszysz odpowiedź o narzędziach. Który model, który edytor, ile kart w terminalu. Zapytaj, czy ma z tego więcej niż trzy miesiące temu — a odpowiedź zamieni się we mgłę.

Miałem ten sam problem z własną pracą i było gorzej niż nieprecyzyjnie — było kierunkowo. Konsekwentnie uważałem, że jestem o szczebel wyżej, niż wynikało z dowodów, bo liczyłem to, co skonfigurowałem, a nie to, na czym faktycznie polegałem. Zaplanowany agent istniał, więc chyba się liczy. Konektor był ustawiony, więc chyba kontekst płynie. Konfiguracja była prawdziwa. Poleganie nie.

Napisałem więc małą umiejętność, która odpowiada na to pytanie, czytając repozytorium, zamiast pytać mnie. Zajmuje jakąś minutę i ani razu mi nie pochlebiła.

Drabina

Rama pochodzi ze „Steps of AI Adoption“ Borisa Cherny’ego, a jej wartość polega na tym, że każdy szczebel definiuje to, co się psuje, a nie to, co posiadasz.

Szczebel	Agentów naraz	Twoja rola	W co uderzasz
0 Zablokowany	0	—	procesy akceptacji
1 Ze wsparciem	~1	recenzent w parze	twoja uwaga i niskie zaufanie
2 Równolegle	~10	orkiestrator	przegląd N strumieni diffów
3 Nadzorowana autonomia	~100	menedżer menedżerów	zaufanie do pętli, przepustowość decyzji
4 AI-native	1000+	sterowanie intencją, monitorowanie wyjątków	bariery pod każdy typ pracy, w skali

Ciekawa jest ostatnia kolumna. Wejście wyżej nie usuwa wąskiego gardła, tylko je przenosi — i właśnie dlatego warto te szczeble rozróżniać. Na szczeblu 1 ogranicza cię to, jak szybko czytasz kod. Na szczeblu 2 — jak szybko przeglądasz kilka równoległych diffów, dlatego przejście nie polega na „uruchomieniu większej liczby agentów“, tylko na „zbudowaniu czegoś, co recenzuje za ciebie“. Na szczeblu 3 ograniczenie przestaje być techniczne w ogóle i staje się zaufaniem: praca rusza bez twojego zlecenia i albo wierzysz wynikom, albo cała konstrukcja jest teatrem.

Przejścia są konkretne — to właśnie czyni je audytowalnymi:

• 1 → 2: równolegli agenci w izolowanych worktree, pętla samoweryfikacji, której naprawdę ufasz, tryb automatyczny i automatyczny przegląd kodu.
• 2 → 3: harmonogramy i rutyny, agenci uruchamiający innych agentów, kontekst zaciągany, a nie wklejany (zadania, dokumenty, konektory), oraz obwiednia uprawnień na tyle szeroka, żeby agent nie zatrzymywał się na tobie co cztery minuty.
• 3 → 4: automatyzacja w skali domeny — migracje, fuzzing, masowe poprawki — z limitem kosztu na każdy proces.

A opis roli na szczeblu 3 to zdanie, które przestawiło mi najwięcej. Pytanie o pracę agenta przestaje brzmieć „czytałeś ten kod?“, a zaczyna „jakiego kontekstu zabrakło modelowi?”. To inna praca. To różnica między recenzowaniem wyniku a poprawianiem warunków, w których wynik powstaje.

Dlaczego to musiała być umiejętność, a nie lista kontrolna

Próbowałem listy kontrolnej. Przez jakiś czas leżała u mnie w notatce. Problem z listą kontrolną jest taki, że wypełniasz ją sam — z pamięci, hojnie, pod koniec udanego tygodnia.

Trzy cechy sprawiają, że wersja automatyczna jest warta zachodu.

Czyta repozytorium, a nie twoje wyobrażenie o sobie. Sprawdza listę uprawnień w prawdziwych plikach ustawień i mówi, w którym pliku ona leży. Sprawdza zadeklarowane serwery w .mcp.json, a potem wykonuje po jednym tanim wywołaniu tylko do odczytu, żeby zobaczyć, czy autoryzacja żyje — konektor skonfigurowany, ale wygasły liczy się jako punkt otwarty, bo funkcjonalnie taki właśnie jest. Szuka stopek agenta w treści piętnastu ostatnich commitów, a nie w --oneline, które ucina dokładnie ten dowód, którego potrzebujesz. Tam, gdzie sygnał w ogóle nie zostawia śladu — praca w równoległych worktree nie widnieje w gicie — mówi o tym i pyta, zamiast zgadywać.

Zaliczanie jest surowe. Szczebel jest zaliczony tylko wtedy, gdy każdy punkt przejścia jest zrobiony. Trzy z czterech to nie „szczebel 3, częściowo“. To szczebel 2, a raport mówi to wprost: „Szczebel 2 zaliczony; przejście 2→3 — 3 z 4“. Brzmi jak pedanteria i jest zarazem najbardziej użyteczną regułą w całej tej rzeczy. Częściowe zaliczenie to sposób, w jaki zaczynasz wierzyć, że jesteś tam, gdzie cię nie ma — bo częściowe zaliczenie to język samooceny, a w nim każdy niedokończony punkt brzmi jak prawie skończony.

Pamięta — osobno dla każdego projektu. Każde uruchomienie zapisuje się w pamięci projektu: linia statusu z datą, migawka dowodów, punkty otwarte. Dzięki temu kolejne uruchomienie jest diffem, a nie świeżym zgadywaniem, a pytanie „czy coś ruszyło od czerwca?“ ma prawdziwą odpowiedź. W tej samej pamięci jest sekcja „Zdecydowano PRZECIW — nie proponować ponownie“. Jeśli oceniłem jakąś praktykę i odrzuciłem ją z dobrych powodów, chcę, żeby odrzucenie się trzymało. Asystent, który co miesiąc od nowa sprzedaje odrzucony pomysł, nie pomaga — sprawia tylko, że mówienie „nie“ staje się kosztowne.

Podział na projekty okazał się ważniejszy, niż się spodziewałem. Uczciwie jestem na różnych szczeblach w różnych repozytoriach, a uśrednienie ich do jednego osobistego „poziomu“ niszczy jedyną informację, która ma wartość. Dojrzała usługa z testami i szeroką obwiednią uprawnień udźwignie pracę bez nadzoru. Dwutygodniowy prototyp nie udźwignie i nie powinien. Ten sam deweloper, te same narzędzia, inny szczebel.

Co to faktycznie wyłapuje

Infrastrukturę policzoną jako postęp. To był mój własny tryb awarii i w tej sprawie umiejętność ma najmocniejsze zdanie. Istniejąca rutyna w harmonogramie to nie szczebel 3. Szczebel 3 stoi na wynikach bez nadzoru, którym się ufa. Umiejętność sprawdza więc, że rutyna istnieje, jest włączona i ma sensowne kolejne uruchomienie — i na tym się zatrzymuje, bo pozostałe pytanie może zamknąć wyłącznie człowiek: czy ostatnie raporty były trafne i przydatne? Żadne repozytorium na to nie odpowie. Jeśli nikt ich nie ocenił, szczebel nie jest zaliczony i żadna ilość zielonej konfiguracji tego nie zmieni.

Rzeczy, które wyglądają na skonfigurowane, a nie są. Test autoryzacji łapie konektory, które kiedyś ustawiono, a one po cichu przestały działać. Taniej znaleźć to w ten sposób niż w środku pracy, w której na nie liczyłeś.

Wyciek zakresu. Narzędzia MCP widoczne w sesji mogą pochodzić z konfiguracji użytkownika albo w ogóle z innego projektu — nie są dowodem na temat tego repozytorium. Ograniczenie audytu do plików, pamięci i wyzwalaczy bieżącego projektu trzeba było zapisać wprost, bo kuszący błąd polega tu na pozwoleniu, żeby dobrze wyposażona sesja pochlebiła pustemu repozytorium.

Jest też tryb awarii w drugą stronę, którego poprawienie zajęło kilka uruchomień. Wczesne wersje traktowały brak infrastruktury w młodym projekcie jak niedobór i produkowały raport, który czytało się jak reprymendę. To bezużyteczne. Dla świeżego repozytorium poprawna odpowiedź brzmi „szczebel 1, a oto najkrótsza droga do drugiego“ — pozycja startowa, a nie brak.

Co z tego masz

Uczciwy szczebel, z dowodem przy każdym twierdzeniu — ścieżka do pliku, identyfikator wyzwalacza, odniesienie do commita — żeby dało się spierać z pojedynczą linijką, a nie z werdyktem. Ocenioną tabelę wymagań następnego szczebla, żeby cel był listą czterech konkretnych rzeczy, a nie przeczuciem, że się zostaje w tyle. I trzy kolejne ruchy w kolejności — według zaufania zarobionego na jednostkę wysiłku; ta kolejność jest właściwa, bo górne szczeble są zrobione właśnie z zaufania.

Przestawienie ramy jest warte więcej niż sama ocena. „Czuję, że powinienem wyciskać z tego więcej“ to lęk i nie da się na tym działać. „Automatyczny przegląd kodu jest otwarty i to ostatni punkt między mną a szczeblem 2“ to zadanie na wtorek.

Umiejętność jest krótka — jeden plik Markdown, drabina wszyta w środku, więc nigdy nie marnuje tury na pobieranie czegokolwiek od nowa. Jest opublikowana jako gist, ze ścieżką instalacji i notatkami w README. Wrzuć ją do ~/.claude/skills/adoption-check/, a zadziała w każdym projekcie, który otworzysz.

Uruchom ją tam, gdzie masz o sobie dobre zdanie. Tam jest najbardziej pouczająca.