Claude Code New Features, Explained

O czym jest ten film

Autor twierdzi, że większość ludzi używa Claude Code źle — jak czatu, a nie jak systemu operacyjnego firmy.
Proponuje analogię: skonfiguruj Claude Code tak, jak wdrażasz nowego pracownika — dając mu miejsce pracy, pamięć, zadania i granice.
Dziewięć obszarów do opanowania: workspace, pamięć, brief (plan mode), ticket, „oczy”, review, harmonogram, uprawnienia oraz skills/connectors/hooks.
Konkretna struktura repozytorium: foldery app, context, customers, demos, routines plus trzy pliki: claude.md, roadmap.md, review.md.
Gotowe prompty do stworzenia i optymalizacji każdego z tych plików — autor pokazuje je na żywo na przykładzie produktu dla salonów medycyny estetycznej.
Plan mode jako obowiązkowy krok przed każdą istotną zmianą: „mierz dwa razy, tnij raz”.
„Oczy” — Claude potrafi uruchomić aplikację, klikać przez flow, sprawdzać konsolę i bazę, i ocenić produkt z perspektywy klienta.
Rutyny (routines) — cykliczne zadania typu poranny brief i piątkowy przegląd operacyjny, czyli „nocna zmiana”.
Praca równoległa w osobnych sesjach z izolacją drzew roboczych — kilka niezależnych zadań naraz, każde z osobnym raportem.
Model uprawnień w trzech warstwach (bezpieczne / zapytaj najpierw / tylko człowiek) oraz siedmiodniowy plan wdrożenia całości.

Redakcyjne tłumaczenie

Dlaczego większość ludzi używa Claude Code źle

Uważam, że bardzo wiele osób używa Claude Code w niewłaściwy sposób. A używają go źle dlatego, że jest to jedno z najpotężniejszych narzędzi, jakie kiedykolwiek powstały — i istnieje sposób, żeby uruchomić na nim prawdziwych pracowników AI. Rzecz w tym, że trzeba to skonfigurować w określony sposób. Dziś pokażę wam, na czym ten sposób polega: dziewięć obszarów, które musicie opanować, żeby uruchomić takich pracowników AI.

Ten odcinek może być miejscami nudny, bo przechodzę przez konfigurację krok po kroku. Ale sądzę, że ci, którzy zostaną do końca, którzy naprawdę zakaszą rękawy i skopiują to, co robię — a oddaję tu wszystkie prompty i cały sos — będą w stanie wyprzedzić resztę. Będą budować produkty działające całą dobę i firmy natywnie oparte na AI, które po prostu miażdżą konkurencję.

(Informacja dodatkowa: odcinek powstał we współpracy sponsorskiej z Anthropic, producentem Claude Code — autor deklaruje to na wstępie.)

Mapa: czego potrzebuje pracownik AI

Sposób, w jaki myślę o pracowniku AI i o jego wdrożeniu, jest właściwie dość prosty. Jeśli chcesz, żeby Claude Code zachowywał się bardziej jak pracownik, musisz dać mu te same podstawowe rzeczy, które dałbyś człowiekowi dołączającemu do firmy. To ma sens, prawda?

Po pierwsze, potrzebuje miejsca pracy. W tym przypadku miejscem pracy jest repozytorium. To tam żyje produkt, tam są pliki i tam Claude może faktycznie wykonywać robotę.

Po drugie, potrzebuje pamięci. Pamięć to w istocie kontekst, który wkładasz w projekt — żeby Claude rozumiał, co budujesz, kim jest klient, co jest teraz istotne, jak wygląda dobra robota i czego już się nauczyliście, żeby nie powtarzać tych samych błędów.

Po trzecie, potrzebuje briefu. Zanim Claude zacznie zmieniać wszystko dookoła, chcesz, żeby zrozumiał zadanie. Do tego służy tryb planowania, tzw. plan mode. Mówisz mu: rozejrzyj się, przeczytaj kontekst, przemyśl zadanie i powiedz mi, jak byś do niego podszedł, zanim czegokolwiek dotkniesz. Do takiej pracy możesz chcieć użyć raczej Fable niż Opusa.

(Informacja dodatkowa: Fable 5 i Opus 4.8 to modele z rodziny Claude — autor sugeruje dobór modelu do charakteru zadania.)

Po czwarte, potrzebuje jasnego ticketu, czyli konkretnego zlecenia. Prawdziwy pracownik pracuje lepiej z konkretnym zadaniem — dlaczego z pracownikiem AI miałoby być inaczej? Błąd, który popełnia mnóstwo ludzi, polega na pisaniu: „popraw aplikację”, „niech to lepiej wygląda”. To są bardzo mgliste polecenia. Lepiej być skrajnie konkretnym. Jeśli tworzysz landing page i chcesz formularz zapisu na listę oczekujących, powiedz: „dodaj formularz listy oczekujących do landing page’a, ze stanem powodzenia, i sprawdź go w podglądzie desktopowym”. To zadziała po prostu dużo lepiej.

Po piąte, potrzebuje oczu. W Claude Code można to wreszcie zrobić i to jest naprawdę ekscytujące. Robię to głównie w aplikacji desktopowej. Możesz powiedzieć: „Claude, otwórz aplikację, obejrzyj stronę, przeklikaj cały przepływ, sprawdź, co jest mylące, i powiedz mi, czego naprawdę doświadczyłby klient, przechodząc przez to”. To zupełnie inny poziom użyteczności niż samo edytowanie plików.

Po szóste, potrzebuje review. Przegląd to spojrzenie na zmiany „przed i po”. Claude może pomóc również w recenzowaniu pracy, ale chcesz mieć system, w którym zmiany są faktycznie sprawdzane pod kątem twoich standardów, zanim cokolwiek ważnego trafi na produkcję.

Po siódme, potrzebuje harmonogramu. Tutaj wielu ludzi doznaje olśnienia — bo to jest moment, w którym naprawdę masz pracownika działającego całą dobę. Możesz dać Claude’owi pracę cykliczną: poranny brief, cotygodniowy przegląd zgłoszeń, recenzje pull requestów. Claude nazywa to rutynami (routines) i wrócę do tego w tym odcinku.

I wreszcie potrzebuje uprawnień. Dobry pracownik wie, co może zrobić samodzielnie, a kiedy powinien zapytać. Z Claude’em jest dokładnie tak samo. Może czytać pliki, badać repozytorium, uruchamiać testy, pracować na małych gałęziach — ale zanim ruszy zależności, migracje czy płatności, chcesz mieć pewność, że te decyzje zaufania należą do człowieka.

