Przyjrzyjmy się historii powstania Claude Code, która pochodzi głównie z artykułu technologicznego blogera Gergelya Orosza, w którym przeprowadza wywiad z członkami zespołu Claude Code. Claude Code jest naprawdę niesamowity, roczny przychód wynosi 500 milionów dolarów, a liczba użytkowników wzrosła dziesięciokrotnie w ciągu trzech miesięcy, obecnie jest to również ulubione narzędzie wielu programistów jako Coding Agent. To narzędzie początkowo było tylko małym zabawkowym programem w wierszu poleceń, który potrafił powiedzieć „jaką piosenkę teraz słuchasz”. 🧵

Gergely Orosz przeprowadził wywiad z trzema kluczowymi członkami zespołu Claude Code: • Inżynierem założycielem Borisem Chernym (17-letnie doświadczenie, były główny inżynier w Meta) • Inżynierem numer dwa Sid Bidasarią (autorem funkcji Subagents) • oraz menedżerem produktu Cat Wu. Rozmawiali o tym, jak Claude Code przeszedł od prototypu do produktu, jakie wybory techniczne podjęli oraz jak ten kilkunastoosobowy zespół osiąga codziennie pięć PR-ów na osobę. To może być obecnie najbliższy przykład „zespołu inżynieryjnego z priorytetem AI”. Używają AI do pisania kodu, pisania testów, przeglądania kodu, diagnozowania błędów, a nawet używają Claude Code do rozwijania samego Claude Code. 90% kodu jest pisane przez niego samego. Chcę zebrać najciekawsze części tego wywiadu, aby opowiedzieć, jak ten zespół pracuje, co można z tego zaczerpnąć, a co jest zdeterminowane przez ich szczególne warunki i nie może być bezpośrednio przeniesione. Poniżej podzielone na 7 małych historii, z których każda może być oglądana niezależnie, a razem tworzą pełny obraz.

【1】Małe narzędzie do słuchania muzyki, które stało się produktem przynoszącym 500 milionów dolarów rocznie. We wrześniu 2024 roku Boris Cherny właśnie dołączył do Anthropic i w wolnym czasie napisał małą zabawkę w wierszu poleceń. Co to potrafi? Może za pomocą AppleScript powiedzieć, jaką piosenkę aktualnie słuchasz, a także zmienić utwór na podstawie twoich poleceń. Tak proste. Sam Boris ocenił to jako: „Fajny demo, ale bez większego sensu.”

Prawdziwy zwrot akcji nastąpił po rozmowie z kolegą Cat Wu. Cat badał wtedy zdolności komputerowe AI Agenta, a w trakcie rozmowy Boris wpadł na pomysł: co jeśli damy temu narzędziu wiersza poleceń więcej uprawnień? Na przykład, aby mogło czytać i zapisywać pliki, mogło wykonywać polecenia?

On próbował. A potem nadszedł moment, aby zobaczyć cud. Boris wrzucił to ulepszone narzędzie do repozytorium kodu Anthropic i zadał kilka pytań. Claude zaczął samodzielnie eksplorować system plików — czytał plik, widział w nim instrukcje importu, a następnie podążał za nimi, czytając odwołane pliki, warstwa po warstwie, aż znalazł odpowiedź. „To mnie zszokowało,” wspomina Boris, „nigdy wcześniej nie używałem takiego narzędzia.”

W dziedzinie AI istnieje pojęcie zwane „product overhang”, co można przetłumaczyć jako „nadmiar produktu”. Oznacza to, że model w rzeczywistości posiada pewne zdolności, ale obecna forma produktu nie uwalnia tych zdolności. Boris odkrył ogromny „product overhang”, Claude już dawno mógł to zrobić, tylko nikt nie stworzył dla niego opakowania.

Boris zaczął codziennie korzystać z tego narzędzia, a następnie podzielił się nim z kilkoma współpracownikami. Dwa miesiące później, w listopadzie, opublikowali wersję wewnętrzną. Dane są imponujące: pierwszego dnia 20% inżynierów korzystało z narzędzia; piątego dnia 50%.

