Demo zamiast dokumentacji – jak naprawdę działa zespół AI Native w Anthropic? #EN276

TL:TR

• Demo zamiast dokumentacji – Inżynierowie prototypują pomysły i od razu oddają je do wewnętrznych testów, zamiast tworzyć obszerne specyfikacje
• Kod jako jedyne źródło prawdy – Zespół świadomie unika Google Docs, ponieważ wiedza o produkcie zawarta jest w kodzie, a AI pomaga ją syntezować
• Intensywne testy wewnętrzne – Kluczowym elementem walidacji jest wewnętrzny kanał na Slacku z ponad 1000 pracowników przekazujących regularnie feedback
• Krytyczne opinie są na wagę złota – Zespół aktywnie prosi kluczowych klientów o krytykę, a na priorytetowe błędy reaguje w ciągu jednego do dwóch tygodni
• Płynne role w zespole – Menedżerka produktu i projektantka regularnie zatwierdzają zmiany w kodzie dzięki AI
• Traktowanie AI jak zdolnego stażysty – Zamiast poddawać się po pierwszej porażce, należy korygować błędy AI dawając mu feedback
• Krótki horyzont planowania – W dynamicznym świecie AI zespół planuje w perspektywie kilku miesięcy, a nie lat

Od eksperymentu do produktu – jak powstał Claude Code

Historia Claude Code nie zaczęła się od wielkiej strategii odgórnej. Boris, jeden z inżynierów, chciał lepiej zrozumieć firmowe API i stworzyć narzędzie do augmentacji swojej pracy programistycznej. Zaczął eksperymentować, tworząc prototyp dla własnych potrzeb.

Wtedy Cat Wu spędzała 20% czasu dodając środowiska RL (reinforcement learning) i odkryła, że Claude Code znacznie zwiększa jej wydajność oraz świetnie integruje się z wewnętrznymi narzędziami. Zaczęła wysyłać Borisowi feedback produktowy – sugestie co zmienić w narzędziu.

Narzędzie zaczęło rozprzestrzeniać się organicznie – najpierw używali go inni w zespole Borisa, potem cała organizacja, następnie research, wreszcie przekroczyło granice ról ściśle technicznych, trafiając do data science, product management i product design. Miało wysoki współczynnik wiralności wewnątrz firmy jeszcze przed publicznym uruchomieniem.

Gdy zapadła decyzja o wypuszczeniu na zewnątrz, Cat Wu była podekscytowana możliwością pracy nad tym pełnoetatowo. Od tamtej pory Claude Code został szeroko adoptowany zewnętrznie, a zespół ciągle inwestuje w rozwój funkcji, pracę z heterogenicznymi środowiskami developerskimi oraz większą dostępność.

Terminal jako filozofia – mniej znaczy więcej

Wybór terminala jako interfejsu był świadomą decyzją designerską. Poprzez terminal Claude Code ma dostęp do wszystkiego czym dysponuje developer – GitHub CLI, Datadog CLI, dosłownie każde narzędzie CLI. To sprawia, że wprowadzenie do narzędzia jest błyskawiczne – jeśli wiesz jak używać jakiegokolwiek CLI tool, od razu rozumiesz możliwości Claude Code.

Terminal to również najbardziej minimalistyczna forma interfejsu. Ograniczenia są znaczące: tylko ASCII, tyle znaków ile zmieści się na ekranie, brak możliwości dodania przycisków. Jak wyjaśnia Cat Wu, w rezultacie zespół stał się bardzo pragmatyczny i wręcz brutalny w decyzjach które funkcje pokazać, a które ukryć.

Ta ograniczona przestrzeń ekranu sprawia, że aplikacja jest lekka i nie przytłacza na starcie. Równocześnie, dzięki rozszerzalności, oferuje nieograniczoną głębokość gdy użytkownik się zagłębi.

Filozofia „zero onboardingu”: dla nowych funkcji nie powinno być żadnego wdrożenia. Funkcja powinna być intuicyjna poprzez nazwę i jednoliniowy opis – użytkownik powinien móc natychmiast zacząć bez samouczków czy skomplikowanych instrukcji.

Prototyp zamiast dokumentu – filozofia szybkich iteracji

Najlepsze funkcje Claude Code powstały gdy inżynier zbudował prototyp, wypuścił go do wewnętrznego testowania i po prostu słuchał feedbacku. Nie było potrzeby pisania PRD czy przeprowadzania formalnych przeglądów.

Proces przebiega następująco: inżynier ma pomysł, buduje go, następnie wypuszcza do wewnętrznego testowania dla około tysiąca pracowników Anthropic. Potem zespół obserwuje reakcje – czy ludzie natychmiast rozumieją funkcję? Może są zdezorientowani? A może po prostu to uwielbiają?