I to jest właściwie cała mapa: miejsce pracy, pamięć, ticket, oczy, review, harmonogram i uprawnienia. Jeśli potrafisz to złożyć, masz to, co nazywam pracownikiem AI. To po prostu działający system: dajesz Claude’owi miejsce do pracy, kontekst pozwalający zrozumieć biznes, sposób planowania, sposób wykonania, sposób sprawdzenia produktu, sposób przeglądu zmian, kilka cyklicznych obowiązków wykonywanych codziennie — a na koniec granice, żeby nie zrobił czegoś bardzo ryzykownego. Kiedy skonfigurujesz to w ten sposób, Claude Code przestaje przypominać jednorazowy czat, a zaczyna być warstwą operacyjną twojej firmy.

Krok 1: miejsce pracy, czyli repozytorium

W aplikacji desktopowej Claude wchodzisz do sekcji Claude Code. Wolę pracować w aplikacji desktopowej — jest znacznie mniej przytłaczająca niż terminal, więc dziś jej użyjemy. Wybierasz folder projektu, w którym Claude będzie faktycznie działał.

Na potrzeby tego demo weźmiemy pomysł, który znalazłem na ideabrowser.com: automatyczna odpowiedź na nieodebrane leady dla salonów medycyny estetycznej. Ktoś wypełnia formularz, pisze wiadomość do firmy, dzwoni po godzinach, pyta o cenę — a firma odpowiada za późno. Jest tu okazja, żeby zbudować zarabiający biznes softwarowy.

(Informacja dodatkowa: „med spa” to placówka łącząca gabinet kosmetyczny z zabiegami medycyny estetycznej — model biznesowy bardzo rozpowszechniony w USA.)

Jak wyglądałaby struktura tego repozytorium? Kiedy tworzę aplikację, chcę mieć foldery: app, context, customers, specs, demos, routines — plus trzy pliki Markdown w katalogu głównym.

app to sam produkt.
context to mózg biznesowy.
customers to miejsce na rozmowy sprzedażowe, notatki ze wsparcia, obiekcje i język, którym mówią klienci.
demos to przepływy demo, skrypty do nagrań, zrzuty ekranu.
routines to cykliczne prompty, o których mówiliśmy — zadania powtarzalne.

A trzy pliki w katalogu głównym — twoja instrukcja obsługi — to:

claude.md, który mówi Claude’owi, jak ma pracować,
roadmap.md, który mówi mu, co jest istotne teraz,
review.md, który mówi mu, jak oceniać pracę, zanim coś wypuści.

Pierwszy wniosek, który chcę wam zostawić: Claude staje się znacznie użyteczniejszy, kiedy projekt sam się objaśnia.

Prompt na zbudowanie workspace’u

Jak to skonfigurować najlepiej? Oto prompt:

Pomóż mi przygotować to repozytorium jako miejsce pracy dla pracownika AI. Utwórz lub zaktualizuj claude.md, roadmap.md, review.md oraz foldery context, customers, specs, demos, routines. Użyj tego kontekstu biznesowego. Produkt: automatyczna odpowiedź na nieodebrane leady dla salonów medycyny estetycznej. Kupujący: właściciel i operator salonu. Ból: przychodzące leady stygną, bo zespół odpowiada za późno. Obietnica: odpowiedz na każdy nieodebrany lead, zanim klient umówi się gdzie indziej. Bieżący cel: zbudować prostą stronę docelową i przepływ demo. Zanim zaczniesz pisać, zapytaj mnie o brakujący kontekst, który istotnie zmieniłby tę konfigurację, i zachowaj prostotę pierwszej wersji.

To wszystko, czego potrzebujesz. Ostatnie zdanie — o dopytaniu i o prostocie — jest bardzo pomocne. Claude odpowiada: „Zadam ci najpierw kilka pytań o dużej dźwigni, bo odpowiedzi zmienią to, jak ułożę przepływ demo i folder ze specyfikacją klienta. Całą resztę wypełnię rozsądnymi wartościami domyślnymi i utrzymam wersję pierwszą”. Zadaje serię pytań, ja szybko odpowiadam i na tej podstawie buduje cały zoptymalizowany workspace.

Tak to widzę: ustawiasz się na sukces. Jeśli nie masz zoptymalizowanych plików Markdown i właściwych folderów, Claude Code będzie się tu i ówdzie potykał.

Po zatwierdzeniu Claude tworzy całą strukturę: plik claude.md z podręcznikiem operacyjnym pracownika AI i biznesem opisanym w jednym zdaniu, roadmap.md, review.md oraz komplet folderów. Ale trzeba to jeszcze dopieścić.

Optymalizacja `claude.md` — styl pracy i kontekst biznesowy

Jak zoptymalizować claude.md, żeby naprawdę czuć, że masz do czynienia z pracownikiem AI? Trzeba mu nadać styl pracy. Gdybyś zatrudnił juniora — czy kogokolwiek — chciałbyś powiedzieć: „tak właśnie chcę, żebyś pracował”.

Więc podajesz styl pracy: chcę małych zmian, które da się przejrzeć; chcę, żebyś wyjaśnił plan przed edycją, gdy zadanie wpływa na zachowanie produktu; chcę, żeby zmiany były skupione; chcę, żebyś używał istniejącego stylu kodu; chcę, żebyś uruchamiał odpowiednie testy po zmianach; i chcę podsumowania: co się zmieniło, co przetestowałeś i co wymaga oceny człowieka.

Chcesz też sekcji z kontekstem biznesowym: produkt pomaga salonom medycyny estetycznej szybciej odpowiadać na nieodebrane zapytania; kupującym jest właściciel-operator; oto obietnica. Przypominasz mu, o co tu w ogóle chodzi.

Podajesz również poprzeczkę jakości: strona docelowa ma być zrozumiała w pięć sekund, przepływ demo ma działać na desktopie i na mobile, masz używać konkretnego języka klientów. To wszystko ląduje w claude.md, bo chcesz, żeby wiedział, jak pracujesz i jak wygląda dla ciebie sukces. Prowadzisz go, mentorujesz mu.

Claude aktualizuje claude.md, a przy okazji także review.md — ale do tego drugiego wrócimy, żeby dać mu jeszcze więcej informacji zwrotnej.

Optymalizacja `roadmap.md` — co jest ważne w tym tygodniu

Kolejny krok to powiedzenie Claude’owi, na czym ma się skupić w tym tygodniu. roadmap.md odpowiada na pytanie: jaki jest twój cel na ten tydzień.

Mówię więc: bieżącym celem jest zbudowanie prostego demo pokazującego, jak salon medycyny estetycznej może odzyskać nieodebrane leady. W tym tygodniu skup się na stronie docelowej, formularzu listy oczekujących, przepływie demo i wysłaniu nagrań do dziesięciu właścicieli salonów.