W tym momencie pojawiła się interesująca debata: czy powinno się to opublikować? Argumenty przeciw były bardzo przekonujące: jeśli to rzeczywiście jest tak potężne, jak myślimy, to lepiej zachować to jako "tajną broń", prawda? Dlaczego mielibyśmy oddać przewagę konkurencyjną? Ostatecznie Anthropic zdecydowało się na publikację. Logika była taka: podstawową misją Anthropic jest badanie bezpieczeństwa modeli, a najlepszym sposobem na badanie bezpieczeństwa jest umożliwienie ludziom rzeczywistego korzystania z tych narzędzi. Skoro wewnętrznie zweryfikowano, że Claude Code będzie szeroko używany, to jego publikacja może przynieść więcej wglądu w zdolności i bezpieczeństwo modelu.

W maju 2025 roku Claude Code został oficjalnie udostępniony. Trzy miesiące później, jego użycie wzrosło dziesięciokrotnie, a roczne przychody przekroczyły 500 milionów dolarów. Ciekawe jest to, że Boris początkowo myślał tylko o programistach — dlatego nazwał to „Claude Code”. Ale pewnego dnia przeszedł obok stanowiska data scientisty i zobaczył, że na jego ekranie również działa Claude Code. „Do czego tego używasz?” „Sprawiam, że pomaga mi pisać zapytania, robić wizualizacje.” Teraz każdy data scientist w Anthropic ma to na swoim stanowisku, a niektórzy mają otwartych kilka jednocześnie. Małe narzędzie do słuchania muzyki, które zyskało kilka dodatkowych uprawnień, stało się produktem wartym setki milionów dolarów. To chyba najlepszy dowód na „product overhang”, zdolności modelu zawsze tam były, tylko czekały, aż ktoś je uwolni.

【2】90% kodu jest napisane przez siebie — filozofia wyboru technologii Claude Code Claude Code ma 90% kodu napisane przez siebie. Brzmi jak chwyt marketingowy, ale to w rzeczywistości zasługa ich logiki podejmowania decyzji technologicznych. Najpierw spójrzmy na stos technologiczny: TypeScript jako główny język, React w połączeniu z frameworkiem Ink do UI terminala, otwarte źródło Meta Yoga do systemu układów, a Bun odpowiada za budowanie i pakowanie. Dlaczego wybrano te technologie? Ponieważ są "w rozkładzie". "W rozkładzie" (on distribution) to termin z dziedziny AI. Oznacza to, że model już widział dużą ilość tego typu kodu i jest w stanie sobie z nim poradzić. TypeScript i React to mocne strony Claude. Gdyby wybrano rzadki framework, model musiałby się "uczyć", co obniżyłoby efektywność. Ten wybór prowadzi do wspaniałej pętli: pisanie Claude Code przy użyciu technologii, w których Claude jest dobry, a następnie używanie Claude Code do pisania więcej Claude Code. 90% pisane przez siebie, tak to się dzieje. Ich wybór na poziomie architektury jest równie prosty. Claude Code działa lokalnie. Bez kontenerów Docker, bez chmurowych piaskownic, po prostu bezpośrednio na twoim komputerze, odczytując pliki i wykonując polecenia.

