Claude Code do onboardingu bazy kodu: zapytania, które mapują Twoją aplikację

Czego chcesz się dowiedzieć (a co może poczekać)

Czytanie plików na chybił trafił jest wolne, bo większość repozytoriów nie jest uporządkowana jak opowiadanie. Otwierasz folder, widzisz dziesięć nazw, które wyglądają na ważne, klikasz jedną i kończysz w helperach, konfiguracjach i przypadkach brzegowych. Po godzinie masz masę szczegółów, ale nadal nie potrafisz wyjaśnić, jak działa aplikacja.

Lepszym celem dla Claude Code podczas onboardingu jest zbudowanie prostej mapy mentalnej. Ta mapa powinna odpowiedzieć na trzy pytania:

• Jakie są główne moduły?
• Jakie są kluczowe przepływy uruchamiane przez użytkowników?
• Gdzie są obszary ryzykowne, które mogą zepsuć produkcję lub powodować błędy?

Wystarczająco dobre onboardowanie w 1–2 dni to nie „potrafię wyjaśnić każdą klasę.” Bardziej przypomina to:

• Potrafisz wymienić 5–8 modułów, które mają znaczenie, i co każdy obsługuje.
• Potrafisz prześledzić 2–3 rzeczywiste przepływy użytkownika end-to-end (od UI lub wejścia API do bazy i z powrotem).
• Znasz największe ryzyka (płatności, auth, zapisy danych, zadania w tle) i wiesz, gdzie się znajdują.
• Możesz bezpiecznie wprowadzić małą zmianę, bo wiesz, co przetestować i kogo zapytać.

Niektóre rzeczy mogą poczekać. Głębokie refaktory, perfekcyjne rozumienie każdej abstrakcji i czytanie starego kodu, którego nikt nie dotyka, rzadko daje najszybszą wartość.

Traktuj onboarding jak budowanie mapy, a nie zapamiętywanie ulic. Twoje zapytania powinny ciągle przypominać: „Gdzie jestem w systemie, co się dzieje dalej i co tu może pójść nie tak?” Kiedy masz to ogólne zrozumienie, szczegóły łatwiej się uczą w miarę potrzeby.

Przygotowanie: zdobądź kontekst bez gotowania oceanu

Zanim zaczniesz zadawać pytania, zbierz podstawy, których zwykle potrzebujesz pierwszego dnia. Claude Code działa najlepiej, gdy może reagować na prawdziwe pliki, faktyczne konfiguracje i zachowanie, które możesz odtworzyć.

Zacznij od dostępu i działającego uruchomienia. Upewnij się, że potrafisz sklonować repo, zainstalować zależności i uruchomić aplikację (albo przynajmniej fragment lokalnie). Jeśli lokalne uruchomienie jest trudne, uzyskaj dostęp do środowiska staging i do miejsc, gdzie są logi, aby móc zweryfikować, co kod faktycznie robi.

Następnie znajdź „źródła prawdy”. Szukasz tego, co zespół faktycznie aktualizuje, gdy coś się zmienia: README, krótkiej notatki architektury, folderu ADR, runbooka lub notatki wdrożeniowej. Nawet jeśli są nieuporządkowane, nadają nazwy modułom i przepływom, co sprawia, że Q&A jest o wiele precyzyjniejsze.

Zdecyduj o zakresie wcześnie. Wiele repozytoriów zawiera kilka aplikacji, serwisów i współdzielonych pakietów. Wybierz granice typu „tylko API i worker billing” lub „tylko aplikacja web i jej przepływ auth”. Jasny zakres zapobiega niekończącym się dygresjom.

Zapisz założenia, których nie chcesz, żeby asystent zgadywał. To wydaje się drobne, ale zapobiega błędnym modelom mentalnym, które później marnują godziny.

Oto prosta lista kontrolna przygotowania:

• Potwierdź dostęp do repo, wymagane uprawnienia i sposób uruchamiania testów.
• Zbierz notatki konfiguracji środowiska (zmienne env, seedy, feature flagi) i gdzie przegląda się logi oraz metryki.
• Zidentyfikuj aktualne pliki prawdy (README, notatki architektury, ADRy, runbooki).
• Zdefiniuj, co jest w zakresie i co jest wyraźnie poza zakresem tego przebiegu onboardingu.
• Ustal zasady bezpieczeństwa: nigdy nie wklejaj sekretów, kluczy API, tokenów, prywatnych danych klientów ani logów produkcyjnych zawierających wrażliwe informacje.