Ważne, żeby zaznaczyć, co jest poza zakresem. Wpisuję więc: płatności poza zakresem, integracja z CRM poza zakresem, panele administracyjne, uprawnienia wielu użytkowników. Robię to dlatego, że chcę, żeby model naprawdę popracował nad MVP i przerósł moje oczekiwania.

Optymalizacja `review.md` — twoje standardy jakości

review.md to plik, który zna twoje standardy: co jest dla ciebie akceptowalne, a co nie. Mam do tego gotowy prompt. Podaję listę kontrolną przed wypuszczeniem zmian:

Czy zmiana pasuje do bieżącej mapy drogowej?
Czy zmiana jest na tyle mała, żeby dało się ją przejrzeć?
Czy główny przepływ użytkownika nadal działa?
Czy są problemy z układem na urządzeniach mobilnych?
Czy błędy formularzy są poprawnie obsłużone?
Czy istnieje ryzyko dotyczące uwierzytelniania, płatności albo danych produkcyjnych?
Czy nie dodaliśmy zbędnej złożoności?

A ponieważ budujemy stronę docelową, dokładam: czy odwiedzający po raz pierwszy zrozumie ofertę w pięć sekund? Czy przycisk wezwania do działania jest widoczny? Czy tekst jest napisany konkretnie pod tego kupującego? Czy strona używa słów, których faktycznie używają klienci?

To jest specyficzne dla mojego pomysłu z salonami, ale łatwo sobie wyobrazić, jak wykorzystać ten schemat przy dowolnym innym. W istocie dajesz Claude’owi do zrozumienia: nie możesz po prostu wypuszczać śmieci, nie wypuszczamy AI-owego szlamu. I piękne jest to, że Opus 4.8 czy Fable 5 — przy dobrych plikach Markdown, właściwej strukturze i właściwym „mózgu” — radzą sobie znakomicie. Ale potrzebują tych barierek.

Claude odpowiada, że review.md jest gotowy, a rusztowanie workspace’u w zasadzie skończone: claude.md, mapa drogowa, review i wszystkie pięć folderów są wypełnione i spójne między sobą. Zostaje nazwać produkt i potwierdzić, że demo jest symulowane na ekranie — i można ruszać z pomysłem.

Krok 2: brief, czyli plan mode

Workspace mamy. Kolejnym krokiem jest brief. To element, który wydaje się drobny, ale zmienia cały sposób korzystania z Claude Code.

Kiedy dajesz człowiekowi ważne zadanie, nie przerzucasz go przez mur z nadzieją, że tamten zrozumie, o co chodzi. Najpierw o tym rozmawiasz. Tłumaczysz, co chcesz osiągnąć, co jest istotne, jakie są ograniczenia i co sprawi, że praca będzie dobra, a nie zmarnowana. Tak właśnie chcę, żebyście myśleli o plan mode. To moment, w którym Claude rozgląda się po projekcie, czyta kontekst, przemyśliwuje zadanie i pokazuje wam swoje podejście, zanim zacznie zmieniać pliki.

W tym demo chcę czegoś prostego i konkretnego: poproszę Claude’a o dodanie formularza listy oczekujących do strony docelowej. Ale zamiast rzucić samo „dodaj formularz”, dam mu prawdziwy brief:

Użyj plan mode. Chcę dodać formularz listy oczekujących do strony docelowej. Najpierw zbadaj obecną aplikację, claude.md, roadmap.md i review.md. Następnie podaj mi: pliki, które trzeba zmienić, najmniejszą czystą implementację, doświadczenie użytkownika, ryzyka, sposób weryfikacji oraz to, co świadomie pomijasz w pierwszej wersji. Poczekaj na moją akceptację, zanim zaczniesz edytować.

Ważne, żeby wprost kazać mu przejrzeć te pliki — chodzi o zebranie kontekstu, bo od tego zależy jakość wyniku.

Najważniejsze jest to, że teraz masz na co zareagować. Plan nie musi być doskonały. Możesz powiedzieć: „dobrze, ale zostań przy samym froncie, bo to tylko demo”, albo „nie, podłącz to do Supabase, bo chcę prawdziwych zgłoszeń”, albo „formularz jest za skomplikowany — daj tylko imię, e-mail i firmę”. Możesz też powiedzieć: „nie dotykaj na razie uwierzytelniania, płatności ani bazy danych”. Nie musi być idealnie, ale zaczynasz od czegoś przemyślanego.

Claude przedstawia plan: kontekst, pliki do zmiany, najmniejsza czysta implementacja wraz ze stosem technologicznym (Next.js z TypeScriptem), doświadczenie użytkownika, jak to będzie wyglądać, obietnica w jednym zdaniu, ryzyka takie jak spam i nadużycia. Mogę to wszystko przejrzeć i zaakceptować, odrzucić albo poprosić o poprawki. Akceptuję.

Ogólna zasada dotycząca plan mode: przy każdej istotnej pracy produktowej — a właściwie przy każdej istotnej pracy w ogóle — warto zaplanować. Myślę o tym jak o powiedzeniu „mierz dwa razy, tnij raz”.

Krok 3: ticket, czyli zadanie z widoczną linią mety

Kolejny duży element to ticket. Tutaj wielu ludzi przypadkiem pogarsza działanie Claude’a. Claude Code jest bardzo dobry w wykonywaniu roboty, ale musi wiedzieć, jak wygląda „zrobione”. Ticket to małe, jasne zlecenie z widoczną linią mety.

Zarządzając człowiekiem, raczej nie powiesz „idź i ulepsz produkt”. Powiesz: „dodaj formularz listy oczekujących do strony docelowej; ma zbierać imię, e-mail i firmę, a po wysłaniu pokazywać prosty komunikat o powodzeniu; i trzymaj się naszej obecnej identyfikacji wizualnej”. To jest dobry ticket — daje Claude’owi zadanie, zakres, oczekiwane doświadczenie użytkownika i granicę.

Kilka przykładów ticketów, które sam daję:

Stwórz stronę z cennikiem, używając istniejącego systemu projektowego i zachowując spójność ze stroną główną.
Napraw błąd przekierowania w onboardingu po weryfikacji adresu e-mail.
Zamień te pięć obiekcji klientów w ostrzejszą sekcję strony docelowej.

Są na tyle małe, że Claude rozumie linię mety i po prostu zabiera się do pracy, a ty możesz potem przejrzeć wynik.

Tickety, które wykolejają pracę, to głównie te mgliste: „popraw aplikację”, „zrób to bardziej wiralowym”, „dodaj AI”, „zbuduj całość”. Problem w tym, że wtedy Claude musi zgadywać, co jest ważne. A gdy zaczyna zgadywać, przestajesz zarządzać pracą — zaczynasz po niej sprzątać. Powiem uczciwie: Fable 5 zgaduje zaskakująco dobrze. Ale nadal uważam, że precyzja ticketów to kluczowa część procesu, jeśli chce się wycisnąć maksimum.