Jeśli chodzi o to, dlaczego tak zaprojektowano? Odpowiedź Borisa brzmi: „Za każdym razem, gdy podejmujemy decyzje projektowe, prawie zawsze wybieramy najprostsze rozwiązanie. Lokalne uruchomienie to najprostsza odpowiedź.” Ta prostota rozciąga się na całą filozofię produktu: pisać jak najmniej logiki biznesowej, pozwolić modelowi być głównym bohaterem. „To może brzmieć trochę dziwnie,” mówi Boris, „ale chcemy, aby użytkownicy mogli jak najbardziej „autentycznie” poczuć model. Wiele produktów AI dodaje mnóstwo rusztowań — dodatkowych elementów UI, różnych funkcji pomocniczych — co w rezultacie ogranicza możliwości modelu. To, co chcemy zrobić, to uczynić UI jak najprostszym.” Aby zachować prostotę, za każdym razem, gdy Claude wydaje nowy model, znacznie upraszczają kod. Na przykład, gdy wydano Claude 4.0, usunęli około połowy systemowych podpowiedzi, ponieważ nowy model nie potrzebował już tych „kul crutch”. Liczba narzędzi również jest stale upraszczana — co można usunąć, to usuwają, co można połączyć, to łączą. Cała architektura Claude Code można podsumować w trzech punktach: definiowanie UI i udostępnianie interfejsu do modyfikacji przez model, udostępnianie narzędzi do wywoływania przez model, a następnie odsunięcie się na bok. Oczywiście, prostota nie oznacza braku skomplikowanych elementów. System uprawnień jest wyjątkiem. W końcu pozwolenie AI na wykonywanie poleceń na twoim komputerze wiąże się z ryzykiem. Rozwiązaniem Claude Code jest zapytanie cię przed wykonaniem: czy chcesz zatwierdzić tę operację? Możesz zatwierdzić tylko raz, możesz zatwierdzić na przyszłość lub odmówić. System uprawnień obsługuje wielowarstwową konfigurację — według projektu, według użytkownika, według firmy. Zespoły mogą dzielić się plikami konfiguracyjnymi, dodając często używane polecenia bezpieczeństwa do białej listy. Zasada stojąca za tym projektem uprawnień jest następująca: jeśli uruchomisz Claude Code, nie powinien on zmieniać niczego bez twojej zgody. Ale jednocześnie, powinien dać użytkownikowi możliwość „oddelegowania” — w zaufanych sytuacjach można pominąć etap potwierdzenia. Prosto, ale nie prymitywnie. Powściągliwie, ale nie z brakiem funkcji.

【3】Dwa dni, 20 prototypów — jak wygląda iteracja produktów w erze AI Kiedyś, robiąc prototypy produktów, dwa prototypy w dwa dni uznawano za wysoką wydajność. Boris w dwa dni stworzył 20. To nie jest przesada, to prawdziwy zapis z jego pracy nad funkcją listy zadań w Claude Code. Nawet podzielił się każdym krokiem, wskazówkami i zrzutami ekranu. Przyjrzyjmy się, jak te 20 prototypów ewoluowało. W pierwszej wersji chciał, aby lista zadań była wyświetlana poniżej ostatniego wywołania narzędzia. Wskazówka była krótka: „Niech lista zadań nie pojawia się podczas wpisywania, ale niech nad polem wejściowym wyświetla się stała lista zadań, z tytułem w szarym kolorze '/todo (1 z 3)'”. Spojrzał na efekt, nie był zbyt zadowolony. W drugiej wersji zmienił to na wyświetlanie inline przy każdej aktualizacji zadania. Wskazówka: „Właściwie nie pokazuj listy zadań, zmień to na renderowanie nazwy narzędzia jako pogrubionego tytułu, gdy model zaczyna przetwarzać zadanie. Zachowaj wyświetlanie postępu w stylu 'krok 2 z 4'.” Wciąż coś było nie tak. W trzeciej i czwartej wersji próbował stworzyć „interaktywną pigułkę” — mały kwadrat na dole ekranu, który po kliknięciu pokazuje postęp. „Dodaj pigułkę z zadaniami pod polem tekstowym, w stylu zadań w tle, wyświetlając 'todos: 1 z 3'.” Następnie: „Niech ta pigułka będzie interaktywna, jak pigułka zadań w tle.” Zaczynało być ciekawie, ale to wciąż nie było wystarczająco dobre. W piątej i szóstej wersji zmienił podejście: stworzył „szufladę”, która wysuwa się z prawej strony. „Wycofaj wcześniejsze pigułki i tytuły, zmień to na wyświetlanie listy zadań po prawej stronie pola wejściowego, wyśrodkowane pionowo, oddzielone szarymi liniami.” „Trochę skacze, czy można to zrobić jako animację szuflady?” Wyglądało to całkiem fajnie, ale użyteczność była wątpliwa. W siódmej do dziewiątej wersji przeniósł listę zadań z powrotem nad pole wejściowe, testując różne sposoby przycinania i style tytułów. „Jeśli jest więcej niż 5, wyświetl '... i 4 więcej'”, „dodaj szary tytuł 'Todo:'”. Był coraz bliżej odpowiedzi. W dziesiątej do dwudziestej wersji zaczął myśleć, jak połączyć listę zadań z animacją ładowania. Ostateczne rozwiązanie polegało na umieszczeniu informacji o postępie obok spinnera (wskaźnika ładowania), maksymalizując widoczność. Po publikacji użytkownicy zgłosili, że chcą zobaczyć pełną listę zadań. Dlatego dodano kolejną iterację: naciśnij Ctrl+T, aby rozwinąć wszystkie kroki. To jest obecna wersja online.