Jeśli czegoś brakuje, zanotuj to jako pytanie do kolegi. Nie „obejmuj” brakującego kontekstu domysłami.

Mapa mentalna: co uchwycić podczas eksploracji

Mapa mentalna to mały zestaw notatek odpowiadający na pytanie: jakie są główne części tej aplikacji, jak się komunikują i gdzie może coś pójść nie tak. Dobrze wykonane onboardowanie mniej polega na przeglądaniu plików, a bardziej na budowaniu obrazu, którego możesz użyć ponownie.

Zacznij od zdefiniowania wyników. Chcesz praktyczną listę modułów, nie perfekcyjną. Dla każdego modułu zanotuj, co robi, kto go posiada (zespół lub osoba, jeśli wiesz) oraz kluczowe zależności (inne moduły, serwisy, bazy danych, zewnętrzne API). Zanotuj też główne punkty wejścia: trasy UI, endpointy API, zadania w tle i harmonogramy.

Następnie wybierz kilka ścieżek użytkownika, które mają znaczenie. Trzy do pięciu wystarczy. Wybierz przepływy, które dotykają pieniędzy, uprawnień lub zmian danych. Przykłady: rejestracja i weryfikacja email, zakup planu lub transakcja, akcja admina zmieniająca dostęp użytkownika oraz krytyczny codzienny przepływ używany przez większość użytkowników.

Zdecyduj, jak oznaczysz ryzyko zanim zaczniesz zbierać notatki. Trzymaj kategorie proste, aby później dało się to szybko przeskanować. Przydatny zestaw to: bezpieczeństwo, integralność danych, dostępność i koszty. Gdy oznaczysz coś jako ryzykowne, dodaj jedno zdanie wyjaśniające dlaczego oraz co udowodni, że jest bezpieczne (test, log, sprawdzenie uprawnień).

Używaj spójnego formatu, żeby potem łatwo przerobić notatki na dokument onboardingowy bez przepisywania wszystkiego:

• Moduły: przeznaczenie, punkty wejścia, zależności, właściciel
• Kluczowe przepływy: wyzwalacz, kroki, zapisane dane, punkty awarii
• Dane: tabele lub kolekcje, istotne pola, ograniczenia
• Ryzyka: kategoria, najgorszy scenariusz, jak monitorować, jak cofnąć
• Otwarte pytania: czego nadal nie wiesz, kogo zapytać

Przykład: jeśli Checkout wywołuje Billing, który zapisuje do payments i invoices, oznacz to jako integralność danych i koszty. Zanotuj, gdzie występują retry i co zapobiega podwójnemu obciążeniu.

Krok po kroku: pytania Q&A do eksploracji repozytorium

Kiedy dołączasz do nowego repo, chcesz szybkiej orientacji, a nie perfekcyjnego zrozumienia. Te zapytania pomogą Ci zbudować mapę mentalną w małych, bezpiecznych krokach.

Zacznij od przekazania asystentowi drzewa repo (albo wklejonego podzbioru) i poproś o „tour”. Trzymaj każdą rundę skoncentrowaną, a na końcu zadawaj jedno pytanie mówiące, co czytać dalej.

1) Repo tour
"Here is the top-level folder list: <paste>. Explain what each folder likely contains and which ones matter for core product behavior."

2) Entry points
"Find the app entry points and boot process. What files start the app, set up routing, configure DI/env, and start background jobs? Name the exact files and what they do."

3) Module index
"Create a module index: module name, purpose, key files, and important external dependencies. Keep it to the modules that affect user-facing behavior."

4) Data model hints
"Based on migrations/models, list the key tables/entities, critical fields, and relationships. Call out fields that look security-sensitive or used for billing/permissions."

5) Flow trace
"Trace this flow end-to-end: <flow>. Where does the request/event start, where does it end, and what does it call in between? List the main functions/files in order."

6) Next inspection
"What should I inspect next and why? Give me 3 options: fastest clarity, riskiest area, and best long-term payoff."

To konkret: jeśli mapujesz „użytkownik rejestruje się i tworzy pierwszy projekt”, poproś o handler trasy API, walidację, zapis w DB i każde zadanie asynchroniczne wysyłające emaile lub provisioning. Potem uruchom ponownie trace dla „użytkownik usuwa projekt”, żeby wypatrzyć luki w czyszczeniu zasobów.