Wiele funkcji przeszło przez 2-3 iteracje wewnętrznie, zanim trafiły do publicznej wersji. Co więcej, jeszcze więcej funkcji zostało po prostu porzuconych, ponieważ nie sprawdziły się w praktyce.

Rola PM w takim setupie jest specyficzna. PM dla developer tools musi akceptować, że developer jest końcowym użytkownikiem. Zadaniem PM-a jest wyznaczanie szerszego kierunku oraz dbanie o to, żeby produkt był dostępny dla świata. W erze narzędzi AI duża część roli PM to również pricing i packaging – upewnienie się, że developerzy mogą skupić się na tworzeniu najlepszego coding experience.

Dla większych projektów istnieje formalny przegląd. Przykładem są integracje z VS Code i IntelliJ, które były świadomą decyzją zespołu chcącego spotkać ludzi tam gdzie pracują i mieć więcej kontekstu o ich narzędziach. Praca trwała kilka miesięcy, jednak dla mniejszych funkcji jak lista zadań czy plan mode PRD nie był potrzebny. Trudność polega bowiem na znalezieniu właściwej formy poprzez promptowanie, nie na wyzwaniu integracyjnym.

Rozszerzalność jako strategia, nie funkcja

Hooks, custom slash commands i sub agents to nie tylko funkcje, lecz fundamentalna strategia. Środowiska developerskie są bowiem bardzo różne, dlatego zespół chce zapewnić narzędzia umożliwiające każdemu inżynierowi oraz zespołowi odpowiedzialnemu za produktywność dostosowanie Claude Code do swojej konfiguracji.

To właśnie dlatego zespół rozwija hooks (dla notyfikacji i integracji), custom commands (dla specyficznych workflow) oraz sub agents (dla specjalizowanych zadań).

Historia listy zadań – gdy model zapominał o 25 taskach

Sid, inżynier w zespole, zauważył problem: ludzie używali Claude Code do refaktoringu lub zmiany nazw zmiennych – zadań wymagających 20-30 zmian. Claude Code robił pierwsze 5 i zapominał o reszcie.

Sid wpadł na genialny pomysł: zmusić model do zapisania swoich zadań, dokładnie tak jak robi to człowiek podczas dnia. Zespół był totalnie zaskoczony rezultatem – samo zmuszenie modelu do zapisania zadań i przypomnienie „nie możesz przestać dopóki nie skończysz” sprawiło, że model wykonywał wszystkie 20-30 itemów bez wcześniejszego stopowania.

Na początku lista zadań była tylko w transkrypcie i przelatywała po ekranie. Ludzie jednak używali jej do śledzenia postępu modelu, co oznaczało, że musi być bardziej trwała – inaczej użytkownicy patrzący na terminal nie wiedzą nad czym agent pracuje.

Boris potem eksperymentował z różnymi formatami, żeby lista była bardziej widoczna, jednak niektóre rozwiązania (jak wrzucenie do „thinking bubbles”) nie zyskały akceptacji użytkowników.

Feedback jako kompas rozwoju produktu

Wewnętrzny chat z około tysiącem pracowników Anthropic, którzy dobrowolnie się dołączyli, stanowi główne źródło informacji zwrotnej. To nie default membership – ludzie muszą świadomie zdecydować się na udział. Nowa informacja zwrotna pojawia się średnio co 10 minut i zawsze jest wysokiej jakości.

Dodatkowo zespół ściśle współpracuje z około 10 firmami enterprise, którym wprost komunikuje: „Bądźcie jak najbardziej głośni. Jeśli coś nie działa, piszcie. Może nie naprawimy tego natychmiast, ale chcemy o tym wiedzieć.”

Cat Wu jest bardzo szczera co do oczekiwań: „Nie chcemy uprzejmości. Chcemy słyszeć, co nie działa.”

Priorytetyzacja przy tak dużym wolumenie feedbacku nie stanowi problemu. Gdy coś jest naprawdę ważne, zespół usłyszy o tym 10 razy. Pojawi się zgłoszenie na GitHubie ze 100 thumbs up, a zespół sprzedażowy napisze, że trzech klientów ma problem. Priorytety same się wyłaniają.

Claude Code w zarządzaniu feedbackiem:

• Syntezowanie opinii ze Slacka poprzez zapytania typu „którzy klienci pytali o customizację modeli?”
• Automatyczne usuwanie duplikatów zgłoszeń na GitHubie (często występuje 5+ duplikatów)
• Tworzenie pierwszego draftu dokumentacji (człowiek sprawdza ostatnie 10%)
• Szybkie informowanie właściwych osób o nowych funkcjach