W całym procesie, wskazówki Borisa były zaskakująco krótkie - większość z nich to jedno lub dwa zdania. Ale każda wersja to działający prototyp, a nie statyczny obrazek, nie prezentacja PPT. Może naprawdę testować i weryfikować tę funkcję, odczuwając, czy jest wygodna w użyciu. Tradycyjny proces rozwoju produktu to: pomysł → dyskusja → tworzenie wireframe'ów → robienie wysokiej jakości projektów → rozwój → testowanie → uruchomienie. Każdy krok zajmuje czas, każdy krok może utknąć. Teraz proces zmienił się na: pomysł → jednozdaniowa wskazówka → działający prototyp → jeśli coś nie pasuje, robimy nową wersję. To w rzeczywistości wymaga od deweloperów zmiany sposobu myślenia, aby dostosować się do tego procesu rozwoju. Kiedyś prototyp miał na celu „weryfikację pomysłu” - ponieważ koszt wykonania prototypu był wysoki, musiałeś najpierw dokładnie przemyśleć, zanim przystąpisz do działania. Teraz prototyp stał się „eksploracją możliwości” - ponieważ koszt wykonania prototypu jest niski, możesz najpierw coś stworzyć, a jeśli nie wyjdzie, po prostu to wyrzucić. Boris mówi, że używając Claude Code, często pomija etap tworzenia projektów graficznych i od razu robi działającą wersję, co jest bardziej intuicyjne niż cokolwiek innego. Codzienny rytm zespołu Claude Code to: każdy inżynier codziennie wprowadza około 5 PR, wewnętrznie codziennie wydawane jest 60-100 wersji, a zewnętrznie codziennie wydawana jest 1 wersja. 5 PR dziennie to w większości firm nie do pomyślenia. Uber w najcięższym okresie przebudowy potrafił wprowadzić jeden średniej wielkości PR dziennie i to było już niezłe. Narzędzia się zmieniły, rytm się zmienił, a sposób myślenia również musi się zmienić.

