O czym jest ten film
- Aktualizacja autorskiego warsztatu kodowania z AI: około 70% pracy w Claude Code (Opus 4.7, tryb maksymalny) i 30% w Cursorze (GPT 5.5 w wariancie extra high).
- Największy przełom autora: automatyzacja testowania. Xcode Build MCP — darmowe narzędzie od zespołu Sentry — buduje aplikację, steruje symulatorem, klika w interfejs, robi zrzuty ekranu i pobiera logi, dzięki czemu Xcode może pozostać zamknięty.
- Odpowiednik na webie: rozszerzenie Claude Chrome z poleceniem
claude --chromealbo wbudowana przeglądarka Cursora — koniec z ręcznym przeklejaniem logów i zrzutów. - Debugowanie na produkcji: Sentry, Axiom, Supabase i Firebase podpięte jako MCP lub CLI pozwalają zlecić modelowi całe „śledztwo” wokół zgłoszenia użytkownika — zamiast 45 minut składania układanki ręcznie, około 3 minuty.
- Reguła wyboru integracji: gdy usługa ma i MCP, i CLI, domyślnie wybieraj CLI — zjada mniej tokenów, a agenci lepiej sobie z nim radzą.
- Greptile (sponsor odcinka) — automatyczna recenzja każdego pull requesta; w porównaniu na około 60 PR-ach wypadł zauważalnie lepiej niż Bug Bot z Cursora; ocena 5/5 jako bramka przed publikacją.
- Remote control — kontynuowanie sesji Claude Code na telefonie; według samego twórcy narzędzia (Borisa) to najużyteczniejszy trik warsztatowy; przez
/configmożna ustawić autostart tej funkcji. - Cmux zamiast terminala Cursora: pasek boczny z projektami, powiadomienia wskazujące okno wymagające uwagi i minimalne zużycie RAM — 20 instancji działa płynnie tam, gdzie 5 w Cursorze dławi maszynę.
- Kontrowersyjna teza autora: GPT 5.5 extra high z oknem kontekstu miliona tokenów radzi sobie lepiej niż Opus 4.7 przy złożonych błędach, ale jest bardzo drogi — stąd strategia „tańszy model na co dzień, droższy na trudne zadania” (łącznie 400 USD miesięcznie).
- Podsumowanie „co warto przejąć”: automatyzacja testów, integracje MCP/CLI wszędzie, AI do przeglądu kodu, dokładny przegląd ustawień
/configi praca zdalna z telefonu.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zautomatyzuj testowanie na iOS przez Xcode Build MCP
Na czym polega: Darmowy serwer MCP od zespołu Sentry daje Claude Code i Cursorowi około 90% możliwości Xcode: budowanie aplikacji, uruchamianie symulatora, klikanie w interfejs, zrzuty ekranu i pobieranie logów. Model nie tylko naprawia błąd, ale sam go weryfikuje.
Jak stosować: Podłącz MCP do Claude Code i przy każdym błędzie wydawaj jedno polecenie: „wprowadź zmianę i sprawdź w symulatorze, czy działa”. Możesz zostawić Xcode zamknięty i wrócić po 20–30 minutach do sprawdzonej poprawki.
Na co uważać: Około 10% przypadków zostaje poza zasięgiem: ustawienia dostępne wyłącznie w Xcode (szybciej zmienić ręcznie) oraz gesty wielodotykowe, np. przestawianie elementów listy — te testuj sam, choć odczyt logów po teście możesz oddelegować modelowi.
2.Testy webowe bez przeklejania logów
Na czym polega: Wtyczka Claude Chrome plus polecenie claude --chrome dają modelowi żywą instancję przeglądarki: klika, robi zrzuty ekranu i czyta konsolę. W Cursorze to samo zapewnia wbudowana przeglądarka.
Jak stosować: Przy poprawkach w aplikacji webowej zlecaj pełną pętlę: napraw → zweryfikuj w przeglądarce → działaj dalej, aż problem zniknie. Bez tej pętli łatwo wrócić do ręcznego kopiowania zrzutów i komunikatów z konsoli — i to właśnie tam ginie najwięcej czasu.
Na co uważać: Automatyzacja działa tylko wtedy, gdy model faktycznie dostanie dostęp do przeglądarki — zadbaj o poprawną instalację wtyczki przed pierwszym użyciem.
3.Debugowanie produkcji przez MCP i CLI
Na czym polega: Sentry, Axiom, Supabase i Firebase podpięte bezpośrednio do Claude Code. Zgłoszenie użytkownika o awarii wystarczy przekazać modelowi — sam pobierze dane konta, raporty crashy, wersję systemu użytkownika, miejsce błędu w kodzie i logi z backendu.
Jak stosować: Skonfiguruj swoje usługi (monitoring błędów, baza danych, logi serwerowe) jako MCP albo CLI i zamień przeskakiwanie między zakładkami na jedno zlecenie w języku naturalnym. Autor podaje efekt: 45 minut pracy ręcznej schodzi do około 3 minut.
Na co uważać: Jakość wyników zależy od konfiguracji źródeł — bez poprawnego mapowania awarii na miejsca w kodzie (jak w Sentry) model dostaje znacznie mniej użytecznych danych.
4.Wybieraj CLI zamiast MCP, gdy masz wybór
Na czym polega: Według inżynierów, z którymi rozmawiał autor, interfejsy wiersza poleceń są w większości przypadków oszczędniejsze dla okna kontekstu — zużywają mniej tokenów niż serwery MCP. Agenci też lepiej sobie z nimi radzą.
Jak stosować: Przy integracji usługi, która oferuje obie opcje, domyślnie bierz CLI; MCP zostaw na przypadki, gdy CLI nie istnieje.
Na co uważać: Różnica nie jest na tyle duża, żeby opłacało się tracić godziny na optymalizację — oba warianty działają dobrze.
5.Automatyczny przegląd kodu dla jednoosobowego zespołu
Na czym polega: Greptile recenzuje każdy otwarty pull request i wytyka problemy. W porównaniu autora na około 60 PR-ach wypadł zauważalnie lepiej niż Bug Bot z Cursora, a na około 95% pull requestów łapał przynajmniej jedną zasadną uwagę.
Jak stosować: Załóż konto, podłącz repozytoria, włącz przełącznik — każdy nowy PR dostaje recenzję automatycznie. Koszt to około 30 USD miesięcznie, z 14-dniowym okresem próbnym bez podawania karty.
Na co uważać: Odcinek jest sponsorowany przez Greptile — warto o tym pamiętać, choć autor deklaruje, że korzystałby z usługi niezależnie od sponsoringu.
6.Pętla „recenzuj i poprawiaj” aż do oceny 5/5
Na czym polega: Greptile wystawia pull requestom ocenę liczbową. Autor każe Claude Code poczekać na koniec recenzji, wdrożyć zasadne uwagi i powtarzać cykl, aż padnie piątka — dopiero wtedy PR idzie na produkcję.
Jak stosować: Połącz narzędzie do przeglądu z agentem w jedną samonapędzającą się pętlę i traktuj ocenę jako bramkę jakości. To sposób na zastąpienie drugiej pary oczu, gdy rozwijasz projekt sam.
Na co uważać: Piątka nie zwalnia z własnej wiedzy o produkcie — recenzent AI nie zna kontekstu biznesowego, więc kluczowe zmiany (migracje, bezpieczeństwo) weryfikuj osobiście.
7.Remote control — sesja Claude Code w kieszeni
Na czym polega: Polecenie /remote-control przenosi bieżącą sesję Claude Code z komputera na telefon (aplikacja Claude, sekcja Code), z pełną synchronizacją między urządzeniami. To właśnie tę funkcję wskazał twórca narzędzia jako najbardziej wartościowy trik warsztatowy.
Jak stosować: Włącz /remote-control, a przez /config ustaw, by sesja zdalna startowała automatycznie przy każdym uruchomieniu — wtedy żadne wyjście z domu nie przerywa pracy.
Na co uważać: Autor sam przyznaje, że to uzależnia i „trochę niezdrowe”. Odpowiednik w Cursorze (Cloud Agents) ma dostęp tylko do zdalnych MCP — podpięcie lokalnych integracji wymaga uciążliwej konfiguracji.
8.Cmux zamiast terminala w IDE
Na czym polega: Cmux to nakładka na Claude Code z paskiem bocznym projektów, wieloma oknami, powiadomieniami wskazującymi instancję wymagającą uwagi — i bardzo małym zużyciem pamięci. Autor płynnie uruchamia 20 instancji tam, gdzie 5 w terminalu Cursora dławiło komputer z M4 Max i 64 GB RAM.
Jak stosować: Jeśli pracujesz równolegle nad wieloma projektami, przenieś Claude Code z terminala IDE do Cmux i traktuj powiadomienia jako sygnalizator, z którą instancją trzeba się zająć.
Na co uważać: To zmiana organizacyjna, nie merytoryczna — zyskujesz wygodę i RAM, ale musisz się pogodzić z pracą poza środowiskiem Cursora.
9.Zanim ocenisz „głupotę” agenta, sprawdź model i tryb myślenia
Na czym polega: Nowe sesje Claude Code domyślnie startują w trybie średnim. Autor zauważa, że gdy ktoś narzeka na jakość odpowiedzi, w ponad połowie przypadków pracuje na Sonecie w trybie medium — i to, a nie „głupota” narzędzia, jest przyczyną.
Jak stosować: Ustaw flagę wymuszającą start sesji w wybranym trybie (np. maksymalnym), a przy słabych wynikach najpierw sprawdź konfigurację, zanim zarzucisz pracę.
Na co uważać: Maksymalny tryb nie jest konieczny do wszystkiego — do większości zadań wystarczy wyższy lub średni poziom, a wyższy tryb szybciej wyczerpuje limity planu.
10.Dwa modele do dwóch typów zadań — i świadomy budżet
Na czym polega: Autor dzieli pracę: na co dzień Opus 4.7 w trybie maksymalnym w Claude Code, a przy bardzo złożonych błędach pełnych przypadków brzegowych — GPT 5.5 extra high z oknem kontekstu miliona tokenów w Cursorze. Przy funkcji zadań cyklicznych (około 50 miejsc w kodzie, kilka repozytoriów, kilkanaście przypadków brzegowych) Opus naprawiał jeden błąd, psując dwa trzy inne, a GPT 5.5 załatwiał temat w jednym, dwóch podejściach.
Jak stosować: Zacznij od tańszego modelu; gdy utyka albo z góry wiesz, że zadanie jest wyjątkowo złożone, przeskocz do mocniejszego. Łączny koszt 400 USD miesięcznie autor uzasadnia tym, że żyje z budowania aplikacji.
Na co uważać: Drogi model błyskawicznie wypala środki z planu (widoczne już po kilku dniach) i to przerost formy nad treścią dla około 90% zadań. Porównanie obu modeli to subiektywna ocena autora — przetestuj je na własnym kodzie.
Redakcyjne tłumaczenie
Wprowadzenie: co nowego od ostatniego razu
Od ostatniego odcinka o moim warsztacie kodowania minęło kilka miesięcy, ale zmieniło się na tyle dużo, że wreszcie czas na aktualizację. W tym materiale pokazuję wszystkie nowości, które wdrożyłem: dlaczego płacę osobno za Claude Code i za Cursora, jak zautomatyzowałem testowanie na iOS i w webie, a także kilka funkcji, które kompletnie odmieniły moją pracę.
Jeśli trafiasz tu pierwszy raz — nazywam się Chris i buduję aplikacje wspomagające produktywność. Krótkie zastrzeżenie: ten odcinek jest dla nieco bardziej zaawansowanych i skupiam się w nim wyłącznie na nowościach. Podstawy — tryb planowania, tryb debugowania, dyktowanie — opisałem w starszych filmach, linki zostawiam w opisie. Dziś mowa o rzeczach nowszych i mniej oczywistych.
Modele, na których pracuję
Zanim wejdziemy w konkret, słowo o modelach. W Claude Code pracuję na Opusie 4.7 — zawsze w najwyższym trybie „myślenia” (max mode) — a w Cursorze na GPT 5.5 w wariancie extra high. W chwili nagrania to najświeższe dostępne wersje. Około 70% mojej pracy z kodem odbywa się w Claude Code, pozostałe 30% w Cursorze. Kiedy i po czym przełączam się między nimi — wyjaśniam dalej.
Największy przełom: automatyczne testowanie na iOS
Największą zmianę ostatnich miesięcy zafundowałem sobie sam: sprawiłem, że Claude Code i Cursor korzystają z moich aplikacji i same je testują. Standardowa pętla — pewnie wielu z was zna ją z autopsji — wygląda tak: model wprowadza poprawkę, ja ręcznie odpalam symulator i sprawdzam, czy zadziałało.
Na iOS trafiłem niedawno na Xcode Build MCP: darmowy serwer MCP przygotowany przez ludzi z Sentry. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard pozwalający modelom AI sięgać po zewnętrzne narzędzia i usługi — bazy danych, systemy monitoringu itd. Sentry to z kolei popularna platforma do śledzenia błędów i awarii aplikacji.) Po podłączeniu tego serwera Claude Code albo Cursor potrafią zbudować aplikację, wystartować symulator, klikać w elementy interfejsu, robić zrzuty ekranu i pobierać logi — czyli około 90% tego, co robi się w Xcode.
Dziś przy naprawianiu błędu wystarczy jedno polecenie: „wprowadź tę zmianę, a potem sprawdź w symulatorze przez Xcode Build MCP, czy wszystko działa”. Gdy model kończy, symulator otwiera się sam, Claude Code przejmuje nad nim stery i zaczyna klikać oraz testować za mnie. Ma dostęp do zrzutów ekranu i logów, więc koniec z kopiowaniem komunikatów z Xcode i przeciąganiem obrazów do okna czatu — wszystko załatwia się samo. Dzięki temu przy pracy nad aplikacjami na iOS mogę w ogóle nie otwierać Xcode: wystarczy Claude Code, który załatwia niemal wszystko, co trzeba.
Zostaje jakieś 10% rzeczy, których to MCP nie obejmuje. Po pierwsze ustawienia dostępne wyłącznie w Xcode — tam po prostu szybciej otworzyć środowisko i przestawić je ręcznie. Po drugie testy wymagające złożonych gestów wielodotykowych. W mojej aplikacji do planowania dnia można zmieniać kolejność pozycji na liście — tego narzędzie przetestować za mnie nie potrafi, więc ten fragment weryfikuję osobiście. Ale ponieważ ma dostęp do logów, po moim ręcznym sprawdzeniu może je od razu odczytać — przynajmniej ta część dzieje się już bez mojego udziału.
Testy w webie: Claude z Chrome
W webie sprawa jest jeszcze prostsza. Korzystam z rozszerzenia Claude with Chrome: zasada podobna jak przy symulatorze, tylko zamiast środowiska testowego dajesz modelowi żywą instancję przeglądarki Google Chrome. Instalujesz wtyczkę Claude Chrome, uruchamiasz polecenie claude --chrome i od tej chwili Claude steruje przeglądarką: testuje aplikację, robi zrzuty ekranu, a nawet czyta konsolę. Koniec z przeklejaniem logów między Chrome a Claude Code. A jeśli pracujesz w Cursorze, masz jeszcze łatwiej — wbudowana przeglądarka robi to wszystko sama.
Dla kontrastu: kiedyś moja pętla wyglądała tak. Mówiłem Claude Code, że coś nie działa. On wprowadzał poprawkę. Ja ręcznie sprawdzałem, czy naprawa zadziałała. Jeśli nie — robiłem zrzuty ekranu, wklejałem komunikaty z konsoli, wracałem z wiadomością „nadal nie działa, spróbuj jeszcze raz” i tak w kółko, aż problem znikał.
Dziś wystarczy jedno zlecenie: „napraw problem, zweryfikuj go przez Xcode Build MCP albo Claude with Chrome i działaj dalej, aż się uda”. Zostawiam Claude Code na dwadzieścia, trzydzieści minut i wracam do gotowej, sprawdzonej poprawki. Poza samym czasem zyskuję coś jeszcze: mogę zostawić narzędzie bez nadzoru na dłużej i w spokoju zająć się czymś innym — przełączanie się między zadaniami przestaje boleć.
Drugi wielki przełom: MCP i CLI w debugowaniu produkcji
Skoro mowa o automatyzacji — druga kluczowa zmiana to znacznie intensywniejsze korzystanie z MCP i CLI. Kiedy nagrywałem poprzedni film o Claude Code, używałem ledwie MCP Supabase. Dziś nie wyobrażam sobie pracy bez tych integracji.
Jak to wygląda na przykładzie mojej aplikacji działającej na produkcji? Dostaję od użytkownika wiadomość: „Chris, aplikacja wywala się, kiedy otwieram ekran ustawień”. Jeszcze niedawno poświęciłbym na takie zgłoszenie dobre godzinę. Weszlibyśmy do Sentry po raporty awarii, do bazy danych, żeby sprawdzić, czy dane tego użytkownika się nie uszkodziły, czasem jeszcze do Axiom po logi z serwera — i tak po kolei, żeby z kilku usług złożyć w głowie jedną spójną historię.
Dziś wszystkie te usługi mam podpięte do Claude Code jako MCP albo CLI, więc mówię po prostu: „ten użytkownik, ten adres e-mail, zgłosił awarię na ekranie ustawień — ustal, co się stało. Śmiało zajrzyj do Sentry, Axiom, Supabase czy Firebase przez dostępne CLI i MCP”. Model sięga po MCP Supabase i wyciąga dane konta, patrzy, czy ustawienia nie wyglądają podejrzanie. Sprawdza w Sentry, czy są awarie tego konkretnego użytkownika, przy okazji jakiej wersji iOS używa i czy coś nie rzuca się w oczy przy jego urządzeniu — może problemem jest starszy system operacyjny. Przy poprawnie skonfigurowanym Sentry — takim jak moje — widać nawet miejsce w kodzie, gdzie doszło do błędu. A gdyby były potrzebne logi z backendu, model ma pod ręką Axiom, w którym trzymam całe logowanie.
Składanie tej układanki zajmowało mnie około 45 minut. Claude Code ogarnia ją w jakieś trzy minuty. Prawie każda poważna usługa dla programistów ma dziś swoje MCP albo CLI i nie widzę powodu, żeby z tego nie korzystać.
CLI czy MCP? Krótka wskazówka
Jeśli zastanawiasz się, co wybrać, gdy usługa oferuje obie opcje — moim domyślnym wyborem jest CLI. Rozmawiałem o tym z inżynierami, którzy znają się na tym lepiej ode mnie, i ich zdaniem interfejs wiersza poleceń jest w większości przypadków oszczędniejszy dla okna kontekstu: zjada dużo mniej tokenów niż serwery MCP. Mam też wrażenie, że agenci po prostu lepiej radzą sobie z CLI niż z MCP. Ale szczerze mówiąc — oba warianty są w porządku i trudno tu o zły wybór.
Przegląd kodu: Greptile i pętla do piątki
Kolejny element warsztatu: code review. To najczęstsze pytanie, jakie dostaję pod filmami. Ostatnio wdrożyłem usługę Greptile — i tu ukłon w stronę sponsorów tego odcinka. Ale nawet gdyby mnie nie sponsorowali, i tak byłoby to moje podstawowe narzędzie.
Greptile to serwis AI recenzujący kod: ilekroć otwieram pull request w którejkolwiek z moich aplikacji, dostaję automatyczną recenzję z wykazaniem problemów. Dla mnie to bezcenne, bo rozwijam swoje projekty całkowicie sam — nie mam drugiej pary oczu, a codziennie wystawiam mnóstwo PR-ów. Wcześniej używałem Bug Bota z Cursora, ale przeszedłem na Greptile i nie wiem, jak im się to udało: recenzuje wyraźnie lepiej. Przez ostatnie półtorej miesiąca puszczałem oba narzędzia równolegle na około 60 pull requestach i Greptile wypadł w tym starciu zdecydowanie korzystniej.
Chcesz zobaczyć, jak to wygląda w praktyce? Niedawno otworzyłem kod źródłowy mojego agenta AI — repozytorium ma skonfigurowanego Greptile, więc w zakładce z pull requestami możesz obejrzeć jego komentarze i ocenić go w akcji. Na jakieś 95% moich PR-ów wyłapał przynajmniej jedną zasadną uwagę. Konfiguracja jest banalna: zakładasz konto, podpinasz repozytoria, włączasz przełącznik — od tej chwili każdy nowy PR dostaje recenzję automatycznie.
Mój konkretny sposób pracy, który sam w sobie był dla mnie odkryciem: gdy wysyłam nową funkcję, otwieram PR, Greptile go recenzuje, a ja każę Claude Code: „poczekaj, aż Greptile skończy, przejrzyj wszystkie uwagi, popraw to, co zasadne, i działaj w pętli, aż Greptile wystawi piątkę”. Greptile ocenia pull requesty w skali — mój model iteruje więc do piątki na pięć i dopiero wtedy wiem, że PR można wypuszczać. Link do usługi zostawiam w opisie: 14 dni testu bez podawania karty, abonament jakieś 30 dolarów miesięcznie. Za spokojny sen jednoosobowego zespołu — warto.
Remote control: sesja Claude Code w kieszeni
Kolejna funkcja — myślałem, że wszyscy o niej wiedzą, a ludzie za każdym razem są zaskoczeni. Nazywa się remote control i pozwala kontynuować sesję Claude Code prowadzoną na komputerze — na telefonie albo innym komputerze stacjonarnym. Ja korzystam głównie z telefonu, co ratuje mi sytuację, bo wciąż zdarza mi się wychodzić z domu w środku sesji kodowania.
Działa to tak: gdy Claude Code pracuje u ciebie na komputerze, wpisujesz /remote-control i tę samą sesję możesz prowadzić dalej na telefonie. W aplikacji Claude przechodzisz do sekcji Code, sesja pojawia się tam i kontynuujesz ją, jakby nic się nie stało — wszystko synchronizuje się między urządzeniami. Przerywa mi się coś w połowie roboty, muszę iść do sklepu? Sesja jedzie dalej ze mną. Pewnie trochę niezdrowo, ale przyznaję się bez bicia.
Miałem okazję rozmawiać z Borisem — twórcą Claude Code — i zapytałem go, jaka funkcja jest według niego najfajniejsza i co stanowi jego największy trik warsztatowy. Wskazał właśnie tę. Dorzucił jeszcze wskazówkę: poleceniem /config można ustawić, żeby każde uruchomienie Claude Code od razu włączało sesję remote control. Tak u siebie mam.
A czy Cursor ma odpowiednik? Są Cursor Cloud Agents i działają naprawdę dobrze — wciąż używam ich do niektórych rzeczy. Wolę jednak remote control w Claude Code, bo tam model ma dostęp do wszystkich moich lokalnych MCP i CLI. Cloud Agenty Cursora ograniczają się do garstki zdalnych MCP. Da się obejść to ograniczenie i podpiąć konkretne CLI czy lokalne serwery, ale konfiguracja jest na tyle uciążliwa, że — mówiąc szczerze — nie chciało mi się w to bawić.
Cmux — czyli w czym uruchamiam Claude Code
W kwestii samego uruchamiania: Claude Code prowadzę w aplikacji Cmux, a Cursor to po prostu Cursor. W starszych filmach trzymałem Claude Code w terminalu Cursora — zmieniłem to z trzech powodów.
Po pierwsze, Cmux ma wygodny pasek boczny: po lewej widzę wszystkie projekty, po prawej otwieram dowolną liczbę okien. Żonglowanie kilkoma projektami naraz, co u mnie jest codziennością, staje się naprawdę proste.
Po drugie, są wbudowane powiadomienia. Gdy któraś instancja Claude Code domaga się uwagi, dostaję sygnał, a po kliknięciu otwiera się właściwe okno — jeszcze dodatkowo podświetlone. Niezbędne, jeśli — jak ja — trzymasz naraz dziesięć instancji.
Po trzecie, i to chyba najważniejsze: Cmux jest nadzwyczaj lekki dla pamięci. Claude Code w terminalu Cursora potrafi pochłonąć tyle RAM-u, że komputer wyraźnie zwalnia — a mówimy o bardzo mocnej maszynie: M4 Max z 64 GB RAM. Przy pięciu instancjach w Cursorze sprzęt już się dławi. W Cmux spokojnie odpalam ich dwadzieścia i wszystko pracuje płynnie — zużycie pamięci jest minimalne.
Ustawienia modelu i trybu myślenia
W samym Claude Code pracuję na Opusie 4.7 w trybie max, czyli najwyższym dostępnym poziomie „myślenia”. Mam plan Max za 200 dolarów miesięcznie i jak dotąd nie wpadłem na limity użycia.
Praktyczna sztuczka: każda nowa sesja Claude Code domyślnie startuje w trybie średnim. Męczyło mnie ręczne przestawianie na maksimum, więc poszukałem — i znalazłem flagę, którą ustawia się raz, po czym każda kolejna sesja od razu rusza z najwyższym trybem. Tak mam skonfigurowane. Szczerze: do większości zadań spokojnie wystarczyłby wyższy poziom, a nawet średni — maksimum włączam, bo po prostu mam ten droższy plan.
Przy okazji: ludzie często mówią mi, że Claude Code „nie ogarnia”, że nie jest aż tak inteligentny. Proszę ich wtedy o jedno — sprawdź, na jakim modelu pracujesz i w jakim trybie myślenia. W ponad połowie przypadków okazuje się, że siedzą na Sonecie w trybie średnim. I to jest właśnie cała zagadka. Do typowych zadań takie ustawienie może wystarczy, ale niemal wszystko, czym ja się zajmuję, wymaga Opusa w trybie maksymalnym, żeby wyniki były najlepsze.
Tryb „no flicker” — drobiazgi, które czuć
Mam też włączony tryb „no flicker” — w chwili nagrania to jeszcze beta. To nowy sposób renderowania interfejsu w terminalu; funkcjonalnie nic nie tracisz, ale kilka rzeczy działa inaczej. Na przykład przy przewijaniu rozmowy pasek wpisywania tekstu zostaje przypięty do dołu ekranu, a dodatkowy przycisk pozwala jednym kliknięciem wrócić na sam koniec. Samo przewijanie jest też po prostu płynniejsze.
Największa zmiana jest jednak inna: klikasz w dowolne miejsce pola tekstowego i kursor przeskakuje dokładnie tam, gdzie kliknąłeś. W domyślnym Claude Code trzeba było przesuwać kursor wielokrotnym naciskaniem strzałek, bo klikanie nie działało wcale — irytujące. Do tego dochodzi jeszcze kilka drobnych udogodnień; te dwa odczułem najbardziej. Pełną listę łatwo znaleźć w sieci — polecam włączyć, bo to wyraźny krok w jakości codziennej pracy. Wystarczy ustawić właściwą flagę, którą pokazuję na ekranie.
Po co mi Cursor: dwa modele do dwóch typów zadań
Wspominałem na początku, że około 30% zadań robię w Cursorze. Po co, skoro Claude Code zwykle wystarcza? Są sytuacje, w których Opus 4.7 — nawet w trybie maksymalnym — po prostu nie daje rady. Chodzi w szczególności o bardzo złożone błędy pełne przypadków brzegowych. Wtedy przeskakuję do Cursora i uruchamiam GPT 5.5 w wariancie extra high z oknem kontekstu o pojemności miliona tokenów.
Prawdopodobnie najbardziej kontrowersyjna teza w całym odcinku: w moim doświadczeniu GPT 5.5 extra high z milionem tokenów kontekstu wypada lepiej niż Opus 4.7 w trybie maksymalnym w większości zadań — zwłaszcza tych naprawdę złożonych. Przykład: funkcja zadań cyklicznych w mojej aplikacji do planowania dnia. To istny potwór złożoności: dotyka około pięćdziesięciu miejsc w bazie kodu, rozrzuconych po kilku repozytoriach, a kiedy coś się sypie, trzeba uwzględnić kilkanaście przypadków brzegowych. Za każdym razem, gdy brał się za to Opus 4.7, naprawiał jeden błąd, ale po drodze psuły się dwie, trzy inne rzeczy. GPT 5.5 w wariancie extra high zwykle przemyśla te przypadki z góry i załatwia temat w jednym, maksymalnie dwóch podejściach.
Dlaczego więc nie używać go wszędzie? Cena. To absurdalnie drogi model. Mam plan Cursor Ultra za 200 dolarów miesięcznie i widzę, że środki z planu znikają po zaledwie kilku dniach pracy na tym modelu. Do tego dla około 90% moich zadań to ogromny przerost formy nad treścią. Stąd moja zasada: pierwszeństwo ma Opus 4.7 w Claude Code, a na GPT 5.5 extra high z milionem kontekstu przeskakuję wtedy, gdy tamten utyka albo kiedy od razu przeczuwam, że zadanie go przerośnie.
Tak, płacę 200 dolarów za plan Max i 200 za Cursor Ultra — 400 dolarów miesięcznie za narzędzia AI. Utrzymuję się jednak z budowania aplikacji, więc ta kwota po prostu się broni.
A co z Codexem?
Pewnie ktoś zapyta: czemu nie Codex zamiast Cursora? Plan Codexu mam, do testów, ale po prostu znacznie bardziej odpowiada mi praca w Cursorze i wolę sięgać po niego, gdy tylko się da. Przyznaję jednak, że Codex ma wyśmienitą aplikację na Maca, a podobno szykuje się wersja na iPhone’a — będę ją testował na bieżąco i jeśli coś się zmieni, dowiecie się pierwsi.
Podsumowanie: co warto przejąć
Krótkie zebranie całości — cztery rzeczy, które warto sobie „ukraść”.
Po pierwsze: jeśli budujesz na iOS, użyj Xcode Build MCP, żeby wyrugować Xcode z codziennej pracy; na webie — Claude with Chrome albo wbudowanej przeglądarki Cursora. Jeśli jeszcze nie próbowałeś zautomatyzować testów, koniecznie to zrób. To jedna z tych rzeczy, które „klikają” dopiero, gdy się ich dotknie — a po takim przejściu nie ma już powrotu.
Po drugie: sięgaj po MCP i CLI wszędzie, gdzie się da. W debugowaniu produkcji to dla mnie skok o klasę wyższą. Mam wrażenie, że słowo „przełom” padło w tym odcinku sto razy — ale te rzeczy naprawdę nim są.
Po trzecie: zadbaj o automatyczny przegląd kodu, choćby Greptile. Jako jednoosobowy zespół nie mam nikogo do oceny pull requestów, a to rozwiązanie pozwala mi spać spokojnie.
Po czwarte: poświęć chwilę na konfigurację Claude Code. Polecenie /config pokazuje pełną listę ustawień — przejrzyj je wszystkie i dopasuj narzędzie do własnego sposobu pracy. A jeśli nie próbowałeś remote control i kodowania z telefonu — spróbuj. Uprzedzam: uzależnia i pewnie trochę mi to szkodzi, ale możliwość wleczenia sesji za sobą w biegu jest dla mnie bezcenna.
To wszystkie nowości. Podstawy mojego warsztatu znajdziesz w dwóch starszych filmach — linki w opisie. Jeśli podobają ci się takie treści, zajrzyj na mój Instagram i TikTok, gdzie publikuję niemal co drugi dzień o budowaniu aplikacji. I oczywiście — zasubskrybuj. Dzięki za obejrzenie i do zobaczenia w następnym odcinku.