Po zaakceptowaniu planu daję Claude’owi prompt utrzymujący go w ryzach:

Zaimplementuj poprawiony plan jako jedną skupioną zmianę. Utrzymaj ją na tyle małą, żebym mógł ją przejrzeć w widoku różnic. Po edycji uruchom odpowiednie testy, otwórz aplikację w podglądzie desktopowym, podsumuj, co się zmieniło, powiedz mi, co przetestowałeś, i co nadal wymaga oceny człowieka.

Czym jest diff? W skrócie: pokazuje stan przed i po. Jeśli Claude edytuje kod, zmienia teksty, dodaje albo usuwa pliki, diff pokazuje dokładnie, co się zmieniło. Fajne jest to, że w aplikacji desktopowej Claude jest to dość wizualne — możesz wejść w zmienione pliki, przejrzeć edycje, zostawić komentarze i poprosić o poprawienie tego, co ci nie pasuje.

I właśnie dlatego rozmiar ticketu ma takie znaczenie. Mały ticket da się ogarnąć. Przy wielkim kończysz z górą zmian, która może wygląda imponująco, ale trudno jej zaufać. Zasada jest prosta: jeden jasny ticket naraz — jedno zadanie, jedna linia mety, jedna zmiana do przejrzenia.

W wyniku dostaję wizualne podsumowanie: oto plik, oto co robi, zmieniona powłoka, nowy nagłówek, style w podejściu mobile first. Widzę, co zostało przetestowane, czego nie udało się zrobić i dlaczego oraz co faktycznie wymaga oceny człowieka.

Krok 4: oczy, czyli sprawdzanie własnej pracy

Czwarty element to coś, co nazywam oczami. Tutaj Claude Code naprawdę zaczyna przypominać operatora. Mówiąc „oczy”, nie mam na myśli wyłącznie podglądu wizualnego. Chodzi o to, że Claude potrzebuje sposobu, by sprawdzić pracę po jej wykonaniu.

Pomyśl o dobrym pracowniku: wykonuje zadanie, a potem je sprawdza. Otwiera produkt, przeklikuje przepływ, uruchamia testy, szuka błędów, zagląda w konsolę, sprawdza jakiś dziwny przypadek brzegowy i pyta: czy to faktycznie zadziała dla klienta? Takiej pętli chcę z Claude Code: budujesz, uruchamiasz, używasz, testujesz, poprawiasz.

Podgląd desktopowy jest tu istotny, bo praca produktowa jest szczególnie wizualna. Strona docelowa może się załadować i wciąż być myląca. Formularz może się wysłać i wciąż być niezręczny. Przycisk może być na stronie i wciąż być trudny do zauważenia. Nagłówek może wyjaśniać produkt i wciąż nie trafiać w ból kupującego.

Ale oczy to coś więcej niż podgląd w przeglądarce. Claude może uruchomić zestaw testów, sprawdzić logi konsoli, błędy sieciowe, zweryfikować, czy formularz naprawdę zapisuje zgłoszenie. Właściwie może zrobić prawie wszystko.

Po zbudowaniu formularza chcę, żeby Claude zbadał całość zarówno z perspektywy klienta, jak i operatora produktu. Mój prompt:

Uruchom aplikację i zbadaj przepływ listy oczekujących. Otwórz stronę docelową w podglądzie desktopowym. Sprawdź to doświadczenie z perspektywy właściciela salonu, który widzi to po raz pierwszy. Następnie zweryfikuj implementację. Powiedz mi: co kupujący rozumie w pierwszych pięciu sekundach, co wydaje się mylące lub mało wiarygodne, czy formularz działa i co dzieje się po wysłaniu. Potem wykonaj jedno skupione przejście, poprawiając problem o największym wpływie.

To dokładnie to, co robi dobry pracownik — tylko my wpisujemy to w proces.

Widać, jak strona powstaje i jak Claude sprawdza, czy renderuje się poprawnie. Pisze: „teraz testuję przepływy jako odwiedzający po raz pierwszy; najpierw puste wysłanie — klikam »dołącz do listy oczekujących« bez wypełnienia niczego”. Potem stwierdza, że obsługa pustego stanu działa. Użył do tego czterech narzędzi — widać, że wszedł na stronę, przeczytał ją i użył komputera. To, że naprawdę potrafi to zrobić, jest po prostu szalone. Widzę, że stan powodzenia się wyrenderował, że weryfikuje w backendzie, czy rekord został zapisany, i że sprawdza konsolę i sieć pod kątem błędów.

A potem to: „Problem o największym wpływie: strona prosi nieznającego nas właściciela salonu o podanie adresu e-mail bez żadnego zapewnienia, czym jest ta lista oczekujących ani czy nie dostanie spamu. To największy punkt tarcia przy działaniu, o które strona prosi. Moje skupione przejście: dodać przy przycisku mikrotekst ustawiający oczekiwania”. To jest dokładnie to, czego chcesz od dobrego pracownika.

Naprawdę świetne jest to, że Claude Code ma oczy — i zdumiewające, jak mało osób z nich korzysta. Kiedy wpiszesz to w swój proces, będziesz mieć lepsze QA i po prostu lepszy produkt na końcu, bo go testujesz. Oczy są niedoceniane.

Krok 5: review, czyli przenoszenie wąskiego gardła

Kolejny element to review. To ta część konfiguracji, która czyni całość użyteczną — bo gdy Claude potrafi budować szybko, wąskie gardło przesuwa się na osąd. Czy rozwiązał właściwy problem? Czy zmienił właściwe pliki? Czy nie stworzył dziwnego przypadku brzegowego? Czy produkt stał się dla klienta jaśniejszy?

Dlatego review ma takie znaczenie: jeśli zamierzasz oddać Claude’owi znacznie więcej pracy, potrzebujesz sposobu na jej kontrolę bez zamieniania każdego zadania w wielogodzinny przegląd kodu.

Myślę o review warstwowo.

Pierwsza warstwa to twoje własne czytanie. Otwierasz widok różnic w aplikacji desktopowej i patrzysz na pliki, których Claude dotknął. Przeklikujesz zmiany i zadajesz sobie kilka pytań: czy to odpowiada ticketowi? Czy to odpowiada planowi? Czy jest tu coś zaskakującego? Zaskakujące zmiany to zwykle miejsce, gdzie siedzi ryzyko — dlatego to ważne pytanie. Jeśli Claude miał dodać formularz listy oczekujących, a nagle zmienił uwierzytelnianie, routing i bazę danych, chcę o tym wiedzieć natychmiast.