【4】Przeprojektowanie terminala wiersza poleceń po integracji z AI Terminal wiersza poleceń istnieje od dziesięcioleci, dlaczego teraz potrzebuje przeprojektowania? Ponieważ przed pojawieniem się LLM, terminal nie zwracał zbytniej uwagi na doświadczenie interakcji. Tradycyjny wiersz poleceń to pytanie i odpowiedź: wpisujesz polecenie, a on zwraca wynik, koniec. Brak dialogu, brak kontekstu, brak informacji zwrotnej podczas oczekiwania. Patrzysz na migający kursor, nie wiedząc, co dzieje się w tle. Claude Code to jeden z pierwszych produktów, które naprawdę musiały pomyśleć o "UX terminala". Dodali kilka drobnych szczegółów, które wydają się nieistotne, ale korzystanie z nich jest zupełnie inne. Pierwszy: wskazówki dotyczące ładowania kontekstu. Gdy model myśli, ekran może wyświetlać generowane wskazówki związane z aktualnym zadaniem: na przykład "czytam twoją strukturę kodu" lub "myślę o rozwiązaniu". To mały dotyk, ale nadaje narzędziu "osobowość". Czujesz, że pracuje poważnie, a nie utknęło. Boris powiedział, że ostatni raz widział tak przyjemną interakcję podczas procesu wprowadzania dla nowych użytkowników Slacka. Drugi: wskazówki edukacyjne podczas oczekiwania. Gdy Claude wykonuje długie zadanie, na dole ekranu będą się na przemian wyświetlać wskazówki, takie jak "możesz nacisnąć Esc, aby przerwać bieżące zadanie" lub "spróbuj /help, aby zobaczyć wszystkie polecenia". Wiersz poleceń uczy wiersza poleceń, proste i mądre. Trzecia historia jest jeszcze ciekawsza: renderer Markdown. Dzień przed wydaniem, inżynier narzekał, że zagnieżdżone listy wyglądają brzydko, a odstępy między akapitami są nieprawidłowe. Problem leżał w rendererze Markdown. Boris przetestował wszystkie dostępne renderery na rynku, żaden nie wyglądał dobrze w terminalu. Więc spędził dzień z Claude Code, pisząc od podstaw parser i renderer Markdown. Tak, dzień przed wydaniem. Tak, od podstaw. Tak, używając Claude Code. Wynikowy renderer, który powstał w pośpiechu, wyglądał lepiej niż wszystkie dostępne rozwiązania. Po prostu go opublikowali. Boris uważa, że obecnie żaden inny terminal nie ma takiej samej jakości renderowania Markdown. Ta historia pokazuje jedną rzecz: gdy masz wystarczająco dobry narzędzie do programowania AI, koszt "tworzenia własnych kół" znacznie spada. Kiedyś kompromis "może być" teraz może stać się "zróbmy lepsze". Ten stary interfejs terminala ożywa dzięki integracji LLM. Terminal to wciąż ten sam terminal, ale dzięki integracji AI musimy poważnie pomyśleć: jak lepiej rozmawiać z AI w terminalu.

【5】AI przenika do każdego etapu — eksperyment zespołu inżynieryjnego w zakresie "pełnej automatyzacji AI" Zespół inżynieryjny Anthropic może być jednym z zespołów, które najbardziej ekstremalnie wykorzystują narzędzia AI. Nie tylko w pisaniu kodu, ale we wszystkich etapach projektu. Przegląd kodu: Pierwsza runda przeglądu wszystkich PR jest przeprowadzana przez Claude Code, inżynierowie robią drugą rundę. Boris mówi, że Claude Code potrafi wykryć wiele problemów już w pierwszej rundzie. Ta funkcja była pierwotnie używana tylko wewnętrznie, ale później udostępnili ją publicznie, więc każdy może używać Claude Code do przeglądów bezpieczeństwa. Pisanie testów: Zestaw testów Claude Code jest prawie w całości napisany przez Claude Code. Boris mówi: "Kiedyś, jeśli ktoś zgłaszał PR bez testów, wahałem się, czy coś powiedzieć — czułem, że to jak czepianie się. Ale teraz, mając Claude, pisanie testów to tylko kwestia podania jednego polecenia, nie ma wymówki, żeby ich nie pisać." Reakcja na incydenty: inżynier oncall prosi Claude Code o pomoc w analizie Root Cause (najbardziej podstawowej przyczyny problemu). Potrafi on wyciągnąć odpowiednie dyskusje z Slacka, pobrać logi błędów z Sentry, z różnych systemów monitorujących pobrać dane, a następnie przeprowadzić analizę. Boris mówi, że Claude Code w niektórych sytuacjach znajduje Root Cause szybciej niż ludzie. Przekierowanie zgłoszeń GitHub: Za każdym razem, gdy pojawia się nowe zgłoszenie, Claude Code najpierw przeprowadza analizę, a następnie inżynier pyta go "czy można to zrealizować". Boris mówi, że w około 20%-40% przypadków udaje mu się to za pierwszym razem. Wykresy i zapytania: Dane produktowe znajdują się w BigQuery, prawie wszystkie zapytania i wizualizacje są generowane przez Claude Code. Inżynierowie nawet proszą go o bezpośrednie generowanie wykresów ASCII.

