Narzędzia do pracy z AI zmieniają się bardzo szybko — nazwy komend, limity i domyślne zachowania modeli potrafią się zmienić z tygodnia na tydzień. Opisujemy tu nawyki i zasady, a nie instrukcję obsługi konkretnych komend. Fakty o tym, jak to działa, oznaczamy „wg Anthropic" i linkujemy w Źródłach. Stan na lipiec 2026.
W skrócie: siedem nawyków
Jeśli masz przeczytać tylko tyle, to zapamiętaj te siedem rzeczy. Każdą rozwijamy niżej, z przykładem, jak to wygląda w realnej pracy.
- Zacznij od planu, nie od roboty. Najpierw ustal, co ma powstać, dopiero potem każ to zrobić.
- Puść kilku pomocników naraz. Osobne rozmowy do niezależnych zadań i do sprawdzenia efektu świeżym okiem.
- Zapisuj przepisy z tego, co właśnie zrobiłeś ręcznie. Powtarzalną robotę spakuj, gdy jeszcze pamiętasz, jak ją zrobić.
- Daj modelowi sposób, żeby sam sprawdził swoją robotę. To najprostsza droga do wyższej jakości.
- Dobierz model do zadania. Nie każde zadanie potrzebuje najmocniejszego modelu.
- Pilnuj pamięci rozmowy i rachunku za nią. Wiedz, ile już „nagadaliście", i zaczynaj świeżo, gdy trzeba.
- Zbuduj system, który się uczy. Notatka ze stałymi zasadami, dziennik zrobionej roboty i okresowy przegląd „co się powtarza".
1. Zacznij od planu, nie od roboty
Bezpośrednia rada: zanim poprosisz o zrobienie czegokolwiek, poproś, żeby model najpierw przepytał Ciebie i spisał, co dokładnie ma powstać. To taki brief, jak dla grafika: uzgadniasz go, zanim ktokolwiek zacznie robotę. Dopiero na zatwierdzonym briefie pozwól mu ruszyć. To jedna zmiana, która oszczędza najwięcej poprawek.
Powód jest prosty: bez takiego uzgodnienia model zgaduje, czego chcesz, a większość zgadywań jest błędna albo niepełna. Kiedy każesz mu od razu „zrób X", dostajesz jego wyobrażenie o X, nie Twoje. Kiedy najpierw zmusisz go do zadania pytań, wychodzą na wierzch decyzje, o których sam byś nie pomyślał: co z nietypowymi sytuacjami, jak ma wyglądać komunikat o błędzie, co jest poza zakresem.
U nas wygląda to tak: włączamy tryb planowania i piszemy wprost „nie rób jeszcze nic, najpierw przepytaj mnie o wymagania, jedno pytanie naraz, a potem spisz ustalenia". Model przechodzi przez kilkanaście pytań, zapisuje wnioski i dopiero wtedy zaczyna. Te same ustalenia stają się potem punktem odniesienia przy sprawdzaniu: łatwo zobaczyć, czy zrobił to, co uzgodniliśmy, a nie coś obok.
2. Puść kilku pomocników naraz
Bezpośrednia rada: niezależne od siebie zadania rób w osobnych rozmowach równolegle, każda z własną pamięcią. To trochę jak zespół zamiast jednej osoby, która robi wszystko po kolei: kilku pomocników pracuje naraz nad różnymi kawałkami. Nie pchaj wszystkiego przez jedno okno.
Dwa zastosowania dają najwięcej. Pierwsze to zwykłe przyspieszenie: jeśli trzy kawałki roboty nie zależą od siebie, niech trzej pomocnicy robią je jednocześnie, zamiast czekać w kolejce. Drugie jest ciekawsze: świeże oko. Jeden pomocnik coś robi, drugi (świeży, bez wiedzy o tym, jak pierwszy to zrobił) sprawdza wynik. Chodzi o to, żeby uniknąć „poklepywania się po plecach": ktoś, kto sam coś napisał, chętnie broni własnej roboty. Osobny pomocnik z czystą głową patrzy na to jak ktoś z zewnątrz i łatwiej wyłapuje luki.
W praktyce: kończymy większą zmianę, a potem otwieramy drugą rozmowę z zadaniem „przejrzyj to pod kątem zgodności z ustaleniami i błędów, nie poprawiaj, tylko wypisz problemy i napisz, na ile jesteś pewny". Dwa spojrzenia zamiast jednego, prawie bez straty czasu.
3. Zapisuj przepisy z tego, co właśnie zrobiłeś ręcznie
Bezpośrednia rada: przepis (po angielsku „skill") to zapisana raz procedura, którą potem odpalasz i za każdym razem robi to samo tak samo, jak szablon albo checklista. Nie chodzi o abstrakcyjny „poradnik na przyszłość", tylko o powtarzalną robotę spakowaną z rzeczy, którą właśnie zrobiłeś ręcznie. Najlepszy moment na jej zapisanie jest tuż po tym, jak coś zadziałało, bo pamiętasz jeszcze wszystkie pułapki.
Kilka zasad, które wg Anthropic robią różnicę. Przepis nie musi być długi: dobre zaczynają się od kilku linijek i jednej pułapki, a rosną dopiero, gdy trafiasz na nowe, nietypowe sytuacje. Najważniejsza jest w nich sekcja „Gotchas"(czyli „pułapki") — to do niej dokładasz każdą rzecz, która raz Cię ugryzła, żeby nie ugryzła drugi raz.
Druga rzecz: przepis, który tylko powtarza to, co model i tak zrobiłby sam, wg Anthropic „dodaje kontekst, nie dodając wartości". Zapisuj więc tylko to, czego model sam by nie zgadł: nietypowe zasady, Twoje decyzje, rzeczy specyficzne dla Was. I trzecia: przepis to nie jeden plik z tekstem, tylko folder. Może mieć w środku gotowe skrypty, materiały i dane, a wczytuje się stopniowo: najpierw sama nazwa i opis, reszta dopiero, gdy jest potrzebna. Powtarzalne kroki warto zamknąć w gotowych skryptach; wg Anthropic pozwalają one modelowi „spędzać tury na komponowaniu, a nie odtwarzaniu boilerplate'u" (po ludzku: tworzyć nowe rzeczy, zamiast w kółko przepisywać ten sam szablonowy początek).
Drobny, ale realny szczegół z materiałów Anthropic: opisy przepisów warto pisać trochę „napastliwie", bo model ma tendencję, żeby nie używać ich tam, gdzie powinien(Anthropic nazywa to „niedowyzwalaniem"). Lepiej, żeby opis mocno mówił „użyj mnie, gdy…".
4. Daj modelowi sposób, żeby sam sprawdził swoją robotę
Bezpośrednia rada: danie modelowi sposobu, żeby sam sprawdził swoją robotę, zanim Ci ją odda, to najmocniejsza dźwignia jakości. Jeśli może sam zobaczyć, czy zrobił dobrze, i poprawić się przed oddaniem, jakość rośnie skokowo. Wg Anthropic to właśnie takie sprawdzanie miało wewnętrznie największy mierzalny wpływ na jakość wyniku.
Sposób sprawdzenia dobierasz do zadania. Jeśli budujesz coś technicznego, sprawdzianem będą testy albo uruchomienie kodu; jeśli pracujesz z tekstem czy grafiką, ten sam pomysł działa tak samo dobrze. Kod da się sprawdzić testami. Wygląd strony — otwierając ją w przeglądarce i patrząc na realny efekt (Anthropic wymienia tu m.in. Playwright i nagrania). Tekst albo grafikę — narzędziem, które pilnuje, czy wynik trzyma Wasz styl i ton. Wspólny mianownik jest jeden: model dostaje twardy sygnał „to jest źle", zamiast zgadywać, czy trafił.
U nas ta zasada wygląda banalnie, a działa: przy zmianach na stronie każemy modelowi ją uruchomić, zrobić zrzut ekranu i samemu ocenić, czy element wygląda jak trzeba, a przy tekstach mamy sprawdzacz, który wyłapuje zwroty brzmiące jak AI. Model poprawia się sam, a my dostajemy gotowszy wynik.
5. Dobierz model do zadania
Bezpośrednia rada: nie każde zadanie wymaga najmocniejszego modelu. Do prostych, powtarzalnych rzeczy tańszy albo starszy model często wystarcza i kosztuje mniej. Traktuj to jak dobór narzędzia: młotek do gwoździa, nie do wszystkiego.
| Rodzaj zadania | Który model | Dlaczego |
|---|---|---|
| Trudne myślenie, projektowanie, szukanie błędu | Najmocniejszy | Koszt błędu jest wysoki, więc opłaca się najlepsza jakość. |
| Rutynowe zmiany, przepisywanie, porządki, proste rzeczy | Tańszy / starszy | Wystarcza, a różnica w cenie i szybkości jest realna. |
| Masowe, powtarzalne przebiegi (np. przez wiele plików) | Tańszy | Przy dużej ilości koszt się mnoży, więc każda oszczędność się liczy. |
Dwa nawyki wokół tego. Po pierwsze, model można przypisać na stałe do konkretnej procedury, więc dana robota zawsze rusza na właściwym modelu, bez Twojej decyzji za każdym razem. Po drugie, gdy historia rozmowy nie jest już potrzebna, warto zacząć na czysto — świeża rozmowa bywa i tańsza, i celniejsza niż ciągnięcie jednego długiego wątku.
6. Pilnuj pamięci rozmowy i rachunku za nią
Bezpośrednia rada: rozmowa z modelem ma dwie strony. Im więcej w nią wrzucisz, tym więcej model musi trzymać w swojej pamięci roboczej i tym większy robi się rachunek za rozmowę (to właśnie „kontekst" i „tokeny", o których słyszysz). Miej z tyłu głowy, ile już „nagadaliście", i czyść to świadomie, a nie dopiero, gdy rozmowa zaczyna gubić wątek.
Dwa różne ruchy, które łatwo pomylić. Kiedy chcesz zachować sens dotychczasowej rozmowy, ale odzyskać miejsce — streść ją (w Claude Code robi to /compact). Kiedy zaczynasz zupełnie nowe zadanie i stara rozmowa tylko przeszkadza — wyczyść ją do zera (/clear). Ciągnięcie jednego wątku bez końca ma dwie wady: płacisz za coraz większą rozmowę i topisz ważne polecenia w gąszczu starych wiadomości.
Dbanie o to nie jest skąpstwem, tylko jakością. Model, który ma przed sobą krótką i na temat rozmowę, odpowiada celniej niż ten, który przekopuje się przez pół dnia nieistotnej historii. Nasze krótkie zasady: nowe zadanie to nowa rozmowa; długi wątek streszczamy, zanim spuchnie; a przy automatyzacjach, które chodzą same, patrzymy na koszt, bo tam rachunek rośnie najszybciej.
7. Zbuduj system, który się uczy
Bezpośrednia rada: nie zaczynaj za każdym razem od zera. Spisz stałe zasady projektu w jednym miejscu, które model czyta na starcie każdej rozmowy (w Claude Code to plik CLAUDE.md, taka notatka „u nas robimy to tak"), i traktuj go jak żywy dokument, który rośnie z każdą wpadką.
Trzy elementy składają się na taki system. Pierwszy to właśnie ta notatka z zasadami, których model ma się trzymać, plus dopasowany start nowego projektu, żeby od razu miał te reguły u siebie. Drugi to dziennik tego, co i kiedy zostało zrobione: ślad, który działa jak dziennik pokładowy i pozwala wrócić do „jak to wtedy zadziałało". Trzeci to okresowy przegląd — raz na jakiś czas patrzysz wstecz i pytasz: co się tu powtarza i warto to naprawić albo zapisać jako gotowy przepis? To ta sama pętla, co przy „pułapkach", tylko na poziomie całego systemu, nie pojedynczej roboty.
Efekt się kumuluje. Każda naprawiona pułapka i każda spisana zasada to o jeden błąd mniej w przyszłym miesiącu. Po kwartale pracujesz w środowisku, które zna Wasze zasady, zamiast tłumaczyć je od nowa w każdej rozmowie.
Gdzie zostaje człowiek
Uczciwie: nie wszystko warto oddawać maszynie w całość, i nie o to tu chodzi. Wszędzie tam, gdzie w grę wchodzi ocena, wyczucie albo wysoki koszt błędu, lepiej działa wsparcie człowieka niż pełna automatyzacja. Zasada, którą się kierujemy: zostaw człowiekowi miejsca, w których sprawdza wynik, tam, gdzie pomyłka boli — przy płatnościach, publikacji na zewnątrz, danych klientów, rzeczach nie do cofnięcia.
Przed oddaniem czegokolwiek maszynie w całość zadaj sobie dwa pytania. Czy to zadanie wymaga wyczucia albo oceny, których model nie ma? I czy 80% jakości mi tu wystarczy? Jeśli tak — zostaw ostatnie słowo człowiekowi. Jeśli nie — spokojnie oddaj to automatowi.
| Kiedy decyduje człowiek (wspieramy) | Kiedy model działa sam (automatyzujemy) |
|---|---|
| Wysoki koszt błędu: płatności, wysyłka na zewnątrz, dane wrażliwe | Niski koszt błędu, łatwo cofnąć |
| Trzeba wyczucia lub oceny (styl, ton, decyzja strategiczna) | Da się prosto sprawdzić, czy wyszło dobrze |
| Rzadkie, nietypowe przypadki | Powtarzalne, przewidywalne, dużego wolumenu |
| 80% jakości to za mało | 80% jakości w zupełności wystarcza |
Kiedy już decydujesz się na automat, który chodzi sam (pętle, harmonogramy albo tak zwane hooki, czyli kod, który sam się odpala, gdy wydarzy się coś ustalonego), włączaj go z trybem treningowym: na start zatwierdzasz każdy krok ręcznie i dopiero, gdy widzisz, że działa poprawnie, puszczasz go luzem. Powód praktyczny: źle ustawiony automat potrafi po cichu przepalać pieniądze godzinami. Lepiej zobaczyć kilka przebiegów pod kontrolą, niż odkryć problem na rachunku.
Co to znaczy dla Twojego zespołu
Zauważ, że żaden z tych siedmiu nawyków nie jest o „lepszym wpisywaniu poleceń" ani o czekaniu na mocniejszy model. Wszystkie są o tym, jak układasz pracę wokół narzędzia: plan przed robotą, druga para oczu, spakowane przepisy, sprawdzanie własnej roboty, właściwy model, czysta rozmowa, system, który się uczy. To są rzeczy do wdrożenia, nie do kupienia.
Dlatego u nas nie uczymy „obsługi Claude Code", tylko tych nawyków na realnych procesach zespołu. Różnica między kimś, kto klika w AI w kółko tak samo, a kimś, kto ma dobry brief, kilku pomocników do sprawdzania i nawyk weryfikacji, to nie kilka procent. To inne tempo i inna jakość przy tym samym modelu. Pokazujemy to na warsztatach „Agenci AI" na Waszych zadaniach, nie na slajdach, bo sami budujemy w ten sposób własne projekty.
Jeśli w firmie wdrażasz takich pomocników do zadań, które dotykają treści idących na zewnątrz, warto od razu ułożyć miejsca, w których człowiek sprawdza wynik, zgodnie z obowiązkami AI Act. To dokładnie ta sama logika „gdzie zostaje człowiek", tylko widziana od strony prawa.
Najczęstsze pytania
Od ustalenia, co ma powstać, a nie od rzucania się do roboty. Poproś, żeby model najpierw przepytał Cię o szczegóły i spisał krótki brief, a dopiero potem zaczął. Bez tego model zgaduje, czego chcesz, a większość zgadywań trzeba potem poprawiać.
Nie. Do prostych, powtarzalnych rzeczy tańszy albo starszy model zwykle wystarcza i kosztuje mniej. Najmocniejszy zostaw na trudne myślenie, projektowanie i szukanie błędów.
Danie modelowi sposobu, żeby sam sprawdził swoją robotę, zanim Ci ją odda: podgląd w przeglądarce, testy albo narzędzie pilnujące stylu. Wg Anthropic to właśnie takie sprawdzanie miało wewnętrznie największy mierzalny wpływ na jakość wyniku.