Druga warstwa to review Claude’a wobec twoich standardów. Pamiętacie plik review.md? Teraz prosisz Claude’a, żeby ocenił pracę przez pryzmat tego, na czym projektowi naprawdę zależy. Prompt:

Użyj review.md jako standardu. Przejrzyj bieżące zmiany pod kątem problemów produkcyjnych, zepsutych przypadków brzegowych i mylących przepływów użytkownika. Podziel problemy na: trzeba naprawić, warto naprawić, można wypuścić. Skup się na błędach, dezorientacji użytkownika, ryzykach bezpieczeństwa i zbędnej złożoności, plikach zmienionych poza zakresem ticketu oraz wszystkim, co narusza mapę drogową.

Cała ta wcześniejsza praca nad review.md zaczyna się teraz zwracać. Claude rozdziela wynik na te trzy kategorie i pyta, czy chcę od razu naprawić pozycje pierwszą i drugą. Dobrze to wiedzieć, jeśli naprawdę wypuszczam aplikację na produkcję. Format „musi / warto / można” uważam za wyjątkowo pomocny.

Możesz użyć polecenia /review, żeby po prostu przejrzeć kod. Ale jeśli robisz coś naprawdę ryzykownego, warto sięgnąć po /ultra review — uruchamia zdalną sesję pogłębionego przeglądu dla repozytorium. Zanim wypuścisz coś dużego na produkcję, na przykład uwierzytelnianie czy płatności, warto zrobić właśnie taki przegląd.

(Informacja dodatkowa: w bieżących wersjach Claude Code odpowiada temu polecenie /code-review ultra; /ultrareview jest wycofywanym aliasem tej samej funkcji.)

Krok 6: harmonogram, czyli rutyny i „nocna zmiana”

Szósty element to harmonogram — czyli idea, że pracownik AI pracuje dla ciebie proaktywnie. Do tej pory mówiliśmy głównie o Claude pomagającym ci, gdy siedzisz przy nim: promptujesz, dajesz kontekst, plan, ticket, każesz budować, sprawdzać i przeglądać. To fajne, ale pracownik jest cenniejszy między innymi dlatego, że ma powtarzalne obowiązki.

Każdy biznes ma taką pracę: ktoś musi przejrzeć notatki od klientów, ktoś musi zauważyć, jakie problemy się powtarzają, ktoś musi przejrzeć otwarte zadania i powiedzieć: „jest tu coś, co trzeba zrobić”. To praca w cudzysłowie nudna, mało efektowna — ale dokładnie ona utrzymuje firmę w ruchu i sprawia, że klienci wciąż dostają wartość.

Właśnie od tego bym zaczął. Nie zacząłbym od proszenia Claude’a, żeby wypuszczał kod produkcyjny, kiedy śpię. Zacząłbym od cyklicznego zadania operatorskiego: przygotuj mi poranny brief. Służy do tego funkcja Claude Code o nazwie rutyny. Przykładowy prompt:

W każdy dzień roboczy o 7 rano przeczytaj customers i context, otwórz zgłoszenia w GitHubie, jeśli jest podłączony, a następnie utwórz lub zaktualizuj context/morning-brief.md, podając: najważniejszy ból klienta z najnowszych notatek, jedno ryzyko produktowe, jedno rekomendowane zadanie budowlane na dziś i jedno pytanie, które powinienem dziś zadać klientom. Nie edytuj kodu produkcyjnego, nie otwieraj pull requestów i zmieść się w 500 słowach.

To coś, co możesz zrobić niezależnie od tego, co budujesz. I całe szczęście, że mamy to repozytorium z folderami customers i context — pewnie zaczynacie już widzieć, jak to wszystko się składa.

Lubię to zadanie jako pierwsze, bo jest użyteczne i kontrolowane. Nie zmienia produktu, nie dotyka produkcji, nie buduje przypadkowych funkcji. Po prostu czyta biznes, patrzy na bieżącą pracę i daje ci ostrzejszy punkt startowy na dzień. A ustawienie tego zajęło kilka sekund.

Kolejny poziom to cotygodniowy przegląd operacyjny:

W każdy piątek o 15:00 przejrzyj otwarte zgłoszenia i najnowsze notatki od klientów, pogrupuj powiązane zgłoszenia lub wskaż duplikaty, zaproponuj jedną najbardziej dźwigniową poprawkę na nadchodzący tydzień i opublikuj podsumowanie w context/weekly-ops.md. Nie edytuj kodu.

Drugi zaplanowany agent działa. Świetne jest w tym to, że zgłoszenia nie będą się już piętrzyć. Claude pomoże ci dostrzec wzorce — może były skargi klientów, których nie zauważyłeś, może wiele osób miało ten sam problem z onboardingiem. To pomaga ustawić priorytety tygodnia; trochę jak szef sztabu.

Mam teraz dwie rutyny: poranny brief i cotygodniowy przegląd operacyjny. Ostatnia rzecz, którą bym dodał — i zachęcam do tego samego — to domknięcie pętli na pull requestach:

Kiedy otwiera się pull request, przejrzyj go zgodnie z review.md. Zostawiaj komentarze tylko przy sprawach, które mogą wywołać błędy, zepsute przepływy użytkownika, problemy bezpieczeństwa lub mylące zachowanie. Następnie opublikuj krótkie podsumowanie: co wygląda dobrze, co wymaga uwagi i czy to jest gotowe do przeglądu przez człowieka.

Kiedy to zadziała, każdego ranka Claude Code powie ci, co jest istotne i jakie widzi wzorce, a przy każdym pull requeście sprawdzi pracę wobec twoich standardów, bo patrzy na review.md.

I to właśnie znaczy „nocna zmiana”. Kiedy ludzie mówią o Claude Code pracującym całą dobę, mają na myśli to: praca jest nieustannie porządkowana, napływające informacje zwrotne są podsumowywane, ryzyka biznesowe wypływają na wierzch, a kolejne zadania stają się coraz wyraźniejsze.

Krok 7: agenci równolegli

Kolejny duży temat to praca równoległa. Oczywiście nie chcesz robić wszystkiego po kolei. Marzeniem jest mieć wielu agentów robiących wiele rzeczy naraz. To już nie jeden pracownik — to powielenie pięciu, dziesięciu, piętnastu, dwudziestu. Czy to możliwe? Tak.

Jeśli praca jest dobrze zakresowana, Claude może pchać kilka rzeczy naprzód jednocześnie. W aplikacji desktopowej zakładka kodu może prowadzić osobne sesje. Każda sesja ma własny kontekst i własny zestaw zmian, a dzięki izolacji drzew roboczych zmiany zostają rozdzielone, zamiast się mieszać.

(Informacja dodatkowa: drzewa robocze to mechanizm gita pozwalający mieć kilka niezależnych kopii roboczych tego samego repozytorium.)