Najbardziej zaskoczyło mnie odrodzenie TDD (rozwoju napędzanego testami). TDD to stara koncepcja: najpierw piszesz testy, a potem piszesz kod, który przechodzi te testy. Teoretycznie brzmi to pięknie — zmusza cię do przemyślenia, czego naprawdę chcesz. Ale w praktyce większość ludzi uważa, że to zbyt wolne i zbyt uciążliwe, więc ta metoda powoli marginalizowała się przez ostatnie kilkanaście lat. Ale Boris mówi, że po użyciu Claude Code zrobił mnóstwo TDD: „Najpierw każę modelowi napisać test, jednocześnie mówiąc mu, że ten test teraz nie przejdzie, niech nie próbuje go przechodzić. Potem każę mu napisać kod, aby zrealizować funkcjonalność i sprawić, by test przeszedł, ale nie może zmieniać samego testu.” „Kiedy model ma wyraźny cel do iteracji — na przykład test jednostkowy lub mock — radzi sobie bardzo dobrze.” Szczególnie podkreślił, że Claude 4.0 to pierwsza seria modeli, która pozwala modelowi napisać większość testów. Poprzednie wersje mogły napisać część, ale wymagały dużej interwencji człowieka. Jest też nowa koncepcja: multi-clauding. Oznacza to jednoczesne uruchamianie wielu instancji Claude Code, aby mogły równolegle przetwarzać różne zadania. Sid mówi, że często tak robi — uruchamia kilka agentów podczas spotkania, a potem wraca, aby zobaczyć wyniki. Anthropic odkrył, że 25% subskrybentów Max (premium użytkownicy płacący miesięcznie 100-200 dolarów) codziennie korzysta z multi-clauding. To bardzo interesująca zmiana. Programowanie zawsze było „jednowątkową” działalnością: możesz robić tylko jedną rzecz na raz, a dopiero podczas przeglądu kodu lub wdrożenia zmieniasz zadania. Ale teraz „programowanie równoległe” stało się możliwe — możesz jednocześnie posuwać do przodu kilka rzeczy. Oczywiście jest tu wiele niewiadomych: czy praca równoległa jest naprawdę bardziej efektywna, czy tylko wydaje się bardziej efektywna? Jakie rodzaje zadań nadają się do pracy równoległej? Czy mniejsza uwaga przydzielona każdemu agentowi nie spowoduje problemów? Na te pytania nie ma jeszcze odpowiedzi. Ale mamy nowe narzędzie do eksperymentowania. Na koniec opowiem o jednym przypadku. Pewna firma miała przeprowadzić migrację frameworka, pierwotnie szacując, że zajmie to dwa lata inżynieryjne — jeden inżynier przez dwa lata lub dziesięciu inżynierów przez dwa i pół miesiąca. Użyli Claude Code, a jeden inżynier załatwił to w dwa tygodnie. Boris mówi, że wcześniej byłby sceptyczny wobec takich stwierdzeń, ale słyszeli już zbyt wiele podobnych historii.

