O czym jest ten film
- Odcinek typu „potluck” podcastu Syntax: Wes Bos i Scott Tolinski odpowiadają na pytania słuchaczy o pracę z agentami kodującymi.
- Jak przenieść kontekst z jednego agenta do drugiego (np. z Claude Code do Codex): pliki Markdown, komentarze w kodzie, prompty przekazania, narzędzie Dex i GitHub issues jako wspólna „pamięć robocza”.
- Czy skille tworzone przez AI są dobre — dyskusja o tym, że wiele skilli powinno być zwykłymi skryptami, a globalne skille i kontekst częściej szkodzą, niż pomagają.
- Wierne wdrażanie projektów z Figmy: Figma MCP pobiera realne wartości z design systemu, a pętla weryfikacji wizualnej zastępuje „mierzenie na oko”; wskazówki modelowe (Opus 5.5, Fable, Astra).
- Jakie umiejętności rozwijać bez informatycznego wykształcenia: zamiast „jak robić stare szybciej” pytać, które problemy — także w zupełnie innych branżach — da się dzięki AI rozwiązać.
- Bezpośrednia odpowiedź na krytyczny list słuchacza: o zależności emerytur od branży AI, o „rzemieślniczym” kodzie pisanym ręcznie i o relacji Syntaxa z firmą Sentry.
- Web Serial w przeglądarce i flashowanie ESP32: dlaczego przy ciągłej iteracji lepszy jest terminal albo aplikacja desktopowa.
- Poczucie winy wobec własnej, ciężko zdobytej wiedzy: o żałobieniu umiejętności, które unieważniła technologia — i o tym, co naprawdę zostaje (architektura, UX, produkt).
- AG-UI kontra WebMCP: mapa sposobów komunikacji agenta z aplikacją, w tym różnica między wywołaniami narzędzi a podejściem zdarzeniowym.
- Setup Scotta w pi i pi durable („mniej znaczy więcej”) oraz Sick Picks: naścienne ramienia boom do światła i ultracienkie kable Ethernet Monoprice.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Kontekst żyje w plikach, nie w czacie
Na czym polega: Wszystko, co nie może przepaść razem z zamknięciem rozmowy z agentem, powinno trafić do pliku Markdown w repozytorium albo do komentarzy w kodzie. Agenty coraz lepiej same podchwytują kontekst z tego, co leży w projekcie.
Jak stosować: Po każdej istotnej sesji mów agentowi: „zapisz ustalenia do pliku .md w repo, żebyśmy mogli je podjąć”. Nowe narzędzie czyta plik na starcie i kontynuuje pracę.
Na co uważać: Komentarze w kodzie muszą nadal zgadzać się z implementacją — jeśli kod się zmieni, a komentarz nie, wprowadzają w błąd kolejnego agenta.
2.Proś o prompt przekazania, zanim skończy się sesja lub limit
Na czym polega: Zamiast czekać na komunikat o wyczerpaniu limitu, pilnuj zużycia i na czas poproś agenta o krótki „prompt przekazania”: nad którymi plikami pracował, na jakim etapie jest, co dalej.
Jak stosować: Przy zbliżającym się końcu rozmowy: „napisz mi prompt przekazania do następnego czatu”. Kopiujesz, wklejasz do nowego narzędzia i jedziesz dalej.
Na co uważać: Gotowe skille przekazania często zapisują pliki w katalogach tymczasowych (trzeba potem podawać długie ścieżki) albo zostawiają śmieci w projekcie — ustal miejsce zapisu i sprzątaj po odebraniu.
3.GitHub issues jako wspólna lista zadań dla wielu agentów
Na czym polega: Etap planowania warto oddać taniejmu modelowi: bada, co trzeba zrobić, i zakłada zgłoszenia. Potem kilka agentów realizuje je równolegle, a na końcu jeden „grubszy” agent scala pull requesty.
Jak stosować: „Oto lista rzeczy, które chcę zrobić — zbadaj, co jest potrzebne, i załóż issue do każdej”. Następnie odpal 3–4 agenty równolegle; przy 16 otwartych PR-ach poproś jednego o scalenie całości.
Na co uważać: Równoległość oznacza konflikty przy scalaniu — planuj zadania tak, żeby jak najmniej dotykały tych samych plików.
4.Skille powstają przez destylację, nie na zamówienie
Na czym polega: Dobry moment na utworzenie skilla to ten, gdy po godzinie-dwóch rozmowy udało się coś ustalić i chcesz to powtarzać identycznie. Sklepiony od zera na polecenie „zrób mi skill, który robi X, Y, Z” zwykle zawiera mnóstwo zbędnych rzeczy, a raporty wskazują, że takie skille są mniej skuteczne.
Jak stosować: Gdy czujesz „nie możemy tego stracić — tak chcemy to robić”, powiedz: „zapisz to jako skill, żebyśmy następnym razem zrobili dokładnie tak samo”.
Na co uważać: Skill to nie tylko instrukcja po angielsku — dobre skille to często przede wszystkim zbiory skryptów. Zanim zapiszesz coś jako skill, sprawdź, czy to nie powinien być po prostu skrypt.
5.Regularnie przycinaj globalne skille i pliki kontekstu
Na czym polega: Wczytanych „w tle” umiejętności może być osiemnaście — i agent robi wtedy rzeczy, o które nikt go nie prosił (w rozmowie: zapomniana globalna preferencja SvelteKit w projekcie czysto skryptowym, bez UI). Zdarzają się też konflikty między skillami.
Jak stosować: Rób audyt skilla po czasie; rozważ wybieranie skilli per projekt przy jego zakładaniu i całkowitą rezygnację z globalnych. Część skilli przerób na zwykłe skrypty.
Na co uważać: Mocno rozszerzone narzędzia bywają slower i żarłoczne tokenowo (przykład z odcinka: agent budujący 4000 testów przepuszczanych przez przeglądarkę) i trudniej je zsynchronizować między kilkoma maszynami.
6.Figma MCP: bierz wartości z projektu, nie zgaduj ich ze zrzutu
Na czym polega: Zamiast „mierzyć” projekt na obrazku, agent podłączony przez Figma MCP dostaje wartości wprost z pliku — może odczytać design system i tokeny, jeśli projekt jest w Figme dobrze zbudowany.
Jak stosować: Podłącz Figma MCP, pozwól agentowi pobrać tokeny i wartości, a potem wbuduj pętlę weryfikacji: zrzuty ekranu w kilku rozmiarach okna i porównanie z projektem.
Na co uważać: Wtyczka Figmy działa tylko z częścią środowisk agentowych (harnessów) — sprawdź zgodność, zanim zaplanujesz cały proces wokół niej. Weryfikacja wizualna zjada tokeny i czas; zarezerwuj na nią budżet.
7.Do pracy wizualnej — modele mocne w obrazie, ale czytaj wygenerowany kod
Na czym polega: Wskazówka z odcinka: Opus 5.5, Fable i Astra świetnie radzą sobie z wejściem wizualnym. Przykład ostrzegawczy: agent producenta Randy’ego odtworzył przycisk z wideo co do piksela, a kod był fatalny pod względem wydajności.
Jak stosować: Przy implementacji makiet wybierz model dobry w obrazie, a jakość kodu weryfikuj osobno — wydajność, strukturę, dostępność.
Na co uważać: „Wygląda identycznie” nie znaczy „zrobione dobrze” — wygląd i jakość implementacji trzeba oceniać oddzielnie.
8.Interakcja i UX to wciąż przewaga człowieka — zwolnij i kieruj
Na czym polega: Modele słabo radzą sobie z interakcją w interfejsach. Zadanie człowieka to zdefiniować prymitywy (wzorce kodu, plik agents.md, skill opisujący „jak u nas się robi te rzeczy”) i iterować powoli, będąc człowiekiem w pętli.
Jak stosować: Cel: osiągnąć z interakcją i UI to, co z kodem — moment „to jest dokładnie taki HTML/CSS/JS i taka dostępność, jakie sam bym napisał”. Zaufanie budują procesy weryfikacji: zrzuty wracające do agenta, testy dostępności.
Na co uważać: Jeśli cała twoja usługa to przepisywanie pliku z Figmy na wierny kod, ta usługa szybko straci wartość. Ratunkiem jest przejście od „robienia” do „kierowania agentami”.
9.Pytaj „co nowego mogę dzięki temu robić”, a nie „jak robić stare szybciej”
Na czym polega: Według Wesa to pytanie rozgranicza ludzi, którym się teraz powodzi, od reszty. Przykłady z odcinka: AI do wykrojów krawieckich (branża żony, program Clo 3D) oraz broker nieruchomości bez wykształcenia informatycznego, który w jedną noc postawił biznes sprzętowy wokół ramki za 17 dolarów sztuka.
Jak stosować: Spisz problemy swojej branży i branż, których wcześniej nie dotykałeś, i sprawdzaj po kolei, które da się zaadresować agentami. Buduj małe, tanie eksperymenty.
Na co uważać: Szybko „przepompowane” biznesy klepane w całości przez AI wysychają — trwałą wartość dają realne problemy. I nie odpuszczaj po pierwszym „nie działa” — w odcinku różnicę robili ludzie z uporem, nie z dyplomem informatyki.
10.W agentach (i w pi) mniej znaczy więcej
Na czym polega: W benchmarkach omawianych w odcinku czyste, „gołe” pi wypadło lepiej niż mocno rozbudowane zestawy rozszerzeń. Setup warto rozbudowywać dopiero wtedy, gdy czegoś realnie brakuje.
Jak stosować: Zacznij od minimalnej konfiguracji i dodawaj pakiety tylko wtedy, gdy ich potrzebujesz (a brakujące — jak rozszerzenie WebMCP — możesz napisać sam). Rozważ własne mikro-narzędzia, np. „zaznacz element w UI, opisz problem, a system wysyła do agenta DOM, komponent i ścieżkę do naprawy”.
Na co uważać: Katalog rozszerzeń kusi obietnicami — nadmiar pogarsza wyniki, spowalnia pracę i komplikuje synchronizację między maszynami.
Redakcyjne tłumaczenie
Wstęp
Wes: Witamy w Syntax. Dzisiaj „potluck”, czyli odcinek z waszymi pytaniami. Wśród nich: jak przekazać kontekst z jednego agenta kodującego do drugiego — przesiadasz się z Claude Code do Codex albo czegokolwiek innego, a w tamtej rozmowie siedzi cała cenna wiedza. Zapytamy też, czy skille tworzone przez AI są w ogóle dobre. I na jakie umiejętności techniczne warto się teraz nastawić — bo parę dzisiejszych pytań emanuje smutkiem co do przyszłości, ale spokojnie, postaramy się was pocieszyć. Rozbierzemy na części temat stron o wysokiej wierności projektowej: jest taki słuchacz, który dostaje w Figme świetne projekty i musi je implementować — czym on w ogóle jeszcze się zajmuje, prawda? A na koniec wyciśniemy ze Scotta jego setup w pi. Pytania nadsyłajcie na syntax.fm, zakładka „potluck” w nawigacji. Nazywam się Wes, ze mną Scott. Zaczynamy.
(Informacja dodatkowa: „potluck” to stały format Syntax — odcinki, w których Wes Bos i Scott Tolinski odpowiadają na pytania słuchaczy.)
Jak przekazać kontekst między agentami
Wes: Pierwsze pytanie — i od razu ciekawostka: najwyraźniej ktoś próbował przemycić u nas promocję własnego produktu, bo w przesłanym linku siedział znacznik UTM ze źródłem „syntax.fm”. Nazwy nie wymienimy, bo to próba nieczystej gry, ale samo pytanie jest dobre: gdy odpalasz Claude Code i Codex równolegle do różnych zadań, jak śledzisz, co który robi, i jak przenosisz kontekst z jednego do drugiego? Notatki, pliki, osobne repo na agenta?
Mam to nawet u siebie: zadanie, o którym myślę „zrobię to tańszym albo darmowym modelem”, a ten model musi przecież wiedzieć, co ustaliłem w tamtej długiej rozmowie. Claude Code i Codex coraz lepiej same pamiętają, co się działo, ale ja i tak prawie zawsze mówię: „zapisz ustalenia do pliku Markdown, żebyśmy mogli je podjąć”, albo „dodaj w kodzie komentarze, dlaczego tak zrobiliśmy”. Wiem, że nad komentowaniem się wzdycha, ale komentarze to świetny nośnik kontekstu — byle nie rozjeżdżały się z implementacją. Poza tym te narzędzia i tak bardzo dobrze zbierają kontekst z tego, co leży w projekcie. Zasada jest prosta: jeśli coś nie może przepaść razem z zamknięciem czatu, musi być zapisane — w kodzie albo w pliku Markdown, co zwykle jest najprostsze. Scott, a ty masz jakieś ulubione sposoby na pamięć?
Scott: Używam narzędzia Dex, dostępnego na dex.rip — napisał je zresztą mój szef, David Cramer. To w gruncie rzeczy zarządzanie projektem zapisane w pliku JSON, więc agent może je odpytać i wiedzieć, na którym kroku czegoś jest. Mam wpiętą ogólną instrukcję: „odnotowuj w tym, nad czym pracujesz”. Dzięki temu zadania nie znikają w wewnętrznej liście rzeczy-do-zrobienia konkretnego agenta — a to jest właśnie dziwne w tych narzędziach: każde buduje własną listę zadań, zamiast żeby ta lista żyła w projekcie, jako coś, co da się wrzucić do gita, choćby w stylu zgłoszeń na GitHubie. Robił to dokładnie projekt Beads, ale Dex jest znacznie lżejszy i używam go bez przerwy.
Co do samego przekazywania: są gotowe skille typu „handoff”, które zapisują w dokumentacji plik z opisem, nad którymi plikami się pracowało i w jakim kontekście. Moim największym zastrzeżeniem jest to, że takie pliki lądują w katalogu tymczasowym — i trzeba potem agentowi podać tę długą ścieżkę — albo w samym projekcie, jako kolejny plik-śmietnik, którego nikt nie sprząta. Ja po prostu jestem na bieżąco z użyciem agenta: nie czekam na komunikat, że skończył się limit. Gdy widzę, że się zbliża, proszę: „napisz mi prompt przekazania”. I to wszystko — coś, co mogę ręcznie skopiować i wkleić do następnego narzędzia. U mnie działa to idealnie. Im większy i bezobsługowy system budujesz, tym bardziej chcesz, żeby to szło automatycznie do plików; ale ja nie robię nic ponad „napisz mi krótki prompt: nad którymi plikami pracujesz i na jakim etapie”. A przy Dexie, gdzie każde zadanie ma zapisane szczegóły — które pliki, jaki plan — kontekstu z przekazania w ogóle nie potrzebuję. Mówię „weź następne zadanie” i agent czyta wszystko prosto z niego.
Wes: Mam jeszcze dwa wnioski. Jeśli chodzi o to, jak coś robimy — proszę agenta, żeby destylował to do skilla, żeby następnym razem zrobić to dokładnie tak samo. Jeśli zaś chodzi o to, co trzeba zrobić — uwielbiam GitHub issues. Na etapie planowania odpalam taniego agenta: „oto lista rzeczy, które chcę zrobić; zbadaj, co jest potrzebne, i załóż zgłoszenie do każdej”. Potem możesz je realizować po kolei albo równolegle — trzy, cztery agenty naraz — bo nic nie jest uwięzione w jednym czacie. Może być szesnaście otwartych pull requestów i jeden „grubszy” agent, który na koniec scala wszystko w całość.
Scott: Zgadzam się z tym wszystkim, ale mam coś do przetestowania na tobie: skille tworzone przez AI są dla mnie problematyczne. Widziałem niedawno raport, że takie skille są mniej skuteczne. I tak z innej beczki — gdy mam kilka maszyn, każda z własnymi skillami w repozytorium gita, wszystko i tak się rozjeżdża; dochodzą globalne pliki kontekstu i po jakimś czasie nikt nie pamięta, co gdzie jest. Zamierzam to brutalnie przyciąć, bo czasem mam wrażenie, że moje skille i domyślny kontekst przysparzają więcej problemów niż korzyści. Poza tym wiele skilli można by zredukować do zwykłych skryptów. Oczywiście nie wszystko: rzeczy oparte na guście albo na zachowaniach agenta mają sens jako skill — ale skill wygenerowany przez agenta często mógłby być po prostu skryptem.
Wes: Moja reguła wygląda tak: gdy po godzinie, dwóch rozmowy z agentem dochodzimy do momentu „nie możemy tego stracić — wymyśliliśmy to, tak chcę to robić”, wtedy proszę o zapisanie w skillu. I nie jest to „skill wygenerowany przez AI” w tym sensie, który cię boli. Ale jeśli powiesz nowej rozmowie „zrób mi skill, który robi X, Y i Z”, nawciska tam mnóstwo zbędnych rzeczy. Ostatni skill, który zrobiłem, dotyczył ramki na zdjęcia — projektu, w którym setki osób naraz zgłaszało logi i problemy ze swoimi ramkami. Nie było mowy, żebym czytał to wszystko osobiście.
Scott: Czytać… ręcznie?
Wes: No właśnie. Więc otworzyłem nową rozmowę: „musimy to wszystko przetworzyć — zadawaj mi pytania, jak sobie z tym radzić”. Po kilku rundach odsiewaliśmy śmieci: ludzie próbowali na przykład wciągać w pull requestach całe frameworki. Nie — załóż własne repozytorium, my nie dodajemy każdej funkcji pod słońcem. Całość, po serii pytań i odpowiedzi, wylądowała w skillu.
I coś, czego wiele osób nie zauważa: skill może składać się z wielu skryptów. Moje skille często są cięższe od strony skryptów niż od strony instrukcji. Więc skille tworzone przez agenta są w porządku — pod warunkiem ostrożności. Ludzie narzekają, że „Claude robi X, Y, Z”, a to dlatego, że mają wczytanych osiemnaście skilli i agent robi dokładnie to, co mu kazano.
Scott: I czasem te skille się wzajemnie gryzą. Piszę przeważnie w Svelte, ale robiłem projekt czysto skryptowy, bez ani jednego elementu interfejsu. Agent na to: „plan — zbudujemy to w SvelteKit”. Skąd?! A, zapisałem to kiedyś w globalnym kontekście i po prostu zapomniałem.
Wes: Globalne skille to błogosławieństwo i przekleństwo. Mam tak z „agent browserem”: kocham, gdy agent sam odpala przeglądarkę i robi zrzuty ekranu — ale czasem postanawia „skonstruuję cztery tysiące testów i przepuszczę je wszystkie przez przeglądarkę”. Wolne i żarłoczne tokenowo, trzeba go hamować. Bardzo podoba mi się w Open Code, że na pasku bocznym od razu widać podłączone MCP. Szkoda, że tak nie widać skilli — włączałbym je per rozmowa. Da się, ale na tyle地势 upierdliwie, że po prostu tego nie robię.
Scott: Może rozwiązanie jest takie: przy zakładaniu nowego projektu wybieram skille przeznaczone konkretnie dla niego, a globalnych pozbywam się w ogóle. I częściej niż skill chcę po prostu skryptu: „co chcesz zrobić? — to i to — dobrze, biorę te narzędzia”. Inaczej te głupie skille będą przeszkadzać — bo czasem naprawdę przeszkadzają. Ciekawy pomysł; ktoś na pewno już to zrobił, sprawdzimy.
Wierne wdrażanie projektów z Figmy
Scott czyta pytanie od Wijgaarta z Holandii: „Dostaję od klientów projekty w Figme, a moją pracą jest przełożenie ich na działające strony. Większość klientów to projektanci i agencje projektowe, więc kluczowa jest wierność odwzorowania — i w tym się przez lata wyspecjalizowałem. W erze AI mam wrażenie, że ta specjalizacja mnie hamuje: niemal całą pracę deweloperską mogę zlecić agentom, ale to, za co dostaję zapłatę i co pochłania najwięcej czasu — wierne przenoszenie projektów — agentom wciąż wychodzi słabo. Jak zmusić agenta, żeby pisał CSS tak jak ja? Jaki model polecacie?”
Scott: Zawsze, gdy robię cokolwiek wizualnego, opieram się na modelach Anthropic — mam wrażenie, że lepiej „widzą”, jak coś wygląda. Czy to się utrzyma przy samej implementacji cudzego projektu, a nie przy projektowaniu — zobaczymy, ale tak mi się pracuje najlepiej. Mamy teraz w toku projekt nowej strony Syntax, więc temat żyję. Ogromną wartość dał mi Figma MCP. Trzeba tylko pilnować, żeby używać właściwego harnessa, bo Figma udostępnia tę integrację tylko niektórym — i to jest moja mała zadra. (Informacja dodatkowa: MCP, Model Context Protocol, to standard łączenia modeli z zewnętrznymi narzędziami i danymi; harness to środowisko, w którym pracuje agent, np. Claude Code.) Figma MCP sprawia, że agent nie „mierzy” projektu ze zrzutu — dostaje wartości wprost z pliku: odczyta design system, wyciągnie tokeny. Jeśli projekt jest w Figme porządnie zbudowany, agent ma komplet danych. A potem dochodzi pętla weryfikacji wizualnej: agent browser albo coś podobnego, zrzuty w kilku rozmiarach okna, sprawdzanie, czy wartości się zgadzają. To jest właśnie to — wbudowane kroki walidacji.
Wes: Nagraliśmy kiedyś film, w którym nasz producent Randy stanął ze mną w pojedynku na odtworzenie przycisku. Randy po prostu wrzucił agentowi wideo tego przycisku — i dostał dokładnie ten przycisk. Patrzysz potem w kod, a kod jest fatalny, zły dla wydajności. Ale wizualnie: pełny sukces. Wskazówki więc: Opus 5.5, Fable i Astra świetnie radzą sobie z wejściem wizualnym — jeśli zależy ci na wysokiej wierności, używaj któregoś z nich. Pytający ma pewnie też na myśli interakcje — i to jest miejsce, w którym modele są po prostu słabe. Trzeba zejść do prymitywów: zdefiniować w przykładach kodu, a także w agents.md albo skillu, „jak u nas się robi te rzeczy”, żeby agent wiedział, jak chcesz. I trzeba zwolnić. Interakcji w UI i UX żaden z tych modeli jeszcze nie rozgryzł — bądź człowiekiem w pętli. Bo jeśli twoim całym zajęciem jest wzięcie pliku z Figmy i wyprodukowanie wysokowiernej strony, to wkrótce odkryją, że do tego nie potrzebują ciebie. Ale jeśli naprawdę poświęcisz czas subtelnym interakcjom i likwidowaniu bylejakich interfejsów — to będzie twoja praca: jak budować i kierować agentami tak, żeby wynik był taki, jakbyś budował sam. Z kodem ten moment już mamy — od roku, dwóch mówimy na podcaście „to jest kod, który sam bym napisał”. Jak dojść do tego samego zdania o interakcji, HTML, CSS, JavaScripcie i dostępności?
Scott: Po części to kwestia zaufania, że agent napisze coś dobrego — a ono bierze się z procesów weryfikacji: zrzutów wracających do agenta, testów dostępności, rzeczy, które prowadzą do lepszego, bardziej przewidywalnego kodu, wciąż w stylu agentycznym. Sam dużo w to zainwestowałem.
Wes: Zabawne, bo to wraca do poprzedniej odpowiedzi: weryfikacja na końcu potrafi ciągnąć się w nieskończoność. Właśnie po to czekam na nowy, mocniejszy komputer — żeby te setki skryptów kontrolnych biegały szybciej niż na Macu mini. Laptopa mam pięć lat i przez cztery chyba ani razu nie słyszałem wentylatora; teraz słychać go bez przerwy, bo agent odpala tysiąc okien przeglądarki, robi zrzuty, renderuje trójwymiar i wszystko ze sobą porównuje. Wniosek o mocy obliczeniowej jest ciekawy: nie chodzi tylko o to, żeby odpalać własne modele lokalnie — chodzi też o to, żeby weryfikacja przebiegała możliwie szybko.
Jakie umiejętności techniczne rozwijać w erze AI
Scott czyta pytanie od słuchacza, który przedstawia się jako „nietypowy programista”: „Co robić, by rozwijać kompetencje techniczne, lepiej przyjąć AI jako narzędzie i stać się mniej wymiennym na rynku pracy — zwłaszcza gdy nie ma się klasycznego informatycznego wykształcenia, bez zajęć z algorytmów i teorii?”
Wes: To pytanie słyszymy już setny raz. „Czy dokładać do algorytmów?” — matematycy pewnie odradzą, bo AI robi to również coraz lepiej. Ale najważniejsze jest co innego: przestań pytać „jak użyć tej technologii, żeby robić to, co robiłem wcześniej”. To za mało, bo każdy będzie mógł robić swoje dawne zajęcie szybciej. Jeśli chcesz zostać w branży, zadaj sobie dwa pytania. Pierwsze: jak zastosować tę technologię w mojej branży albo w branżach, których wcześniej nie dotykałem? Ludzie, którym teraz idzie świetnie, to ci, którzy patrzą na ten „dżin z butelki” i pytają: do czego go użyć? Przykład: wykroje krawieckie. Moja żona jest projektantką mody — szyje, kupuje wykroje. Spora część tej branży zajmuje się projektowaniem wykrojów tak, by idealnie leżały. Jest program Clo 3D, w którym projektuje się ubrania w trójwymiarze i dostaje płaski wykrój do wycięcia i zszycia. Mój umysł od razu: czy AI potrafi robić wykroje? Dałoby się przez WebMCP powiedzieć „zaprojektuj t-shirt… skróć szyję, wydłuż rękawy”? Zeskanować siebie i dostać idealnie dopasowany T-shirt? Są już ludzie, którzy zadają te pytania — i to jest naprawdę ciekawa pozycja dla kogoś takiego jak pytający: jakie problemy mojej branży, albo nowej, da się dzięki temu rozwiązać.
Drugie: bądź ciekawski, jak rzeczy działają. Cały czas wracam do ramki na zdjęcia — haka, który zrobiłem z taniej ramki cyfrowej za 50 dolarów. Da się na niej odpalić przeglądarka, kod w Ruście czy własna aplikacja na Androida, ma ekran dotykowy. Film jest na kanale YouTube Syntax — warto. (Informacja dodatkowa: materiał Wesa o przeróbce ramki za 50 dolarów wywołał falę — kilka tysięcy osób kupiło taką ramkę i eksperymentuje.) Najciekawsze było obserwowanie ludzi: jedni od razu „nie działa, oddaję, śmieć” — a inny człowiek odpalił na tym Ollamę, inni znaleźli własne metody. To pokazuje zacięcie ludzi, którzy dostawszy nowy kawałek technologii pytają: co z nim można zrobić? I idealny przykład — facet napisał do mnie wiadomość (pozwolił ją cytować): „Bardzo podobał mi się twój wpis. Skleciłem firmę o nazwie Daywell i kazałem agentowi negocjować z chińskim producentem zamówienie 250 sztuk. Zdobyłem 23 przedsprzedaże w jedną noc. Reklamy zrobiłem w ElevenLabs i Magic Patterns”. Tło: „Jestem pośrednikiem w obrocie nieruchomościami komercyjnymi w Atlancie. Nigdy nie miałem informatycznego wykształcenia, zawsze interesowałem się sprzętem. Ten świat jest niesamowity”. Zobacz, co zrobił: bez żadnego doświadczenia pytał — czy zrobię do tego interfejs? czy znajdę producenta? Ramki, które kosztują 50 dolarów, wykupił po 17 sztuka, więc widać, jakie są tanie w wytworzeniu. Czy rozkręcę reklamę? Takie pytania powinieneś zadawać. Niekoniecznie „czy zbuduję na tym biznes” — sam takiego w całości AI-klepanego przedsięwzięcia nie pochwalam, takie okazje szybko wysychają — ale „co jeszcze mogę dzięki temu robić? Jakie inne branże? Co zrobiłbym dziś, czego wcześniej nigdy bym nie zrobił — na przykład sprzętowy produkt, będąc pośrednikiem nieruchomości?”.
Scott: No i to zacięcie, żeby przepchnąć się przez „nie działa”, zamiast odpuścić po pierwszej próbie.
Wes: Niestety trzeba ciężko pracować; nie da się tylko klepać w okienko i czekać, aż wszystko zadziała… choć ten gość, szczerze mówiąc, właśnie tylko klepał w okienko.
Scott: W sporej mierze tak. Zgadzam się w stu procentach, niewiele mam do dodania. AI połyka znacznie więcej niż jedną-dwie branże. Mój ojciec kończył szkołę jako kreślarz techniczny — inżynier, rysował części. I wyobraź sobie: dopracowujesz taki warsztat, a tu przychodzi CAD i cała twoja tożsamość zawodowa zostaje zwinięta w jeden z tysiąca innych warsztatów. Dużo o tym myślę — jak wielką transformację trzeba było przejść, żeby zostać na fali. To wszystko jest teraz dziwne dla ludzi.
Wes: To prawda i to jest trudne. Rozumiemy — sami tak czujemy. Ale trzeba trzymać się dalej.
Odpowiedź na krytyczny list słuchacza
Scott czyta list od Saeeda: „Długoletni słuchacz, piszę z ciężkim sercem: Syntax jako firmowa własność w końcu zaczyna dawać się we znaki. Długo opierałem się tej prawdzie, ale ostatni potluck wbil ostatni gwóźdź do trumny. Dwa punkty mnie zabolały. Po pierwsze: twierdziliście, że utrzymanie wielu ludzi — emerytury, inwestycje — jest związane z firmami AI i że życzenie AI upadku to życzenie źle zwykłym, niewinnym ludziom. Po drugie: mówiliście, że pisanie kodu ręcznie to przeszłość — chyba że ktoś chce być artystą i robić ręcznie robiony, rzemieślniczy kod”.
Wes: No dobra — obie te rzeczy powiedzieliśmy.
Scott: Wes, ty masz na to bardziej ułożone przemyślenia.
Wes: Do pierwszego: to prawda, że od branży AI zależy utrzymanie wielu ludzi. Ogromne inwestycje — a więc i emerytury — tkwią w tych centrach danych. Nie mówiliśmy, że to dobrze. Dostaliśmy po tamtej rozmowie naprawdę przemyślane wiadomości od ludzi, którzy tłumaczyli, jak dokładnie wygląda kwestia wody w tych instalacjach — bo w praktyce nikt tego nie rozumie. Ale tak: choć nie chcę, żeby to była prawda, wiele bardzo dużych firm jest mocno obciążonych zakładem, że AI się powiedzie. Jeśli się nie powiedzie — a może się nie powieść — poleciałyby z tym nie cała gospodarka, ale jej spory kawał.
Scott: Tempo tych zmian jest szalone. Myślę o bańce dotcomów: po jej pęknięciu komputery nie zniknęły i internet nie zniknął — ale mnóstwo zupełnie zwykłych, niewinnych ludzi straciło wtedy pracę.
Wes: I dopowiem: patrząc na pieniądze wlewane w całość — także w ludzi — nie widzę, jak to się ma zwrócić. Widać teraz masowe przeskoki między firmami, a gdybyście słyszeli kwoty, jakie ci ludzie dostają… Wielkie firmy wydają niewiarygodne pieniądze po to, żeby wygrać. Jestem tylko zwykłym programistą, ale nie pojmuję, jak abonament stu, dwustu dolarów miesięcznie dla zaawansowanych użytkowników zamieni się w takie przychody. Więc tamta uwaga była po prostu stwierdzeniem, jak to działa — linkowaliśmy film — ale ja też się tego trochę boję.
Do drugiego punktu: „pisanie kodu ręcznie to przeszłość, chyba że ktoś chce być artystą”. Chyba powiedzieliśmy „ręcznie robiony, rzemieślniczy”?
Scott: Tak. Z miłością. Taki zwrot używaliśmy zawsze na rzeczy robione bez gotowców.
Wes: Niestety uważam, że to była uczciwa teza. Nie cały mój kod powstaje dziś z AI — wchodzę tam i sporo robię sam, zwłaszcza przy interakcjach, które mnie niepokoją. Ale punkt był sprawiedliwy.
Scott: Pisze dalej: „Biorąc pod uwagę kontrowersje wokół całej branży AI, odpowiedzialnym podejściem dla najpopularniejszych programistów webowych byłaby neutralność, a nawet lekka defensywa”. Na to odpowiadam: nie sądzę, żeby ktoś miał mi mówić, jak mamy się z tym czuć. Uważam, że na tym podcaście jestem człowiekiem wyważonym, zmieniam zdanie, gdy ktoś mnie sensownie prostuje — czasem ludzie mają po prostu lepsze informacje. Ale nie będę celowo przyjmował pozycji defensywnej „bo tak wypada”. Staram się mówić po prostu wprost, jak jest.
I jeszcze zarzut, że „firmowa własność w końcu daje się we znaki”. Chcę powiedzieć jedno: mamy nad Syntaxem pełną kontrolę twórczą. (Informacja dodatkowa: Syntax należy do firmy Sentry, zajmującej się monitoringiem aplikacji; Scott jest jej pracownikiem.) Jedyna rzecz, jaką Sentry nam kiedykolwiek zakomunikowała, to „mówcie o Sentry mniej, bo mówicie o Sentry za dużo”. Są absolutnie nieingerujący i wspierający: dają budżet, zero wytycznych, przestrzeń na próby i na zatrudnianie dobrych ludzi. Każda zmiana, jaką widzicie w Syntax, pochodzi od Wesa i ode mnie — to nie jest nic korporacyjnego. Rozumiem, skąd to wrażenie, ale tak to wygląda. A skoro już przy tym jesteśmy — sprawdźcie Sentry na sentry.io/syntax: znajdą pierwotną przyczynę błędu i o drugiej w nocy założą pull request, więc budzisz się, a kod sam się zasklepił. Dzięki, Saeed, za okazję do wstawienia tej reklamy. Czuję się trochę jak Garth z „Wayne’s World” — właśnie zdjęłem bluzę Sentry i pod spodem mam koszulkę Sentry. Ale to naprawdę fajna firma i to dzięki niej możemy robić fajne rzeczy. Pozdro, Sentry.
Web Serial: flashowanie ESP32 w przeglądarce
Scott czyta pytanie Evana Willsa: „Jak obsługujecie ponowne łączenie w Web Serial? Buduję przeglądarkowe IDE kompilujące firmware dla smartwatcha na ESP32 — biorę malutki mikrokontroler, dokładam ekran, wibrator, kolorowy wyświetlacz i powstaje majsterkowany smartwatch. Flashowanie idzie przez Web Serial. Gdy układ S3 restartuje się do bootloadera, połączenie potrafi spaść i wrócić”.
Scott: O co chodzi: gdy wgrywasz nowy firmware, ESP32 musi wejść w specjalny tryb przyjmowania oprogramowania, po czym uruchamia się z powrotem. Problem w tym, że przy każdym połączeniu przez Web Serial w przeglądarce wyskakuje to głupawe okienko wyboru urządzenia — jak przy wyborze kamery z listy. Automatycznego ponownego połączenia nie ma. Jakie masz opcje? Po pierwsze — dlatego wielu ludzi idzie w Electrona: chcesz tej samej technologii, ale innego doświadczenia; mógłbyś dystrybuować własną przeglądarkę, która łączy się z powrotem bez tego zabezpieczenia. Po drugie — aplikacja desktopowa albo po prostu terminal. Po trzecie — da się to chyba obejść dobrym UX-em. Flashowanie w terminalu jest po prostu wygodne przy ciągłej iteracji: mam tu badge podpięty przez USB cały dzień — nieustannie lecą na niego nowe firmware, logi, sprawdzam, jaki kształt danych przychodzi z czujnika. W przeglądarce tego nie zrobisz. Web Serial nadaje się do „wrzucę firmware raz”; gdy nieustannie iterujesz — patrz raczej na aplikację desktopową albo narzędzie w terminalu.
Wes: Mój „prompt boy” — urządzenie z ESP32-S3 i ekranem — musiałem ostatnio szybko rozebrać. To taki ciasny klocek, a podczas pracy bardzo się nagrzał. Niepokojąco. Parę minut napięcia było.
Scott: Też tak miałem — kilka egzemplarzy zrobiło się bardzo gorących. Zwykle to zwarcie: coś dotyka złego pinu i napięcie leci złą drogą. Czasem zostaje tylko wyrzucić do wiadra, bo nadają się do niczego.
„Czuję się dziwnie winna”: żałoba po własnych umiejętnościach
Scott czyta pytanie od Rainy z Vancouver: „Słucham was od pierwszego odcinka i rosłam jako programistka razem z podcastem — od niewiedzy, czym jest React, po pełnostackowe aplikacje produkcyjne. Kupiłam kursy i u Scotta, i u Wesa. Od lat buduję wewnętrzną aplikację Reactową, na której działa cały nasz rodzinny biznes. Ostatnie miesiące to mocne kodowanie z AI, obecnie Claude Code w VS Code. Przerabiam gigantyczny zaległy backlog rzeczy, które zawsze chciałam dodać — ale czytam coraz mniej kodu, a czasem w ogóle go nie rozumiem do końca. Z jednej strony szybko rozwiązuję bardzo realne problemy biznesowe, z drugiej zdaję sobie sprawę, że pisanie kodu nigdy nie było tym, co naprawdę lubiłam — zawsze czekałam na gotowy produkt. Bez AI nie zaczęłabym nowego projektu. Na szczęście, bo uczyłam się wszystkiego po trudnemu, wystarczająco rozumiem programowanie, architekturę systemów, projektowanie UI i UX. Jak patrzycie na ten nowy paradygmat? Nie przeszkadza mi, że AI robi pracę, którą umiem zrobić sama — ale czuję się dziwnie winna, że zastępuję AI wiedzę zdobywaną latami”.
Scott: Czuję to cały czas. Cały czas o tym myślę. Ale powiem tak: nie uwierzysz, ile się kiedyś nauczyłem o budowaniu stron pod Internet Explorerem 5, 6 i 7. Ile narzędzi i technik — „sliding doors”, clearfixy — ile realnego, ciężko wypracowanego czasu w to włożyłem, a wszystko unieważniły kolejne fale i frameworki. Nawet sam React w trakcie swojego życia wymienił osiemnaście sposobów robienia rzeczy. To przychodzi i odchodzi. Więc nie czuj się winna — choć rozumiem doskonale i sam opłakuję umiejętności, na które zapracowałem się naprawdę ciężko. Trzeba to po prostu przeżałować: uznać, że ten czas i ten wysiłek były prawdziwe. I nie patrzeć wstecz zbyt mocno, bo patrząc wstecz przestajesz patrzeć do przodu — a w tej branży nie masz teraz innej opcji niż patrzeć do przodu. Jeśli praca sprawia ci teraz więcej radości, nie masz się z czego tłumaczyć.
Wes: To zresztą zawsze tak wyglądało. Sprzedawałem kursy dziesiątkom tysięcy ludzi — Raina wśród nich, bardzo elegancko się przechwalam — i widziałem, że połowi kod nigdy nie chodził sam dla siebie: był środkiem do celu, liczył się produkt, bo mieli coś do zbudowania. Druga połowa kochała kod głęboko. Ja jestem chyba w obu obozach: ekscytowałem się i produktem, i nową składnią CSS, nowym media query. Duża część tego odchodzi. Ale sama napisałaś najlepszą odpowiedź: „wystarczająco rozumiem programowanie, architekturę systemów, UI, UX”. Nic z tego nie znika. Znika wiedza, gdzie postawić średnik. Architekturą, programowaniem i interfejsem nadal trzeba się zajmować — i to bardzo. Widać też przesunięcie w tym, kto będzie w tej branży naprawdę dobry: stara gwardia — ludzie, obok których zaczynałem kodować, w tym wczesni ludzie ze Shopify — odeszła od kodu do zarządzania, do najwyższych szczebli, a teraz wraca do kodu, bo może po prostu „promptować dalej”, a oni są świetni w projektowaniu produktu i w dopasowaniu do rynku. Ci, którzy kochali kod, a nie produkt, mogą być zmuszeni zmienić to, co ich ekscytuje. Albo robić własne narzędzia — jak połowa branży.
Scott: Budować własny tooling — uwielbiam. Zresztą w nauczaniu zawsze to podkreślałem: ludzi nie obchodzi technologia, obchodzi ich możliwość tworzenia. I dlatego, gdy się uczysz, wkładasz w to intencję: nie budujesz „aplikacji do zadań” — budujesz aplikację dla mamy, bo ona akurat tego potrzebuje. Motywacja jest zupełnie inna. Raina ma właściwą motywację, żeby świetnie sobie radzić w tym nieustannie zmieniającym się świecie.
AG-UI czy WebMCP — dwie drogi do tego samego
Scott czyta pytanie od DeveloPapy: „Słyszeliście o AG-UI do integracji agentów? Zrobiliście niedawno odcinek o WebMCP — wygląda na to, że AG-UI próbuje osiągnąć to samo zupełnie innym podejściem. Wasze zdanie?”. — Wes, ty wiesz, co to za AG-UI?
Wes: Dobra, patrzymy… AG-UI — nie mylić z A2UI. To warstwa interakcji od ludzi od CopilotKit — nie mylić z Microsoft Copilot, co akurat jest ich problemem nazewniczym, bo „Copilot” należy do Microsoftu. Rozłóżmy może całą tę przestrzeń. Masz aplikację i masz agenta. Żeby agent mógł z aplikacji korzystać, jest dziś kilka dróg. „Computer use” — agent po prostu obsługuje przeglądarkę jak człowiek. MCP — w skrócie: bezgłowe wywoływanie narzędzi i surowe dane. WebMCP — twoja istniejąca strona rejestruje swoje funkcje jako narzędzia, więc sam z niej korzystasz, ale możesz też powiedzieć agentowi „zaksięguj te pięć kosztów w moim systemie fakturowanym”. I jest jeszcze świat generowanego interfejsu: rozmawiasz z agentem i zamiast surowych danych dostajesz kawałek UI wpleciony w czat — restauracja do zarezerwowania, lista zakupów do odhaczenia; tak działają MCP UI czy MCP apps. AG-UI jest warstwą pomiędzy twoją aplikacją — webową, mobilną, desktopową — a samym agentem: obsługuje komunikację w obie strony i ma jedną rzecz, której WebMCP nie ma, a mianowicie jest zdarzeniowe. Coś się wydarza w aplikacji — może to wyzwolić reakcję. W WebMCP na razie są wywołania narzędzi: „podaj listę elementów”, „zaktualizuj element”. AG-UI rozwijają ludzie od CopilotKit, a CopilotKit to jeden ze sposobów zamiany danych agenta na faktyczny interfejs; jednym ze sposobów konsumpcji danych AG-UI jest renderowanie HTML. Widzę, że ma spory rozpęd i jest bardzo aktywnie rozwijane — wyglądają, jakby wiedzieli, co robią. Osobiście nie obchodzi mnie, czy ostatecznie wygra WebMCP albo czy te rzeczy w ogóle się pokrywają. Cieszę się, że przybywa dróg agentowego korzystania z aplikacji.
Scott: Ja wpiąłem WebMCP do mojej aplikacji wideo i rozmawiałem ze swoim osobistym agentem, a on nagle proponuje: „zrobić animację w twojej aplikacji?”. Pytam: „umiesz?”. On na to: „połączę się przez WebMCP” — i rzeczywiście się połączył i wręczył mi prototyp. Pomyślałem wtedy: WebMCP rządzi. Rządzi, bo siedzi w samej przeglądarce, i moim zdaniem łatwo go przyjąć. A teraz wszedłem na stronę AG-UI i aż mi niespokojnie — ile to nowych rzeczy naraz się pojawiło.
Wes: Najtrudniejsze w tych wszystkich projektach jest samo wytłumaczenie, czym one są. Gwarantuję, że po publikacji dostanę od tych ludzi wiadomość: „nie do końca dobrze to wytłumaczyłeś”. Ja też jestem pełen uznania dla WebMCP, choć drzemie we mnie jedna niewygodna kwestia — właśnie zdarzenia. Jeśli agent ma zareagować na zmianę na stronie, dziś musiałby ją raczej cyklicznie odpytywać. A wszyscy, którzy programowali, wiedzą: podejście zdarzeniowe jest po prostu lepsze.
Setup pi: mniej znaczy więcej
Scott czyta pytanie od Manon: „Możecie nagrać film o setupie pi — jak go używacie, cały flow?”
Wes: Wpychałem to pytanie do odcinka, bo nie chcę, żebyś tu robił cały film — ale jestem ciekaw: gdybyś zaczynał absolutnie od zera, z pi albo z pi durable, budując własnego agenta — jaki byłby twój proces?
(Informacja dodatkowa: pi to minimalistyczny, otwarty agent kodujący pracujący w terminalu; „pi durable” to jego wariant — szkielet do budowy trwałych, własnych agentów, które zapisują historię swojej pracy.)
Scott: Najważniejsza rzecz, o której trzeba pomyśleć na starcie: mniej znaczy więcej. To, co kusi w pi, to możliwość rozszerzania go do woli — wchodzisz w pakiety i widzisz wielki katalog obietnic. Część z nich jest świetna i konieczna, część mniej, a niektóre wręcz przeszkadza. Były niedawno oceny i benchmarki różnych harnessów — i czyste, „gołe” pi wypadło lepiej niż OMP, czyli „Oh My Pi”, jak „Oh My Zsh”, które w gruncie rzeczy jest zbiorem dobranych rozszerzeń pi. OMP ma zresztą przepiękną stronę i naprawdę dobry terminal „Turn”, do którego mam dostęp — jest co lubić. Ale wniosek jest taki: nie instaluj wszystkiego naraz. Instaluj rzeczy wtedy, gdy ich potrzebujesz albo chcesz ich spróbować — i poznawaj swój workflow z nimi i bez nich. Przeszedłem fazę „dużo zainstalowanego” i fazę „mało zainstalowanego”; teraz mam w pi bardzo niewiele. Gdy zabrakło dobrego rozszerzenia WebMCP — po prostu napisałem je sam do swojego agenta, zero problemu. Potem MCP trafiło do pi natywnie. Zacznij minimalnie, dokładaj tylko to, czego realnie potrzebujesz — chyba że naprawdę poczujesz głód dodatków.
Wes: To wraca jak bumerang do wcześniejszych pytań o to, nad czym pracować. Wielu ludzi chce najpierw idealnie dopieścić własny system — a często wcale nie trzeba. Przy interfejsach, o których rozmawialiśmy, na razie trzeba. Ale to może się zmienić.
Scott: Mój pi durable zrobił się z czasem mocniej dopieszczony, ale nie przez rozszerzenia — przez łączenie narzędzi i robienie wszystkiego po swojemu. Najlepsza rzecz, jaką w nim zrobiłem, służy całej mojej rodzinnej, „agentowej” otoczce — napędza też moją ramkę na zdjęcia, oczywiście. Dodałem małe narzędzie: zaznaczasz fragment interfejsu, otwiera się okienko, piszesz, co jest nie tak — a system wysyła do agenta DOM, komponent i ścieżkę, żeby to naprawił. Nie odkryłem Ameryki, inni też to robią, ale ten drobiazg jest niesamowicie wygodny. Odpala się trwały czat, mogę pogadać, jeśli chcę — ale w przeważającej części po prostu to naprawia. Pi durable używam ostatnio więcej niż pi, ale używam obu.
Sick Picks: naścienne ramienia boom i cienkie kable
(Informacja dodatkowa: „Sick Picks” to stały segment Syntax, w którym gospodarze polecają gadżety.)
Wes: Mój pick nie jest dla każdego. Mam w biurze światła i różne sprzęty stojące na małych, chybotliwych trójnogach, o które ciągle się potykam — to nie są porządne statywy klasy C-stand. Znalazłem za to uchwyty montowane do ściany — boom army — i to jest rewelacja: światła (a można też kamerę) wieszasz na ścianie i obracasz, gdzie chcesz, a przede wszystkim nie zajmują ani centymetra podłogi i mogę pod nimi swobodnie przechodzić, bo wchodzą wystarczająco wysoko. Marka Neewer, jedna z porządniejszych fotograficznych marek dostępnych na Amazonie, ma poziomy boom arm za 36 dolarów; odpowiedniki na B&H były niepotrzebnie droższe. A samo szukanie w świecie fotografii to osobna przygoda — nie wiedziałem, jak nazywa się „patyczek, w który wkręca się światło”. Nazywa się „baby pin”.
Scott: Światła, kamery i… akcja. Z moich starszych paneli LED połowa diod już nie świeci — ale mam je od wieków, więc trudko. I rozumiem do bólu syndrom kolekcjonowania sprzętu: marzy mi się wielka pozioma belka pod sufitem. Nagrywałem kiedyś w studiu Microsoftu — mieli cały sufitowy ruszt i pomyślałem: chcę taki ruszt. Niestety to bardzo drogie. Rozglądałem się też za słupkami na wcisk, na tarciu — zajmują tylko słupek zamiast całego trójnogu — ale w rozsądnej cenie nie znalazłem, a te od glazurników są zbyt brzydkie.
Wes: Rozciągliwe rzeczy na tarciu — przy dzieciach to proszenie się o kłopot, zaraz ktoś się na tym buja.
Scott: Ty masz zresztą dwa z tych ładnych światła, prawda?
Wes: Mam dwa Amrany 150c — jeden mnie doświetla z przodu, drugi stoi z tyłu i wypełnia tło, mogę go nawet podkręcić. Poza tym tanie płaskie panele LED — tak twarde, że nie mierzę nimi w twarz — i parę fioletowo-niebieskich słupków dla koloru. Oświetlenie to czysta frajda. I bardzo dobrze, że bierzesz Monoprice, bo Amazon roi się od „Cat 19” z aluminiowymi żyłami — takim kablem nie ma co ufać.
Scott: A to akurat mój pick: ultracienkie kable Ethernet od Monoprice. Są w masie kolorów, od patchcordu pięciocalowego do pięćdziesięciu stóp. Jeśli jesteś estetą — a jestem — i chcesz, żeby kable w racku wyglądały spójnie: są cieniutkie i piękne. Dokupuję kolejne, bo z przodu racka już wszystkie mam takie, a z tyłu wisi osiemnaście różnych kabelków z całego życia.
Wes: Ja swoje kable robiłem sam i wygląda to fatalnie: niebieskie żyły, pomarańczowe koszulki… Wymieniłbym wszystko, ale nie umiem tego obronić nawet przed samym sobą.
Scott: Tyle że twój rack widać cały czas, a mój stoi w pomieszczeniu technicznym. Robią je na niebiesko, Wes.
Wes: Nie chcę niebieskich. Niebieski jest brzydki.
Scott: Dobrze — są też czerwone, żółte albo białe.
Zakończenie
Wes: Dzięki wszystkim za słuchanie. Nadsyłajcie pytania: syntax.fm, w nawigacji przycisk „potluck” — klik, pytanie, odpowiemy w którymś z kolejnych odcinków. Na razie.
Scott: Na razie.