Aby odpowiedzi były użyteczne, proś o konkretne artefakty, nie tylko podsumowania:

• Ścieżki plików i nazwy funkcji
• Wypisane założenia i nieznane
• Zależności sformułowane jako „jeśli zmienię X, co się zepsuje?”
• Jedno krótkie zadanie do przeczytania, które zajmie 10 minut

Jak przechowywać odpowiedzi, żeby były przydatne

Największy zysk z onboardingu to zamiana rozrzuconych Q&A w notatki, których inny developer też użyje. Jeśli notatki są zrozumiałe tylko dla Ciebie, za chwilę znów odrobisz tę samą robotę.

Prosta struktura zwycięża długie dokumenty. Po każdej sesji eksploracji zachowaj odpowiedzi w pięciu małych artefaktach (jeden plik lub dokument wystarczy): tabela modułów, glosariusz, kluczowe przepływy, nieznane i rejestr ryzyk.

Oto kompaktowy szablon, który możesz wkleić do notatek i wypełniać w trakcie:

Module table
- Module:
  Owns:
  Touches:
  Entry points:

Glossary
- Term:
  Meaning:
  Code name(s):

Key flow (name)
1.
2.
3.

Unknowns
- Question:
  Best person to ask:
  Where to look next:

Risk register
- Risk:
  Location:
  Why it matters:
  How to verify:

Trzymaj przepływy krótkie celowo. Przykład: 1) użytkownik loguje się, 2) backend tworzy sesję, 3) klient ładuje dashboard, 4) API pobiera dane, 5) UI renderuje i obsługuje błędy. Jeśli nie możesz zmieścić przepływu w pięciu krokach, podziel go (logowanie vs ładowanie dashboardu).

Gdy korzystasz z Claude Code, dodaj do każdej odpowiedzi jedną linijkę: „Jak bym to przetestował?” Ta jedna linijka zmienia pasywne notatki w checklistę, którą możesz potem uruchomić, zwłaszcza gdy nieznane i ryzyka zaczynają się nakładać.

Jeśli budujesz w platformie vibe-coding jak Koder.ai, takie notatki pomagają też zauważyć, gdzie generowane zmiany mogą mieć efekty uboczne. Moduły z wieloma punktami styku często przyciągają zmiany.

Jak szybko znaleźć obszary ryzykowne (bez czytania każdego pliku)

Ryzyko w bazie kodu rzadko jest losowe. Grupuje się tam, gdzie aplikacja decyduje, kim jesteś, zmienia dane, rozmawia z innymi systemami lub uruchamia pracę w tle. Większość znajdziesz pytaniami celowanymi i kilkoma fokused searchami.

Zacznij od tożsamości. Zapytaj, gdzie odbywa się uwierzytelnianie (logowanie, sesje, tokeny) i gdzie żyją decyzje autoryzacyjne (sprawdzanie ról, feature flagi, reguły właścicielstwa). Częstym pułapkiem są rozproszone checki po UI, handlerach API i zapytaniach do DB bez jednego źródła prawdy.

Następnie zmapuj ścieżki zapisów. Znajdź endpointy lub funkcje, które tworzą, aktualizują lub usuwają rekordy, plus migracje, które zmieniają dane w czasie. Uwzględnij też zadania w tle. Wiele tajemniczych błędów pochodzi od workerów asynchronicznych zapisujących nieoczekiwane wartości długo po zakończeniu żądania.

Przykładowe zapytania odsłaniające ryzyko szybko:

• "Wypisz wszystkie miejsca, które egzekwują uprawnienia dla [zasób X]. Które jest ostateczną bramą?"
• "Pokaż pełną ścieżkę zapisu [tabela/encja X]: handler API -> serwis -> wywołanie DB. Gdzie są walidacje?"
• "Jakie integracje zewnętrzne istnieją (płatności, email, webhooki, API stron trzecich)? Gdzie ustawione są retry i timeouty?"
• "Gdzie praca może uruchomić się dwukrotnie (kolejki, goroutines, cron)? Co sprawia, że jest idempotentne?"
• "Co może się zepsuć po cichu i jak byśmy to zauważyli (logi, metryki, alerty, dashboardy)?"

