O czym jest ten film
- Leon van Zyl pokazuje własny, otwarty projekt: wirtualne biuro w 3D, w którym „pracują” prawdziwi agenci kodujący — instancje Claude Code, Codex i OpenCode.
- Dotychczasowe „fabryki oprogramowania” sprowadzały się do dwóch wariantów: podpięcia do GitHuba (issue → agent → pull request) albo self-hostowanego Paperclipa z panelem webowym — działały, ale wymagały technicznej pielęgnacji.
- Kluczowa nowość: warstwa pośrednia w postaci agenta-CEO, który zatrudnia agentów, rozdziela zadania i nadzoruje wiele projektów — człowiek rozmawia wyłącznie z nim.
- Rekrutacja przebiega jak w firmie: CEO wskazuje kandydatów z opisami ról, a ty zatwierdzasz ich w poczekalni albo z wbudowanego telefonu; możliwy też tryb w pełni automatyczny.
- Biała tablica w świecie 3D to zwykły backlog z GitHuba: nowe zadania same trafiają do agentów według ich ról.
- Obieg jakości: zmiany testuje agent QA, który odsyła błędy do „programistów”, a jego raport — ze zrzutami ekranu — doklejany jest do pull requesta.
- Automatyczne scalanie następuje dopiero po przejściu wszystkich testów (CI/CD, CodeRabbit, Vercel) i da się je wyłączyć jednym polem wyboru.
- Podgląd projektu na żywo (serwer deweloperski, widok responsywny) dostępny bez wychodzenia ze świata; na czas czekania — gry i zabawki, m.in. pistolet na pianki.
- Budowa: wyłącznie Opus 5.5 na wysokim poziomie rozumowania; jeden prompt dał ok. połowę efektu, resztę dorobiono iteracjami z agentem-CEO. Koszt pierwszej sesji: ok. 35 dolarów i 1 godz. 16 min.
- Całość jest darmowa: instalacja jedną komendą, repozytorium w opisie filmu (plus materiał sponsorowany Oracle i promocja społeczności Agentic Labs).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Trójwymiar to nakładka, nie magia
Na czym polega: Wirtualne biuro jest tylko interfejsem nałożonym na sprawdzone mechanizmy: zagadnienia w GitHubie, pull requesty, CI/CD. Grafika 3D nie zmienia logiki pracy agentów — zmienia sposób, w jaki ją oglądasz i nią sterujesz.
Jak stosować: Jeśli chcesz uprościć pracę z agentami sobie lub mniej technicznym osobom, rozdziel orkiestrację od interfejsu. Tu wystarczy traktować aplikację jako kokpit — dane i tak żyją w GitHubie, więc równolegle możesz używać zwykłych narzędzi.
Na co uważać: Ładne opakowanie nie naprawi mglistych opisów zadań. Jeśli issue jest nieprecyzyjne, agent zrobi coś innego niż chcesz — niezależnie od tego, jak efektownie wygląda jego biurko.
2.Agent-CEO jako jedyne okno na zespół
Na czym polega: Zamiast rozmawiać z każdym agentem z osobna, użytkownik wydaje polecenia jednemu agentowi-„prezesowi”. Ten tworzy zagadnienia, przydziela je, pilnuje obciążenia zespołu i w razie potrzeby zatrudnia kolejnych wykonawców.
Jak stosować: Sformułuj dla CEO jasny zestaw zasad (imię, cechy, reguły postępowania) i kieruj do niego wszystkie prośby: nowy projekt, funkcja, poprawka błędu. Do terminali pojedynczych agentów zaglądaj tylko wtedy, gdy chcesz coś podejrzeć lub dopisać uwagę.
Na co uważać: Każda warstwa pośrednia to miejsce, w którym intencja może się przekręcić. Przy ważnych zadaniach zajrzyj do zagadnienia w GitHubie i sprawdź, co CEO faktycznie zlecił.
3.Deleguj rekrutację, ale najpierw zatwierdzaj osobiście
Na czym polega: CEO sam znajduje „kandydatów” do zespołu i każdemu przypisuje rolę wraz z zakresem odpowiedzialności; człowiek zatwierdza kandydatury albo włącza tryb pełnej automatyzacji.
Jak stosować: Zacznij od ręcznej aprobaty — czytając opisy ról, poznajesz sposób, w jaki CEO rozumie Twój projekt. Dopiero gdy opisy są dopracowane, pozwól mu zatrudniać bez pytania.
Na co uważać: Automatyczna rekrutacja może mnożyć agentów szybciej, niż przybywa dla nich pracy, a każda instancja generuje koszt tokenów. Miej oko na liczebność zespołu.
4.Jeden backlog, dwa światy
Na czym polega: Tablica w świecie 3D pokazuje dokładnie te same zagadnienia, które istnieją w repozytorium jako GitHub issues. Nowy wpis to nowe issue, a komentarze i aktualizacje agentów widać po obu stronach.
Jak stosować: Możesz spokojnie pracować w GitHubie, traktując trójwymiarowy świat jako podgląd — albo odwrotnie. Podpięcie istniejącego repozytorium zachowuje całą historię zadań i PR-ów.
Na co uważać: Nie edytuj tego samego zadania równolegle w dwóch miejscach — łatwo o niespójności. Wybierz jedno źródło zmian i się go trzymaj.
5.Obieg QA z dowodami w każdym PR
Na czym polega: Gotowa zmiana trafia do agenta QA, który ją testuje i recenzuje; przy problemach odsyła zadanie z powrotem do developera. Raport kontroli — razem z dowodami, np. zrzutami ekranu z testów — dołącza do pull requesta.
Jak stosować: We własnych konfiguracjach narzuć zasadę: pull request nie idzie dalej bez raportu z testów i dowodów (screeny, logi). To podnosi jakość automatycznych zmian i ułatwia decyzję o scaleniu.
Na co uważać: Agent QA to również model — może się pomylić lub coś przeoczyć. Traktuj jego raport jako pomoc w decyzji, a nie jako wyrok.
6.Automatyczne scalanie dopiero po wszystkich testach
Na czym polega: Aplikacja potrafi scalać pull requesty sama, ale wyłącznie gdy QA zaliczy zmianę i wszystkie testy kontrolne przejdą pomyślnie — standardowe checki CI/CD z GitHuba, a jeśli ich używasz, także CodeRabbit czy Vercel. Jedno pole wyboru wyłącza automat.
Jak stosować: W projektach eksperymentalnych zostaw automat włączony, żeby utrzymać tempo pracy roju. W poważnych projektach odznacz auto-merge i scalaj po własnym przeglądzie.
Na co uważać: Zielone checki mówią, że kod przeszedł testy — a nie, że realizuje Twoją intencję. Scalanie bez przeczytania raportu QA to prosta droga do regresji.
7.Skróć pętlę zwrotną podglądem na żywo
Na czym polega: Na piętrze projektu stoi monitor, z którego jednym przyciskiem startuje serwer deweloperski; obok widać podgląd strony i wariant mobilny, odświeżane na bieżąco wraz ze zmianami wprowadzanymi przez agentów.
Jak stosować: Przy pracy z agentami włączaj podgląd od razu. Widok efektu w czasie rzeczywistym pozwala błyskawicznie wychwycić, czy agent zmierza w dobrą stronę — i skorygować polecenie, zanim zmiana urośnie.
Na co uważać: Serwer deweloperski nie zastępuje testów na realnych urządzeniach. Responsywność sprawdź także poza wbudowanym widokiem telefonu.
8.Prompt buduje trzon, iteracje budują produkt
Na czym polega: Całą aplikację van Zyl uruchomił jednym promptem do modelu Opus 5.5 (środowisko 3D w przeglądarce, kreskówkowa grafika, widok z pierwszej osoby, Claude Code i Agent SDK, mechanika fabryki z issue i PR, osobna sesja per agent). To dało ok. 50% efektu; resztę dorabiał, prosząc agenta-CEO o kolejne elementy — wewnątrz gotowego świata.
Jak stosować: Przy dużych projektach nie licz na uzyskanie całości jednym zadaniem. Opisz trzon (architekturę i mechanikę), a funkcje dodawaj pętlą: poproś → sprawdź → doprecyzuj. Narzędzie może rozwijać samo siebie.
Na co uważać: Pierwsza wersja będzie goła — tu zabrakło monitora podglądu czy zabawek. Zaplanuj czas i budżet na iteracje, zamiast oczekiwać cudownego pierwszego przebiegu.
9.Taki prototyp kosztuje kilkadziesiąt dolarów i godzinę
Na czym polega: Pierwsza sesja budowy — wyłącznie Opus 5.5, głównie z bardzo wysokim poziomem rozumowania — trwała godzinę szesnaście minut i kosztowała około 35 dolarów.
Jak stosować: Przy podobnych eksperymentach przyjmij punkt odniesienia: kilkadziesiąt dolarów i jedna–dwie godziny za działający szkic. Mierz czas i koszt każdej sesji (w aplikacji są statystyki), żeby wiedzieć, ile naprawdę kosztuje Cię iterowanie.
Na co uważać: To rachunek za jedną sesję. Dalszy rozwój — zwłaszcza na najwyższych ustawieniach rozumowania i przy wielu agentach naraz — będzie się sumował.
10.Open source: przetestuj, zanim ocenisz
Na czym polega: Projekt jest otwarty i darmowy. Instalacja to jedna komenda w terminalu, a kreator przeprowadza przez nazwę firmy, konfigurację CEO, tryb rekrutacji (ręczny albo automatyczny) i wybór projektu: nowy, folder z dysku lub repozytorium z GitHuba.
Jak stosować: Zainstaluj, podepnij mały, nieistotny projekt na próbę i sprawdź, czy taki sposób sterowania agentami Ci odpowiada. Repozytorium możesz sforkować i przerobić pod siebie (link w opisie filmu).
Na co uważać: To narzędzie self-hosted: sam zarządzasz zależnościami i bezpieczeństwem, a agenci dostają realny dostęp do Twojego kodu. Zanim podepniesz ważne repozytoria, sprawdź uprawnienia i warunki licencji.
Redakcyjne tłumaczenie
Fabryka oprogramowania, tylko bez terminala
Kto powiedział, że praca z agentami kodującymi musi być nudna? To, co właśnie widzicie, to moja fabryka oprogramowania rozstawiona w przestrzeni 3D. Każda mała postać siedząca za biurkiem to prawdziwy agent — instancja Claude Code albo Codex.
Fabrykami zajmuję się od dawna i mam osobny film o tym, jak zbudować własną. W praktyce sprowadzają się one do dwóch wariantów. Pierwszy polega na podpięciu się wprost do GitHuba: zakładasz zagadnienie, przypisujesz je agentowi, a któryś członek roju wprowadza zmianę i otwiera pull request. Drugi to narzędzie pokroju Paperclipa (Informacja dodatkowa: Paperclip to otwarty projekt, który układa agentów kodujących w strukturę wirtualnej firmy — z agentem-CEO i panelem webowym; wymaga jednak własnego hostingu.) — czyli kolejna aplikacja lub narzędzie CLI, które trzeba samodzielnie postawić i utrzymywać. W Paperclipie definiujesz firmę w przeglądarce, ustawiasz agenta-CEO i stąd zarządzasz całością. O nim też mam osobny film. Działa — ale, powiedzmy szczerze, nie zachwyca.
Dlatego zbudowałem coś mniej technicznego. Nie musisz tu zarządzać GitHubem, sam zakładać zagadnień ani pilnować pull requestów — a mimo to w każdej chwili masz do wszystkiego pełny wgląd, jeśli tylko chcesz. Z Paperclipa przeniosłem natomiast strukturę organizacji: nie odzywamy się do agentów pojedynczo (choć nic nie stoi na przeszkodzie) — naszym głównym rozmówcą jest agent-CEO. Prezes może zatrudniać nowych pracowników, rozkładać między nich obciążenie i nadzorować kilka projektów naraz.
W tym filmie pokażę, jak to wszystko powstało — i wskażę, jak możesz zacząć korzystać z tej aplikacji już dziś. Najpierw jednak szybka wycieczka.
Biuro na parterze: ustawienia i projekty
Na parterze mieści się nasze własne biuro. Z terminala wchodzimy w ustawienia — i tu wybieramy domyślne narzędzie kodujące, tzw. harness, czyli środowisko robocze agenta. Do wyboru: Claude Code, Codex i OpenCode. Dalej model, domyślny poziom rozumowania i kilka innych parametrów. W tym samym miejscu zakłada się projekty: zupełnie nowy, istniejące repozytorium z GitHuba albo folder na własnym komputerze.
Mam aktualnie dwa: Glaze Club, czyli sklep z pączkami, oraz CubeFarm — ten właśnie projekt. Tak, rozwijam go w jego własnym trójwymiarowym świecie.
Gabinet prezesa i telefon zamiast biegania
Obok stoi nasz CEO. Określamy jego imię, cechy i zasady, którymi ma się kierować, a tablica przy jego biurku pokazuje, czym prezes akurat jest zajęty. Z każdym agentem można też wejść w interakcję: podgląd otwiera prawdziwy interfejs terminala — dokładnie ten, który daje Claude Code czy Codex w przypadku tej konkretnej instancji — a z małego okienka wyślemy agentowi wiadomość. Nasz CEO właśnie mi odpisał.
Ważne: prezes ma dostęp do wszystkich projektów i widzi każdego podwładnego w roju. Tak jak w Paperclipie nie musimy rozmawiać z agentami pojedynczo. Mówimy CEO, czego potrzebujemy — nowego projektu, funkcji w istniejącym, naprawy błędu — a on tworzy zagadnienia, przydziela zadania, a gdy brakuje rąk do pracy, zatrudnia kolejne osoby.
Żeby zamienić z nim słowo, nie trzeba do niego biegać. Wystarczy wyjąć telefon. Z telefonu rozmawiamy z Morganem (tak nazywa się mój CEO), sprawdzamy, nad czym pracują wszyscy, czy czegoś potrzeba, planujemy kolejne kamienie milowe — albo po prostu prosimy o zwiększenie zatrudnienia. Zróbmy to: „Proszę zatrudnić więcej programistów do projektu CubeFarm”. Wysyłam — Morgan zabiera się do roboty, a tablica przy jego biurku pokazuje, że faktycznie odpisuje. Zaczekamy na efekt.
Telefon służy też do podglądu naborów i pokazuje całą firmę jednym rzutem oka. Agentom zajmuje chwilę dokończenie pracy, więc czekanie można sobie jakoś umilić.
Rekrutacja w poczekalni
Prezes wskazał już kilku kandydatów — siedzą w poczekalni. Podchodzimy, klikamy na którąś z postaci i widzimy, jaką rolę miałaby pełnić; opis stanowiska da się rozwinąć i sprawdzić, za co dokładnie ten agent będzie odpowiadał. Jeśli wszystko się zgadza, klikamy „zatrudnij”, a nowa osoba przechodzi na piętro projektu. Nie musimy nawet podchodzić — to samo zrobimy z telefonu, w zakładce naborów.
Piętro projektu: prawdziwe terminale, prawdziwa strona
Każdy projekt zajmuje osobne piętro. Wjeżdżamy windą i przenieśmy się na piętro Glaze Club — trójwymiarowego sklepu z pączkami, powstającego na żywo. Siedzący tu pracownicy to autentyczne instancje Claude Code i Codex, które po prostu grzebią w kodzie. Podejdźmy do Ady: na bieżąco widzimy jej terminal i przeglądarkę agenta. Lewy przycisk myszy albo klawisz E powiększają obraz, żeby dokładnie przyjrzeć się temu, co się dzieje. A jeśli chcesz popracować tak jak w zwykłym Claude Code czy Codexie — śmiało: wiadomości można wpisywać wprost do terminala konkretnego agenta. Po prawej stronie ekranu widać z kolei podgląd strony z przeglądarki agenta. Wszystko dzieje się w czasie rzeczywistym.
Przerwa od sponsora: Oracle Agent Studio
Zanim pójdziemy dalej, słowo od sponsora — Oracle. Jeśli budowałeś kiedyś agenta AI, który znakomicie spisuje się w demie, to znasz ciąg dalszy: gdy prawdziwa firma ma zacząć go używać, robi się trudno. Kto ma dostęp do czego? Kto zatwierdza zmiany? Kto to wszystko śledzi? Zwykle właśnie na tym etapie takie projekty utykają. Oracle Agent Studio dla Fusion Applications podchodzi do tematu sprytnie: agenty działają wewnątrz samego Fusiona, więc z marszu dostają bezpieczeństwo, reguły i śledzenie zmian, którym firmy już ufają. Podoba mi się też to, że buduje się je narzędziami używanymi na co dzień — VS Code, Cursor, terminal, Git, agenty pokroju Codex i Claude Code. Do tego publiczne repozytorium na GitHubie pełne szablonów, projektów startowych i przykładowych aplikacji (github.com/oracle/Fusion-AI-Studio), więc nigdy nie zaczynasz od zera. Klienci Fusion dostają Agent Studio bez dodatkowych opłat, a repo jest otwarte dla wszystkich — szczegóły na oracle.com/applications/fusion-ai, link w opisie filmu. Dzięki, Oracle, za wsparcie.
Biała tablica, którą jest GitHub
Wracamy na piętro. Agent, przy którym stoimy, używa Claude Code, a Grace pracuje na Codexie — w jej oknie terminala widać model GPT‑5 Astra z wysokim poziomem rozumowania.
Przy białej tablicy obejrzymy cały backlog i to, kto nad czym siedzi. Zasada jest prosta: nowy wpis na tablicy to zwykłe zagadnienie w GitHubie. Jeśli znacie GitHuba, ten widok nie was zaskoczy. W Glaze Club widać issue, nad którym pracuje właśnie rój — mówi o tym etykieta. Agenci w trakcie dodają komentarze i aktualizują zagadnienie, a zadania trafiają do nich same, dopasowane do pełnionych ról. Nad tą sprawą siedzą trzej agenci i wszystko odświeża się na żywo. Gdy któryś skończy swoją część, zmiana przechodzi do agenta QA, który ją testuje i recenzuje; natrafi na problem — odsyła zadanie z powrotem do programisty do poprawki.
Kontrola jakości i automatyczne scalanie
Najciekawsze zaczyna się przy pull requestach, które przeszły już przegląd. Kliknięcie karty przenosi nas do GitHuba, do samego PR — widzimy dokładnie, co zostało zmienione. Do tego dochodzi raport od agenta QA: co dokładnie zrecenzował, wraz z dowodami z testów, na przykład zrzutami ekranu. Możesz więc sam przejrzeć zmiany i scalić je ręcznie — ale aplikacja potrafi scalać też sama.
Schemat wygląda tak: gdy powstaje pull request, agent QA go bada i wydaje werdykt — zaliczony albo odrzucony. Automatyczne scalanie następuje dopiero wtedy, gdy pomyślnie przejdą wszystkie testy kontrolne: standardowe checki CI/CD z GitHuba, a jeśli ich używasz, także CodeRabbit (Informacja dodatkowa: CodeRabbit to bot automatycznie recenzujący pull requesty.) czy Vercel. Nie chcesz automatycznego scalania? Wystarczy odznaczyć jedno pole („auto merge z QA i checkami”) i decyzje wracają do Ciebie.
Spójrzcie: karta właśnie przesunęła się do kolumny „gotowe do scalenia”, czyli zmiana zaliczyła kontrolę QA. Za sekundę–dwie pull request numer 69 zostanie automatycznie scalony z gałęzią główną.
Podgląd na żywo — i coś na czas czekania
Wszystko ładnie wygląda, ale jak obejrzeć efekt pracy agentów? Nie trzeba wychodzić z tej aplikacji. Obok stoi monitor: jednym przyciskiem startujemy serwer deweloperski i natychmiast mamy podgląd strony na żywo. Gdy agenci coś zmienią, zobaczymy to od razu. Jest też widok telefonu, żeby sprawdzić responsywny układ. Serwer, strona i zmiany działają tu w czasie rzeczywistym.
A że czekanie na agentów bywa długie, po świecie porozrzucano sporo rozrywek: interaktywne obiekty 3D, piłka, którą można spróbować wrzucić do kosza, wreszcie pistolet na piankowe pociski — da się postrzelać do agentów i popatrzeć na ich reakcje. Szkoda tylko, że nie oddają ognia.
Cały kod jest otwarty i darmowy. Zobaczmy więc, jak to zbudowałem — i jak możesz zacząć dzisiaj.
Jak to powstało: jeden prompt i Opus 5.5
Pewnie wielu z was ciekawi, jak powstała ta całość. Zacznijmy od modelu. Opus 5.5 jest niesamowicie mocny w pracy z 3D, a już szczególnie w budowie środowisk znanych z gier. W całym projekcie użyłem więc wyłącznie Opusa 5.5, w większości czasu z bardzo wysokim poziomem rozumowania.
Sedno promptu, który do niego wysłałem, było takie: zbuduj środowisko 3D działające w przeglądarce, z kreskówkową grafiką i widokiem z pierwszej osoby. Na start poleciłem użyć Claude Code i Claude Agent SDK oraz mojej subskrypcji, żeby postawić rój agentów. Dodałem, że całość ma działać jak fabryka oprogramowania — tworzyć zagadnienia w GitHubie i pull requesty — a każdy agent ma mieć własną, osobną sesję Claude Code. Całego promptu nie będę czytał; macie go do wglądu, a główne elementy, jak tablica Kanban, już omówiłem.
Ten jeden prompt dał mniej więcej połowę tego, co widzicie. Agenci mogli już siedzieć za biurkami, tablica działała, ale zabawek ani piłek nie było, a ponieważ brakowało monitora, nie dało się podglądać budowanej aplikacji. Wtedy otworzyłem projekt — ten sam, w tym samym świecie 3D — i zacząłem prosić agenta-CEO o kolejne dodatki: monitor do podglądu na żywo, obsługę Codexa i OpenCode. Po prostu bawiłem się tym środowiskiem i prosiłem o kolejne iteracje.
Rachunek: godzina szesnaście i 35 dolarów
Podsumujmy pierwszą sesję w statystykach. Cały etap budowy szedł na Opusie 5.5, trwał godzinę i szesnaście minut i kosztował jakieś 35 dolarów.
Twoja pierwsza firma: instalacja krok po kroku
Chcesz spróbować sam albo sforkować projekt i przerobić go pod siebie? Jak najbardziej — wszystko jest otwarte, a link do repozytorium znajdziesz w opisie filmu. Jeśli chcesz wesprzeć przedsięwzięcie, daj mu gwiazdkę na GitHubie.
Instalacja sprowadza się do jednej komendy. Kopiujesz ją, wklejasz do terminala — wiersza poleceń czy PowerShell, co wolisz — a skrypt sam pobiera zależności i otwiera przeglądarkę. Kreator pyta najpierw o Twoje imię i nazwę firmy. Dalej ustawiasz CEO: moja nazywa się Luna, wybieram postać żeńską i zmieniam kolor. Następnie decydujesz o rekrutacji. Prezes z własnej inicjatywy szuka podwładnych do roju — masz dwa wyjścia: zatwierdzać każdą kandydaturę osobiście albo pozwolić Lunie zatrudniać bez pytania. Ja wybieram ręczny przegląd kandydatów.
Na koniec pierwszy projekt: budujesz coś od zera, wskazujesz folder na swoim komputerze albo podpinasz repozytorium z GitHuba. Ja wskazuję folder z Glaze Club i dodaję go jako nowe piętro. Projektów może być dowolnie wiele. I to tyle — firma startuje.
Pierwsze kroki w biurze
Wchodzimy do środka, a aplikacja od razu prowadzi krótki samouczek. Klawisz P otwiera telefon: stąd rozmawiamy z Luną, przeglądamy nabór, patrzymy na całą firmę jednym rzutem oka — a przy okazji grajemy w Snake’a czy Tetrisa. Jest nawet wirtualny zwierzak na biurku, którego trzeba karmić, bawić się z nim i utrzymywać go w dobrym nastroju. Nowe projekty dodasz w każdej chwili: podchodzisz do komputera i wskazujesz folder, repozytorium albo tworzysz projekt od zera.
Zajrzyjmy do CEO — klawisz E albo lewy przycisk myszy pokazuje, czym jest zajęta. U mnie Luna właśnie szuka kandydatów; poczekamy, aż ten krok się zakończy. Samouczek przewinę, bo chcę, żebyście przeszli go sami.
Moja rada: na początku rój jest pusty, więc odczekaj, aż prezes zatrudni pierwszych pracowników. Gdy się pojawią, poproś CEO o stworzenie zadań. To naprawdę takie proste: „Hej, do projektu Glaze Club dodaj więcej zadań — popraw wygląd wizualny, może większy wybór pączków”. Już to wysyłam… a, widzę, że nowi kandydaci są gotowi — siedzą w holu. Zatrudniam Adę, Linusa, Grace i Alana. Teraz piętro projektu nie będzie wyglądać tak pustawo, a prezes właśnie dopisuje kolejne zadania.
Zjedźmy na piętro projektu: agenci zajmują miejsca, a ponieważ biała tablica jest podpięta do prawdziwego repozytorium, widać na niej wszystkie zagadnienia i pull requesty z mojej poprzedniej sesji.
Na koniec: społeczność Agentic Labs
Napiszcie w komentarzach, co sądzicie o tym projekcie — i koniecznie wypróbujcie go sami. Czekam na wasze wrażenia. A jeśli chcecie nauczyć się budować z agentami podobne rzeczy, zajrzyjcie do mojej społeczności Agentic Labs na Skoolu (Informacja dodatkowa: Skool to platforma płatnych społeczności łączących forum z kursami.). Znajdziecie tam kilka klas i wiele godzin nagrań o skutecznej pracy z agentami — od podstaw programowania agentowego i poprawnej konfiguracji środowisk, przez design systemy i animacje, po projekty do odtworzenia krok po kroku. Co tydzień spotykamy się na żywo: we wtorki luźno przy kawie — pogadać o czymkolwiek, od kariery po premiery nowych modeli — a w czwartki na głębszych analizach; jutro na przykład rozmawiamy o Jeffie z TypeSafe AI. Link w opisie filmu.