【6】Trzydniowy hackathon — jak powstała funkcja Subagents Funkcja Subagents zainspirowana została postem na Reddit. Ktoś napisał, że uruchomił pięć instancji Claude Code, nadając każdej z nich różne role, a następnie użył systemu plików, aby umożliwić im komunikację. Kiedy Sid Bidasaria zobaczył ten post, jego pierwsza reakcja brzmiała: to świetny pomysł, ale użytkownicy nie powinni musieć się tak męczyć. Powinniśmy to zrobić jako wbudowaną funkcję produktu. Akurat w firmie odbywał się trzydniowy wewnętrzny hackathon, więc Sid postanowił wykorzystać te trzy dni na realizację tego pomysłu. Pierwszego dnia zespół z entuzjazmem narysował różne skomplikowane struktury topologiczne Agentów: Agenci komunikujący się za pomocą magistrali wiadomości, w trybie asynchronicznym, interakcje wiele do wielu… Rysunki były piękne, a koncepcja bardzo nowoczesna. Drugiego dnia zdali sobie sprawę, że to może być niewykonalne. Problem nie leżał w technicznej realizacji — te skomplikowane modele można zrealizować. Problem polegał na tym, że użytkownicy nie będą w stanie tego zrozumieć. Interfejs użytkownika Claude Code to po prostu prosty terminal, jak można w tak prostym interfejsie sprawić, by użytkownicy zrozumieli te skomplikowane modele komunikacji Agentów? Postanowili zacząć od nowa, wracając do podstawowego pytania: jaka jest najprostsza forma, którą mogą wykorzystać zwykli deweloperzy? Ustalili dla siebie dwa ograniczenia: Po pierwsze, nie wymyślać nic nowego. Używać tylko istniejących możliwości Claude Code — komendy „/” i pliki .md. Po drugie, nie robić komunikacji między Agentami. Zmienić to na prosty model orkiestracji: jest główny Agent, który może wywoływać podagenty, a podagenty po wykonaniu zadania zwracają wyniki, i to wszystko. Rozmawiali również z zespołem badawczym Anthropic. Naukowcy badali model wielu Agentów, ale wnioski były takie, że nie ma jeszcze jednoznacznej odpowiedzi na pytanie, czy skomplikowane topologie Agentów są naprawdę skuteczne. To dodało im więcej pewności: skoro nawet zespół badawczy mówi, że skomplikowane niekoniecznie jest lepsze, to tym bardziej powinni zrobić prostszą wersję. Na koniec trzeciego dnia stworzyli działającą wersję. Użytkownicy mogą w plikach .md definiować role i możliwości podagentów (na przykład „podagent front-end: używający React 19 i Next.js”), Claude Code wywoła je w odpowiednim momencie, lub użytkownicy mogą je ręcznie uruchomić. Po zakończeniu hackathonu, po drobnych poprawkach, funkcja została uruchomiona. Teraz możesz definiować różne dedykowane podagenty: backendowy Agent z ekspertyzą w audycie bezpieczeństwa, frontendowy Agent znający konkretne frameworki, Agent QA specjalizujący się w pisaniu testów… Mogą pracować równolegle w tle, każdy w swojej roli. Wiele zespołów na hackathonie nie chce porzucić swoich skomplikowanych rozwiązań, w końcu spędzili cały dzień na rysowaniu i dyskutowaniu, mają do tego emocjonalny stosunek. Uznanie, że „ta droga nie prowadzi do celu” i rozpoczęcie od nowa wymaga odwagi oraz wiary w „prostotę”. Prostota nie jest lenistwem. Prostota polega na znalezieniu w niezliczonych możliwościach formy, którą użytkownik naprawdę może wykorzystać.