Prosty sposób myślenia jest taki: każda sesja ma przypominać przekazanie jednego jasnego zadania jednej osobie.

Wyobraź sobie, że siadasz rano i chcesz pchnąć naprzód trzy rzeczy. Pierwsza jest techniczna: przekierowanie w onboardingu psuje się po weryfikacji e-maila i ktoś musi to rozgryźć i naprawić. Druga dotyczy klarowności produktu: nagłówek na stronie docelowej jest zbyt ogólny, a chcesz, żeby właściciel salonu rozumiał wartość w pięć sekund. Trzecia to sprzedaż: masz stertę notatek od klientów i chcesz je zamienić w ostrzejszy skrypt demo. To zupełnie różne zadania — debugowanie, produkt i tekst, wsparcie sprzedaży.

W starym trybie pracy robiłbym je jedno po drugim. W trybie pracownika AI mogę dać każdemu własną sesję Claude’a, z tym samym kontekstem produktowym i bardzo jasno określonym rezultatem:

Sesja z błędem ma wrócić z przyczyną źródłową, listą zmienionych plików, uruchomionymi testami i wskazówką, czego szukać w diffie.
Sesja od strony docelowej ma wrócić z nagłówkiem przed i po, użytym językiem klientów, tym, co zmieniło się w podglądzie, i uzasadnieniem, dlaczego nowa wersja jest jaśniejsza.
Sesja od demo ma wrócić z wyciągniętymi notatkami klientów, obiekcją, którą próbowała obsłużyć, i tym, co powinienem sprawdzić przed nagraniem.

Sedno jest takie: nie chcesz na koniec dnia gigantycznej hałdy pracy AI, którą trzeba rozplątywać, bo to nie jest przyjemne. Chcesz małych paczek pracy, które człowiek może obejrzeć, zaakceptować, poprawić albo odrzucić.

Jak to wygląda w praktyce? Pierwszy prompt:

Zajmij się błędem przekierowania w onboardingu po weryfikacji e-maila. Zanim zaproponujesz poprawkę, użyj plików kontekstowych projektu. Zacznij od wyjaśnienia, co twoim zdaniem powoduje błąd i które pliki musisz obejrzeć. Po zatwierdzeniu planu wprowadź najmniejszą czystą poprawkę. Na koniec podaj mi przyczynę źródłową, zmienione pliki, uruchomione testy, to, co powinienem przejrzeć w diffie, i wszystko, co wydaje ci się niepewne.

Dla nagłówka strony docelowej format jest podobny: popraw nagłówek tak, żeby właściciel salonu rozumiał wartość w pięć sekund; użyj claude.md, roadmap.md, review.md i najnowszych notatek od klientów — ważne, żeby to wpisać; ogranicz zmianę do sekcji nagłówka, chyba że drobna zmiana wspierająca jest konieczna; na koniec podaj wersję przed i po, i tak dalej.

A dla sprzedaży: przeczytaj najnowsze notatki od klientów i zamień je w krótki skrypt demo dla produktu odpowiadającego na nieodebrane leady; używaj, gdzie się da, prawdziwych słów klientów; demo ma pokazać ból, moment produktowy i efekt; na koniec podaj mi skrypt, i tak dalej.

Co tu zrobiłem? Dałem każdej sesji jasne zadanie, ten sam kontekst projektu i konkretny sposób przekazania wyniku. Nie chodzi o to, żeby AI rozpylało pracę we wszystkich kierunkach. Chodzi o to, żebyś po przebudzeniu wybrał trzy najbardziej użyteczne strumienie pracy i pozwolił Claude’owi pchnąć każdy z nich naprzód w sposób, który da się faktycznie przejrzeć.

Krok 8: uprawnienia

Ósmy element to uprawnienia. Są naprawdę ważne, bo to ryzykowna sprawa. Myślę o nich tak, jak myślę o delegowaniu: pewne rzeczy Claude może robić swobodnie, o pewne powinien pytać, a pewne muszą zostać przy człowieku.

Działania bezpieczne: czytanie plików, badanie bazy kodu, proponowanie planów, uruchamianie lokalnych testów, edytowanie małej gałęzi funkcjonalnej, aktualizowanie dokumentacji, tworzenie szkicu pull requesta.

Działania wymagające pytania: instalowanie zależności, zmiany migracji bazy danych, ruszanie uwierzytelniania, zmiany w logice płatności, usuwanie plików.

Działania zastrzeżone dla człowieka: wdrożenia produkcyjne, decyzje dotyczące danych klientów, decyzje rozliczeniowe, zmiany wrażliwe pod względem bezpieczeństwa. Nawet jeśli masz pracowników AI, te rzeczy o wysokim ryzyku nadal powinny należeć do ludzi.

W aplikacji desktopowej możesz wybierać tryby uprawnień w zależności od tego, ile kontroli chcesz zachować. Zacznij zachowawczo, używaj plan mode do większych zmian i ręcznego przeglądu, gdy dopiero uczysz się systemu. Pozwoliłbym Claude’owi przyspieszać w miarę, jak mózg repozytorium, lista kontrolna review i zakresy zadań stają się coraz mocniejsze. To właśnie model zarządzania: dajesz AI przestrzeń do pracy i granice. Szkoda, że robi tak niewielu. Tryb „na żywioł” jest jednak zbyt ryzykowny. Myślenie o uprawnieniach jak o strategii pomoże wam realnie skalować zespół pracowników AI.

Krok 9: skills, connectors i hooks

Dziewiąty element to umiejętności, konektory i haki. To ta część, w której Claude Code przestaje być czymś generycznym, a zaczyna należeć do twojej firmy.

Czym jest skill? To powtarzalny sposób wykonywania pracy. Jeśli wpisujesz w kółko ten sam prompt, prawdopodobnie powinien być umiejętnością. W projekcie dla salonów zrobiłbym umiejętność „rozbiórka strony docelowej”: przy każdym użyciu Claude ma spojrzeć na stronę oczami właściciela salonu, sprawdzić pięciosekundową klarowność, znaleźć mgliste sformułowania, poszukać brakujących sygnałów wiarygodności, obejrzeć przycisk akcji i zaproponować jedno skupione ulepszenie.

Zrobiłbym też umiejętność „notatki klientów”: czyta najnowsze rozmowy albo zgłoszenia do wsparcia i wyciąga dokładne słowa używane przez klientów, powtarzające się obiekcje i wyzwalacze zakupowe. To bardzo użyteczne, bo wtedy Claude nie buduje z mojej opinii, tylko z języka klientów. To zresztą trend, który widzę coraz częściej — i ma sens. Tej samej umiejętności możesz użyć przy pisaniu tekstów reklamowych.