Potem sprawdź konfigurację i obsługę sekretów. Szukaj zmiennych środowiskowych, plików konfiguracji runtime i domyślnych fallbacków. Fallbacki są użyteczne, ale ryzykowne, gdy ukrywają błędy konfiguracji (np. użycie klucza deweloperskiego w produkcji, bo wartość była pusta).

Krótki przykład: w backendzie Go z PostgreSQL możesz znaleźć zadanie "send email" z retry. Jeśli retry działa bez klucza idempotencji, użytkownicy mogą dostać duplikaty maili. Jeśli błędy tylko logują ostrzeżenie i nie ma alertu, awaria przebiega cicho. To obszar wysokiego ryzyka, który warto udokumentować i przetestować wcześnie.

Przykładowe przejście: mapowanie jednego realnego przepływu użytkownika

Użyj jednego realnego przepływu, aby zbudować pierwszy wątek end-to-end przez system. Logowanie to dobry start, bo dotyka routingu, walidacji, sesji lub tokenów i odczytów z bazy.

Scenariusz: aplikacja React wywołuje API w Go, a API czyta i zapisuje PostgreSQL. Twoim celem nie jest zrozumienie każdego pliku. Chodzi o odpowiedź: „Kiedy użytkownik klika Zaloguj, jaki kod uruchamia się dalej, jakie dane się przemieszczają i co może pójść nie tak?” To utrzymuje onboarding konkretnym.

Zmapuj przepływ od przeglądarki do bazy

Zacznij od UI i idź krok po kroku. Proś o konkretne nazwy plików, funkcji oraz kształt requestów i response'ów.

• "Znajdź trasę/stronę React dla ekranu logowania. Który komponent ją renderuje i jaka akcja jest wywoływana przy submit?"
• "Gdzie wykonywane jest wywołanie klienta API (fetch/axios/etc.)? Jaką dokładnie ścieżkę URL, metodę, nagłówki i body wysyła?"
• "Po stronie Go, gdzie zarejestrowany jest handler dla tej ścieżki? Pokaż konfigurację routera i funkcję handlera."
• "W handlerze, gdzie odbywa się walidacja wejścia (frontend, backend, czy oba)? Jakie są reguły i gdzie formatowane są błędy?"
• "Jakie zapytanie do bazy wykonuje się przy logowaniu? Wskaż repozytorium/plik SQL, wypisz dotykane tabele/kolumny i zanotuj transakcje lub blokady."

Po każdej odpowiedzi zapisz jedną krótką linię w mapie mentalnej: "UI component -> endpoint API -> handler -> serwis -> zapytanie DB -> response." Podawaj nazwy, nie tylko "jakiejś funkcji."

Potwierdź szybkim uruchomieniem

Gdy masz ścieżkę, zweryfikuj ją krótkim testem. Sprawdzasz, czy odwzorowana ścieżka to ta, której aplikacja rzeczywiście używa.

Obserwuj żądania sieciowe w narzędziach deweloperskich przeglądarki (ścieżka, kod statusu, body odpowiedzi). Dodaj lub włącz logi serwera wokół handlera i wywołania DB (jeśli jest request ID, użyj go). Zapytaj PostgreSQL o oczekiwane zmiany (dla logowania może to być last_login_at, wpisy sesji lub rekordy audytu). Wymuś jedną awarię (zły password, brak pola) i zanotuj, gdzie powstaje komunikat o błędzie i gdzie jest wyświetlany. Zapisz oczekiwane odpowiedzi dla sukcesu i porażki (kody statusu i kluczowe pola), żeby następny developer mógł szybko sanity-checkować.

Ten jeden przepływ często ujawnia granice własności: czemu UI ufa, co API egzekwuje i gdzie błędy znikają lub są podwójnie obsługiwane.

Zamień mapę mentalną w krótki dokument onboardingowy

Gdy masz przyzwoitą mapę mentalną, utrwal ją w 1–2 stronicowej notatce. Cel nie jest kompletny. Chodzi o to, żeby następny developer umiał odpowiedzieć: czym jest ta aplikacja, gdzie szukać na początek i co najprawdopodobniej się zepsuje.

Jeśli używasz Claude Code, traktuj dokument jako wynik twojego Q&A: jasny, konkretny i łatwy do przeskanowania.

Prosta struktura 1–2 stron

Utrzymaj dokument przewidywalnym, żeby ludzie mogli szybko znaleźć to, czego szukają. Dobra struktura to:

• Cel: co aplikacja robi, kto jej używa i co znaczy „sukces”
• Podsumowanie architektury: główne serwisy, magazyny danych i jak żądania przemieszczają się przez system
• Jak uruchomić: prerekwizyty, jedna komenda do startu i jedna komenda do uruchomienia testów
• Gdzie co jest: foldery, które się liczą, plus 5–10 plików służących jako wejścia
• Kluczowe przepływy i ryzyka: krótkie ścieżki ważnych podróży plus co sprawdzić po zmianach

Uczyń to działającym, nie akademickim

Dla „Gdzie co jest”, podawaj wskazówki typu "Auth zaczyna się w X, logika sesji w Y, trasy UI w Z." Unikaj zrzutów całego drzewa. Wybierz tylko to, czego ludzie będą dotykać.

Dla „Kluczowych przepływów”, napisz 4–7 kroków na przepływ: wyzwalacz, kontroler/handler, główny moduł, zapytanie do bazy i efekt zewnętrzny (wysłano email, zaktualizowano stan, wstawiono zadanie do kolejki). Dodaj nazwy plików przy każdym kroku.

Dla „Obszarów ryzykownych”, nazwij tryb awarii i najszybszą kontrolę bezpieczeństwa (konkretny test, smoke run albo log do obserwacji).

Zakończ krótką listą pierwszych zadań, żeby ktoś mógł bezpiecznie wnieść wkład:

• Zaktualizuj drobną treść lub regułę walidacji w jednym zamkniętym ekranie
• Dodaj mały unit test wokół trudnego helpera, który zidentyfikowałeś
• Napraw niski priorytet bug z jasnym repro i oczekiwanym wynikiem
• Dodaj guardrail: lepszy komunikat błędu, sprawdzenie wejścia lub timeout
• Dowiedz się, kto odpowiada za deployy produkcyjne i kogo pingować w sprawach domenowych

Częste błędy i jak ich unikać

Najszybszy sposób zmarnować asystenta to prosić o "pełne wyjaśnienie całego repo." Dostaniesz długie podsumowanie, które brzmi pewnie, ale pozostaje ogólne. Zamiast tego wybierz mały fragment, który ma znaczenie (jeden moduł + jeden przepływ), potem rozszerzaj.

Blisko za tym jest nieokreślenie, które podróże mają znaczenie. Jeśli nie powiesz "checkout", "login" lub "admin edit", odpowiedzi dryfują w stronę ogólnej architektury. Zaczynaj każdą sesję konkretnym celem: "Pomóż mi zrozumieć proces rejestracji end-to-end, włącznie z walidacją, stanami błędów i tym, gdzie dane są przechowywane."

Inną pułapką jest pozwolenie asystentowi na zgadywanie. Kiedy coś jest niejasne, wymuś oznaczenie niepewności. Poproś o oddzielenie tego, co można udowodnić z kodu, od wniosków.

Trzymaj nieznane widoczne (żeby je rozwiązać)

Ustal prostą zasadę: każde twierdzenie musi mieć jedną z etykiet:

• Potwierdzone w kodzie
• Potwierdzone przez uruchomienie aplikacji
• Założenie (wymaga sprawdzenia)
• Nieznane (brakuje kontekstu)

Notatki też się rozlatują, gdy są zbierane bez struktury. Stosuj spójny szablon: moduły, punkty wejścia, kluczowe funkcje i pliki, dotykane dane, efekty uboczne, ścieżki błędów i testy do uruchomienia.

Nie traktuj wyników jak faktów

Nawet z Claude Code traktuj wynik jako szkic. Weryfikuj kluczowe przepływy w działającej aplikacji, szczególnie te fragmenty, które mogą zepsuć produkcję: auth, płatności, uprawnienia, zadania w tle i migracje.

Praktyczny przykład: jeśli asystent mówi "reset hasła wysyła email przez X", potwierdź to, wywołując reset w środowisku deweloperskim i sprawdzając logi lub sandbox mailowy. Ten reality check zapobiega onboardowaniu się w historię, która nie jest prawdziwa.

Szybka lista kontrolna zanim powiesz „Jestem onboardowany”

Nie musisz zapamiętywać całego repo. Musisz mieć wystarczającą pewność, by bezpiecznie wprowadzić zmianę, debugować realny problem i wyjaśnić system następnej osobie.