Baza kodu jako jedyne źródło prawdy

Zespół Claude Code praktycznie nie używa Google Docs. Cała baza kodu jest na tyle mała, że jeśli chcesz wiedzieć dlaczego zbudowano daną funkcję, wystarczy zapytać Claude Code i znajdzie oryginalny PR z wyjaśnieniem.

Podczas gdy normalne zespoły używają Google Docs do dokumentowania funkcjonalności oraz powodów stojących za decyzjami, w Claude Code „dlaczego” często znajduje się po prostu w PR. Ponieważ baza kodu jest niewielka, zapytanie Claude Code zainicjalizowanego w tym repo jest szybsze i dokładniejsze niż czytanie dokumentu, który może być już nieaktualny.

To podejście ma dodatkowy benefit – wszyscy w zespole mogą zatwierdzać zmiany w kodzie, nawet designer Megan, która wcześniej nigdy tego nie robiła. Gdy zaczęła używać Claude Code, rozpoczęła tworzenie PRów do Console (systemu zarządzania kluczami API) oraz do samego Claude Code.

Cat Wu również zatwierdza kod, gdy to ma sens. Podczas współpracy z Rickiem Rubinem nad vibe coding, brand team chciał dodać komendę „vibe” z fragmentami jego pism. Łatwiej było Cat Wu to zrobić samej niż delegować zadanie komuś innemu.

Claude Code ułatwia również weryfikację skomplikowanych przepływów. Przy różnych warunkach dla różnych planów (max plan, 1P API, 3P API, enterprise) wystarczy zapytać: „prześledź kod dla każdego przypadku i powiedz co się dzieje” – można wtedy czuć się pewnie co do dokładności.

Evals – trudna sztuka mierzenia AI

Cat Wu bardzo otwarcie mówi o trudnościach z evals, przyznając bez ogródek: „Evals są naprawdę trudne.”

Zespół dba o dwa główne typy testów. End-to-end evals polegają na uruchamianiu SWE-bench na nowych wersjach Claude Code w celu sprawdzenia czy wydajność nie spadła. Problem? Jeśli wynik się zmienia, nie zawsze wiadomo dlaczego, dlatego trzeba przeczytać setki trudnych transkryptów, żeby znaleźć wzorce.

Triggering evals są znacznie prostsze – sprawdzają czy Claude Code podejmuje właściwe decyzje o użyciu narzędzi. Przykładowo, wyszukiwanie w sieci nie powinno się włączać za każdym razem, ale powinno aktywować się gdy pytasz o najnowszy release React i nowe funkcjonalności. Tutaj łatwo stworzyć eval i ocenić czy zadziałało.

Najtrudniejsze są capability evals. Aby sprawdzić czy nowy harness jest lepszy w data science, potrzebny jest setup podobny do SWE-bench – z dużym zbiorem danych, możliwością pisania i iterowania zapytań, wzorcową odpowiedzią oraz zerową niejednoznacnością co do poprawnej odpowiedzi.

Dla triggering evals Cat Wu radzi: zacznij od skrajności – przypadki gdzie coś absolutnie powinno lub nie powinno się wydarzyć, natomiast szare strefy zostaw na później.

Zabawny przykład – lista zadań czasem tworzyła się dla jednego zadania, a potem była od razu odhaczana. Ewidentnie niepotrzebne, dlatego eval mógłby sprawdzać czy lista ma minimum 3-5 itemów albo czy w ogóle się nie tworzy dla pojedynczych zadań.

Prawda jest jednak taka, że przy tak zaangażowanej społeczności użytkownicy i tak pilnują jakości. Nawet dla listy zadań zespół spędził sporo czasu upewniając się że triggering działa dobrze.

Planowanie w erze szybkich zmian

Gdy pada pytanie o wizję na rok czy dwa, Cat Wu odpowiada szczerze: „Rok czy dwa to naprawdę długi czas.” Może natomiast powiedzieć o najbliższych miesiącach.

Modele zmieniają się tak szybko, że trudno przewidzieć więcej niż 6 miesięcy do przodu. Ważne jest budowanie produktów na następną generację modeli, jednak te możliwości nie stają się oczywiste dopóki nie są parę miesięcy przed wydaniem.

Zespół jest bardzo pragmatyczny – buduje produkty, które chcieliby mieć dziś, dlatego fokus utrzymuje się na 3-6 miesiącach, nie latach.

Trzy filary rozwoju:

• CLI – najbardziej potężny agent kodujący, ultra konfigurowalny dla każdego środowiska developerskiego
• SDK – więcej agentów w świecie (nie tylko coding, lecz również legal, EA, health, financial assistance)
• Dostępność – wyjście poza terminal, najpierw role tech-adjacent (data science, PM, design), następnie marketing i sprzedaż

Trzy zasady maksymalnego wykorzystania Claude Code

Cat Wu dzieli się konkretnymi wskazówkami z własnego doświadczenia:

Demos, not docs Claude Code sprawia, że robienie prototypów jest tak łatwe, że zamiast pisać wielostronicowy dokument „czy powinniśmy zbudować tę funkcję?”, lepiej zapytać czy Claude Code może zrobić prototyp. Wtedy od razu poczujesz czy to jest użyteczne.

Traktuj Claude Code jak entuzjastycznego juniora Narzędzie jest bardzo responsywne na feedback. Ludzie czasem dają ambitny prompt, a gdy Claude Code robi błędne założenia, po prostu się poddają. Zamiast tego należy po prostu powiedzieć że robi coś źle, dokładnie jak udzieliłbyś informacji zwrotnej człowiekowi. Claude Code się dostosuje i zmieni kierunek.

Zainwestuj w plik CloudMD To jest pamięć Claude Code – każda sesja się z tym zaczyna. Można to traktować jak wdrożenie inżyniera, dlatego powinno zawierać wszystko co powiedziałbyś nowej osobie w bazie kodu: architekturę, pułapki, sposób testowania, metodę weryfikacji pracy – wszystko co nowemu pracownikowi.

Możesz mieć globalny osobisty CloudMD dla wszystkich projektów (opisujący kim jesteś i twoją rolę) oraz specyficzne dla każdego repo. W przypadku Megan, designer, jej CloudMD komunikuje: „jestem product designerem, musisz wszystko mi bardzo szczegółowo wytłumaczyć.”

Historie z życia zespołu, które warto znać

Easter egg z naklejkami – gdy ktoś przypadkiem wspomniał o „swag” czy „stickers” podczas używania Claude Code, agent automatycznie wysyłał link do portalu gdzie można było podać adres i zamówić darmowe naklejki. Ktoś odkrył ten mechanizm w source maps i zespół dostał 500 zgłoszeń. Mimo to zamiast zignorować prośby, cały wieczór spędzili na pakowaniu i wysyłaniu naklejek, co pokazuje ich autentyczne zaangażowanie w społeczność. Planowali, że 12 osób wyśle je w godzinę, jednak zamiast tego spędzili 8 godzin, przy czym zamówili jedzenie zamiast robić planowane pierogi.

Kontrowersja wokół plan mode – zespół początkowo opierał się dodawaniu tej funkcji, ponieważ chcieli uczyć użytkowników wyrażania potrzeb w naturalnym języku (wtedy Claude i tak robi plan). Przez dwa miesiące ludzie jednak tak bardzo chcieli wyraźnego skrótu, że zespół „poddał się” i dodał explicit plan mode. W przyszłości, gdy model będzie lepiej słuchał takich instrukcji, mogą usunąć tę funkcję.

Ludzkie godziny vs AI godziny – Claude Code często oszacuje zadanie na „dwa tygodnie”, a następnie zrobi to w 10 minut. Model cytuje „human hours” bo tylko takie widział w internecie, dlatego zespół musi nauczyć go lepszego wyczucia czasu.

Praktyczne prompty i polecenia – jak zespół rzeczywiście używa Claude Code

Zarządzanie feedbackiem i research

Szukanie powiązanych opinii:

"Which other customers have asked for [feature name]?"

Użyj gdy: Chcesz wiedzieć kto będzie zainteresowany nową funkcją przed jej wypuszczeniem

Sprawdzanie zgłoszeń na GitHubie:

"Look at our GitHub issues and see if there's any GitHub issues about [topic]"

Użyj gdy: Musisz zamknąć wszystkie powiązane zgłoszenia po zaimplementowaniu funkcji

Znajdowanie kontekstu decyzji:

"What was the original inspiration for [feature]? Search GitHub"

Użyj gdy: Chcesz zrozumieć historię i uzasadnienie za danym rozwiązaniem

Weryfikacja i audyt kodu

Śledzenie przez różne scenariusze:

"Trace the code for each of these [scenarios] and tell me exactly what happens"

Użyj gdy: Masz skomplikowane przepływy z wieloma warunkami i chcesz upewnić się że wszystko działa poprawnie

Wdrażanie i nauka

Dla kompletnych nowicjuszy:

"Build an app"

Po czym, gdy nie wiesz co dalej:

"How do I run this?"

Użyj gdy: Wdrażasz osobę bez technicznego backgroundu – pozwól im zobaczyć że mogą pytać o wszystko

Research z kontekstem:

"What was the latest [technology] release and what new functionality is available there?"

Użyj gdy: Potrzebujesz aktualnych informacji + włączasz wyszukiwanie w sieci automatycznie

Planowanie i dekompozycja zadań

Żądanie dla plan mode:

"Tell me what you're going to do, but don't write code yet"

Użyj gdy: Chcesz najpierw zobaczyć plan działania przed wykonaniem

Dla dużych refaktorów: Nie potrzebujesz specjalnego prompta – Claude Code sam stworzy listę zadań dla prac wymagających 20-30 zmian Użyj gdy: Robisz refactoring, zmieniasz nazwy zmiennych lub wykonujesz inne zadania wymagające wielu kroków

Dostosowanie i personalizacja

W pliku CloudMD:

"I'm a product designer, you gotta over explain everything to me"

Użyj gdy: Jesteś w roli nietechnicznej i potrzebujesz bardzo szczegółowych wyjaśnień

Przykład custom command:

/vibe

Użyj gdy: Chcesz szybki dostęp do inspiracji lub wytycznych

Debugowanie i rozwiązywanie problemów

Gdy coś nie działa:

"This is wrong because [reason]. Please fix it by [suggestion]"

Użyj gdy: Model zrobił błędne założenie – nie poddawaj się, tylko daj jasną informację zwrotną

Kluczowa zasada

Najważniejsze to pamiętać że Claude Code jest „eager to please” – bardzo responsywny na feedback. Większość ludzi robi jeden ambitny prompt i gdy model robi błędne założenia, się poddają. Zamiast tego należy iterować, dawać feedback oraz traktować jak osobę która chce pomóc, ale potrzebuje wskazówek.

Najważniejsza umiejętność AI PM

Najtrudniejsza i najrzadsza umiejętność AI PM to silna intuicja co do możliwości modeli.

Evals są trudne, dlatego w dużej mierze sprowadza się to do intuicji. Jeśli chcesz zbudować funkcję, musisz mieć dobre wyczucie czy model jest w stanie ją obsłużyć. Jeśli nie – jak daleko? Model jest 80% gotowy i możesz wypromptować ostatnie 20%? Czy dopiero 10% i lepiej wrócić za 3-6 miesięcy?

Musisz wiedzieć – jeśli model zawodzi, czy to kwestia złego kontekstu, niewłaściwego modelu do zadania, czy model po prostu nie jest w stanie? To najbardziej wartościowa umiejętność.

Co zespół szuka w nowym PM

Cat Wu rekrutuje PM do zespołu Claude Code. Wymagania:

• Uwielbianie developerów (idealnie sam byłeś developerem)
• Bycie zaawansowanym użytkownikiem Claude Code
• Chęć zapewnienia że SDK jest najlepszym sposobem na budowanie agentów
• Pragnienie rozwijania ekosystemu – hub gdzie ludzie dzielą się customizacjami

W wywiadzie proszą o poświęcenie czasu na poznanie produktu oraz krytykę – co można ulepszyć. To wystarcza żeby zobaczyć jak bardzo ktoś jest zaangażowany w narzędzie.

Kluczowy insight

Dokumentacja to Dług Techniczny

Standardowo myślimy: Im więcej piszemy dokumentacji (specyfikacji, PRD, wiki), tym lepiej zespół rozumie produkt i tym łatwiej będzie go rozwijać w przyszłości.

W praktyce okazuje się, że: Aktualna, zrozumiała baza kodu jest jedynym trwałym źródłem prawdy. Zamiast pisać dokumentację, która szybko staje się nieaktualna, lepiej inwestować w czysty kod i używać AI do jego syntezy na żądanie.

Dlaczego to jest istotne: Traktowanie dokumentacji jako aktywa prowadzi do marnowania czasu na jej synchronizację i podejmowania decyzji na podstawie przestarzałych informacji. Zmiana myślenia uwalnia zasoby i zapewnia, że zespół zawsze opiera się na faktycznym stanie produktu.

Test na jutro: Następnym razem gdy ktoś w zespole zapyta „Jak działa funkcja X?”, zamiast odsyłać go do strony w Confluence, spróbujcie razem zadać to pytanie agentowi AI (np. Claude Code) w repozytorium projektu i sprawdźcie, czy odpowiedź oparta na kodzie jest szybsza i bardziej precyzyjna niż przestarzała dokumentacja.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Inside Claude Code: How an AI Native Team Actually Works | Cat Wu