Zrobiłbym również umiejętność „skrypt demo”: bierze najnowszy stan produktu i notatki klientów i zamienia je w krótkie demo — oto ból, oto moment produktowy, oto efekt. To rzecz, która oszczędza godziny tygodniowo. Umiejętności można pobierać z gotowych źródeł albo tworzyć samemu. Jeśli będzie zainteresowanie, mogę zrobić pogłębiony materiał o marketplace’ach z umiejętnościami — dajcie znać w komentarzach.

Czym jest konektor? Daje Claude’owi lepszy kontekst: dostęp do GitHuba, do Lineara, jeśli go używasz, do Google Drive, do Slacka. To po prostu wtyczka pozwalająca sięgać po te wszystkie narzędzia.

A czym jest hook? Haki to barierki wokół pracy. Po tym, jak Claude zedytuje kod, uruchom formatowanie. Przed podsumowaniem pull requesta uruchom testy. Zanim zmiana trafi dalej, uruchom istotne kontrole.

Masz więc umiejętności, które czynią pracę powtarzalną, konektory, które dają lepszy kontekst, i haki, które czynią przepływ bezpieczniejszym. A gdy połączysz to wszystko z mapą drogową, standardami review, notatkami od klientów i rutynami, Claude staje się o wiele bardziej dopasowany do twojej firmy. To jest szerszy sens tego wszystkiego: to są ulepszenia dla twojego biznesu. Można sobie wyobrazić, że tworzy się w ten sposób pewien rodzaj fosy — bo dobry system wokół tego oznacza naprawdę dobre wyniki z Claude Code.

Plan na siedem dni

Może myślisz teraz: dobrze, ale jak zrobić z tego plan działania? Oto siedmiodniowy plan, który dałbym komuś, kto chce stworzyć cyfrowego pracownika AI. Możesz go zrealizować w siedem godzin, w siedemdziesiąt minut, w siedem dni albo w trzydzieści jeden — zależy, jak techniczny jesteś, ile masz czasu i czy pracujesz na etacie. Ale dla zabawy rozpiszmy to na tydzień.

Dzień 1 — zbuduj mózg repozytorium. Stwórz claude.md, roadmap.md, review.md, foldery context, customers i resztę. Opisz klienta, problem, bieżący cel i definicję ukończenia.

Dzień 2 — uruchom plan mode. Wybierz jedno małe zadanie produktowe i każ Claude’owi zbadać repozytorium przed edycją. Rezultatem ma być plan, lista plików, ryzyka i kroki weryfikacji.

Dzień 3 — zbuduj jedno widoczne ulepszenie. Formularz listy oczekujących, stronę z cennikiem, przepływ demo, poprawkę błędu w onboardingu. Wybierz coś na tyle małego, żeby dało się przejrzeć, i na tyle prawdziwego, żeby dało się pokazać klientowi.

Dzień 4 — użyj pętli podglądu. Niech Claude otworzy aplikację w podglądzie desktopowym, przeklika przepływ, sprawdzi wersję mobilną i poprawi klarowność.

Dzień 5 — przejrzyj pracę. Otwórz widok różnic, przeczytaj zmiany przed i po, poproś Claude’a o przegląd wobec review.md, a przy poważniejszej zmianie użyj pogłębionego przeglądu kodu.

Dzień 6 — wyślij to dziesięciu osobom. Nagranie, demo, stronę docelową — cokolwiek zbudowałeś — do ludzi, których to może obchodzić. Ich odpowiedzi wrzuć do folderu customers.

Dzień 7 — stwórz pierwszą rutynę. Zacznij od porannego briefu. Niech Claude czyta notatki klientów i zgłoszenia, a potem rekomenduje jedno użyteczne zadanie budowlane.

Teraz masz pętlę. Ona żyje i oddycha, a ty zaczynasz każdy dzień z kontekstem, informacją zwrotną i następnym ruchem.

Pętla, czyli podsumowanie

To już jest pracownik AI, bo końcowa pętla wygląda tak: opinie klientów trafiają do customers, kierunek produktu do roadmap.md, styl pracy do claude.md, standardy jakości do review.md. Małe zadania przechodzą przez plan mode. Zmiany przechodzą przez podgląd i przegląd. Praca cykliczna staje się zaplanowaną rutyną. I to jest cała konfiguracja całodobowego pracownika Claude Code.

Kiedy raz zobaczysz to w ten sposób, Claude Code przestaje być czatem. Produkt, opinie klientów, dokumentacja, dema, przeglądy i praca cykliczna zaczynają żyć w jednej pętli operacyjnej, którą z czasem trzeba optymalizować. Nie będzie idealnie. Ale kiedy raz zaczniesz budować w ten sposób, nie wrócisz do starego. Wszystkie prompty, przez które przeszedłem, wrzucam do opisu odcinka, żebyście mogli je skopiować i sami uruchomić swoich pracowników AI.

Uważam, że dźwignia, jaką daje dziś uruchamianie pracowników AI, jest szalona. Możecie użyć Claude Code, możecie użyć innych systemów — ale zróbcie to. Bawcie się dobrze, zakaście rękawy. Do zobaczenia następnym razem.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Traktuj repozytorium jak stanowisko pracy, nie jak folder z kodem

Na czym polega: Struktura app, context, customers, specs, demos, routines plus trzy pliki Markdown (claude.md, roadmap.md, review.md) sprawia, że projekt sam się objaśnia — model nie musi zgadywać, czego dotyczy praca.

Jak stosować: Zbuduj tę strukturę jednym promptem na starcie projektu, zamiast dokładać ją po miesiącu. Poproś model, żeby najpierw dopytał o brakujący kontekst, a dopiero potem pisał pliki.

Na co uważać: Puste albo nieaktualne pliki kontekstowe są gorsze niż ich brak — model będzie się na nie powoływał. Jeśli nie zamierzasz ich utrzymywać, ogranicz się do jednego pliku, który faktycznie odświeżasz.

2.Rozdziel „jak pracować”, „co teraz” i „co jest dobre” na trzy osobne pliki

Na czym polega: claude.md zawiera styl pracy i kontekst biznesowy, roadmap.md — cel na najbliższy tydzień wraz z listą rzeczy poza zakresem, review.md — listę kontrolną jakości przed wypuszczeniem zmian.

Jak stosować: W roadmap.md zawsze wpisuj sekcję „poza zakresem”. To ona najsilniej powstrzymuje model przed budowaniem funkcji, o które nikt nie prosił.

Na co uważać: Wrzucenie wszystkiego do jednego pliku sprawia, że model traktuje standardy jakości i bieżące priorytety jako jedną masę. Rozdzielenie ma sens tylko wtedy, gdy w promptach wprost wskazujesz, którego pliku ma użyć.

3.Zawsze przechodź przez plan mode przy istotnej zmianie

