O czym jest ten film
- Ross z kanału Ras Mic robi очередной przegląd swojego warsztatu, bo narzędzia i modele do budowania aplikacji z AI zmieniają się szybciej, niż zdążają się starzeć poprzednie rekomendacje.
- Ze środowisk pracy z agentami („harnessów”) korzysta praktycznie ze wszystkich — T3 Code, Claude Code, Cursor, OpenAI, Devin, różne CLI i aplikacje — częściowo dla frajdy, częściowo po to, żeby móc rzetelnie doradzać widzom.
- Codziennie pracuje w T3 Code, czyli „harnessie harnessów”: narzędzie pod spodem używa natywnych silników Claude Code czy Cursora, a na wierzchu daje jeden interfejs z panelem przypominającym skrzynkę odbiorczą i możliwość rozpraszania agentów na kilka komputerów w domowej sieci.
- OpenAI Codex służy mu głównie do sterowania komputerem, badań i pracy 3D (m.in. prototyp sprzętowego startupu w Blenderze), Claude Code — niemal wyłącznie jako CLI przez SSH, a Cursor i Devin — przede wszystkim do agentów działających w chmurze.
- W kwestii subskrypcji radzi świadomą „nielojalność”: wybieraj dostawcę, który akurat oferuje najwięcej — przez pewien czas były to odnawiane limity OpenAI, a po premierze Claude’a Opus 5.5 przewagę zyskało Anthropic.
- Modele (stan na wrzesień 2026): Opus 5.5 jako wszechstronny koń roboczy, GPT-6 Astra do głębokiego researchu — z zastrzeżeniem, że za dwa–trzy miesiące ten ranking będzie do wymiany.
- Stack technologiczny: SvelteKit (ewentualnie Next.js) na front, Convex wraz z komponentami integracyjnymi na backend, Effect do typowanej obsługi błędów, PlanetScale jako Postgres, a wdrożenia na Vercelu albo — jeśli już Cloudflare, to z całym jego pakietem (Workers, R2, Hyperdrive, Durable Objects).
- Narzędzia codzienne: Graphite do automatycznego przeglądu kodu z pętlą iteracji do oceny 5/5, Orgo (osobne komputery dla agentów — autor ujawnia, że jest inwestorem), Paper i Mobbin do projektowania, WhisperFlow do dyktowania, Linear do zarządzania zadaniami zespołu.
- Jego repozytorium skills jest open source i stanowi całą „fabrykę oprogramowania”: osobny worktree na każdą funkcję, pisanie kodu według narzuconej struktury, dowód działania (nagranie, zrzuty przed/po albo testy) w pull requeście oraz iterowanie po uwagach Graphite aż do oceny 5/5.
- W środku materiału znajduje się segment sponsorowany Grokbota — botów wyposażonych we własne komputery, które projektują interfejsy, wdrażają strony i scalają pull requesty prosto z telefonu.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Jedno środowisko-„meta” zamiast gorsetu pojedynczych harnessów
Na czym polega: T3 Code nie konkuruje z Claude Code czy Cursorem, tylko je spina — pod spodem pracują natywne silniki, a użytkownik dostaje jeden spójny interfejs, panel zadań wyglądający jak skrzynka odbiorcza (wątek domyka się sam po scaleniu pull requesta) i możliwość rozsyłania agentów na różne maszyny w sieci.
Jak stosować: Jeśli pracujesz na kilku komputerach albo prowadzisz wiele wątków równolegle, potraktuj takie narzędzie jako warstwę zarządzania. Wątek uznawaj za zamknięty dopiero wtedy, gdy domyka się w panelu — to zwalnia z ręcznego sprawdzania statusu pull requestów.
Na co uważać: Meta-warstwa to dodatkowe ogniwo, które może się zepsuć — warto umieć błyskawicznie zejść do natywnych CLI poszczególnych harnessów.
2.Bywaj nielojalny wobec subskrypcji
Na czym polega: Realna wartość subskrypcji zmienia się z miesiąca na miesiąc — najpierw OpenAI kusiło częstym odnawianiem limitów, po premierze Opusa 5.5 najlepszy stosunek jakości do ceny zapewnia Anthropic.
Jak stosować: Przed odnowieniem okresu rozliczeniowego porównaj aktualne limity, promocje i moc modeli u dwóch–trzech dostawców i przełącz się tam, gdzie dostajesz najwięcej. Traktuj subskrypcję jako decyzję rewizyjną, nie małżeństwo.
Na co uważać: Przeskakiwanie między ekosystemami oznacza utrzymywanie konfiguracji (ustawień, plików z instrukcjami dla agentów) w kilku miejscach naraz — trzymaj je w repozytorium, żeby każda migracja była tania.
3.Do budowania aplikacji w praktyce wystarczą dwa modele
Na czym polega: Opus 5.5 nie wygrywa skokiem inteligencji, tylko wszechstronnością: trzyma się instrukcji i świetnie znosi długie, wielogodzinne zadania. GPT-6 Astra ma sens punktowo — do głębokiego researchu i dogłębnej analizy codebase.
Jak stosować: Ustaw jeden model jako domyślny koń roboczy i drugi jako „specjalistę” od researchu. Wybór przeglądaj co dwa–trzy miesiące, bo tabela wyników starzeje się w tym tempie.
Na co uważać: Nie buduj trwałych procesów zakładających dostępność konkretnego modelu — odnośniki do nazw modeli w skryptach i dokumentacji łatwo zamienić na zmienną konfiguracyjną.
4.Agenty chmurowe powinny zaczynać pracę, zanim przeczytasz zgłoszenie błędu
Na czym polega: Tracker Linear połączony przez MCP z Cursorsem i Devinem: wystarczy otagować narzędzie przy zgłoszeniu, a agent w chmurze zabiera się do biletu. Przy błędach z produkcji bywa tak, że pull request z poprawką czeka gotowy, zanim człowiek dokończy czytać raport.
Jak stosować: Połącz swój tracker zadań z agentami chmurowymi i ustaw prostą ścieżkę: zgłoszenie → automatyczne przypisanie → pull request. Zgłoszeniom z produkcji nadaj priorytet automatycznej pracy agenta.
Na co uważać: Automat nie zna kontekstu biznesowego — ostateczny przegląd i scalenie zostaw sobie. Pilnuj też kosztów: równoległa praca wielu agentów na wielu biletach potrafi szybko zjeść budżet.
5.Wybieraj framework, w którym modele piszą dobrze „z natury”
Na czym polega: Aplikacje w Svelte/SvelteKit są domyślnie szybkie i responsywne — nawet bez proszenia modelu o optymalizacje — a agentom ta technologia świetnie wychodzi. Next.js jako alternatywa; oba dobrze współgrają z Vercelem.
Jak stosować: Przy nowym projekcie oceniaj framework przez dwa pryzmaty: jak dobrze modele go znają i jakie wyniki dostajesz „za darmo”, bez ręcznego strojenia wydajności.
Na co uważać: Framework to decyzja długoterminowa (rekrutacja, biblioteki, utrzymanie). To, że AI napisze kod w czymkolwiek, nie znaczy, że koszty utrzymania będą podobne.
6.Integracje z komponentów zamiast pisania ręcznego
Na czym polega: Convex Components to gotowe klocki integracyjne (Stripe, PostHog, WorkOS, Browserbase). Wystarczy wrzucić agentowi link do komponentu i polecić konfigurację — łącznie z sandboxem — a integracja działa od razu.
Jak stosować: Zamiast opisywać integracje słowami, podawaj agentom dokumentację w postaci komponentów. Efekt: mniej kodu integracyjnego do czytania i recenzowania.
Na co uważać: Gotowy komponent to głębsze związanie z dostawcą i utrudniona migracja. Przynajmniej raz zajrzyj, co komponent robi pod maską, zanim uznasz go za standard w projekcie.
7.Typuj błędy tak samo jak dane
Na czym polega: Effect wprowadza błędy do systemu typów — model i człowiek widzą z góry, gdzie coś może pójść nie tak, przez co powstaje mniej awaryjny kod. Dawniej zniechęcająca, rozwlekła składnia przestała być barierą, bo pisze ją za ciebie AI.
Jak stosować: W serwisach backendowych uczyń Effect domyślnym sposobem obsługi błędów, a trudniejsze biblioteki ogarniaj z pomocą modeli — one znacznie obniżają próg wejścia.
Na co uważać: Jakość kodu w trudnych bibliotekach zależy od modelu — słabsze potrafią mieszać warstwy abstrakcji, więc standardy zapisz w plikach instrukcji dla agentów.
8.Zasada „albo cały Cloudflare, albo Vercel”
Na czym polega: Jeśli projekt wymaga czegokolwiek z ekosystemu Cloudflare (storage, e-mail, edge), opłaca się wziąć cały pakiet: Workers, R2, Hyperdrive, Durable Objects. Jeśli nie — aplikacja ląduje na Vercelu. Postgres: PlanetScale, ewentualnie przez Hyperdrive.
Jak stosować: Decyzję o hoście podejmuj na starcie od wymaganych możliwości (przechowywanie plików, poczta, bliskość użytkownika), a nie od ceny samego wdrożenia.
Na co uważać: „Cały Cloudflare” to głęboka integracja, z której wyjście później bywa kosztowne. Dla prostych aplikacji Vercel bywa tańszy w utrzymaniu i prostszy w obsłudze.
9.Pętla jakości: iteruj do oceny 5/5, a człowieka włączaj na końcu
Na czym polega: Graphite ocenia pull request wskaźnikiem pewności, a skill GP Loop podaje uwagi z powrotem agentowi kodującemu — i nie odpuszcza, dopóki ocena nie osiągnie 5/5. Człowiek patrzy na diff dopiero po przejściu tej bramki.
Jak stosować: Włącz automatyczny przegląd kodu z oceną jako obowiązkowy status check w CI i dopiero po nim czytaj zmiany. Pętla „feedback → poprawka” powinna działać bez twojego udziału.
Na co uważać: Wysoka ocena automatu nie gwarantuje poprawności biznesowej ani bezpieczeństwa — ostateczna decyzja należy do człowieka. Uważaj też, by agent nie „grał pod recenzenta”, dopasowując się do komentarzy zamiast do sensu zmian.
10.Równoległość przez worktree i dowód działania w każdym pull requeście
Na czym polega: Każda funkcja zaczyna się od osobnego worktree od gałęzi głównej, więc kilkanaście agentów pracuje bez kolizji. Pull request musi zawierać dowód, że rozwiązanie działa: nagranie wideo (dla interfejsów), zrzuty przed/po albo wyniki testów.
Jak stosować: Wymuszaj dowód działania w skryptach agentów i w CI — to naturalne miejsce na automatyczną weryfikację. Przy wielu agentach równolegle nadawaj każdemu odseparowaną kopię roboczą repozytorium.
Na co uważać: Nagranie czy zrzut pokazują jeden scenariusz, nie wszystkie — uzupełniaj je testami. A worktree trzymane zbyt długo bez scalania łatwo się rozjeżdżają z główną gałęzią, więc scalaj często.
Redakcyjne tłumaczenie
Wszystko zmienia się za szybko — stąd ten przegląd
Narzędzia i technologie, których używam do budowania aplikacji z AI, zmieniają się nieustannie. Co chwilę nowe modele, co chwilę nowe narzędzia. Dlatego dziś zaktualizowany przegląd wszystkiego, z czego korzystam. Będzie o harnessach, o modelach, o narzędziach i o całym zestawie technologii. Powiem nawet, jakiej marki pieluchy kupuję dziecku — dobra, to już za dużo informacji. Tak czy siak: po tym materiale będziecie znać cały mój warsztat. Pokażę, jak z niego korzystam i dlaczego właśnie tak.
(Informacja dodatkowa: „harness” to w żargonie środowiska AI kompletne środowisko pracy z agentem kodującym — edytor, terminal (CLI) albo aplikacja z interfejsem graficznym.)
Środowiska pracy: używam ich wszystkich
Ze środowisk korzystam praktycznie wszystkich: T3 Code, Claude Code, Cursor, rozwiązania OpenAI, Devin, różne CLI i aplikacje. Częściowo po to, żeby być na bieżąco i dawać wam w materiałach rzetelne rekomendacje, a częściowo… bo po prostu sprawia mi to frajdę. Trochę to smutne, wiem. Ale do rzeczy — pokażę wam, jak tego wszystkiego używam.
T3 Code — codzienne narzędzie robocze
T3 Code to mój koń roboczy na co dzień. Jest wyjątkowy w tym sensie, że to nie jest zwykłe środowisko — to środowisko środowisk. Gdy pracuję w nim z Claude’em, pod spodem działa prawdziwy Claude Code. Gdy z Cursorsem — prawdziwy silnik Cursora. Każde narzędzie, którego używam, pracuje na swoim natywnym silniku; T3 Code jest poziom wyżej, jakby meta-warstwa.
Błyszczy za to z jednego powodu: pozwala pracować na różnych maszynach w sieci. Mam maszynę z Linuksem, maca i MacBooka Pro, na którym nagrywam — i właśnie na tych komputerach buduję aplikacje. T3 Code bardzo ułatwia podłączanie kolejnych maszyn i rozsyłanie agentów po wszystkich naraz. Interfejs graficzny jest przyzwoity. Z kolei panel boczny, moim zdaniem, jest świetny: gdy prowadzisz wiele projektów i wiele wątków, wygląda niemal jak skrzynka odbiorcza. Od razu widać, co jest skończone — mogę domknąć wątek ręcznie albo domyka się sam, gdy pull request zostanie scalony. Nie muszę nic klikać ani sprawdzać; system sam mówi mi, że praca jest zrobiona. Ten interfejs budują ludzie, którzy sami masowo katują te narzędzia tak jak my — i to widać. Wielki plus dla T3 Code.
Nawiązując: wkrótce film o tym, jak buduję w domu mini data center — pokażę całą moją sieć. Zapiszcie się na kanał, żeby nie przegapić.
Segment sponsorowany: Grokbot, czyli sześć botów z własnymi komputerami
Wiecie, co ostatnio jest u nas w domu bardzo intensywnie eksploatowane? Drogie pieluchy. Czas więc na słowo od sponsora — proszę bardzo. Jest niewiele istot na świecie, z którymi mogę rozmawiać o dziecku, a przy okazji projektować aplikacje webowe i mobilne. Nie mówię o żonie — mówię o Grokbot. Szczerze mówiąc, lepiej pokażę, niż opowiem.
Mam sześć botów, ale trzy są kluczowe: Engineer, Designer i Baby. Baby odpowiada na wszystkie pytania świeżo upieczonego taty o noworodka — Grokbot na ratunek. Z Designerem i Engineerem wygląda to tak: trafiam na stronę, która mi się bardzo podoba, wysyłam zrzut ekranu do bota Designera i mówię — chcę coś podobnego, przygotuj projekt w Paper. (Paper to alternatywa dla Figmy, bardzo dobrze współpracująca z agentami.) Po chwili mam gotowy projekt.
I teraz najlepsza część: nie wychodzę nawet z Grokbota. Zakładam czat grupowy z Designerem i Engineerem i proszę designera, żeby przekazał projekty inżynierowi do wdrożenia — chcę wersję uruchomioną pod adresem URL. Designer przekazuje, Engineer siada do roboty, Designer potem sprawdza jego pracę, a na końcu dostaję link do wdrożonej strony. Co równie fajne: każdy Grokbot ma własny komputer — może pobierać aplikacje, logować się i korzystać z informacji, które mu udostępnię.
Na koniec dowód, że Grokbot to nie zabawka — da się na nim wykonać prawdziwą pracę. Miałem do ogarnięcia sześć pull requestów. Poleciłem Grokbotowi wziąć do tego agenty chmurowe Cursora i wszystkie PR-y przeszły zatwierdzenie bez wychodzenia z aplikacji — robiąc to z telefonu. Część miała konflikty przy scalaniu; po ich naprawieniu scaliłem wszystko. Bot poczekał nawet, aż Graphite wystawi ocenę pięć na pięć. Ta cała inżynieria, projektowanie i doradztwo rodzicielskie zdarzyły się w jednym narzędziu. Da się to osiągnąć tylko z Grokbotem — albo z żoną inżynierem, ale zostańmy przy Grokbot. Link w opisie.
Wracamy do materiału.
Codex — sterowanie komputerem, badania i 3D
Korzystam też z Codexa, ale głównie do sterowania komputerem (tzw. computer use), researchu i wszystkiego, co trójwymiarowe. Przykład: nadchodzący odcinek o projekcie sprzętowym, nad którym pracuję. Cały sprzęt już zamówiony i czeka na składanie — zwlekam tylko z drugim stołem, żeby budować razem z wami. Gdy na początku zgłębiałem ten pomysł, robiłem to właśnie przez sterowanie komputerem w Codexie: Blender plus rozmowa z modelem Astra. Jeśli macie subskrypcję OpenAI, Codex sprawdza się znakomicie właśnie w takich zadaniach — projekt sprzętowy albo praca „na żywym komputerze”.
Poza budowaniem aplikacji Codex ma u mnie swoje miejsce: widzicie w panelu, że siedzi w budżecie domowym, że pomaga ulepszać moje stanowisko pracy. Zbudowałem sobie pokój w Blenderze i zapytałem, jak poprawić ustawienie sprzętu i oświetlenie. Takie rzeczy.
Claude Code — tylko CLI
Aplikacji Claude Code prawie nie dotykam. Jestem pewien, że coś w niej poprawili, ale ostatnie spotkanie było fatalne — od tamtej pory nie wracałem. Za to CLI używam chętnie, i to jest jedyna forma, w jakiej pracuję z Claude’em. Typowy scenariusz: wchodzę przez SSH na nową, obcą maszynę i muszę ustawić konfigurację sieci. Claude — zwłaszcza w wersji Opus 5.5 — jest do tego znakomity. Więc: Claude równa się CLI, nigdy interfejs graficzny.
Cursor i Devin — agenty w chmurze podpięte pod Linear
Zostają Cursor i Devin, oba używane przez interfejs graficzny, zwykle w wersjach webowych. I oba trzymam głównie do agentów chmurowych — czyli takich, które pracują na maszynach u dostawcy, niezależnie od mojego komputera. Mam swoją chmurę, ale gdy lokalnie coś już mi działa, a potrzebuję tego w agencie chmurowym, wtedy sięgam po Cursora i Devina. (CLI Cursora też używam, ale to właśnie produkt cloud agents robi na mnie wrażenie.)
Mój przepływ pracy opiera się na połączeniu tych narzędzi z Linear przez MCP. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard łączenia modeli i agentów z zewnętrznymi narzędziami i danymi — tutaj z trackerem zadań.) Jeśli chcę, żeby agent chmurowy zajął się czymś, po prostu otaguję Cursora albo Devina przy zgłoszeniu i on się tym zajmuje. I tak przy aplikacjach działających na produkcji: ktoś zgłasza błąd, a agent chmurowy bierze się do pracy, zanim w ogóle przeczytam raport. Kiedy zaczynam rozumieć, co się stało, mam już pull request gotowy do scalenia.
Którą subskrypcję wybrać? Tę, która akurat daje najwięcej
Każde z tych środowisk ma inne mocne strony, ale gdybyście pytali, po które sięgnąć — patrzcie na koszty. Czyli: gdzie dostaniecie najwięcej w ramach subskrypcji. Przez pewien czas był to OpenAI, bo limity często nam się odnawiały, ale po premierze Opusa 5.5 — powiedzmy to sobie po cichu — przewaga jest po stronie Anthropic. Tak czy inaczej moja rada brzmi: bądźcie bardzo nielojalni. Nie przywiązujcie się do jednej subskrypcji, przeskakujcie między dostawcami i bierzcie tam, gdzie dostajecie najwięcej za swoje pieniądze.
Modele: dwa warte uwagi (stan na wrzesień 2026)
Gdy idzie o modele, do budowania aplikacji używam w praktyce dwóch — a właściwie jednej: Opusa 5.5. To zdecydowanie jeden z najlepszych modeli. Nie dlatego, że robi ogromny skok inteligencji względem GPT-6 Astra (choć jest lepszy), tylko dlatego, że jest po prostu wszechstronny: trzyma się instrukcji i świetnie znosi długotrwałe zadania. Model bez wad, komplet z każdej strony. Od czasu premiery Opusa 5.5 nie czułem potrzeby sięgania po cokolwiek innego. Astra dobrze sprawdza się przy naprawdę głębokiej pracy — researchie, dogłębnym rozumieniu codebase — ale szczerze: jestem zadowolony z Opusa 5.5.
Jedno zastrzeżenie: to się zmieni w ciągu dwóch–trzech miesięcy. Wyjdzie nowy model, lepszy, następny poziom — i przestawimy się na niego. Taki już jest ten świat. Stan na dziś, wrzesień 2026 rok: Opus 5.5 i GPT-6 Astra to najlepsze modele, a ja częściej sięgam po tego pierwszego.
Framework: Svelte
Dawniej, gdy pisaliśmy kod ręcznie, nieustannie rozmawialiśmy o stacku technologicznym: jaki framework wybierasz, React czy co innego. AI wymieszało te rozważania, ale nadal są decyzje, które warto przemyśleć — pokażę krok po kroku, na czym buduję.
Mój framework to SvelteKit. Svelte’a używam więcej niż Reacta; czasem sięgam po Next.js. Oba dobrze dogadują się z Vercelem, na którym wdrażam aplikacje. Dlaczego Svelte? Po pierwsze: modele AI naprawdę dobrze piszą w Svelte i SvelteKit. Po drugie: zauważyłem, że każda aplikacja zbudowana w Svelte jest domyślnie szybka, żywa i responsywna — nawet bez proszenia modelu o optymalizacje wydajności. Po prostu od razu dobrze działa. A to dlatego, że — moim zdaniem — Svelte to po prostu lepszy framework. Budując aplikacje webowe, pracuję na nim.
Backend: Convex i jego komponenty
Teraz backend — i dostanę po rękach, bo pracuję w tej firmie: Convex. Powody są takie: AI świetnie sobie radzi z Convexem; całość jest w pełni typowana; wszystko działa w czasie rzeczywistym, więc nie muszę zarządzać websocketami; jest szybki i świetnie współgra z Svelte — istnieje biblioteka, która łączy te dwa światy niemal idealnie.
Ale to nie wszystko. Convex ma coś, co nazywa się Convex Components — wyobraźcie sobie budulce do integracji z usługami zewnętrznymi, w całości zapisane w kodzie i wpinane prosto w aplikację. Prosty przykład, mój własny: komponent Stripe. Budując aplikację na Convexie, dosłownie wrzucam agentowi link do komponentu i mówię: „skonfiguruj Stripe przez komponent Stripe” — i on to robi, łącznie z sandboxem, jeśli taki jest potrzebny. Potrzebuję PostHog? WorkOS, mojego ulubionego dostawcy uwierzytelniania — to jest liga mistrzowska, jeśli chodzi o logowanie? Coś w stylu Browserbase? Niezależnie od tego, jaki komponent jest potrzebny, podaję go agentowi, a on go konfiguruje i działa od razu, prosto z pudełka. Nie musiałem czytać ani linijki kodu przy konfigurowaniu komponentów, bo AI po prostu rozumie Convexa. Więc tak, Convex to spory kawał mojego warsztatu.
Effect — typowana obsługa błędów w każdym serwisie
Jest jeszcze coś, o czym dawno nie mówiłem, choć od dawna używam: przy każdym serwisie backendowego typu — zawsze i na zawsze — będzie to Effect. Od lat chciałem w nim pracować, ale składnia i krzywa uczenia wydawały mi się przerażająco rozwlekłe. Wtedy przyszło AI i zarówno nauka, jak i samo pisanie stały się bardzo łatwe.
Świetny przykład: Bezel, moja aplikacja, to jeden wielki serwer MCP napisany w całości w Effect, a strona stoi na Svelte. Zatem każdy zewnętrzny serwis backendowy, cokolwiek buduję, zawsze będzie w Effect. Główny powód: Effect jest znakomity w obsłudze błędów — i to daje mnie oraz agentowi przewagę w budowaniu aplikacji, w których błędów po prostu nie ma nadmiaru. Bo spójrzcie: w JavaScript jest mnóstwo miejsc, w których coś może pójść nie tak — i dlatego używamy TypeScriptu. Typy są niezbędne: to język, w którym definiujemy funkcje i wiemy, czy kod powstaje właściwie. Problem w tym, że w świecie TypeScriptu nie obejmowało to błędów. Effect czyni obsługę błędów łatwą. Nie buduję aplikacji, która by z niego nie korzystała.
Baza danych i wdrożenia: PlanetScale, a hosting — Vercel albo cały Cloudflare
Gdy buduję serwis i nie stawiam na Convex jako backendu, mam dwie bazy danych. A właściwie jedną: PlanetScale. To najpoważniejszy dostawca Postgresa; można z niego korzystać także przez Cloudflare Hyperdrive — chyba tak się to nazywa. Tak czy inaczej: zawsze, gdy potrzebuję Postgresa, biorę PlanetScale. Świetnie współpracuje z Effectem.
Wdrożenia trzymam w dwóch miejscach: Vercel i Cloudflare. Ciekawostka: jeśli już sięgam po Cloudflare, to biorę cały ich zestaw — Workers, magazyn R2, Hyperdrive, Durable Objects, całość. A jeśli nie Cloudflare, to aplikacja ląduje na Vercelu.
Przykład aplikacji chodzącej po Cloudflare: Go Email — wkrótce otworzę źródła. To dostawca poczty dla agentów; używam go w Bezelu i Pluto. Całość działa na Cloudflare: ich obsługa e-maili, Workers, Hyperdrive, R2. Kompletna infrastruktura u jednego dostawcy. Cloudflare to znakomity produkt infrastrukturalny — ale Vercel też. Zależnie od projektu: jeśli cokolwiek dotyka Cloudflare, zostaję przy Cloudflare; jeśli nie — Vercel.
Podsumowując stack: Svelte, Effect, Cloudflare, Vercel, PlanetScale i Convex Components. Nie używam wszystkich naraz, ale każda moja aplikacja ma w sobie co najmniej jeden z tych elementów. To jest zestaw, który po prostu lubię.
Narzędzia codzienne
Przechodzimy do narzędzi — omówię je jedno po drugim.
Code review: Graphite. Potrzebujecie automatycznego recenzenta kodu — ja używam Graphite i bardzo go cenię. (Informacja dodatkowa: Graphite to narzędzie do automatycznego przeglądu pull requestów, które wystawia im tzw. wskaźnik pewności — w transkrypcji jego nazwa jest kilkakrotnie zniekształcona.) Kluczowe są dwie rzeczy: wskaźnik pewności oraz skill GP Loop z mojego repozytorium skills (jeśli nie znaliście — koniecznie zajrzyjcie). Skill każe agentowi iterować po uwagach Graphite aż do uzyskania oceny pięć na pięć. Pokażę na żywo: otwieram pull request, Graphite wystawia wskaźnik pewności, a pętla GP Loop zmusza agenta do poprawek, dopóki nie dojdzie do piątki. Po prostu znakomite — uwagi, które dostaję od Graphite i od mojego agenta kodującego, to jedno z moich ulubionych narzędzi w całym zestawie.
Osobne komputery dla agentów: Orgo. W Pluto każda instancja ma własny komputer — i tym komputerem jest Orgo. Muszę być jasny: jestem inwestorem Orgo. Zainwestowałem, bo korzystam z ich produktu tak dużo, że napisałem do zespołu, czy mogę wystawić scout check — i przyjęli. (Informacja dodatkowa: scout check to skromna inwestycja dokonana przez osobę polecającą startup fundowi inwestycyjnemu.) Traktujcie więc moją ocenę z odpowiednią rezerwą. Faktem jest, że zawsze, gdy chcę dać agentowi osobny komputer, sięgam po Orgo.
Projektowanie: Paper i Mobbin. Paper, o którym już wspomniałem, to alternatywa dla Figmy przyjazna agentom. Projektuję w nim stronę-portfolio i Pluto — Pluto przeszło kompletny redesign i szczerze mówiąc: nie wyglądałoby tak czysto, gdyby nie Paper. To narzędzie bierze mnie — człowieka, który nie jest projektantem — i sprawia, że czuję się jak on; pozwala budować i eksplorować różne style, wszystko przy użyciu AI. Mają świetne MCP: podpinacie agenta i on dosłownie tworzy projekty wprost na kanwie. Drugie narzędzie to Mobbin — kolekcja najpiękniejszych istniejących stron zebranych pod jednym adresem, również z serwerem MCP dla agentów. To moje ulubione miejsce na zbieranie inspiracji i budowanie ładnie wyglądających aplikacji. Nie tak pięknych jak wy — ale się staram.
Dyktowanie: WhisperFlow. Aplikacja do zamiany mowy na tekst, samo się tłumaczy. Świetna rzecz, zwłaszcza gdy chce się agentowi dużo nagadać. Wolę przekrzyczeć niż przepisywać — chyba że zależy mi na precyzji, wtedy piszę. WhisperFlow świetnie mi służy.
Zadania: Linear. Dla solisty to może już przesada, ale prowadzę zespół, więc używamy Linear: zgłoszenia, praca do wykonania, statusy. Też mają MCP — podpinacie agentów, zwłaszcza chmurowe, i wystarczy wskazać Cursora czy Devina przy zgłoszeniu, żeby przypisać im bilet. Przepiękny przepływ pracy.
Skills — cała fabryka oprogramowania w otwartym repozytorium
Na koniec moje skills. Robiłem o nich osobny film, ale dla nowych widzów: repozytorium jest open source — cała moja fabryka oprogramowania, cały workflow. Wyjaśnię skrótowo, jak to działa.
(Informacja dodatkowa: „skills” to pakietowe instrukcje i procedury, które podpowiedzą agentowi, jak ma pracować; AGENTS.md to z kolei plik z konwencjami projektu, które agent czyta przed startem — odpowiednik README pisany dla AI.)
Krok pierwszy: promptuję agenta, który ma dostęp do całego repozytorium skills oraz do pliku AGENTS.md. Gdy każę zbudować funkcję, agent najpierw izoluje pracę — tworzy osobny worktree od gałęzi głównej, dzięki czemu agenty mogą działać równolegle. (Informacja dodatkowa: worktree to funkcja gita pozwalająca utrzymywać kilka równoległych kopii roboczych tego samego repozytorium — każdy agent dostaje własną, więc ich zmiany się nie gryzą.) Mogę więc pracować nad piętnastoma funkcjami naraz i agenci nie będą się nawzajem blokować.
Potem agent pisze kod — korzystając ze skilla code structure, który porządkuje kod dokładnie tak, jak lubię. A następnie musi udowodnić, że przedstawione rozwiązanie działa. Jeśli dotyczy interfejsu — nagrywa wideo działającego rozwiązania. Jeśli nie — uruchamia testy, które potwierdzają zaimplementowanie funkcji. A gdyby maszyna nie umiała nagrać wideo, robi zrzuty „przed i po” i wkleja je do pull requesta.
Gdy pull request powstaje, do głosu dochodzi Graphite, mój recenzent z wyboru: uruchamia się na PR i wystawia wskaźnik pewności. Jeśli nie ma piątki — wchodzi skill GP Loop. To pętla, która bierze uwagi Graphite, podaje je z powrotem agentowi kodującemu z poleceniem „zajmij się tym, popraw to” — i nie odpuszcza, dopóki ocena nie wyniesie pięć na pięć. Na końcu dostajesz pull request z piątką, gotowy do twojego przeglądu i scalenia.
Zakończenie
Wiecie już, jak używam poszczególnych środowisk, jakie modele cenię, jaki stack technologiczny wybrałem i jakie narzędzia trzymam pod ręką — dostaliście ode mnie nawet skille, którymi buduję oprogramowanie. Nie ma więc powodu, żeby nie wejść do kuchni i nie zacząć gotować. Skorzystajcie ze wszystkiego, o czym opowiedziałem. Link do moich skillów znajdziecie w opisie; resztę narzędzi będziecie musieli wygooglować — nie zamierzam wklejać wszystkich linków. Byliście świetni. Jestem Ross — dziękuję, że oglądaliście. Łapka w górę, komentarz, subskrypcja z dzwonkiem. Dajcie znać, co jeszcze chcielibyście zobaczyć. Cześć.