O czym jest ten film
- Autor pokazuje w praktyce swój odświeżony sposób programowania z agentami AI — od pierwszego promptu po scalenie kodu na gałęzi staging.
- Zestaw narzędzi: edytor Cursor z modelem GPT 5.5 („extra high fast”), Greptile do automatycznych recenzji kodu i WhisperFlow do dyktowania promptów.
- Budowaną funkcją są „artefakty” — panel podglądu obok czatu (znany z Claude), w którym agent pokazuje wygenerowane strony HTML, wykresy czy dokumenty.
- Sceneria: aplikacja Pluto — platforma agentów dla firm, z czatem, integracjami (Slack, Telegram, iMessage), warsztatem plików, finansami, kartami i dedykowanymi komputerami dla każdego agenta.
- Sercem procesu jest skill „grep loop”: agent czyta uwagi recenzenta, poprawia kod, wysyła i czeka na nową ocenę — aż do piątki w skali 1–5.
- Najważniejsza lekcja o recenzjach: pull requesty muszą być małe. PR z ponad 2000 linii w kółko dostawał 3/5, a po podziale na cztery mniejsze każdy doszedł do 5/5.
- Strategia gałęzi: praca lokalna → staging (testy) → main; nowe PR-y trafiają do staging, nie do main.
- Stack technologiczny Pluto: SvelteKit, Electron, Convex, Daytona oraz Supermemory, Agent Mail, Plaid i Twilio.
- Rozdzielenie ról modeli: do sterowania rozwojem służy GPT 5.5, a w samym produkcie pracuje tańszy GLM 5.
- Architektura podagentów: research trafia do osobnego agenta, dzięki czemu główny wątek czatu pozostaje wolny do rozmowy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Dyktuj prompty — głos jest szybszy niż klawiatura
Na czym polega: Autor promptuje głównie głosem (WhisperFlow) i w ten sposób przekazuje agentowi wielokrotnie więcej kontekstu, niż zdążyłby napisać. Darmowy plan narzędzia wystarcza mu od miesięcy.
Jak stosować: Podłącz dyktowanie do edytora i mów do agenta jak do kolegi: opisuj intencje produktowe, ograniczenia i wymagania pełnymi zdaniami, zamiast klepać skrócone polecenia.
Na co uważać: Mowa BYWA rozgardziaszem — po nagraniu sprawdź, czy agent nie wziął dygresji za wymaganie. Dyktowanie nie zwalnia z myślenia, tylko je przyspiesza.
2.Niech agent sam zbada temat, zanim zaproponuje rozwiązanie
Na czym polega: Zamiast tłumaczyć agentowi, czym są artefakty Claude, autor każe mu wyszukać to w sieci i streścić. Agent wraca z opisem produktu i propozycją elementów architektury.
Jak stosować: Gdy funkcja wzoruje się na istniejącym produkcie, zacznij od polecenia: „poszukaj w sieci, jak to działa, streść i zaproponuj kształt”. Oszczędzasz czas i unikasz błędów z nieporozumienia.
Na co uważać: Decyzje o zakresie zostaw sobie — model streści i zaproponuje, ale to ty wybierasz, co wchodzi do pierwszej wersji, a co poczekają na później.
3.Planuj przede wszystkim dla siebie, nie dla agenta
Na czym polega: Autor przyznaje, że plan w trybie planowania służy częściej jemu samemu — pracuje nad kilkoma funkcjami naraz i musi pamiętać, nad czym pracował — niż agentowi.
Jak stosować: Przy każdej większej funkcji zapisuj krótki plan zakresu i wracaj do niego po przerwach w pracy. To deux rzeczy: zakotwiczenie dla ciebie i kontrakt dla agenta.
Na co uważać: Plan nie może stać się celem samym w sobie — czasem lepiej budować w dialogu bez planu, a plan nie zastąpi testów tego, co powstało.
4.Małe, wąskie PR-y to warunek dobrej automatycznej recenzji
Na czym polega: Pull request z ponad 2000 linii dostawał oceny 3/5 w kółko. Po podziale na cztery PR-y poniżej tysiąca linii każdy przeszedł pętlę poprawek do piątki.
Jak stosować: Jeden PR = jedna konkretna zmiana. Jeśli recenzent bez końga łapie kolejne problemy, to często sygnał nie tyle o jakości kodu, ile o rozmiarze PR-a — podziel go.
Na co uważać: Przy częściach, które realnie zależą od siebie, użyj serii PR-ów budowanych jeden na drugim („stacked PR”), a nie niezależnych gałęzi — inaczej łatwo o konflikty.
5.Zautomatyzuj pętlę: recenzja → poprawka → recenzja
Na czym polega: Skill „grep loop” łączy agenta w Cursorze z recenzentem Greptile: agent czyta komentarze, łata kod, wysyła zmiany, a push automatycznie wywołuje kolejny przegląd — aż do oceny 5/5 lub limitu rund.
Jak stosować: Ustal próg akceptacji (dla autora 4+/5), podepnij automatyczny przegląd do GitHuba i pozwól agentowi iterować, a sam zająć się czymś innym.
Na co uważać: Przy dużych PR-ach ocena potrafi po poprawkach nawet spaść. Pętla nie jest świętością — to narzędzie, które trzeba nadzorować.
6.Ustaw próg akceptacji i umiej przerwać pętlę
Na czym polega: Gdy agent utknie na 4/5 w nieskończoność, autor przerywa iteracje, sam przegląda kod i scala. Agent, który bez końca edytuje, w końcu zaczyna halucynować.
Jak stosować: Wyznacz limit rund (u autora około pięciu) i po jego wyczerpaniu przejmij stery: ręczny przegląd i decyzja o scaleniu.
Na co uważać: Zasada „krótko, prosto, konkretnie” dotyczy także poprawek — rozwlekłe łatanie w koło to prosta droga do wymyślania nieistniejących problemów.
7.Feedback produktowy przesyłaj zrzutami ekranu
Na czym polega: Uwagi o interfejsie (możliwość rozciągania panelu, „ciemny motyw”, który wcale nie był ciemny) autor przekazuje screenshotami wklejanymi do czatu agenta, często z jednym zdaniem: „zrób jak w desktopie”.
Jak stosować: Pokazuj zamiast opisywać. Zrzut ekranu + jedno zdanie kontekstu to najszybszy sposób na przekazanie uwag wizualnych.
Na co uważać: Model potrafi twierdzić, że już zrobione — wtedy zrzut staje się dowodem. Upewnij się też, że twój model faktycznie dobrze czyta obrazy.
8.Oddziel staging od main — PR-y najpierw do staging
Na czym polega: Autor pracuje lokalnie, potem funkcja trafia na gałąź staging, jest tam testowana przez jakiś czas i dopiero wtedy przechodzi do main. Pull requesty kieruje do staging, nigdy od razu do main.
Jak stosować: Traktuj staging jako bufor na testy funkcji. Gdy coś się sypie, wracasz na lokalną gałąź, naprawiasz i znowu scalasz do staging.
Na co uważać: Staging nie usprawiedliwia wielkich PR-ów — nawet na staging małe, skupione zmiany są warunkiem sensownej recenzji.
9.Czytelna architektura jest darem dla agenta
Na czym polega: Własny skill /code-structure przebudowuje kod danej funkcji w warstwę serwisową. Autor prawie nie zagląda do środka, ale — co ważniejsze — agent dużo łatwiej czyta i rozumie taki kod.
Jak stosować: Po zbudowaniu funkcji przepuść kod przez porządkującą konwencję lub skill. Każda usługa powinna odpowiadać za jedną rzecz i być łatwa do znalezienia w strukturze projektu.
Na co uważać: Refaktor bez siatki testów to ryzyko — autor opiera się na testach, które sam model dopisuje w trakcie pracy.
10.Drogim modelem steruj, tanim działaj
Na czym polega: Rozwój prowadzi GPT 5.5 „extra high fast”, ale w samej aplikacji pracuje znacznie tańszy GLM 5. Stosunek ceny do jakości jest korzystny, choć estetyka generowanych artefaktów cierpi.
Jak stosować: Rozdziel modele według roli: do programowania ze sobą bierz najinteligentniejszy, do działania w produkcie wystarczy tańszy model, który „wykona robotę” akceptowalnie.
Na co uważać: Tańszy model oznacza gorsze wykończenie wyników — zadbaj o architekturę pozwalającą bezboleśnie podmienić model na lepszy.
Redakcyjne tłumaczenie
Zmiana w moim sposobie pracy
Mój sposób programowania z agentami zmienił się — i to na lepsze. Modele zrobiły krok naprzód, część narzędzi wymieniłem. Najważniejsze jest jednak co innego: gdy sięgam po agentów do budowy aplikacji, steruje mną doświadczenie z klasycznego tworzenia oprogramowania.
Dotąd pokazywałem w filmach głównie narzędzia i ogólny zarys mojej pracy. Tym razem zrobimy coś konkretnego: mam aplikację Pluto i wspólnie zbudujemy jedną z zaplanowanych funkcji. Film może wyjść długi albo krótki, może zejść do_samego szczegółu — nie mam gotowego scenariusza. Po prostu nagrywam, jak powstaje funkcja. Jeśli to was wciąga — usiądźcie wygodnie i zaczynamy.
Trzy narzędzia, na których opieram wszystko
W skrócie: pracuję w edytorze Cursor z modelem GPT 5.5 w wariancie „extra high fast”. Wiem, że wielu osobom podoba się aplikacja i wiersz poleceń Codex — to też uczciwa droga. Ja po prostu wolę Cursora. Wychodzi drożej, ale moim zdaniem wart swojej ceny, zwłaszcza przy aplikacji, którą buduję.
Po drugie: Greptile do automatycznego przeglądu kodu. Porządnych narzędzi jest więcej, ale w Greptile zostałem przez umiejętność (skill) „grep loop” — za chwilę pokażę, jak działa.
Po trzecie: WhisperFlow. Zauważyłem, że na głos człowiek przekazuje o wiele więcej treści niż palcami po klawiaturze. Przepisywanie zabiera czas, a ja i tak żyję z gadania — jestem youtuberem, więc dyktowanie promptów to mój naturalny tryb. I powiem szczerze: korzystam z WhisperFlow od paru miesięcy i nie zapłaciłem ani grosza. Nie mam nawet pojęcia, co dostaje wersja płatna — tyle mówi o hojności darmowy plan.
Zestaw mamy więc taki: Cursor, GPT 5.5 extra high fast, Greptile ze skillem grep loop i WhisperFlow do promptowania. Czas budować.
Czym jest Pluto i co dokładnie budujemy
Do Pluto chcę dodać artefakty — funkcję znaną z Claude. Jeśli ktoś nie kojarzy: poprosiłem kiedyś agenta o prognozę majątku osoby, która odkłada 500 dolarów miesięcznie od osiemnastego roku życia — ile nazbiera do czterdziestki. Claude zbudował komponent wewnątrz rozmowy, całkiem zgrabny (może kiedyś do niego wrócimy), ale mnie chodzi o to, co pojawiło się obok: wygenerowaną stronę HTML, aplikację Reacta — cokolwiek wizualnego — którą widzę na własne oczy, na żywo. To właśnie są artefakty. Według mnie to jeden z najładniejszych pomysłów Anthropic i chcę tego samego w Pluto.
Sama aplikacja jest niezła. Na start jest interfejs czatu i integracje z iMessage, Telegramem czy Slackiem. Jest też kilka ciekawszych form: tablica Kanban z zadaniami, „rutyny”, czyli zadania powtarzalne, a każdy agent dostaje własny adres e-mail i ponad tysiąc integracji przez Compozio. Działa osobny warsztat plików: wrzucacie faktury, umowy, arkusze, rusza rozpoznawanie tekstu, a agent ma precyzyjny dostęp do danych — szczególnie przy bardzo dużych plikach. Są karty — właśnie pracuję nad tym, żeby agent dostał własną wirtualną kartę płatniczą — oraz własną linię telefoniczną. W dziale finansów podpinacie finanse firmy, a agent czyta te dane w całości. Krótko mówiąc: to agent dla firm. Każdy agent ma też swój własny komputer — na razie z Linuksem; być może niedługo dojdą maszyny Mac albo Windows. Tak wygląda Pluto w pigułce. Jeśli chcecie osobny film o tym, jak to działa — dajcie znać w komentarzach.
Budujmy.
Pierwszy krok: niech agent sam zbada temat
Otwieram Cursora, przybliżam ekran i zaczynam mówić: „Chcę zbudować funkcję podobną do artefaktów Claude. Jeśli nie wiesz, o co chodzi: proszę agenta o coś, a gdy wynik ma warstwę wizualną — plik HTML, markdown, Reacta — obok rozmowy pojawia się podgląd. Jesteś sprytnym agentem i masz dostęp do internetu, więc wyszukaj w sieci, czym są artefakty Claude, i opowiedz mi — bo właśnie to budujemy.”
Przy okazji słowo o gałęziach: korzystam z GitHuba, a rozwój prowadzę lokalnie. Gdy funkcja mi się podoba, trafia na gałąź staging, testuję ją tam przez jakiś czas i dopiero potem przechodzi do main.
Grep loop: pętla poprawek do skutku
Wyjaśnię spokojnie, jak działa grep loop. Jednym z moich recenzentów kodu jest Greptile. Otworzę duży pull request — całości tu nie przegadamy, ale pokażę, o co chodzi. Do każdego PR Greptile dołącza podsumowanie i ocenę pewności w skali od jeden do pięciu. Wszystko od czwórki w górę uznaję za wystarczające.
Konfiguracja jest banalna: w repozytorium Greptile znajdujecie ich skille i instalujecie „Grep Loop”. A mechanika wygląda tak — narysuję: tu jestem ja, wysyłam zmianę, Greptile ją recenzuje. Załóżmy, że dostaję dwójkę: działa, ale przegapiłem kwestie bezpieczeństwa i kilka przypadków brzegowych. Mogę przeczytać uwagi i ręcznie przekazać je agentowi. Mogę też — mając zainstalowany skill — po prostu wpisać „/grep loop”. Wtedy agent czyta komentarze z GitHuba, wprowadza poprawki, wysyła je i czeka na kolejną recenzję, bo każdy push na tę gałąź automatycznie wywołuje nowy przegląd. Przyszła trójka? Pętla widzi, że to jeszcze nie piątka — wraca, łata, wysyła znowu. I tak w kółko, z limitem około pięciu–sześciu rund, aż do piątki.
Dlaczego GPT 5.5 extra high fast? To naprawdę inteligentny model, a przy złożonych funkcjach sam pisze mnóstwo testów. I tu się to wprost opłaca: gdy przychodzą uwagi, model zagląda do testów i stwierdza — „mój pierwotny przypadek przechodzi, trzeba dołożyć dodatkowe”. Do tej pory sama przyjemność.
Agent wrócił z researchu: „Znalazłem tę funkcję — chodzi ci chyba o artefakty Claude” (acha, sam napisałem «clawed artifacts», moja wina). Streścił: artefakty to samodzielne, generowane treści pokazywane w osobnym panelu obok rozmowy; Claude tworzy je, gdy wynik jest obszerny, stanowi całość i prawdopodobnie będzie później edytowany, ponownie używany lub przeglądany. Przykłady z dokumentacji: markdown, fragmenty kodu, strony jednostronicowe, SVG, diagramy, przepływy, interaktywne komponenty Reacta. Zgadza się.
Ciekawsza jest dalej część o kształcie produktu: agent pisze normalnie w czacie, ale gdy tworzy wizualny, wielokrotnego użytku „wytwór”, wynik awansuje do pełnoprawnego artefaktu — z własnym cyklem życia, typem, tytułem, źródłem, rendererem podglądu, historią wersji, obsługą błędów i ścieżką aktualizacji. Elementy architektury: rozpoznawanie i tworzenie artefaktów, ich rejestr, środowisko podglądu, przełącznik między kodem a podglądem, pętla iteracji, izolacja i bezpieczeństwo, przechwytywanie błędów, a później eksport i udostępnianie. Ruszamy dalej.
Plan i porządek w kodzie
Teraz precyzuję zadanie: „Wiesz już, jaką funkcję chcę. Przygotuj plan budowy. Przejrzyj cały kod i zrozum, jak wszystko działa — nie chcę budować tej funkcji kosztem zepsucia innej. Zrób to porządnie.” I przechodzę w Cursorze do trybu planowania.
Mam też inne skille, a jeden używam wyjątkowo często: /code-structure (mój własny — link w opisie). Przebudowuje on kod danej funkcji w warstwę serwisową. W efekcie jest czysto i czytelnie, gdybym chciał zajrzeć do środka — choć szczerze mówiąc, po wdrożeniu tego skilla prawie tam nie zaglądam. Co ważniejsze, agent znacznie łatwiej czyta i rozumie taki kod. Więc i z niego skorzystamy.
W Cursorze widać, że nad planem ruszyło kilka podagentów. Skoro funkcja się „gotuje”, mogę odpalić Steam — znowu wciągnęło mnie Red Dead Redemption 2. Grałem już, kończyłem już, a jednak musiałem wrócić. Póki agent pracuje, łowię ryby z Jackiem — synem Johna Marstona, dla pytających.
Segment sponsorowy: o nauce, gdy agent pisze kod
Póki AI generuje kod, pokażę, jak doszlifować własne umiejętności — i tu wchodzi sponsor tego odcinka. Ale najpierw kilka słów od naszego ulubionego szefa, Daria Amodeia z Anthropic. Zobaczmy, co ma do powiedzenia.
„Nie wiem… Może jesteśmy sześć do dwunastu miesięcy od momentu, w którym model będzie wykonywał większość — a może całość — tego, co dziś robią inżynierowie oprogramowania, od początku do końca.”
Skoro więc całe programowanie mają przejąć agenci, to czemu na stronie karier Anthropic, w dziale inżynierii i projektowania produktu, widać dwadzieścia otwartych etatów? Trzeba to powiedzieć wprost: inżynieria nie umarła. Wręcz przeciwnie — ożyła, bo wygenerowanie kodu stało się łatwiejsze niż kiedykolwiek. Dlatego polecam Scrimbę i jej ścieżkę full-stack developera. Gdybym zaczynał dziś i nie chciał spędzić czterech lat na uczelni, wybrałbym dokładnie tę drogę. Nauczysz się HTML i CSS, projektowania responsywnego, stawiania backendów w Node.js, baz danych, Expressa, projektowania interfejsów, Reacta, zaawansowanego Reacta i Next.js — jednego z moich ulubionych frameworków, choć uważam, że Svelte jest lepszy. A sama platforma? Nie mówię tego, bo płacą za promocję — po prostu pokażę. Odpalam losową lekcję: słychać wykładowcę, widać jego ekran, a jednocześnie ten ekran to pełne środowisko programistyczne w przeglądarce — w każdej chwili mogę zatrzymać film i samemu pomajstrować przy kodzie. Nie znam innej platformy do nauki w podobnym stylu. Jeśli chcecie skorzystać z czasów, w których żyjemy, nie ma lepszej drogi niż nauka pisania, projektowania i inżynierii — a Scrimba to najlepszy start. Link w opisie. Wracamy do filmu.
Plan gotowy: pięć małych PR-ów zamiast jednego wielkiego
Plan jest. „Do /dashboard/chat dochodzi prawy panel artefaktów, otwierany, gdy asystent tworzy obszerną treść wizualną lub nadającą się do ponownego użycia. Pierwszy kamień milowy ma bezpiecznie obsługiwać artefakty markdown, HTML, SVG i kod. Podglądy komponentów frameworkowych pójdą osobno, sandboxowym kompilatorem — zamiast uruchamiać arbitralny kod Reacta czy Svelte bezpośrednio w głównej aplikacji.” Słusznie.
Plan dalej nieco mnie czaruje — i bardzo nam miło: główna powierzchnia czatu już obsługuje stan listy, strumieniowanie z bramki, plany awaryjne, odtwarzanie aktywnego podglądu, renderowanie wiadomości, załączniki, panel desktopowy i inspektor podagentów. Do tego diagram: prompt użytkownika → wiersz uruchomienia czatu → strumień z bramki → sprawdzenie, czy treść wymaga podglądu → parser bloków artefaktów.
Zauważyłem jednak w planie wdrożenie na pięć PR-ów. Pytam: „Planujesz pięć osobnych pull requestów? Bo zmiana będzie duża?” I tu ważna rzecz: żeby Greptile — zresztą każdy recenzent kodu — działał dobrze, PR-y muszą być szczupłe. Zbyt duży pull request z masą plików żaden agent nie obejmie wzrokiem. Minimalne PR-y, wprost rozwiązujące jedną konkretną sprawę — ideał.
Agent przyznaje: tak, to jego rekomendacja, bo funkcja przecina sporo warstw. Nie musi być pięć — praktyczny podział mógłby być i na dwa: model danych, parser i testy w jednym; integracja z czatem i panel boczny w drugim. Ale wersja pięcio-PR-owa jest najłatwiejsza do zrecenzowania.
Ja zostaję przy pierwotnym planie: wolę minimalnie i prosto. Agent się zgadza — pięć PR-ów to bezpieczniejsza droga, bo pozwala najpierw sprawdzić strumieniowanie i zapis danych, a dopiero potem dokładać interfejs podglądu i kod wykonywalny. To się broni. Wolę małe PR-y: mogę przetestować, upewnić się, że wszystko działa, i przejść dalej, zamiast wlec jeden wielki. I jeszcze to: staging służy właśnie do testowania funkcji; gdy coś nie działa, wracam na lokalną gałąź, naprawiam i znów scalam do staging. Ale do tej funkcji potrzebuję kilku PR-ów — i tak będzie.
Muzyka w tle: szczerze polecam tę płytę — mixtape, cokolwiek to jest — ogień, a ulubione kawałki to „Gen 5” i „Took a Break”. Tak mniej więcej wygląda życie w inżynierii agentowej: proces idzie, ja czekam, mogę poczytać, pograć albo popracować nad czymś innym. I nie mogę uwierzyć, że Arsenal wziął Premier League. Całe życie jestem dumnym hejterem tego klubu; oglądanie ich porażek to moje małe święto — a tu proszę. Serio, to znak, że świat się kończy.
Pierwszy test: II wojna światowa jako artefakt
Cursor skończył — plan podglądu artefaktów wdrożony. Nie będę czytał całości, testujmy od razu. Proszę: „Stwórz artefakt wyjaśniający przebieg II wojny światowej”. Enter. Pierwsze podejście — może nie zadziałać, może zadziałać do połowy. Zobaczmy.
Agent od razu wylewa HTML-a strumieniem na ekran czatu — nie o to chodziło, wolałbym komunikat w stylu „chwilka, działam” — ale działa. Przy okazji: modelem działającym pod spodem aplikacji jest GLM 5. (Informacja dodatkowa: GLM to rodzina modeli pozycjonowanych jako tańsza alternatywa dla flagowych modeli OpenAI czy Anthropic.) Stosunek ceny do jakości jest bardzo dobry; to naturalnie nie Opus ani GPT‑5.5, ale robotę zrobi. I proszę — podgląd się pojawia. Brzydki, bo GLM 5; na Opusie byłby śliczny i szykowny. Ale jest.
Szlify produktowe: zrzuty ekranu zamiast opisów
Z perspektywy produktowej brakuje mi jednego: możliwości rozciągania panelu. Robię zrzut ekranu, wrzucam do Cursora: „Dobra — działa. Ale chcę zmieniać rozmiar okna artefaktów, tak jak w widoku desktop. Zerknij, jak tam działa skalowanie, i zrób dokładnie to samo.”
W desktopie można złapać krawędź i dopasować rozmiar do upodobań; w nowym panelu był zabetonowany. Da się też pobrać HTML na dysk. Sprawdzam iterację: „Zmień motyw z jasnego na ciemny” — ciekawe, czy zaktualizuje istniejący artefakt, czy zrobi coś od zera.
Po drodze przydarzył mi się znany bug aplikacji: po otwarciu i zamknięciu widoku desktopowego wysypuje się routing. Uznajmy, że tego nie było — żenujące, wiem, ale temat na inny dzień. Próbuję jeszcze raz.
Poprawki weszły: skalowanie działa, świetnie. Ale z motywem agent uparł się, że ciemny już jest. Wysyłam zrzut, a on na to: „Widzę problem — podgląd dalej pokazuje jasny motyw, wyemituję zaktualizowaną wersję pod tym samym kluczem, żeby go odświeżyć.”
I tu wniosek dotyczący strumieniowania: „Kiedy agent pisze HTML, nie chcę oglądać całego kodu lecącego po ekranie. Zamiast tego niech pojawi się pulsująca animacja «tworzę artefakt»”. Prostsze i ładniejsze. Kolejna sprawa: prosiłem o aktualizację istniejącego artefaktu — zaktualizował, ale niczego nie pokazał. „Przejrzyj ten proces i spraw, żeby każda aktualizacja była widoczna. Chcę też mieć dostęp do wszystkich wcześniejszych wersji.” Kolejkuję obie zmiany.
GPT‑5, jak to GPT‑5, przy okazji dopisał testy. Testy to dobro — cieszymy się.
Ciekawostka: mogę podejrzeć instrukcje, które agent sam sobie wygenerował do obsługi artefaktów. W skrócie: tworząc obszerną, samodzielną treść wizualną, zamknij ją w wydzielonym bloku („fence”) o ściśle określonym otwarciu — z typem (markdown, HTML, SVG, kod), krótkim tytułem i stabilnym kluczem w formacie kebab-case; przy kodzie dodaj identyfikator języka; poprawiając istniejący artefakt, użyj tego samego klucza, a aktualizacja stanie się nową wersją; wewnątrz bloku umieść tylko źródło, a wyjaśnienia pisz poza nim. Do tego: „Aktualizacje artefaktów wracają z pełną historią wersji. Panel boczny pokazuje wersje; wybranie starszej przełącza podgląd i źródło; nowa aktualizacja wraca do najnowszej, chyba że użytkownik celowo wybrał starszą”.
Sprawdzam w praktyce: obok podglądu widać V2 i V1. Dodaję zadanie: „Dopisz do tego artefaktu też historię I wojny światowej”. Dokument opisuje II wojnę jako globalny konflikt mocarstw alianckich z państwami Osi — od niemieckiej inwazji na Polskę 1 września 1939 roku po kapitulację Japonii 2 września 1945. I teraz zamiast strumienia widać tylko informację, że agent pisze HTML — o to właśnie chodziło. Wersje mam, panel mogę zamykać, otwierać i rozciągać. Chyba niczego tu nie brakuje.
Ciekawe przy okazji: planu wdrożenia na pięć PR-ów jakoś nie dotrzymaliśmy — zobaczymy. A tak poza tym: nie zawsze robię plan dla agenta, choć pomaga. Zdarza mi się budować funkcję po prostu w dialogu, bez planu. Ten plan — w większości wypadków — jest naprawdę dla mnie: pracuję nad kilkoma rzeczami naraz i muszę pamiętać, nad czym pracowałem ja, a nad czym agent. Niech więc będzie: jestem za planowaniem, przede wszystkim własnym.
Aktualizacja weszła, aktywna jest wersja trzecia, w dokumencie jest i I, i II wojna światowa. Funkcja w zasadzie gotowa. Szczerze? Spodziewałem się więcej problemów. Ludzie — GPT 5.5 extra high fast to kosmos.
Pull request i recenzja Greptile
Czas posprzątać. „Wypchnij to na nową gałąź i stwórz z niej pull request do staging. Nie scalamy do main — do staging. Daj mi link.” Ponieważ mam podpięty GitHub, agent założy gałąź, wypchnie zmiany, otworzy PR i wrzuci link. Potem recenzja i ocena od Greptile.
Przy okazji stack technologiczny: to SvelteKit — aplikacja w całości na Svelte (sam zobaczcie pliki .svelte). I nie tylko web: jest aplikacja desktopowa na Electronie oraz panel administracyjny, a wszystko napędza Svelte. Backend to Convex — najlepszy backend świata, orkiestruje dosłownie wszystko. Wdrożenie na Daytonie, najlepszej chmurze pod agentów; testowałem kilka i się zakochałem. Do tego Supermemory do pamięci, Agent Mail do poczty, Plaid do finansów i Twilio do telefonii. Wszystko spięte w warstwę serwisową z abstrakcjami, które dają się swobodnie łączyć: każda usługa odpowiada za jedną rzecz i łatwo znaleźć jej kod. W mojej ocenie to przemyślany projekt „inżynierii agentowej”. Nie idealny — ale całkiem, całkiem.
Otwieram PR-a. Mógłbym w podglądzie Cursora — całkiem ładnym, tylko nie odświeża się sam i trzeba klikać — ale idę na GitHuba. Greptile już wystartował; mamy też pipeline CI — o nim może osobny film, jeśli będziecie chcieli. Liczby: 2000 linii dodanych, 13 usuniętych, do tego niezłe podsumowanie od Cursora. Czekamy na recenzję.
Pętla rusza: od trójki do czwórki
Recenzja jest — i dostajemy trójkę. Dlaczego? „PR dodaje kompletny system artefaktów: parser bloków, wersjonowanie w Convex, skalowany panel boczny i bezpieczny podgląd markdown.” A w szczegółach błąd bezpieczeństwa: logika dopasowywania kart artefaktów do wiadomości potrafi przypisać roboczy szkic do starszych wiadomości podczas aktywnego strumienia — gdy szkic dzieli klucz z już zapisanym artefaktem, zamiast właściwej, historycznej treści użytkownik widzi niekompletny, „żywy” draft. Widoczne dla każdego użytkownika. Do tego kilka rzeczy z bezpieczeństwa.
Takie komentarze wskazują miejsce problemu; można skopiować gotowy prompt naprawczy, czasem dostać wręcz propozycję commita. I tu wchodzi grep loop: w Cursorze wpisuję „/grep loop” i enter. Mechanika znana: wypchnąłem zmianę, dostałem trójkę, pętla czyta uwagi, Cursor poprawia, wysyła, czeka na nową recenzję; czwórka — znowu poprawka; koniec przy piątce albo po pięciu rundach.
To jest mój proces: zbuduj funkcjonalność, przetestuj, zobacz, że działa. Ale są przypadki brzegowe, których pierwsze użycie nie wyłapie. Wysyłam do Greptile, dostaję recenzję — przegapiliśmy też kwestie bezpieczeństwa — i „/grep loop” robi swoje. Agent melduje: „Greptile zostawił trzy komentarze: prawdziwy błąd z wyciekiem szkicu, zacieśnienie sandboxa i drobny porządek w pomocniczej funkcji. Łatam, aktualizuję testy, odpalam testy artefaktów, commituję, wypycham i wywołuję kolejną iterację.” Ja idę po jedzenie — pasta w sosie śmietanowym.
Wracam. Pętla wypchnęła zmianę — sam nic nie pisałem. Skorzystała z API GitHuba i dodała komentarz „@greptile review”; gdy Greptile wrzuca emoji, znaczy, że recenzuje. Przegląd ruszył minutę temu. Za chwilę zobaczymy, czy piątka, czy czwórka — bywa, nie ukrywam, że przy dużych PR-ach ocena potrafi nawet spaść.
Jest aktualizacja: czwórka. „Bezpieczne do scalenia, o ile lukę w wykrywaniu błędów w ramkach iframe załatamy, zanim naprawowy trafi do użytkowników.” Recenzent wskazuje konkretny plik: podpięcie zdarzenia „on error” wymaga innego podejścia — na przykład komunikatu postMessage z wnętrza ramki — żeby błędy renderowania artefaktów HTML i SVG faktycznie dawało się zobaczyć. Recenzja zakończona, kciuk w górę, zostaje jeden komentarz. Mogę go skopiować, wkleić i po pushu otagować „@greptile review” — albo po prostu poczekać, aż grep loop dalej działa.
Zauważcie schemat: poprzednio trójka, teraz czwórka — miejmy nadzieję, że za chwilę piątka. Zdarza się, że utknie na czwórce. Jeśli widzę, że kręci się w kółko, przerywam, sam przeglądam kod i scalam. Bo nie chcę, żeby agent bez końca edytował, edytował, edytował — w końcu zacznie halucynować i wymyślać. Krótko, prosto, konkretnie, bez rozwlekania: to jest ten sos, który u mnie działa. Agent właśnie łata przypadek brzegowy; mogę podejrzeć zmiany albo pograć w Red Deada.
Gdy recenzja krąży: podziel PR
Nowa recenzja: znów trójka. „Bezpieczne dla artefaktów markdown i kodu, ale podgląd HTML i SVG będzie po cichu pokazywał treść nieinteraktywną przez konfigurację sandboxa, a zapytanie o historię wersji przy aktywnych czatach może zamienić się w problem z przepustowością.”
Mógłbym odpalić grep loop — ale moim skromnym zdaniem ten PR jest po prostu za duży: ponad 2000 linii. Wracam więc do Cursora: „PR powstał, Greptile dał trójkę, ale pull request wydaje mi się za duży, żeby agent objął recenzją wszystko. Co powiesz na podział na mniejsze kawałki — żeby Greptile mógł go przejrzeć i żebyśmy scalili bezpiecznie?” Cel: po kilkaset linii na sztukę, w ostateczności tysiąc. Dwa tysiące to za dużo; nie chcę cyklu, w którym Greptile bez końca łapie problemy, bo PR jest po prostu wielki. A każdy, kto pracował w zespole inżynierskim, to wie: im mniejszy i bardziej skupiony PR, tym lepsze życie. Agentowi też.
Agent się zgadza: „Tak, podział to słuszny ruch. Ten PR łączy kontrakt artefaktów, schemat w Convex, trwałość danych, bezpieczne renderowanie i dużą integrację z interfejsem. Greptile wypadnie lepiej, gdy każdy PR będzie miał jedną rzecz do zrecenzowania.” Proponuje cztery PR-y. Doprecyzowuję: „Chcę serię PR-ów budowanych jeden na drugim, a nie niezależne gałęzie — późniejsze części realnie zależą od poprzednich. Zrób to, plan wygląda dobrze.” (Informacja dodatkowa: taka seria to „stacked PR” — pull requesty ułożone kaskadowo, w których każdy kolejny bazuje na poprzednim i scala się je po kolei.) GPT 5.5 extra high fast bierze gwiazdkę — brzmi jak zamówienie w Starbucksie.
PR-y się dzielą. Cztery sztuki, każda poniżej tysiąca linii — dużo łatwiej o dobrą recenzję i o naprawy przez grep loop.
Cztery piątki i scalenie do staging
Recenzje przyszły — i każdy PR dostał trójkę. Każdy, po kolei. Przykład uwagi: „Bezpieczne dla prostych artefaktów jednoblokowych, ale markdown z zagnieżdżonymi blokami kodu zostanie po cichu ucięty na pierwszym napotkanym bloku zamykającym, bo wzorzec dopasowuje każdą gołą linię z trzema grawisami — bez żadnego błędu.” Dobra obserwacja.
Odpalam grep loop, tym razem z numerem: „/grep loop, PR 87”. Złoty tekst: agent wie, że pętla ma działać na PR 87 — przeczyta recenzję i uwagi, poprawi, wypchnie, a push wywoła kolejny przegląd Greptile. I nie przestanie, aż dostanie piątkę albo skończą się rundy.
Tu zdradza mnie koszulka w kadrze: złapałem obowiązki z etatu i czas dla mojej dziewczyny, zrobiło się gorąco. Ale pętle są dokończone — więc zamiast nudzić szczegółami, pokazuję wynik: PR 87 grep-loopowany do piątki i scalony; PR 88 — piątka, scalony; 89 — piątka; 90 — scalony. Wszystko wylądowało na staging.
Test końcowy: restauracje w Toronto i podagenty
Zostało przetestować. Otwieram czat: „Stwórz artefakt z najlepszymi restauracjami w Toronto”. Jeśli nie zadziała — będziemy debugować razem; jeśli zadziała — udało się.
Agent odpowiada: „Zdeleguję to zadanie researchowe podagentowi, który zbierze aktualne informacje o Toronto.” Podagent ruszył; mogę kliknąć „otwórz inspektor” i podglądać, co robi. System zobaczył, że potrzebny research, i zamiast blokować główny wątek, wysłał podagenta. A to oznacza, że mogę w trakcie swobodnie pogadać z głównym agentem — pytam choćby „co tam u ciebie?”, jak kolegi. Główny wątek odpowiada, że u niego dobrze, wspomina o działającym podagencie i można mu zlecać kolejne rzeczy. O tym, jak zbudowałem tę architekturę, opowiadam w filmie „My agent is better than Claude co-work” — czwarty film na kanale, zajrzyjcie.
Podagent zebrał dane z Condé Nast Traveler i Time Out Toronto i właśnie dociąga kolejne źródła, żeby lista była kompletna. I proszę — artefakt jest. Nie najpiękniejszy; powiedzmy szczerze: brzydki, pewnie przez GLM 5. Ale zrobiony.
Funkcja skończona — i zawdzięczam to prostemu workflow: GPT 5.5 extra high fast, narzędzia Greptile, skill grep loop i minimalne PR-y. Do tego odrobina dialogu i odrobina struktury — a to robi ogromną różnicę.
Na koniec rzecz, o której wspominałem: zaraz, już poza kadrem, przepuszczę kod przez /code-structure, żeby wszystko było poukładane i udokumentowane — żebym ja wiedział, gdzie są artefakty, i żeby agent wiedział. I to w zasadzie tyle. Tak wygląda inżynieria agentowa — a przynajmniej tak wygląda moja. Mam nadzieję, że było warto. Wiem, że film wyszedł długi — napiszcie, czy takie formaty wam odpowiadają. Za każdym razem, gdy opowiadam o tym w podcastach czy u innych twórców, ludziom bardzo się to podoba, a jakoś na własnym kanale nigdy tego nie robiłem. Łapka, komentarz, subskrypcja — bardzo doceniam. Dziękuję za obejrzenie i do zobaczenia w następnym. Cześć!