Zanim uznasz, że jesteś onboardowany, upewnij się, że potrafisz bez zgadywania odpowiedzieć na pytania:

• Czy potrafisz wyjaśnić pięć najważniejszych obszarów kodu i co każdy obsługuje (np. UI, warstwa API, zadania w tle, dostęp do danych, integracje)?
• Czy potrafisz przejść przez dwa wartościowe przepływy użytkownika end-to-end i wskazać pierwszy plik lub funkcję rozpoczynającą każdy przepływ?
• Czy potrafisz wskazać, gdzie egzekwowane jest uwierzytelnianie i gdzie definiowane są role/permissions oraz jak są sprawdzane?
• Czy potrafisz nazwać najbardziej ryzykowne zapisy do bazy danych (pieniądze, uprawnienia, usunięcia, przejścia stanu) i opisać, jak bezpiecznie przetestujesz każdą zmianę?
• Czy potrafisz przekazać nowemu developerowi krótką notatkę onboardingową, którą przeczyta w mniej niż 10 minut i potem wie, od czego zacząć?

Jeśli brakuje jednej rzeczy, zrób małe, ukierunkowane podejście zamiast szerokiego przeszukiwania. Wybierz jeden przepływ, prześledź go do granicy bazy danych, potem zatrzymaj się i zapisz, czego się nauczyłeś. Gdy coś jest niejasne, zapisz to jako pytanie, nie akapit. "Gdzie tworzona jest rola X?" jest bardziej użyteczne niż "auth jest mylący."

Dobry finalny test: wyobraź sobie, że masz dodać małą funkcję za flagą. Jeśli potrafisz nazwać pliki, które byś dotknął, testy, które byś uruchomił, i tryby awarii, które byś obserwował, to jesteś wystarczająco onboardowany, by wnieść odpowiedzialny wkład.

Kolejne kroki: utrzymuj mapę aktualną i ułatwiaj przekazanie wiedzy

Mapa mentalna jest użyteczna tylko wtedy, gdy odpowiada rzeczywistości. Traktuj ją jako żywy artefakt, nie jednorazowe zadanie. Najłatwiejszy sposób, żeby pozostała aktualna, to zaktualizować ją zaraz po zmianach, które wpływają na zachowanie.

Lekka rutyna bije duże przepisy. Powiąż aktualizacje z pracą, którą już wykonujesz:

• Po każdej funkcji: zaktualizuj listę modułów i główne przepływy, które dotknęła
• Po każdym incydencie: dodaj wyzwalacz, wpływ i dokładne miejsce naprawy
• Po każdym ryzykownym refactorze: zanotuj, co się zmieniło i co pozostało kompatybilne
• Przed wydaniem: ponownie sprawdź top 3 ryzykowne obszary i ścieżki testowe
• Raz w miesiącu: usuń nieaktualne notatki i potwierdź właścicieli kluczowych modułów

Trzymaj dokument onboardingowy blisko kodu i wersjonuj go z tą samą dyscypliną co repozytorium. Małe zmiany są czytane. Duże rewizje zwykle są pomijane.

Gdy wdrożenia są ryzykowne, zapisz, co pomoże następnej osobie szybko odzyskać sprawność: co się zmieniło, co obserwować i jak cofnąć. Jeśli platforma wspiera snapshoty i rollback, dodaj nazwę snapshota, powód i jak wygląda „dobry” wynik po naprawie.

Jeśli używasz Koder.ai (koder.ai), tryb planowania może pomóc Ci sporządzić spójną mapę modułów i notatkę onboardingową z Q&A, a eksport źródeł daje recenzentom czytelny sposób na weryfikację wyniku.

Na koniec, zdefiniuj checklistę przekazania, którą następna osoba będzie mogła wykonać bez zgadywania:

• Co przeczytać najpierw (2–3 pliki lub dokumenty) i dlaczego
• Co uruchomić lokalnie (komendy, zmienne env, dane seed)
• Co zweryfikować (jeden happy path i jeden przypadek błędu)
• Gdzie są ostre krawędzie (ryzykowne moduły, fluktuujące testy, trudne konfiguracje)
• Kogo pytać o co (właściciele kluczowych przepływów)

Dobrze wykonane, Claude Code do onboardingu bazy kodu staje się nawykiem: każda zmiana zostawia jaśniejszą mapę dla następnej osoby.