Boris Cherny, Staff Engineer i szef zespołu Claude Code w Anthropic, od listopada 2025 roku nie napisał ręcznie ani jednej linii kodu produkcyjnego. Całą swoją pracę programistyczną powierza Claude Code — narzędziu, którego sam pomagał tworzyć. Jego codzienne statystyki brzmią jak science fiction: 10 do 30 scalonych pull requestów (PR) dziennie, przy jednoczesnym uruchomieniu wielu agentów AI. Jak wygląda dzień pracy, w którym człowiek nie pisze kodu, a jedynie go nadzoruje i steruje?
Cherny udostępnił serię szczegółowych wątków, odsłaniając metody, które pozwalają mu osiągać tak niewyobrażalną produktywność. Jego filozofia opiera się na fundamentalnym przekonaniu: problem programowania został zasadniczo "rozwiązany" przez AI. Prawdziwa walka toczy się teraz o efektywność, automatyzację i — co najważniejsze — o zarządzanie kontekstem.
Pięć Równoległych Światów: Podstawowa Architektura Pracy
Kluczem do skalowania jest równoległość. Cherny nie korzysta z jednej sesji Claude Code. Uruchamia ich pięć jednocześnie w terminalu, każdą w osobnej, wydzielonej kopii repozytorium Git (tzw. worktree). Każda zakładka terminala ma swój numer (1-5) i dedykowane zadanie: jedna implementuje funkcję, druga uruchamia testy, trzecia przegląda kod, kolejna debuguje, a ostatnia pracuje nad dokumentacją.
To nie koniec. Poza terminalem ma otwartych od 5 do 10 dodatkowych sesji w przeglądarce na claude.ai/code. Płynnie przenosi kontekst między lokalnym a webowym środowiskiem za pomocą flagi --teleport. Rano potrafi nawet rozpocząć zadanie w aplikacji Claude na iPhonie, a dokończyć je później na komputerze. Ta "wszechobecność" agenta pozwala mu na ciągły przepływ pracy bez martwienia się o utratę kontekstu.
Opus: Wolniejszy Model, Szybsze Wyniki
Choć może się to wydawać nielogiczne, Cherny konsekwentnie używa największego i najwolniejszego modelu — Opusa z włączonym trybem „myślenia” — do absolutnie wszystkich zadań. Jego uzasadnienie jest pragmatyczne: Opus, choć generuje odpowiedzi wolniej, wymaga znacznie mniej sterowania i poprawiania przez człowieka. Jest też lepszy w korzystaniu z narzędzi (tool use).
"To najlepszy model do kodowania, jakiego kiedykolwiek używałem" – mówi. "Mimo że jest większy i wolniejszy niż Sonnet, ponieważ trzeba go mniej kierować i lepiej korzysta z narzędzi, to ostatecznie jest prawie zawsze szybszy w użyciu niż mniejszy model". Liczy się nie prędkość pojedynczej odpowiedzi, ale całkowity koszt iteracji — czas od pomysłu do działającego, zweryfikowanego kodu.
CLAUDE.md: Instytucjonalna Pamięć w Pliku Tekstowym
Najpotężniejszą, a jednocześnie najprostszą techniką Chernego jest utrzymywanie pliku z instrukcjami dla modelu. To zwykły plik Markdown trzymany w głównym repozytorium Gita, wspólny dla całego zespołu. Zawiera około 2.5 tys. tokenów i jest aktualizowany kilka razy w tygodniu. To nie jest suchy zbiór reguł stylu.
To żywy dziennik błędów i best practices. "Za każdym razem, gdy widzimy, że Claude zrobił coś niepoprawnie, dodajemy to do tego pliku, żeby wiedział, żeby tego nie robić następnym razem" – wyjaśnia Cherny. Plik zawiera wszystko: od konwencji nazewniczych ("zawsze używaj bun, nie npm"), przez wytyczne projektowe ("nigdy nie używaj enum w TypeScripcie, preferuj unie literałów stringów"), po szablony PR i instrukcje uruchamiania testów.
Mechanizm aktualizacji jest zautomatyzowany. Podczas przeglądu kodu, zamiast pisać długie komentarze, Cherny taguje @.claude i prosi: "dodaj do instrukcji, żeby zawsze preferować type nad interface". Claude Code, z pomocą specjalnej GitHub Action, samodzielnie aktualizuje plik i commituje zmianę. Cherny nazywa to „Inżynierią Składaną” (Compounding Engineering) — każdy błąd zamienia się w trwałą lekcję dla całego zespołu, poprawiając jakość przyszłych generacji kodu.
Planowanie, a Dopiero Potem Implementacja
Cherny rzadko każe Claude'owi od razu pisać kod. Zaczyna w trybie planowania (Plan Mode, uruchamianym przez dwukrotne wciśnięcie Shift+Tab). W tym trybie Claude generuje tylko plan działania, bez wprowadzania zmian w plikach. Cherny iteracyjnie doprecyzuje ten plan, grilluje go, pyta o potencjalne problemy.
Dopiero gdy plan jest solidny, przełącza się w tryb auto-akceptacji i pozwala Claude'owi wdrożyć go "jednym strzałem". To podejście minimalizuje kosztowne błędy i halucynacje. "Dobry plan jest naprawdę ważny, żeby uniknąć problemów później" – podkreśla. Jeśli w trakcie implementacji coś pójdzie nie tak, jego reakcja jest prosta: wrócić do trybu planowania i przepracować problem od nowa.
Slash Commands i Subagenci: Automatyzacja Najmniejszych Pętli
Powtarzalne czynności Cherny zamienia w skrypty i podagenty. Swoje najczęstsze workflow, jak /commit-push-pr (który wykonuje dziesiątki razy dziennie), definiuje jako slash commands w plikach w katalogu .claude/commands/. Są one współdzielone przez zespół przez Git.
Co potężne, te komendy mogą zawierać inline’owy Bash, który wykonuje się przed wysłaniem promptu do modelu. Na przykład, /commit-push-pr może najpierw sprawdzić git status, a następnie skonstruować idealny commit message na podstawie zmienionych plików, bez angażowania AI w te proste kroki.
Podobnie, subagenty to gotowe "role" dla Claude'a, przechowywane jako pliki w .claude/agents/. Cherny ma agenta code-simplifier, który czyści i refaktoryzuje kod po implementacji, czy verify-app z detalicznymi instrukcjami testowania end-to-end. Gdy chce rzucić większą moc obliczeniową na problem, po prostu dodaje do promptu "użyj 5 subagentów".
Pętla Weryfikacji: Najważniejsza Zasada
Według Chernego, to jest absolutny numer jeden. "Prawdopodobnie najważniejsza rzecz, żeby uzyskać świetne wyniki z Claude Code — daj Claude’owi sposób na zweryfikowanie jego pracy" – mówi. "Jeśli Claude ma tę pętlę sprzężenia zwrotnego, to 2-3 razy podniesie jakość końcowego rezultatu".
W praktyce oznacza to, że Claude nigdy nie kończy pracy na napisaniu kodu. Dla zmian w interfejsie claude.ai/code, Claude używa rozszerzenia Chrome, aby otworzyć przeglądarkę, przetestować zmiany UI i iterować, aż wszystko działa idealnie. Dla zmian w backendzie — uruchamia pełną suitę testów. Dla skryptów Bash — wykonuje je w suchym środowisku.
Cherny inwestuje w domenową weryfikację. Zamiast ręcznie sprawdzać każdą zmianę, buduje systemy, w których Claude sam może się przetestować. To uwalnia ludzką uwagę do zadań najwyższego poziomu: strategicznego planowania, projektowania architektury i review kluczowych fragmentów kodu.
Filozofia i Skala: Poza Era Pisania Kodu
Praktyki Chernego nie są tylko o osobistej produktywności. Reprezentują szerszą zmianę paradygmatu. Widzi on AI jako byt "zapominalski", który potrzebuje zewnętrznej pamięci — właśnie takiej jak plik z instrukcjami. Jego zespół nie skupia się już na pisaniu kodu, ale na "kodzeniu po kodowaniu": automatyzacji, inżynierii kontekstu, budowaniu pętli sprzężenia zwrotnego i sterowaniu agentami.
Skala efektu jest wymierna. Według danych, które przytacza, 4% wszystkich publicznych commitów na GitHubie jest obecnie generowanych przez Claude Code, a liczba dziennych użytkowników podwajała się w ostatnim czasie. Przewiduje, że do końca 2026 roku będzie to już 20% wszystkich commitów.
Podsumowanie: Człowiek jako Inżynier Systemu
Metoda Borisa Chernego pokazuje, że przyszłość programowania nie polega na szybszym pisaniu pętli for. Polega na projektowaniu systemów, w których AI może działać niezawodnie i samodzielnie. Klucz leży w inżynierii kontekstu (pliku z instrukcjami), automatyzacji pętli roboczych (slash commands), równoległości (worktrees) i, przede wszystkim, w zamknięciu pętli sprzężenia zwrotnego (weryfikacja).
Jego praca to nie magia, ale skrupulatne zastosowanie inżynieryjnego myślenia do samego procesu współpracy z AI. To dowód, że największą wartością programisty w erze silnej AI nie jest znajomość składni, ale umiejętność jasnego myślenia, planowania systemów i nauczania maszyny, jak nie popełniać dwa razy tego samego błędu. Jak sam to ujmuje, to już nie jest programowanie. To inżynieria składana, gdzie każda poprawka inwestuje w jakość wszystkich przyszłych zmian.