【7】Jak będą wyglądać zespoły inżynieryjne w przyszłości? Niektóre rzeczy można naśladować, a inne nie. Boris powiedział: „Programowanie jest teraz niesamowicie interesujące. Ostatni raz miałem takie uczucie, gdy w szkole średniej pisałem kod na kalkulatorze graficznym. To magiczne uczucie, którego nie doświadczyłem od dłuższego czasu, ale teraz wróciło.” Sid ma podobne odczucia: „Są dwie rzeczy, które mnie ekscytują. Po pierwsze, szybkość, z jaką publikujemy – czasami wydaje się, że jest zbyt szybka. Po drugie, ogromna przestrzeń do eksperymentowania – wcześniejsze prace były szybkie, ale to, co robiliśmy, było dość schematyczne, wiedzieliśmy, co jest odpowiedzią, po prostu to realizowaliśmy. Teraz jest inaczej, model zmienia się co trzy miesiące, musimy ciągle na nowo przemyśleć, jak działać.” Te odczucia są bardzo autentyczne i zaraźliwe. Jednak przed dyskusją na temat „jak będą wyglądać zespoły inżynieryjne w przyszłości” nie zapominajmy o specyfice Anthropic. Po pierwsze, Anthropic to laboratorium badawcze, a nie firma produktowa. Jego główną misją jest badanie bezpieczeństwa i możliwości AI, a produkty są środkiem, a nie celem. Oznacza to, że mają znacznie wyższą tolerancję na „szybkie eksperymenty” niż przeciętne firmy. Po drugie, ich głównym produktem jest sam model Claude. Claude Code to tylko „opakowanie” modelu. Dlatego „usunięcie kodu, aby model mógł robić więcej” jest dla nich naturalnym wyborem, ale dla innych firm może oznaczać oddanie kluczowej logiki biznesowej do czarnej skrzynki. Po trzecie, wszyscy pracownicy mają nieograniczony dostęp do Claude, w tym najdroższego modelu Opus. W większości firm opłata za subskrypcję AI jest budżetowanym projektem, do którego nie można mieć dostępu dla wszystkich. Po czwarte, zespół liczy tylko kilkanaście osób, a procesy są bardzo uproszczone. Prawie nie używają flag funkcji, ponieważ „to zbyt wolne”. To jest nie do pomyślenia w produktach z dużą bazą użytkowników i wysokimi kosztami błędów. Dlatego bezpośrednie kopiowanie metod zespołu Claude Code niekoniecznie jest realistyczne dla większości zespołów. Jednak niektóre rzeczy można naśladować. Sposób myślenia o szybkim prototypowaniu: nawet jeśli nie możesz robić 10 prototypów dziennie, czy możesz przejść z „jednego co dwa tygodnie” na „trzy w tygodniu”? Narzędzia się zmieniły, więc oczekiwania co do „jak szybko powinny być prototypy” również powinny się zaktualizować. AI wspomagająca przegląd kodu: niech AI przeprowadzi pierwszą rundę przeglądu, a człowiek drugą. Ten proces nie zależy od nieograniczonego dostępu do API, więc większość zespołów może spróbować. Ożywienie TDD: jeśli pisanie testów stanie się wystarczająco łatwe, to „nie ma czasu na pisanie testów” przestanie być wymówką. To może być niski koszt punktu wejścia do poprawy jakości kodu. Wartość inżyniera z poczuciem produktu: zespół Claude Code nie ma projektantów ani PM-ów, polega tylko na kilku inżynierach z poczuciem produktu. Narzędzia AI znacznie rozszerzyły to, co mogą robić tacy „wszechstronni specjaliści.”

Oczywiście, są też rzeczy, których nie da się zastąpić narzędziami. Boris potrafi wybrać najlepszy prototyp spośród 20, ponieważ ma wyczucie — wie, co "wydaje się odpowiednie", a co tylko "wygląda na użyteczne". Ten gust to efekt 17-letniego doświadczenia w programowaniu, którego AI nie może dostarczyć. Zespół pierwszego dnia stworzył skomplikowany projekt, a drugiego dnia potrafił z determinacją wszystko zburzyć i zacząć od nowa — ta zdolność do podejmowania decyzji również należy do ludzkiego osądu. Wiedza, kiedy usunąć kod, a kiedy go zostawić, to również taka intuicja architektoniczna. AI przyspiesza wykonanie, ale nie uprościło kwestii "wiedzieć, co robić". Wręcz przeciwnie, ponieważ koszty wykonania spadły, decyzje dotyczące "co robić" stały się ważniejsze — możesz szybko stworzyć 20 wersji, ale musisz wiedzieć, która jest właściwa. Jak będzie wyglądać inżynieria oprogramowania za kilka lat? Nikt nie potrafi tego dokładnie przewidzieć. Ale dzisiejszy zespół Claude Code może być pewnym przedsmakiem tego, co czeka wiele zespołów jutro — szybsze iteracje, mniej "pracy ręcznej", więcej osądów i decyzji. Narzędzia się zmieniają. Nie zmienia się to, że ostatecznie decyzje podejmują ludzie.