Na czym polega: Model najpierw czyta projekt i pliki kontekstowe, potem przedstawia plan — pliki do zmiany, najmniejszą implementację, ryzyka, sposób weryfikacji i to, co świadomie pomija — i czeka na akceptację.

Jak stosować: W prompcie wprost wymień pliki, które ma przeczytać przed planowaniem, i wprost napisz „poczekaj na moją akceptację przed edycją”. Plan traktuj jako materiał do korekty, nie jako gotowy werdykt.

Na co uważać: Plan mode kosztuje czas i przy trywialnych poprawkach bywa zbędnym rytuałem. Odruchowe akceptowanie planów bez czytania niweczy cały sens tego kroku.

4.Jeden ticket to jedno zadanie, jedna linia mety, jedna zmiana do przejrzenia

Na czym polega: Dobry ticket zawiera zadanie, zakres, oczekiwane doświadczenie użytkownika i granicę. Mgliste polecenia zmuszają model do zgadywania, a wtedy przestajesz zarządzać pracą i zaczynasz po niej sprzątać.

Jak stosować: Zamiast „popraw stronę” pisz: „dodaj formularz zbierający imię, e-mail i firmę, po wysłaniu pokaż komunikat o powodzeniu, zachowaj obecną identyfikację wizualną”. Rozmiar ticketu dobieraj do tego, ile diffu jesteś w stanie realnie przeczytać.

Na co uważać: Autor przyznaje, że najnowsze modele zgadują coraz lepiej — łatwo więc popaść w rutynę dużych, mglistych zleceń. Wynik może wyglądać imponująco, a być nieweryfikowalny.

5.Wymuszaj sprawdzanie pracy „oczami”, a nie tylko edycję plików

Na czym polega: Model potrafi uruchomić aplikację, otworzyć ją w podglądzie, przeklikać przepływ, sprawdzić stany błędów, konsolę, żądania sieciowe i zapis w bazie — a potem ocenić rzecz z perspektywy klienta.

Jak stosować: Dopisz do promptu konkretne pytania („co kupujący rozumie w pierwszych pięciu sekundach?”, „co budzi nieufność?”) i poproś o jedno skupione przejście poprawiające problem o największym wpływie.

Na co uważać: Werdykt modelu o tym, „co czuje klient”, to nadal hipoteza, nie badanie użytkowników. Traktuj go jako listę rzeczy do sprawdzenia, a nie jako dowód.

6.Recenzuj w dwóch warstwach: własnym okiem i wobec spisanego standardu

Na czym polega: Najpierw sam czytasz diff i pytasz, czy zmiana odpowiada ticketowi i planowi oraz czy nie ma w niej niespodzianek. Potem prosisz model o przegląd wobec review.md, z podziałem na „trzeba naprawić / warto naprawić / można wypuścić”.

Jak stosować: W prompcie recenzyjnym wprost wymień pliki zmienione poza zakresem ticketu jako osobną kategorię — to najprostszy wykrywacz rozpełzania się zmian.

Na co uważać: Model recenzujący własną pracę ma skłonność do jej akceptowania. Przy zmianach dotykających uwierzytelniania, płatności czy danych produkcyjnych autor zaleca uruchomienie pogłębionego przeglądu, a nie zwykłego.

7.Zacznij rutyny od zadań, które niczego nie zmieniają

Na czym polega: Poranny brief czytający notatki klientów i zgłoszenia oraz piątkowy przegląd operacyjny grupujący problemy to praca użyteczna i całkowicie bezpieczna — nie dotyka kodu ani produkcji.

Jak stosować: W treści rutyny wpisz twarde zakazy („nie edytuj kodu produkcyjnego, nie otwieraj pull requestów”) i limit długości wyniku. Dopiero po kilku tygodniach rozważaj rutyny modyfikujące cokolwiek.

Na co uważać: Rutyna, której nikt nie czyta, to koszt bez zwrotu. Jeśli po tygodniu nie otwierasz porannego briefu, to znak, że pytania w prompcie są źle dobrane — a nie że mechanizm nie działa.

8.Praca równoległa działa tylko przy dobrze rozdzielonych zadaniach

Na czym polega: Osobne sesje z izolacją drzew roboczych pozwalają prowadzić naraz kilka niezależnych wątków — na przykład debugowanie, pracę nad tekstem i materiały sprzedażowe — bez mieszania zmian.

Jak stosować: Każdej sesji nadaj ten sam kontekst projektu, ale odrębne zadanie i odrębny format raportu końcowego. Wybieraj wątki należące do różnych dziedzin, żeby nie kolidowały w tych samych plikach.

Na co uważać: Kilka sesji dotykających tego samego obszaru kodu daje na koniec dnia hałdę zmian do rozplątywania — dokładnie to, czego ten mechanizm miał uniknąć. Skaluj liczbę sesji do tego, ile diffów zdołasz przeczytać.

9.Uprawnienia dziel na trzy poziomy i przesuwaj granicę stopniowo

Na czym polega: Bezpieczne: czytanie, testy lokalne, praca na gałęzi, dokumentacja, szkic pull requesta. Wymagające pytania: zależności, migracje, uwierzytelnianie, płatności, usuwanie plików. Zastrzeżone dla człowieka: wdrożenia produkcyjne, dane klientów, rozliczenia, bezpieczeństwo.

Jak stosować: Zacznij od trybu zachowawczego i luzuj go dopiero wtedy, gdy pliki kontekstowe i lista kontrolna review są dojrzałe. To dojrzałość systemu, a nie zaufanie do modelu, uzasadnia poluzowanie.

Na co uważać: Tryb „na żywioł”, w którym model działa bez pytania, autor uznaje wprost za zbyt ryzykowny. Poziom trzeci nie powinien migrować w dół nigdy, niezależnie od tego, jak dobrze system działa.

10.Umiejętności, konektory i haki to miejsce, gdzie konfiguracja staje się przewagą

Na czym polega: Umiejętności czynią powtarzalną pracę powtarzalną (rozbiórka strony docelowej, wyciąganie języka klientów, skrypt demo), konektory dają dostęp do GitHuba, Lineara, Google Drive czy Slacka, a haki uruchamiają formatowanie i testy w ustalonych momentach.

Jak stosować: Regułą jest: prompt wpisywany po raz trzeci powinien zostać umiejętnością. Szczególnie opłacalna jest umiejętność wyciągająca dosłowny język klientów — jej wynik nadaje się później także do tekstów reklamowych.

Na co uważać: To najbardziej pracochłonna warstwa i ma sens dopiero wtedy, gdy podstawy działają. Umiejętność zbudowana na zgadywaniu, a nie na prawdziwych notatkach klientów, tylko utrwala twoje własne założenia w skali.