O czym jest ten film
- Odcinek w formacie „potluck”: Scott Tolinski i Wes Bos ze Syntax odpowiadają na pytania słuchaczy o codzienną pracę z AI.
- Jak dziś wyróżnić się jako specjalista, skoro klasyczne blogowanie traci zasięgi, a GitHub zalewa wygenerowany automatycznie kod.
- Co robić w czasie, gdy agent pracuje — i jak przerwy w skupieniu zamieniać w backlog dopracowanych zadań.
- Budżety AI w firmach: ile pracodawcy realnie płacą (najczęściej 200–500 USD miesięcznie na osobę) i dlaczego świadomość kosztu tokenów to nowa, obowiązkowa umiejętność.
- Subskrypcje za około 200 USD miesięcznie jako najlepszy obecnie stosunek ceny do pozyskanych tokenów — wraz z pomysłem na mierzenie zużycia.
- Maile transakcyjne (reset hasła, powitalne): własne szablony, standardowe API i unikanie uzależnienia od jednego dostawcy.
- Utrzymanie agentów w ryzach: hooki, listy zakazów, reguły, testy automatyczne i izolacja — a także sztuka wtrącania się w trakcie pracy agenta.
- Jak przekonać zespół inżynierów do pracy agentowej bez efektownych dem — poprzez kulturę dzielenia się procesem.
- Interfejsy do sterowania agentami niekodującymi: od Telegrama, przez czatowe aplikacje typu GrokBot czy Muse, po własne, dedykowane konstrukcje.
- Firmowy „mega-harness” kontra małe agenty z człowiekiem-orkiestratorem — plus motywacja do kodowania w erze AI i porządki z procesami działającymi w tle.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wyróżniaj się opiniami i procesem, nie „zrobiłem to jednym promptem”
Na czym polega: rynek zalewa treść, więc sama publikacja przestała działać. Ludzi — i rekruterów — interesują osoby, które weszły w temat głębiej niż szybkie demo i mają na jego temat zdanie. GitHub pełen wygenerowanego chłamu przestał być dowodem umiejętności.
Jak stosować: publikuj krótkie, konkretne notki z własnych prac: „miałem problem z X, tak go rozgryzłem”, tekst plus zrzuty ekranu. Krótkie wideo traktuj jako trening komunikacji: umieć powiedzieć w minutę, czym się pasjonujesz i co sądzisz.
Na co uważać: treści łatwe do wygenerowania tracą wartość — czytelnik wyczuwa wytwór AI po jednym akapicie. Nie musisz przy tym robić z siebie influencera.
2.Czas oczekiwania na agenta zamieniaj na backlog problemów
Na czym polega: nawet dwie–trzy minuty przerwy rozwijają ciąg pracy i wybijają ze skupienia. Zamiast scrollować media społecznościowe, warto w tym czasie przeglądać aplikację i szczegółowo zapisywać, co jest nie tak — bo doprecyzowanie problemu trwa dłużej niż sama tura agenta.
Jak stosować: ustaw agenta-orkestratora przetwarzającego zgłoszenia z GitHuba oraz osobnego, taniego asystenta, który zamienia twoje luźne notatki na dopracowane issue. Unikaj ogólnikowych poleceń typu „zmodernizuj UI”.
Na co uważać: równoległa praca wieloma agentami wyczerpuje psychicznie. Jeśli agent zbyt często schodzi na manowce, to zwykle sygnał, że za rzadko mu się przyglądasz.
3.Mierz zużycie tokenów — subskrypcje stałej opłaty zwykle wygrywają
Na czym polega: subskrypcja za ok. 200 USD miesięcznie daje tokeny wielokrotnie przewyższające ich wartość przy rozliczeniu przez API. Scott zgłasza tygodnie, w których „skonsumował” tokeny warte 1100 USD, nie płacąc nic zbliżonego do tej kwoty.
Jak stosować: podepnij subskrypcje do licznika zużycia (np. Codex Bar) i oglądaj tygodniowe raporty. Jeśli firma oferuje sfinansowanie takiej subskrypcji — bierz.
Na co uważać: rozliczenie per token, typowe w umowach enterprise, bywa znacznie gorszym interesem. A chwalenie się „wyczerpanymi do limitu” subskrypcjami to często gadanie, nie wyniki.
4.Wprowadź w firmie jawne budżety AI z możliwością eskalacji
Na czym polega: firmy przeszły w pół roku drogę od „nielimitowanej magicznej skrzynki” do kontroli wydatków. Typowe widełki to 200–500 USD miesięcznie na osobę — tymczasem developer budujący nowe funkcje potrafi wydać 1000 USD dziennie.
Jak stosować: ustal limit bazowy i prostą ścieżkę podniesienia („przepisujemy moduł na Rusta, potrzebuję tokenów za X”). Buduj świadomość kosztu tak, jak kiedyś budowano świadomość wydajności kodu: sprawdzaj, co daje tańszy model.
Na co uważać: tania automatyzacja w tle potrafi kosztować tysiące dolarów dziennie (np. agent sprawdzający pocztę co dwie minuty). Ranking „kto spalił najwięcej tokenów” premiuje marnotrawstwo.
5.Maile transakcyjne rób na standardach, nie u jednego dostawcy
Na czym polega: HTML-e mailowe są proste — wystarczy silnik szablonów z komponentami wielokrotnego użytku, renderowanie do HTML i wplecenie stylów. Dostawcy (Resend, Postmark, SES, SendGrid) różnią się ceną i dostarczalnością, a ta bywa loteryjna.
Jak stosować: trzymaj się standardowych mechanizmów wysyłki, żeby móc się przenieść, gdy dostarczalność spadnie. Dla małych projektów rozważ rozliczenie za wiadomość (AWS SES) lub darmowe limity typu 100 maili miesięcznie.
Na co uważać: „darmowe” wysyłki lądują w spamie, a nawet 2% maili w spamie to realne, mierzalne pieniądze. Przesiadka dostawcy to zawsze ryzyko — testuj przed migracją.
6.Ogradzaj agentów warstwą deterministyczną
Na czym polega: model nigdy nie będzie w pełni przewidywalny, ale jego otoczka może. Hooki potrafią zablokować niebezpieczną komendę, listy zakazów i reguły zawężają pole działania, testy pilnują jakości, a kontenery ograniczają szkody.
Jak stosować: pisz reguły negatywne („nie dodawaj zabezpieczeń do każdego przypadku”), twórz testy jakościowe (np. pomiar liczby klatek w przeglądarce po każdej dodanej funkcji) i wyznaczaj z góry ścieżki dla powtarzalnych zadań — automatyzacja zwraca status i instrukcję, zamiast pozwalać agentowi improwizować.
Na co uważać: nadmiar reguł i „skillów” sam zamula system i podbija koszt tokenów. Izolacja w kontenerach brzmi bezpiecznie, ale na co dzień bywa niepraktyczna.
7.Wtrącaj się świadomie: zatrzymanie i doprecyzowanie zwykle wygrywa
Na czym polega: narzędzia różnie obsługują uwagi wplecione w trakcie tury agenta: niektóre przerywają całość, inne kolejkują wiadomość na następną turę, jeszcze inne czekają do końca i się cofają. „Wtrącenia przy okazji” bywają za wolne.
Jak stosować: jeśli nowa informacja jest pilna — zatrzymaj, popraw polecenie, wznowić. Jeśli nie — dopisz ją do następnej tury, która często nadchodzi w 20–30 sekund. Poznaj zachowanie swojego narzędzia i miej jeden sprawdzony nawyk.
Na co uważać: ciągłe korygowanie w locie rozprasza i rozrywa pracę. Zanim się wtrącisz, zdecyduj, czy sprawa naprawdę nie może poczekać pół minuty.
8.Zespołu nie przekonasz demem, tylko procesem
Na czym polega: pokaz „spójrz, co zrobiłem jednym promptem” buduje opór i utrwala mur nieufności. Ludzi przekonuje widok realnego sposobu pracy i korzyści dla nich samych — to problem relacji, nie technologii.
Jak stosować: krótkie wewnętrzne prezentacje „przy kawie”, firmowy kanał do wymiany doświadczeń (także krytycznych!) i nagrania ekranu: „mam taki błąd, tak pracuję, taki mam wynik”. Najlepsi inżynierowie niech dzielą się praktyką regularnie.
Na co uważać: część osób ma ideologiczną niechęć do AI — nie da się jej przełamać na siłę. Chwaląc narzędzia, nie pomijaj wad: szczera krytyka buduje wiarygodność.
9.Interfejs dla agenta codziennego: czat plus kilka pokręteł
Na czym polega: Telegram jako panel sterowania daje za mało kontroli, a pełny dashboard z wywołaniami narzędzi przytłacza. Aplikacje celujące w zwykłych użytkowników pokazują czat jak w komunikatorze — bez ścieżek myślenia i technicznych szczegółów.
Jak stosować: jeśli budujesz narzędzie dla nietechnicznych odbiorców, ukryj trasy rozumowania i zostaw kilka prostych przełączników. Dla własnych potrzeb rozważ gotową aplikację desktopową zamiast samodzielnej konstrukcji.
Na co uważać: własne, dedykowane rozwiązania psują się na okrągło (u Scotta „raz w tygodniu AI nie działa”) i wymagają ciągłego serwisu.
10.Nie buduj firmowego mega-harnessu — otaczaj istniejący narzędziami
Na czym polega: pisanie własnego harnessu od zera to trudny problem (cache’owanie, routing modeli, wydajność) i rzadko opłacalna inwestycja. Sensowniejsza jest firmowa warstwa narzędzi wokół sprawdzonego rozwiązania plus człowiek jako orkiestrator małych, dobrze opisanych zadań.
Jak stosować: audytuj to, co zbudowano: które elementy realnie pomagają, a które tylko zamulają i generują koszty. Regularnie weryfikuj, czy dawne obejścia są nadal potrzebne — modele coraz lepiej same znajdują dokumentację i biblioteki.
Na co uważać: zainstalowane „skills” i integracje żyją własnym życiem — na przykład agent przeglądarkowy robi zrzuty ekranu wszystkiego, zapełnia dysk i spowalnia pracę. Usuwaj balast.
Redakcyjne tłumaczenie
(Informacja dodatkowa: Syntax to jeden z najpopularniejszych podcastów dla programistów; prowadzą go Scott Tolinski i Wes Bos. „Potluck” to format, w którym odpowiadają na pytania słuchaczy. Poniższy tekst powstał na podstawie automatycznego transkryptu — nazwy własne znormalizowano redakcyjnie, a podział ról między prowadzącymi odtworzono z kontekstu rozmowy.)
Wstęp: pięć subskrypcji wyciśniętych do granic
Scott: Coś mnie bierze, gdy słyszę ludzi mówiących: „Mam pięć różnych subskrypcji AI i każdą wyczerpałem do samego limitu”. Dla mnie to pokazówka. Jedną subskrypcję rozumiem, nawet dwie — ujdzie. Ale więcej? Cóż wy właściwie robicie?
Wes: Bo są i tacy z dwudziestoma. Cały czas to widzę na X-ie: dwadzieścia subskrypcji, wszystkie na maksa. I wtedy pytanie: co takiego budujecie?
Scott: Padnie pewnie argument, że to tańsze niż etat. No dobrze, ale czego potrzebujecie? Pokażcie te wspaniałe rzeczy, które powstają. Bo ja widzę na razie wyłącznie wasze gadanie.
Scott: Witajcie w Syntax. Dziś odcinek potluck: o tym, co robić, kiedy pracuje agent; jak się wyróżnić; czy blogowanie umarło; jak trzymać agenta na torach; ile pracodawca powinien pokrywać za tokeny; jak zainteresować inżynierów AI — a na koniec pytanie pozatechniczne: czym wysyłać maile. Jeśli macie swoje pytanie, wejdźcie na syntax.fm, kliknijcie przycisk „potluck” i je wyślijcie — odpowiemy w którymś z kolejnych odcinków. I zapowiedź: 27 października spotykamy się w San Francisco, w browarze Bare Bottle Brewing. Wstęp jest darmowy, ale trzeba zamówić wejściówkę na syntax.fm/meetup. Do zobaczenia.
Czym dziś jest blogowanie? Pytanie od Alexa
Alex: Kiedyś pisanie o tematach technicznych pozwalało zaistnieć, pokazać umiejętności, może dostać pracę developera albo projektanta. Dziś blogów mało kto czyta — ich miejsce zajęły TikTok i Instagram. Czy ludzie w ogóle chcą śledzić cudzą wiedzę techniczną? Jestem projektantem produktu; prototypy front-endowe, które kiedyś budowałem samodzielnie, robię dziś głównie z Claude’em. Kocham tę branżę i nie szukam od niej ucieczki, ale nie chcę też zniknąć w morzu ludzi robiących dokładnie to samo. Krótko: jak się dziś promować?
Scott: To świetne pytanie, bo widzieliśmy to już przy okazji ostatnich głośnych premier agentowych — paru ludzi zawołało: „my zbudowaliśmy coś takiego dużo wcześniej, tylko nie mieliśmy zabawnego filmiku, który by to przeniósł na Twittera”. I choć to frustrujące, dziś nie wystarczy coś zbudować i pokazać. Kiedyś właśnie na tym świat polegał: ciężko pracujesz nad czymś, dużo się uczysz, piszesz o tym posta i ludzie chcą to czytać. Dziś treści jest bez liku i o uwagę trzeba zawalczyć — tym bardziej że spora jej część jest po prostu dobra i dobrze podana. Jak więc promować się dzisiaj? Z moich obserwacji: ludzie szukają opinii. Szukają kogoś, kto poświęcił czas, żeby coś rozgryźć, i wyrobił sobie zdanie o nowej technologii — ktoś, kto ma doświadczenie, eksplorował temat. Najciekawsi są dla mnie ludzie, którzy nie poprzestali na „sześciu promptach i demie”, tylko naprawdę pomyśleli, jak podejść do sprawy: jak to wyglądałoby, gdyby projektować własnym głosem? Jak użyć tych narzędzi do czegoś więcej niż robienia tych samych rzeczy, tylko szybciej? Osoby, które potrafią spójnie zdestylować swoje przemyślenia i zrobić to ciekawie — to one potrafią się dziś promować. Co do mediów: blog wciąż działa dobrze. Milionów wyświetleń nie zdobędziesz, ale Hacker News to wciąż głównie tekst i to teksty tam trafiają. Media społecznościowe też się bronią, a krótkie wideo to osobna liga. Nie jest to zły trening: umieć powiedzieć w sześćdziesiąt sekund „pasjonuję się tym, nauczyłem się tego i tego i mam takie zdanie”.
Wes: Moim zdaniem gadanie to nowe blogowanie. Choć — yapperów jest mnóstwo. Ale zawsze jest miejsce dla kogoś, kto zna temat i umie go przekazać. Tymczasem dostajemy tysiąc okropnych kanałów na YouTube z tytułami „to zmienia wszystko”, z głupimi albo niepoinformowanymi opiniami, wyścigiem o kliknięcia. Pamiętam swoją frustrację, gdy szukałem czegokolwiek sensownego o Hermesie — każdy film na ten temat robił jakiś samozwańczy guru, który kompletnie nie orientował się w temacie i gonił wyłącznie za zasięgami. Zawsze będzie miejsce dla ludzi, którzy wiedzą, o czym mówią — i potrafią to dobrze opowiedzieć.
Scott: Kiedyś doradzaliśmy: buduj rzeczy i wrzucaj na GitHub, bo rekruter zajrzy i zobaczy, że umiesz — a nie kolejną listę zadań, którą każdy robił, ucząc się Railsów. Dziś to już nie działa tak samo, bo każdy może wrzucić na GitHuba stertę wygenerowanego chłamu i nikt tego nie przeorze. Ale gdybym szukał kogoś naprawdę bystrego… Śledzę obecnie na X-ie gościa z Netflixa, który przebudowuje od zera mały model Hugging Face (w transkrypcie: „micro duck”) i wrzuca drobne wypowiedzi o tym, czego się nauczył i na czym utknął. Zwykły tekst i zdjęcia. Gdybym dziś zatrudniał, ten człowiek byłby na szczycie mojej listy. A nie gra w influencera — to zupełnie inna dyscyplina. On po prostu dzieli się ciekawymi rzeczami i umie je dobrze zakomunikować. I to jest dużo trudniejsze do podrobienia przez AI.
Wes: No właśnie. Film na YouTube łatwo dziś wygenerować. A dobre, ręcznie pisane blogi? Kto w ogóle jeszcze takie pisze? Czytam czasem jeden akapit i wiem: „dobra, koniec, to jest śmieć”.
Scott: Dokładnie. Liczy się to, co autentyczne, ludzkie i dające się jakoś zweryfikować. Podsumujmy: rób ciekawe rzeczy i pokazuj je ludziom. Nie zwiruje, ale jeśli chcesz pozostać aktualny i mieć zdanie o tym, co się zmienia, to wyróżni cię wyraźnie — zwłaszcza gdy pracodawca ocenia, czy wiesz, o czym mówisz.
Co robić, gdy agent pracuje? Pytanie od Eliasa
Elias: Kiedy agent kręci się przez kilka minut, wstajecie od biurka, czy siedzicie i patrzycie? Piszę cały dzień z Claude Code i zauważyłem, że w czasie czekania w ogóle się nie ruszam. Napisałem więc hooka, który wypisuje w sesji jedno zdanie przypominające o rozciąganiu — liczy wyłącznie minuty, przez które tura agenta faktycznie mnie wstrzymywała. Dzień pełen szybkich tur w ogóle go nie uruchamia, a odejście na 45 minut zeruje licznik. Oboje traktujecie trening poważnie, więc ciekawi mnie, co robicie wy. Narzędzie jest open source i nazywa się Vibe Stretch.
Wes: Uwielbiam rozciągać się w trakcie pracy. A co robię, kiedy jeden agent pracuje? Puszczam drugiego na inne zadanie. Potem trzeciego na jeszcze inne. Potem czwartego… i tak kręcisz się w pętli, aż mózg się zagotuje. Ale tak szczerze — pewnie najlepiej zrobić pompy, rozruszać krew, wyjść na spacer.
Scott: Zanim odpowiesz na to „co robić”: moje agenty rzadko pracują długo. Jeśli agent kręci się dziesięć minut, zaczynam się denerwować — wolę krótsze pętle. To moja preferencja. Ale nawet dwie, trzy minuty czekania wystarczą, żeby rozerwać kontekst — i stąd te wszystkie narzekania, że nie da się już wejść w stan flow. Ostatnie moje podejście: zamiast uciekać na X-a, patrzę na to, co buduję, i myślę, co dałoby się poprawić. W interfejsie aplikacji zawsze jest masa rzeczy do zrobienia, tylko trzeba je spisać i doprecyzować. W zeszłym tygodniu ustawiłem u siebie agenta-orkestratora oraz drugiego, którego nazywam „GitHub-issue”: bardzo tani model, który po prostu pracuje. Orkiestrator pobiera zgłoszenie z GitHuba i je realizuje, a ja w międzyczasie siadam przy tamtym drugim i wygruzuję mu wszystko, co w aplikacji jest nie tak: „klikam w element, a nie powinienem móc go przeciągnąć” — buduję właśnie trójwymiarowy kreator siłowni, pokażę go w jednym z kolejnych odcinków. I szczerze: zanim wymyślę, co poprawić, przeanalizuję wzorce projektowe i zdestyluję to do porządnego zgłoszenia, mija więcej czasu niż trwa pojedyncza tura agenta. Czyli przepis jest taki: póki agent pracuje, oglądaj swoją aplikację — tę, nad którą właśnie siedzisz, albo zupełnie inną — i szczegółowo dokumentuj problemy. Wtedy, gdy przyjdzie czas na zgłoszenie, masz wielki zapas konkretu zamiast pustego „zrób UI nowocześniejszym, poszukaj trochę”.
Wes: Ludzie, którzy niewiele kodują z AI albo używają go jak autouzupełniania, pomyślą, że to szaleństwo — „przecież ja widzę każdą linię, którą pisze”. Ale my piszemy oprogramowanie inaczej niż kiedyś: zamiast wznosić coś od fundamentów, dostajesz posąg, który za pierwszym podejściem jest już blisko kształtu — i go szlifujesz, szlifujesz, szlifujesz. Ten proces wymaga oka do detali i zamiaru. Twój punkt o wykorzystaniu przerwy na zrozumienie, co trzeba doszlifować, idealnie się w to wpisuje.
(Reklama w odcinku: prowadzący polecają Sentry — narzędzie do śledzenia błędów i wydajności aplikacji; dla słuchaczy dwa miesiące gratis na sentry.io/syntax.)
Ile firma powinna płacić za AI? Pytanie od Anonima
Anonim: Jak firmy podchodzą do korzystania z AI przez pracowników? Ten sam człowiek w domu, na własne pieniądze, wyśle dwa prompty i oczekuje efektu. W pracy, przy praktycznie nieograniczonym firmowym budżecie, będzie promptował i promptował, aż wynik będzie bliski doskonałości. To musi kosztować firmę kupę pieniędzy. Czy pracodawcy przyznają pracownikom budżety na AI?
Scott: Świetny temat — i przez ostatnie pół roku wiele firm wyraźnie zmieniło podejście. Na początku wszyscy mówili: „nieważne, to magiczna skrzynka, róbcie wszystko”. Potem wydatki wymknęły się spod kontroli, ludzie zaczęli strzelać z armat wygenerowanego chłamu, a na to nałożyło się, że ktoś to wszystko musi potem przeglądać, i kwestie bezpieczeństwa. Zapytałem więc na X-ie: ile wasz pracodawca pokrywa za AI? Macie subskrypcje, budżet, a może bez limitu? Garść osób: bez limitu. Kilka: dostajemy 200 dolarów na subskrypcję. Inni: 500. Duża część firm jest na umowach enterprise — a Anthropic i Claude rozliczają tam według tokenów, więc to nie tak dobry interes jak subskrypcja za 200 dolarów miesięcznie. Część osób dostaje 500 dolarów i kupuje za to subskrypcję Codexa oraz Claude’a: jedną wyczerpie, przechodzi do drugiej. Rozstrzał jest ogromny, ale zdecydowana większość mieści się w przedziale od 200 do 500 dolarów miesięcznie. I uważam, że — przynajmniej na razie — trzeba się tego nauczyć świadomie używać. Zasoby są dostępne, ale nie można szastać na ślepo: jako developer, budując mnóstwo nowych funkcji i ciągle skanując całość, bardzo łatwo wydać tysiąc dolarów dziennie. Budżetowanie tego to dziś po prostu umiejętność. Czy za pół roku będzie to jeszcze problem — zobaczymy. Na razie większość dostaje 200–600 dolarów miesięcznie i resztę musi ogarnąć samodzielnie.
Wes: Bo wystarczy podpiąć cokolwiek rozliczanego tokenami i po chwili ktoś z działu HR pisze maila najnowszym modelem — a wydatki puszczają w malunki. Albo ktoś ustawia sobie przypomnienie, które sprawdza pocztę co dwie minuty, i nagle to dziesięć tysięcy dolarów dziennie. Zwykli ludzie nie rozumieją tych kosztów. „Mam w domu subskrypcję ChatGPT — działa i sprawa zamknięta”. Przy rozliczeniu tokenowym robi się z tego koszmar. Moim zdaniem warto samemu wiedzieć, ile to kosztuje — i co dostaję, jeśli wybiorę tańszy model? Podobnie jak musieliśmy kiedyś nauczyć się, jak działa wydajność aplikacji i jak pisać efektywny kod, tak teraz potrzebna jest umiejętność wyciskania najwięcej z tych zasobów. Dostawałem wiadomości od ludzi, którzy mają dostęp za 15 tysięcy dolarów miesięcznie — przy takich widełkach można oszaleć. A jeśli firma prowadzi ranking, kto spalił najwięcej tokenów, ludzie będą je po prostu palić i dodawać do aplikacji zbędne funkcje. Trochę powściągliwości by się przydało, a dobrym jej treningiem jest ograniczony budżet z możliwością zwiększenia w razie potrzeby — na przykład: „Szefie, przepisujemy to na Rusta, potrzebuję tokenów za dwadzieścia tysięcy”. Zamiast ciągłego YOLO — budżet tokenowy zatwierdzany pod konkretne przedsięwzięcie.
Scott: Na pewno zobaczymy więcej takich mechanizmów, bo firmy dopiero szukają, jak to wszystko ogarnąć. Dodam jeszcze jedno: subskrypcje za 200 dolarów miesięcznie to — jeśli spojrzysz na zużyte tokeny — zdecydowanie najlepszy okaz. Używam na Macu aplikacji Codex Bar, do której podpiąłem wszystkie swoje subskrypcje. Nazywa się Codex Bar, ale działa ze wszystkimi. Mam podpięte: Codexa, Claude’a, Cursora, Gemini, Copilota i Z.ai — takie moje aktualne zestawienie. I pokazuje mi, że w ostatnim tygodniu skonsumowałem tokeny warte 1100 dolarów. A to nie liczy tego, co działo się na innych komputerach czy w zdalnych środowiskach. Zdecydowanie nie zapłaciłem 1100 dolarów. Więc jeśli twoja firma płaci za taką subskrypcję — bierz. A wracając do początku: słyszę kogoś, kto mówi „mam pięć subskrypcji i wszystkie wyczerpałem”, i myślę — pokazówka.
Wes: Ludzie z dwudziestoma. Co wy budujecie?
Scott: No właśnie. Pokażcie te niesamowite rzeczy. Bo na razie widzę tylko farmę gadania.
Wes: Może dodać do aplikacji, w której pokazujesz swoje projekty, taki szczegół: zanim usuniesz projekt z dysku, wyświetla ci, ile tokenów na niego wydałeś — i wtedy myślisz sobie „głupi pomysł był”. „Czy na pewno chcesz usunąć te 54 dolary wstydu?”
Maile transakcyjne w 2026 roku. Pytanie od Cosmina
Cosmin: Jak dziś kodujecie maile wysyłane przez aplikacje — resety hasła, powitalne? Zostajecie przy tym, co daje framework, czy wpadacie w króliczą norę własnego HTML-a?
Scott: Zawsze kleiłem własne, chyba że używałem czegoś w rodzaju PocketBase, gdzie maile są wbudowane. Zwłaszcza w erze agentów stało się to banalnie proste. Ale maile transakcyjne to rzecz, za którą nienawidzę płacić — wydaje mi się nieproporcjonalnie droga dla aplikacji, która wysyła maila raz na jakiś czas. Ostatnio używam Resend, ale nie rozumiem, czemu płacę tyle. A ty, Wes?
Wes: Ja używam Reacta — render do stringa. I działa świetnie, bo maile nie są aż tak skomplikowane, a obsługa w nich jest całkiem dobra. Potrzebujesz silnika szablonów z komponentami wielokrotnego użytku — a React jest do tego stworzony. Potem sposobu na wyrenderowanie tego do HTML, co mają wszystkie frameworki. I jeszcze wplecenia CSS w treść, bo tak maile wyglądają najlepiej: system sam rozstrzyga, który styl dotyczy czego. Wiem, że jest mnóstwo innych rozwiązań, jest też React Email. Nigdy nie używałem Resend, głównie dlatego, że nie chcę wiązać się z czymś firmowym i własnościowym.
Scott: Ja używam Resend tylko do wysyłki, przez ich API.
Wes: To nadal ich rozwiązanie. Po prostu używaj SMTP — dowolnego. SendGrid to chyba najczęściej polecana opcja.
Scott: Za drogo. Kiedyś siedziałem na tym produkcie Mailchimpa — Mandrill — i też nie było tanio. A ja bym chciał czegoś za grosze. Idealnie za darmo.
Wes: Darmowego nie ma — tak trafia się do spamu. Ja siedzę na Postmarku od dobrych dziesięciu lat. Ostatnio przestawili się z kupowania kredytów — co uwielbiałem, bo przy wysyłce serii płacisz właśnie za tę serię, a w ciszy nic nie płacisz — na typowy dla SaaS abonament z limitem wysyłek. Zostaję głównie dlatego, że przesiadka z wysyłki maili to choć w zanadrzu udręka. Ale wiem, że mogę zmienić. Postmark ma chyba darmowe 100 maili miesięcznie — czyli dla pobocznych projektów o małym wolumenie, a takich właśnie najczęściej potrzebuję, będzie dobrze. Radziłbym też rzucić okiem na AWS SES — płacisz tam za wiadomość, a jeśli kiedyś potrzebujesz dodatków typu śledzenie otwarć, łatwo je dobudować. I zawsze, ale to zawsze trzymaj się standardowych API. Nie ważne, jak kuszące są firmowe bajery — znacznie lepiej siedzieć na zwykłym, podstawowym mailu. Bo jeśli coś się wydarzy i twoje maile zaczną wpadać do spamu, możesz się przenieść do innego dostawcy.
Scott: A próbowałeś wysyłki przez Cloudflare?
Wes: Nie, szczerze mówiąc nie. To jedna z ich nowszych usług, muszę się temu przyjrzeć.
Scott: Skoro o tym mówimy, przypominam sobie, że oni faktycznie mają routing poczty i SMTP — pewnie podepniesz to przez zwykły nodemailer albo cokolwiek podobnego.
Wes: W tym wszystkim chodzi o dostarczalność. Ludzie są bardzo wyczuleni na zmiany w tym obszarze, bo nagle 2% twoich maili ląduje w spamie — a to duży koszt: ci odbiorcy nie kupują twojego produktu. Dlatego na tym robi się mnóstwo pieniędzy i dlatego Resend jest tak dużą firmą. Dostarczenie maila do skrzynki odbiorcy to samo w sobie biznes.
Scott: Fakt.
Jak nie wypuścić agenta z torów. Pytanie od Milesa Dysona
Miles Dyson: Podsłuchuję w biurze rozmowy rekrutacyjne — kandydatów ciągle pytają, jak zapewnić, żeby agent nie wymknął się spod kontroli. Mam wrażenie, że sami pytający nie znają odpowiedzi. Znak czasów. Jak wy byście na to odpowiadali — i czy w ogóle da się to zrobić niezawodnie?
Wes: Wstawiam to pytanie, bo wiem, że Scott ma sporo przemyśleń na temat determinizmu, reguł i narzędzi, które mają agenta powstrzymać.
Scott: Po pierwsze — ludzie nie zdają sobie sprawy, że ich harness często ma mechanizmy typu hooki. Claude Code ma hooki, które deterministycznie mogą wkroczyć, gdy agent zamierza zrobić na przykład rm. Są też listy zakazów blokujące różne operacje. Weźmy prosty, zrozumiały dla każdego przykład hooka: „czy agent próbuje wykonać rm?” Jeśli tak — operacja jest blokowana, a agent dostaje odpowiedź: „tego nie rób, zrób zamiast tego tamto”. I ten schemat działa zawsze, gdy chcesz skierować agenta na inną ścieżkę, zanim zrobi coś złego. Co do kontrolowania ich w ogóle — da się zrobić tylko tyle i tyle. Są reguły agentów, lintery i tak dalej. Chodzi o wyjęcie pewnych rzeczy spod decyzji agenta: „jeśli robisz to — idź tą drogą, jeśli tamto — tą”. Ja używam do deterministycznego routingu zadań narzędzia Swamp Club i bardzo mi to leży. To nie zapewni ci bezpieczeństwa w stu procentach, ale daje agentowi gwarantowaną ścieżkę. Idealny przykład z życia: padł mi niedawno Jellyfin. Nie wiedziałem dlaczego, więc mówię do agenta: „Jellyfin leży, zerkniesz?”. Agent pobiegł, narobił różnych rzeczy i postawił nową kopię Jellyfina w Dockerze — o co prosiłem? Dokładnie ten typ sytuacji: totalnie zszedł z torów. Zrobiłem więc automatyzację, która sprawdza status mojego istniejącego Jellyfina — gdzie mieszka, co się z nim dzieje. Teraz agent myśli: „pyta o Jellyfina, odpalę automatyzację”, dostaje status plus instrukcje i wie, co dalej. Zamiast zaczynać od zera, wchodzi na prowadzoną ścieżkę. Używam tego szeroko wszędzie tam, gdzie chcę mieć większą pewność — na przykład do orkiestracji kroków: najpierw to, potem tamto. Ale zawsze znajdą się momenty, gdy agent zrobi, co mu się żywnie podoba. Dlatego ludzie tacy jak CJ zalecają izolację: konteneryzację i uruchamianie agentów w kontenerach — tam mogą narobić tylko ograniczone szkody.
Wes: Mnie to się wyaje niepraktyczne na co dzień. Ale poza wymykaniem się z torów i wyrządzaniem szkód, to pytanie dotyczy też tego, żeby agent budował to, czego chcemy, a nie dokładał masę zbędnych rzeczy. Częściowo ogarniesz to w pliku AGENTS.md — na przykład: „nie pisz zabezpieczeń dla absolutnie każdego przypadku”. Bo rzecz, która łapie mnie teraz cały czas: zmieniasz coś w połowie, w drugim prompcie, a agent uznaje, że pierwotny przypadek użycia musi być wspierany do końca świata — i pcha sześć instrukcji warunkowych wszędzie, gdzie się da. Częściowo ogarniają to deterministyczne narzędzia — lintery i testy. Niedawno, pracując nad czymś trójwymiarowym, napisałem zestaw testów, które uruchamiają przeglądarkę agentową i mierzą liczbę klateków renderowania — bo bardzo łatwo dodawać funkcje cały dzień, a potem interfejs zaczyna się dławić. Po każdej zaimplementowanej funkcji test odpalał przeglądarkę, mierzył FPS i pilnował, żebyśmy trzymali się ponad 55 klatek. Tego typu rzeczy działają. I jeszcze jedno: jeśli agent schodzi na manowce stanowczo zbyt często, to prawdopodobnie twoja wina — siedzisz za daleko od procesu i po prostu zbyt lekką ręką walisz prompty.
Wes: U mnie to wygląda tak: obserwuję wyniki, widzę, że agent wchodzi na ścieżki, w które wchodzić nie powinien, i waliłam w klawisz Escape: „Co ty robisz? Nie kazałem ci tego!” — hmm wait, Scott said “that’s on you” and Wes says “Yeah, I do. I’ll watch the output and be like… I’ll spam that escape button”. Let me fix: after Scott’s FPS part, Scott ends with “that’s on you… yoloing prompts”. Then Wes: “Tak, robię to. Obserwuję wyniki, widzę, że wpada na ścieżki, na które nie powinien, i demoluję klawisz Escape: co ty robisz, nie kazałem ci tego!”
Then Wes continues: Skoro mowa o Escape — to formalnie zupełnie inne pytanie, ale dotyczy sterowania w ogóle. Używam wszystkich harnessów i czasem, gdy chcesz powiedzieć „nie, nie rób tego” albo coś dodać, musisz wcisnąć Escape i ubić całość. Niektóre — jak Codex — prześlą twoją wiadomość w następnej turze: poczekają, aż agent wróci, i wtedy podepną twój tekst. Inne czekają, aż skończysz wszystko, i dopiero wtedy wysyłają — agent musi się cofać, a ty kasujesz efekt. W OpenCode nie ma praktycznie żadnego sterowania na żywo. Wiem, że są głosy: „nie wolno się wtrącać wcale” — ale ileż to razy chcę tylko szybko dorzucić kawałek informacji. Claude ma też tryb „przy okazji”: możesz zadać pytanie lub kazać głównej otoczce coś zaktualizować. Jak u ciebie — jakie podejście do sterowania jest najlepsze?
Scott: Nie sądzę, żebym to sobie dobrze poukładał. Nie przepadam za tymi funkcjami „przy okazji”. To po prostu dodatkowe sterowanie, a tura potrafi trwać za długo. W moim przypadku, gdy wchodzę z dodatkową informacją, to zwykle jest pilna — inaczej bym się nie wtrącał. Dlatego prawie zawsze domyślnie zatrzymuję. Jedyne wyjątek, gdzie nie zatrzymuję i pozwalam podchwycić w locie, to Claude Code — akurat to robi naprawdę porządnie. Ale spokojnie mogę wcisnąć stop.
Wes: Bo ileż to razy nie chce ci się zatrzymywać — przecież pracuje, nie robi nic złego, a restart to droga przez mękę. Więc rób tak: następna tura i tak nadejdzie za dwadzieścia, trzydzieści sekund — wrzuć wtedy tę wiadomość z dodatkowym kontekstem, może zmienisz kurs, może skorygujesz sam siebie. Z żadnym rozwiązaniem nie jestem do końca zadowolony, ale Codex jak dotąd podoba mi się najbardziej.
Scott: Słuchacze — a wy jak to robicie? Używacie „przy okazji”? Sterujecie i czekacie, aż podchwyci? Chętnie to zoptymalizuję, tematem jestem zainteresowany.
Jak zarazić inżynierów agentami. Pytanie od Ash
Ash: Kieruję inżynierią w małym startupie. Zainteresowanie rozwojem agentowym wśród moich inżynierów jest niewielkie — eksperymentuję głównie ja i to ja próbuję namówić innych, żeby spróbowali. Jak zachęcić ich, żeby zainteresowali się sami? Marzy mi się prawdziwie zaangażowana kultura wokół tych rzeczy.
Wes: Będzie trudno z osobami, które mają ideologiczny zgrzyt do wdrażania tego typu narzędzi — po prostu nie chcą. Ale myślę też, że sporo ludzi, którzy postawili mur wobec kodowania z agentami — „to nie dla mnie, koniec tematu” — nie zdaje sobie sprawy, jak bardzo modele idą do przodu i jak dobre się stały. Sztuka jest w tym, żeby pokazać korzyść konkretnie dla nich, nie wywołując przy tym obronnego muru, który pewnie zbudowali. To bardziej problem ludzki niż technologiczny.
Scott: Moim zdaniem te pokazy typu „spójrz, jednym promptem” szkodzą bardziej, niż pomagają.
Wes: Szkodzą. Zamiast tego — niech ktoś posiedzi obok i popatrzy na twoją pracę. Albo sessionje typu lunch and learn, na których pokazujesz swoje przepływy: jak to usprawnia twoją pracę, twój proces, twój kod. To uderzy lepiej niż „patrzcie, jakie szalone rzeczy umiem”. I jeszcze jedno: jeśli jesteś szefem inżynierii, najwyżsi inżynierowie powinni nieustannie opowiadać, jak sami używają tych narzędzi — bo ludzie są zaślepieni właśnie tymi „jednym promptem zrobiłem X, Y, Z”.
Scott: Nawet u nas, w Sentry, jest kanał na Slacku, gdzie wszyscy pytają, jak coś zrobić, a najlepsi inżynierowie dzielą się opiniami — sporo z nich jest krytycznych, i to jest bardzo wartościowe, obok tych naprawdę dobrych rad.
Wes: To wspaniały wzorzec: jeśli macie firmowego Slacka albo inny kanał, wprowadźcie regularne dzielenie się tym, czego się nauczyliście. I chociaż zwykłe nagranie ekranu — wystarczy wewnętrznie pokazać: „oto mój proces, mam taki błąd, tak nad nim pracuję” — a korzyść widać na drugim końcu. Zbyt mało ludzi pokazuje, jak naprawdę pracuje.
Scott: Zgadzam się w całości.
Czym sterować agentem, który nie programuje. Pytanie od Andrew
Andrew: Ile jeszcze minie, zanim odchodzimy od kanałów powiadomień typu Telegram jako głównego panelu sterowania dla agentów niekodujących? Patrząc na Hermes desktop i OpenClaw 2.0, wygląda to na interfejsy webowe przebrane za aplikacje desktopowe. Czy tam zmierzamy, czy raczej w stronę dedykowanych urządzeń, takich jakie zbudował Scott? Brak narzędzi zaprojektowanych specjalnie do kontaktu z agentami to jeden z powodów, dla których jeszcze ich w pełni nie przyjąłem. Drugim jest balast, który dokłada się automatycznie — dlatego budowanie własnej rzeczy bawi, zwłaszcza gdy optymalizuje się ją pod mniejsze, lokalne modele.
Scott: Każdy próbuje teraz rozgryźć, co będzie tym świętym Gralem interfejsu do komunikacji z agentami. Widzieliśmy, że Codex połączył się z ChatGPT i stał się po prostu jedną aplikacją — wszyscy budują takie superaplikacje. Zaczynamy też widzieć dwie wielkie nowości, GrokBot i Muse od Facebooka, wymierzone nie w kodowanie, tylko w codzienne zadania — i obie są dużo bardziej aplikacją czatową. Opcji do pokręcenia jest niewiele, i wydaje się, że właśnie tak „zwykli ludzie” mają zostać wciągnięci. Zgadzam się, że zwykłe przepytywanie się przez Telegrama to nie to — potrzebna jest trochę większa kontrola nad tym, co się dzieje. Ale nie taka, żeby przytłaczać. I właśnie dlatego GrokBot i Muse nie pokazują ścieżek myślenia ani wywołań narzędzi — tylko bąbelki czatu, jakbyś pisał na komunikatorze. Zwycięzca będzie chyba gdzieś pomiędzy: luźny czat plus kilka pokręteł do ustawień. To wygra u większości zwykłych użytkowników. A co do w pełni autorskich rozwiązań — są świetne, bo robią, co chcesz, ale powiem ci: moje psuje się bez przerwy. Żona daje mi znak mniej więcej raz w tygodniu, że „AI znowu nie działa”. Jeśli budujesz sam, możesz wpaść w problemy z chwiejnym oprogramowaniem. Mnóstwo ludzi buduje własne nakładki na OpenClaw czy Hermesie. I szczerze: aplikacja desktopowa Hermes jest naprawdę dobra — choć nie wiem, czy postawiłbym ją przed moją żoną. Ale jest dobra. Ja trzymam się swojej własnej, choć bywa irytująca.
Gdzie szukać motywacji. Pytanie od Diabetic Codes
Diabetic Codes: Wiem, że pytanie „czy w świecie AI uczyć się jeszcze programowania” padło milion razy, ale zadam je inaczej. W branży od 2014 roku, z dwuletnią przerwą na czas boomu frameworkowego — i od tamtej pory czuję, jakbym ciągle walczył pod górkę. Pracowałem na dwóch etatach, gdzie AI używamy codziennie, i rozdzieram się między poświęcaniem czasu na poznanie kodu a używaniem AI do szybszego zamykania zgłoszeń. Kiedyś w weekendy uwielbiałem zgłębiać coś nowego w programowaniu — dziś napęd mnie opuścił, nie chcę dotykać komputera. W fitnessie, zdrowiu i życiu jestem bardzo zdyscyplinowany, ale tu nie mogę znaleźć pomysłu, w który mógłbym się wziąć z zapałem. Jak zachować motywację, kiedy jej nie ma?
Scott: To trudne. Sam mocno się z tym zmagam. To trochę jak granie z Game Genie — nie wiem, czy miałeś konsole… Ty nie grałeś dużo, prawda, Wes?
Wes: Miałem Nintenda, ale nigdy nie byłem wielkim graczem.
Scott: A u mojego sąsiada było pełno gier, więc Game Genie znam doskonale. I chodzi o to, że z kodami gra była zabawna przez jakieś pięć minut. Dasz Mariowi superwysoki skok i po chwili myślisz: „dobra, ale to nudne — nie ma wyzwania”. Właśnie tracimy tę trudną, wymagającą część programowania — wgryzanie się w pojęcia i pomysły, intensywne używanie własnej głowy. Zamiast tego wpadamy w inny rytm: „agencie, napraw to; agencie, co nie tak?; agencie, napraw tamto”. Brak prawdziwego wyzwania potrafi mocno dobić. Do tego kodowanie z AI bywa bardziej wyczerpujące z innych powodów — chochołem rozbijanie flow i różne rzeczy, które słyszeliśmy, gdy robiliśmy nasz sondaż o zdrowiu psychicznym przy AI. Więc gdzie szukać zapału i ciekawości? Ja znalazłem frajdę w rozumieniu problemów na innej warstwie: warstwie strategii, głębokiego doszlifowywania interfejsu, rozumienia większych problemów, struktur i architektur. Bo agenci czasem wybierają naprawdę głupie pomysły na rozwiązanie. Więc wyzwanie przeniosłem gdzie indziej: jak rozwiązywać te problemy sprawniej, jak ulepszać mój proces, moją otoczkę, moje umiejętności. Kod staje się efektem ubocznym ulepszania mojego procesu — a nie czymś, co doszlifowuję bezpośrednio własnymi rękami.
Wes: Zgadza się. Dobrze ujęte.
Porządki z rozbestwionymi procesami. Sugestia od Tima Apple’a
Tim Apple: To nie pytanie, tylko pomysł. Wes wspominał chyba, że nigdy nie restartował komputera tak często, jak odkąd pracuje z AI. Zrobiłem sobie na Macu skrót, który ubija wszystkie procesy node i zamyka uruchomione programy. Wygląda na to, że pomaga opanować zdziczałe agenty.
Wes: To wcale nie jest głupi pomysł. Choć u mnie mnóstwo rzeczy działa na node — na przykład mój Stream Deck — i gdy ubiję wszystkie procesy node, Stream Deck umiera. Idealnie byłoby, gdyby restartował się sam, ale tak nie zawsze bywa. To zresztą problem do rozwiązania: te porzucone procesy są bez interfejsu, kręcą się w nieskończoność, nie wiesz, gdzie są, i pożerają procesor. Widzę to po baterii laptopa: kiedyś wytrzymywała jakieś czternaście godzin, a ostatnio godzinę i pół.
Scott: Bardzo podobało mi się Orca — aplikacja, w której można uruchamiać agentów, coś w rodzaju środowiska developerskiego. I to, co w niej uwielbiam, to menedżer zasobów: pokazuje, ile megabajtów, a czasem gigabajtów procesora i pamięci pochłania każdy z twoich agentów. Gdy odpalasz ich całkiem sporo, nagle widzisz czarno na białym, ile to je. Gdybyś przez to przepuścił też swoje procesy deweloperskie, pewnie podobnie. Bo łatwo stracić z oczu wszystko, co się namnożyło — i restart komputera jest dziś ważniejszy niż kiedykolwiek. Choć przyznaję: potrzebuję lepszego sposobu niż obecny, czyli to, co ty — kasowanie rzeczy, gdy zauważę, że coś pracuje.
Wes: Ja i tak siedzę na beta wersji systemu, więc restarty wychodzą mi na zdrowie tak czy owak.
Firmowy harness kontra małe agenty. Pytanie od B. Murpha
B. Murph: Moja firma zainwestowała mnóstwo czasu w własny, wewnętrzny harness postawiony na Claude Code, z masą autorskich skilli i agentów. Moim zdaniem to kicha: pożeracz tokenów, chyba psuje cache’owanie, działa wolno, odpala agentów niepasujących do problemu — i tak dalej. Rozumiem odruch, żeby otoczyć rygorem coraz szersze użycie AI, ale ten kierunek wydaje mi się błędny. Pytanie właściwe: czy w taki szalony harness warto pakować czas i energię, czy lepiej stawiać na mniejsze, dedykowane agenty per problem, z człowiekiem jako głównym orkiestratorem? W moim doświadczeniu znacznie lepiej wychodzi podawanie AI małych problemów, a wobec harnessowi-YOLO jestem sceptyczny. Zbyt sceptyczny, hejter, czy trafiłem?
Wes: Harness to trudny problem — i specjaliści od harnessów nie są tu przypadkiem. Wymaga niepsucia cache’owania, sprawnego routingu modeli, dopilnowania, żeby wszystko działało tak, jak musi. A ja — znasz mnie — to typ, który wszystko klei sam. Ale nigdy nawet nie pomyślałem o własnym harnessie, bo to po prostu nie dla mnie. Natomiast autorskie narzędzia wokół harnessu — jak najbardziej. Firmom sensownie jest budować warstwę wokół gotowego rozwiązania, a nie samo rozwiązanie. I myślę, że odpowiedź jest pośrodku między twoim modelem — człowiek jako orkiestrator, mali agenci pod konkretne problemy — a autorskim harnessem. Oni skręcili w lewo, ty w prawo. Smutna prawda: odpowiedź leży pośrodku.
Scott: Dodam do tego, że mnóstwo rzeczy, których nauczyliśmy się przez ostatnie osiem miesięcy, już nie ma znaczenia. Niedawno myślałem o Context7, tym MCP do dokumentacji — czy w ogóle jeszcze tego potrzebujemy? Bo modele tak dobrze potrafią dziś szukać w internecie i znajdować, czego chcemy, że od dłuższego czasu tego nie uruchamiam. Albo biblioteka do renderowania 3D, którą dałem agentowi — rok temu nie potrafił postawić nawet sześcianu, zanim całość się sypała. A dziś? Renderuje pełne, nadające się do druku 3D modele. Cudownie. Więc jeśli nasypaliście do własnego harnessa mnóstwo rzeczy — własny stos, własne składowe — to może czas zadać pytanie: które elementy realnie nam pomagają, a które tylko zwalniają pracę i żrą tokeny? Bo nawet te instalowane skilli często dokładają zbędny churn tokenowy, czyli po prostu sposoby na wydanie pieniędzy. Nawet z agentem przeglądarkowym muszę czasem wyłączyć — bo chce robić zrzuty ekranu wszystkiego i całość się dławi.
Wes: U mnie zapełnia dysk zrzutami ekranu.
Scott: No właśnie.
Polecane rzeczy na koniec
Scott: Czas na nasze „polecane rzeczy” — tematy, które ostatnio nam się podobają. Ja wybioram grę wideo, bo lubię gry wideo i gram głównie na Steam Decku. Nowa tytuł to Driving Rogue — roguelike o jeździe samochodem. Ludzie opisują go jako „co by było, gdyby Balatro było grą samochodową” — samochodową, nie karcianą, bo Balatro to karty. Na pierwszy rzut oka odrobinę mnie to zniechęcało, bo jest mnóstwo gier typu „co by było, gdyby Balatro było X”, a sam Balatro, choć świetny, ma trochę manipulatywną pętlę nagród. Tymczasem w Driving Rogue jest prawdziwa umiejętność: musisz dobrze jeździć, a elementy roguelike — krótkie wyścigi — ulepszają auto. Świetny kierunek artystyczny. Na początku myślałem: „nie potrzebuję roguelike w grze wyścigowej”, ale pograłem trochę — i kosztowało grosze, jakieś dziewięć dolarów, może dziś dziesięć — i szczerze świetnie się bawię. Jeśli to w twoim gusie, sprawdź.
Wes: A ja mam wkrętakę elektryczną Amazon Basics. Od dawna chciałem akumulatorowy wkrętak — wiem, że to w sumie jest wiertarka, ale szukałem czegoś małego do rozkręcania rzeczy. W końcu obejrzałem film na kanale Torque Test Channel — gość kupuje narzędzia wszystkich marek i realnie testuje moment obrotowy, cenę, wytrzymałość. Zrobił test małych elektrycznych wkrętaków i byłem w szoku: numerem jeden, z dużą przewagą, nie okazał się DeWalt, Milwaukee ani Skil, tylko wkrętaka Amazon Basics. A ta rzecz jest fantastyczna — uwalnia nawet mocno dokręcone nakrętki, wkręca wprost w drewno. Myślałem, że takie zabawki się niesprawdzą, a tu proszę. Kosztowała jakieś piętnaście dolarów — sam akumulator jest wart osiem. Do zestawu kilka końcówek; przyjmuje bity calowe, więc do drobnej elektroniki muszę dokupić albo mniejszą wersję, albo adaptery. Ale w domu — rewelacja. Wiesz, ciągle coś wieszamy na ścianach, ja używam tych metalowych kotew do płyt gipsowych; kiedyś trzeba było wiertarką nawiercić, ręcznie wkręcić kotew, potem wkręt. Teraz wchodzą wprost w płytę, bez wiercenia. Do powieszenia czegokolwiek wystarcza mi ta mała rzecz — uwielbiam. Można regulować moment, żeby czegoś nie przewiercić, ale ja po prostu daję gaz.
Scott: Ja ciągle używam wiertarki ustawionej na za duży moment.
Wes: No widzisz — a tutaj masz regulację. Dobra, to ode mnie wszystko.
Scott: Świetnie. To tyle w tym odcinku — dzięki, że byliście z nami.
Wes: Dzięki za słuchanie. Cześć!