O czym jest ten film
- W 2026 roku zbudowanie agenta AI, a nawet wypuszczenie go na produkcję, jest znacznie prostsze niż jeszcze pół roku wcześniej — narzędzia wzięły na siebie większość ciężaru.
- Agents CLI to opensource’owe narzędzie Google, które w parze z tzw. skills-ami pozwala asystentowi kodującemu (np. Claude Code) przeprowadzić agenta od pomysłu aż po stabilne wdrożenie.
- Podział ról: CLI daje asystentowi możliwość uruchamiania komend (szkielet projektu, ewaluacje, pojedynczy prompt, optymalizacja promptów na podstawie danych z testów), a skills-y uczą go, kiedy i jak z nich korzystać.
- Dokumentacja frameworka ADK jest „zaszyta” w skillach — programista nie musi już sam otwierać dokumentacji ani wklejać jej fragmentów do rozmowy.
- Autor pokazuje cały proces na żywo: instalację CLI, budowę agenta analizującego dane z CSV, ewaluacje i wdrożenie do Google Cloud — nie uruchamiając przy tym ręcznie ani jednej komendy.
- Osobny wątek: po co jeszcze frameworki agentowe (ADK, Pydantic AI, LangChain), skoro istnieją SDK dla agentów kodujących? Odpowiedź autora: SDK są wygodne, ale kosztowne w tokenach i wolne, a na produkcji liczy się szybkość odpowiedzi.
- Wartość dodana wdrożenia u Google: wbudowana piaskownica do bezpiecznego wykonywania kodu, pamięć, ewaluacje, pełna audytowalność dzięki śladom wykonania oraz tożsamość agenta z uprawnieniami jak u konta serwisowego.
- Nawet przy bardziej złożonych projektach (systemy wieloagentowe, rozbudowany RAG) Agents CLI poprowadzi cały proces — trzeba tylko wcześniej poświęcić więcej czasu na specyfikację.
- Autor otwarcie zaznacza, że materiał powstał we współpracy z Google, ale podkreśla, że sam korzysta z tego zestawu na co dzień.
- Główna teza: próg wejścia w budowanie agentów spadł tak bardzo, że cały cykl — od pomysłu po produkcję — można przejść w kwadrans.
10 najważniejszych takeaways — z kontekstem zastosowania
1.CLI to możliwości, skills-y to instrukcje obsługi
Na czym polega: Agents CLI to zestaw komend, ale człowiek nie wpisuje ich ręcznie. Robi to agent kodujący, a dołączone pliki skills mówią mu, kiedy i po co daną komendę uruchomić — dzięki temu asystent potrafi samodzielnie przejść cały proces od szkieletu projektu po wdrożenie.
Jak stosować: zainstaluj CLI razem z umiejętnościami jednym poleceniem, a potem po prostu opisz słowami, czego chcesz („zbuduj agenta”, „zrób ewaluacje”, „wdroż agenta”) — reszta dzieje się bez twojego udziału.
Na co uważać: narzędzie zadziała tylko z asystentami, które obsługują skills-y; w Claude Code możesz sprawdzić, czy zostały wczytane, komendą /skills.
2.Dokumentacja frameworka siedzi w środku, nie w sąsiedniej karcie
Na czym polega: skill z zasadami pisania kodu agenta ma wbudowaną dokumentację ADK, więc asystent kodujący sam z niej korzysta — nie musisz jej ani otwierać, ani podsyłać.
Jak stosować: zweryfikuj efekt (kod, testy, działanie agenta), a nie źródła wiedzy; oszczędzasz czas, który kiedyś schodził na przeklejaniu stron dokumentacji do rozmowy.
Na co uważać: dotyczy dokumentacji konkretnego frameworka — niestandardowe biblioteki i wewnętrzne systemy nadal trzeba opisywać samodzielnie.
3.Jeden strumień pracy: pomysł → kod → ewaluacje → wdrożenie → obserwowalność
Na czym polega: zdaniem autora Google idzie z pomocą dla agentów dalej niż inne frameworki — aż po wdrożenie i obserwowalność na produkcji, podczas gdy większość zestawów skills-ów kończy się na samym budowaniu.
Jak stosować: na każdym etapie wystarczy zwykłe polecenie w języku naturalnym; narzędzie samo dobierze właściwy skill i komendy, a Ty pilnujesz tylko specyfikacji i efektów.
Na co uważać: im większy projekt, tym więcej czasu trzeba poświęcić na dokładne opisanie wymagań — samo „zbuduj” przy systemie wieloagentowym nie wystarczy.
4.Ewaluacje twórz razem z agentem, nie po fakcie
Na czym polega: przy budowie agenta powstaje zestaw testowy; asystent uruchamia go w osobnej rozmowie — bez kontekstu sesji, w której agent powstawał — i sprawdza, czy odpowiedzi zgadzają się z oczekiwanymi wynikami.
Jak stosować: gdy któreś testy nie przechodzą, potraktuj to jako sygnał do iteracji: popraw prompt systemowy i dobór narzędzi, dopóki agent nie będzie gotowy do wdrożenia.
Na co uważać: trzy automatycznie wygenerowane przypadki testowe to za mało na produkcję — zestaw trzeba rozbudować o realistyczne dane i pytania użytkowników.
5.Kod pisany przez agenta uruchamiaj w piaskownicy
Na czym polega: agent typu „zapytaj swoje dane” pisze i wykonuje kod Python; w ADK służy do tego wbudowana, izolowana piaskownica, a po wdrożeniu do chmury Google kwestię izolacji bierze na siebie infrastruktura.
Jak stosować: gdy asystent zapyta, którego executora kodu użyć, wybierz wbudowaną piaskownicę — zwłaszcza jeśli agent ma na produkcji uruchamiać praktycznie dowolny kod.
Na co uważać: hostując takiego agenta samodzielnie, poza środowiskiem Google, problem bezpiecznej izolacji kodu rozwiązujesz we własnym zakresie.
6.SDK agentów kodujących — do własnych narzędzi, framework — na produkcję
Na czym polega: SDK (typu Antigravity) świetnie sprawdzają się w prywatnych „drugich mózgach” i workflowach uruchamianych na własne potrzeby, ale są mało oszczędne wobec tokenów i dają wolniejsze odpowiedzi. Frameworki takie jak ADK pozwalają budować minimalisticznego agenta od podstaw, z pełną kontrolą nad promptami i narzędziami — taniej i szybciej.
Jak stosować: zanim wybierzesz technologię, zdecyduj, gdzie agent będzie żył: coś dla siebie, bez presji czasu i kosztów — SDK; agent w produkcie dla użytkowników — framework.
Na co uważać: schemat „mocny agent z SDK” nie skaluje się na platformę — rachunek za tokeny i opóźnienia rosną вместе z ruchem.
(poprawka: „rośnie wraz z ruchem” — patrz zdanie powyżej)
7.Cztery sekundy na pierwszy token
Na czym polega: według badań, na które powołuje się autor, użytkownik platformy porzuca agenta, jeśli nie zobaczy odpowiedzi — choćby samego pierwszego fragmentu — w ciągu około czterech sekund.
Jak stosować: projektując agenta produkcyjnego, optymalizuj pod czas pierwszego tokenu i lekkość rozwiązania; lekki agent na frameworku to prostsza droga niż ciężki agent zbudowany na SDK.
Na co uważać: autor przywołuje badania ogólnie — traktuj regułę czterech sekund jako mocną heurystykę, a nie dokładną stałą.
8.Nawet ze skills-ami zaczynaj od specyfikacji
Na czym polega: w filmie autor celowo pracuje na skróty („vibe coding”), ale podkreśla, że normalnie najpierw buduje z asystentem specyfikację agenta, a dopiero potem każe wczytywać umiejętności i pisać kod.
Jak stosować: przy każdym poważnym projekcie najpierw spec (cel, dane, narzędzia, kryteria sukcesu), potem implementacja; proste, dobrze opisane agenty można z powodzeniem „załatwić jednym strzałem”.
Na co uważać: pominięcie specyfikacji przy złożonym agencie to prosta droga do błędów w wymaganiach i przerabiania gotowego już kodu.
9.Produkcja to nie tylko „działa”: tożsamość, ślady, audyt
Na czym polega: po wdrożeniu agent dostaje własną tożsamość i uprawnienia — jak zwykły użytkownik czy konto serwisowe; wykonanie można śledzić śladami osobno dla każdego agenta i użytkownika, a środowisko oferuje też pamięć, ewaluacje i piaskownice dla kodu.
Jak stosować: świadomie skonfiguruj uprawnienia agenta — nadaj mu wyłącznie te, których faktycznie potrzebuje; adresy URL pozwalają wpleść go w dowolną platformę.
Na co uważać: nie ignoruj śladów wykonania — to główne narzędzie diagnozy na produkcji i bez niego trudno wyłapać regresje po zmianach promptów.
10.Próg wejścia drastycznie spadł — warto to sprawdzić samemu
Na czym polega: porównanie z filmami autora sprzed dwóch lat (agent budowany linijka po linijce w LangChain) pokazuje, że dziś cały cykl — od pomysłu po wdrożenie — da się przejść w kwadrans, nie dotykając terminala.
Jak stosować: zainstaluj CLI i zbuduj prostego agenta na własne potrzeby, żeby poczuć nową skalę łatwości i ocenić, ile z twojej obecnej pracy można oddelegować.
Na co uważać: łatwość dotyczy typowych przypadków; systemy pamięci, rozbudowany RAG czy wielu agentów wciąż wymagają przemyślanej architektury.
Redakcyjne tłumaczenie
Od pomysłu do produkcji — dziś to naprawdę proste
Dziś każdego stać na zbudowanie agenta AI, a nawet wypuszczenie go na produkcję przestało być czarną magią. Właśnie to chcę pokazać: jak połączenie narzędzia działającego w wierszu poleceń z tzw. skills-ami sprawia, że asystent kodujący przeprowadzi nas przez cały proces — od pomysłu, przez kod, aż po stabilne wdrożenie. Posłużę się Agents CLI od Google. To potężne, otwarte narzędzie (link zostawiam w opisie), które pomaga budować agentów w ADK — frameworku, na którym pracuje dziś sporo twórców. (Informacja dodatkowa: ADK, czyli Agent Development Kit, to opensource’owy framework Google do tworzenia agentów AI; skills-y to pliki z instrukcjami i dokumentacją, które asystent kodujący — np. Claude Code — ładuje do kontekstu, aby wiedzieć, jak wykonać zadanie.)
Przyznaję: dawno nie nagrałem filmu, w którym po prostu buduję agenta. Ostatnio skupiam się głównie na asystentach kodujących i powód jest prozaiczny — narzędzia takie jak to, które zaraz pokażę, tak bardzo ułatwiły pracę, że trudno o materiał o odpowiedniej głębi. Nie chcę przez to powiedzieć, że każdy agent to teraz spacer: złożone systemy pamięci i architektury RAG wciąż potrafią dać w kość. Ale w porównaniu choćby z ostatnim półrokiem próg wejścia wyraźnie się obniżył.
Trzy epoki budowania agentów
Przenieśmy się na chwilę w czasie. Gdy dwa lata temu startowałem z kanałem, moje filmy wyglądały tak: siedzę w VS Code i pokazuję linijka po linijce, jak zbudować agenta w LangChain — tu definiujemy model, tu podłączamy prompt systemowy, tu dodajemy narzędzia. Dobre czasy, ale każdy pojedynczy agent pożerał mnóstwo czasu, a asystentów kodujących jeszcze nie było.
Półtora roku później, gdy asystenci już istnieli, wciąż żyliśmy w dokumentacji. Te oto stronice ADK — sam buduję też mnóstwo agentów w Pydantic AI, frameworków jest bez liku — ale żaden asystent nie potrafił jeszcze z żadnym z nich pracować pewnie. Pojęcia skills-ów, które po prostu dostarczają cały potrzebny kontekst wraz z dokumentacją, jeszcze nie było. Wciąż przechodziliśmy przez poradniki szybkiego startu, kopiowaliśmy wybrane strony i wciskaliśmy je maszynie jako tło. Masę błędów musieliśmy wyłapywać sami, bo agentom kodującym brakowało dojrzałości. Robót było sporo.
A mamy 2026 rok i nie trzeba spędzić w dokumentacji ani sekundy — bo w gruncie rzeczy wnosi się ją do środka asystenta. Jedno polecenie instaluje CLI razem z umiejętnościami, a dalej wystarczy zwykły, ludzki język: prosimy o zbudowanie agenta, jego ocenę, wdrożenie i utwardzenie. Wszystko przychodzi w jednym pakiecie. To, co pokazuję, jest uniwersalne — biorę Google, bo moim zdaniem w Agents CLI robią to najlepiej: doprowadzają agenta aż na produkcję.
CLI to możliwości, skills-y to instrukcje
Wracając do repozytorium: w pliku README zobaczymy komendy, które dają wyobrażenie o działaniu narzędzia. Całością — dodam — będzie sterował agent kodujący. Są więc komendy do wygenerowania szkieletu projektu, do ewaluacji agenta, do pojedynczego uruchomienia promptu, a nawet do optymalizacji promptów na podstawie danych z testów — samo-dostrajanie jest wpisane w narzędzie. I ani jednej z tych komend nie uruchomimy sami; oddamy je w ręce asystenta.
Można to ująć tak: CLI to pakiet możliwości, którymi obdarzamy agenta kodującego — potrafi on po prostu uruchomić wszystkie te polecenia. Dołączone umiejętności uczą go natomiast, jak z CLI korzystać. W tym sedno siły tego duetu: możliwości plus instrukcje. Przykładowo jednym z plików skills są wskazówki, jak faktycznie pisać kod agenta — i właśnie tam mieszka cała dokumentacja ADK, zaszyta w asystencie. Dlatego nie musimy jej ani otwierać, ani nawet podsyłać. Robi to wrażenie.
Każdemu etapowi budowy, dla którego istnieje komenda w CLI, odpowiada własny skill — agent kodujący potrafi więc przeprowadzić proces od deski do deski, trzymając się wyłącznie naszych poleceń i specyfikacji. I właśnie to kocham w Agents CLI: sporo frameworków oferuje umiejętności pomocne przy budowaniu, ale niewiele doprowadza aż do wdrożenia, a już na pewno nie do obserwowalności na produkcji. Dla jasności: ten materiał powstaje we współpracy z Google — cieszę się, że mogę to w ogóle powiedzieć — ale faktycznie sam na tym zestawie buduję, bo ADK z Agents CLI pozwala mi wdrażać na produkcję z niesamowitą łatwością.
Wyzwanie: budowa bez ani jednej komendy z mojej ręki
Do dzieła. Start, jak widzieliśmy, to jedno polecenie instalujące CLI wraz ze skills-ami, a potem po prostu prosimy o agenta. Tyle że ja tego polecenia nawet nie wydam — rzucam sobie wyzwanie: zbuduję i wdrożę całego agenta, nie wpisując w terminalu ani jednej komendy. Przechodzę więc od razu do Claude Code i, korzystając z dyktowania, mówię: „Przeszukaj sieć, żeby wiedzieć, jak zainstalować Google Agents CLI, a potem zainstaluj go w tym projekcie”.
Po trzydziestu sekundach wszystko gra: CLI zainstalowane, wszystkie umiejętności siedzą w folderze .claude (u innego asystenta będą gdzie indziej — narzędzie współpracuje z każdym, byle obsługiwał skills). Otwieram nową sesję, wpisuję /skills i widzę pełną listę: do budowy, do wdrożenia i tak dalej. Teraz wklejam prompt przygotowany wcześniej, żeby oszczędzić czas: każę wykorzystać zainstalowane umiejętności ADK do zbudowania agenta typu „zapytaj swoje dane”. To celowo prosty przykład — użytkownik dostarcza plik CSV i pytanie, a agent pisze kod Python i go uruchamia, żeby odpowiedzieć na pytanie o dane. Wykonanie kodu wybieram nieprzypadkowo: to jedna z tych rzeczy, które muszą dziać się w izolacji, a uczynienie ich niezawodnymi na produkcji bywa sporym wyzwaniem. Google zdejmuje je z naszych barków przy wdrożeniu do chmury właśnie dzięki tym umiejętnościom.
Widać, że asystent doładował odpowiedni skill — zna proces z CLI, szkielet projektu i zasady ADK — więc wie, jak rozkręcić bazę kodu i zbudować agenta. Dla tempa wchodzę od razu w budowę — trochę w trybie vibe codingu. (Informacja dodatkowa: vibe coding to styl pracy, w którym oprogramowanie powstaje głównie z promptów, a programista nie kontroluje każdej linijki kodu.) I zaznaczam wyraźnie: nawet z tymi umiejętnościami polecam normalny proces planowania i implementacji z asystentem — ciągle o tym mówię na kanale. Najpierw wspólnie tworzycie specyfikację agenta, a dopiero potem podajesz ją maszynie, by zaczęła wczytywać umiejętności i pisać kod. Nasz przykład jest jednak na tyle prosty, że powinien dać się załatwić jednym strzałem — zwłaszcza że agent potrafi też iterować i budować ewaluacje, co zobaczymy za chwilę.
W pewnym momencie asystent sam wrócił z pytaniem: którego executora kodu z ADK użyć? Zdecydowanie wbudowanej piaskownicy. Wykonywanie kodu to jedna z najlepszych rzeczy w ADK — opiera się na nim dziś mnóstwo agentów — a skoro na produkcji może zostać uruchomiony kod praktycznie dowolny, musi się to odbywać w bezpieczny sposób. No to pozwalamy maszynie się rozpędzić.
Słoń w pokoju: po co jeszcze frameworki agentowe
Gdy agent buduje się w tle, muszę rozprawić się z pytaniem, które słyszę nieustannie: „Cole, skoro mamy SDK dla agentów kodujących, po co nam frameworki typu ADK, Pydantic AI czy LangChain — te niby-tradycyjne?” Wiem, śmiesznie to brzmi, ale faktycznie są sporo starsze od tych SDK — naprawdę potężnych szkieletów, które od razu dają mnóstwo możliwości, dokładnie tych samych, na których pracują asystenci kodujący. Da się na nich zbudować bardzo mocnych agentów, choćby na SDK Antigravity. (Informacja dodatkowa: SDK dla agentów kodujących to biblioteki dające aplikacji te same możliwości, którymi posługują się asystenci kodujący — na przykład pracę z plikami i terminalem.)
Tyle że przy wypuszczaniu agentów na produkcję te starsze frameworki wciąż mają się dobrze. Rozłóżmy to na proste czynniki. Mnóstwo osób buduje na SDK agentów kodujących swoje „drugie mózgi” albo workflowy, które uruchamiają samodzielnie. Te narzędzia są rzeczywiście potężne, ale cena jest wysoka: znacznie mniejsza oszczędność tokenów i wolniejsze odpowiedzi. Tam, gdzie sami coś odpalamy — jak własny drugi mózg — i bardziej zależy nam na jakości wyniku niż na szybkości i kosztach, sprawdzają się znakomicie. Ja tak zbudowałem swój. Ale wszystko, co trafia na platformę i do produkcji, niemal zawsze lepiej postawić na framework typu ADK: podejście znacznie bardziej minimalistyczne. Agent powstaje od podstaw, kontrolujemy prompty i całe oprzyrządowanie, dzięki czemu można go zrobić bardzo oszczędnym w tokenach i szybkim. Sporo badań wskazuje, że klient platformy, który nie doczeka się od agenta odpowiedzi — a właściwie samego pierwszego tokenu — w cztery sekundy, po prostu odejdzie, albo przynajmniej że ryzyko odejścia jest wtedy bardzo duże. Jeśli agent ma się skalować na platformie, musi być szybki i lekki. I właśnie to pokazuję: na ADK, przy użyciu Agents CLI, budujemy agenta, który skaluje się znakomicie — w środowisku gotowym od razu nawet na miliony użytkowników.
Agent gotowy — test w Streamlit
Po pięciu–dziesięciu minutach agent jest gotowy. Poprosiłem jeszcze o podsumowanie, co narzędzie zrobiło z Agents CLI, więc mamy przegląd uruchomionych komend — na ewaluacje i wdrożenie przyjdzie czas na końcu. Ale cały agent stoi zbudowany i przetestowany. Kazałem też Claude Code dorzucić prosty interfejs w Streamlit, żeby było na co patrzeć przy testach; można go skierować zarówno na agenta lokalnego, jak i — później — na wdrożonego.
Wgrywam przykładowy zbiór danych, który kazałem wcześniej wygenerować. Wiem, że to błahostki, ale nie chcę zaciemniać obrazu nad wyraz skomplikowanym przykładem. Pytanie brzmi: jaka jest mediana przychodu na zamówienie i który wiersz najbardziej odstaje w górę od średniej? Agent za chwilę napisze kod, go uruchomi i poda odpowiedź. Oto ona: mediana przychodu na zamówienie to 1348,65 dolara. A najlepsze w tym interfejsie — i sam agent nam to komunikuje — to widok dokładnego kodu, który napisał do obliczeń. Dane były na tyle małe, że wkleił CSV wprost do kodu (oczywiście mógłby też czytać z pliku) i przy użyciu Pandas doszedł do wyniku, wypisując go na ekranie. Bardzo fajnie.
Ewaluacje w zupełnie nowej rozmowie
Czas pójść dalej: testy, szlif promptu i wdrożenie. Zaczynamy od ewaluacji. Znów zwykłym językiem — tak jak przy budowie — mówię: użyj skilla ADK, żeby ocenić naszego agenta. Robię to w nowej rozmowie i celowo: chcę pokazać, że do zrozumienia, jak wszystko uruchomić, asystent nie potrzebuje kontekstu z sesji, w której agent powstawał. Wczytuje skill ewaluacji, rozpoznaje istniejącą bazę kodu i po prostu odpala zestaw testowy, który sam stworzył przy budowie. Na potrzeby filmu zostawiłem trzy przypadki — na produkcję trzeba taki zestaw zdecydowanie rozbudować — i każdy z nich zaliczony. Ewaluacja polega na wysłaniu zapytania do agenta i sprawdzeniu, czy odpowiedź zgadza się z oczekiwaniami wynikającymi z danych testowych. Genialne w swojej prostocie. A jeśli wyniki wyglądają słabo, to znak, żeby iterować: poprawiać prompt systemowy i dobór narzędzi, dopóki agent nie będzie gotowy wyjść na produkcję.
Wdrożenie na Google Cloud: sześć minut
Samo wdrożenie? „Wdróż tego agenta.” Tyle. Asystent wczytuje skill i przeprowadza cały proces wdrożenia do Google Cloud. Może być potrzebne logowanie i utworzenie projektu w chmurze, ale i przez to narzędzie cię przeprowadzi — pokaże kroki i komendy, gdyby wszystko trzeba było postawić od zera. Ja miałem większość skonfigurowaną wcześniej, przygotowując się do filmu, ale ogólnie jest to naprawdę proste. Sześć minut później agent działa na produkcji: narzędzie postawiło dla nas instancję w GCP. Wszystko, oczywiście, da się skonfigurować. Dostajemy też adres konsoli, gdzie w przeglądarce można testować agenta żyjącego już na produkcji — można mu po prostu pisać. Poza tym: pamięć i ewaluacje wbudowane w środowisko produkcyjne oraz pełna audytowalność dzięki śladom wykonania — to również sprawa dużej wagi. Całe wykonywanie kodu, o którym mówiłem wcześniej, również na produkcji biega w piaskownicach.
Druga potężna rzecz: agent ma tożsamość. Widać ją właśnie tutaj; w konfiguracji usługi, w szczegółach wdrożenia, nadajemy agentowi uprawnienia — dokładnie tak, jak innemu użytkownikowi czy kontu serwisowemu. Ślady wykonania możemy śledzić osobno dla każdego agenta i każdego użytkownika korzystającego z naszych agentów. I mamy adresy URL, żeby wpleść agenta wprost w dowolną platformę, którą trzymamy na produkcji. Bardzo, bardzo fajne.
Ten sam test, ale na produkcji
Wracam do Streamlit — tym razem wybieram agenta wdrożonego. Wgrywam ten sam zbiór i podaję odrobinę inne pytanie: który region zanotował największy wzrost całkowitego przychodu między pierwszym a drugim kwartałem i o ile procent? Znowu zwykłe pytanie kontrolne: interfejs ten sam, tylko odpowiedzi płyną z agenta hostowanego w GCP. Proszę bardzo: mamy wynik, mamy napisany kod, wszystko wygląda naprawdę dobrze.
Kwadrans od pomysłu do produkcji
Przeprowadziliśmy agenta od pomysłu aż po produkcję, a ja nie uruchomiłem ani jednej komendy — całością sterował Claude Code. Tyle Agents CLI w piętnaście minut. To narzędzie o ogromnej mocy, które wyniesie na produkcję każdego agenta. Oczywiście, zależnie od tego, co budujesz, może być trudniej niż w moim przykładzie — systemy wieloagentowe czy rozbudowany RAG wymagają więcej — ale to wciąż będzie narzędzie prowadzące cały proces; po prostu więcej czasu spędzisz na dopracowywaniu szczegółów ze swoim asystentem kodującym. Link zostawiam w opisie. Wypróbuj, zbuduj agenta i zobacz, jak łatwe to dziś jest — choćby w porównaniu z samym rokiem temu. Jeśli podobał ci się materiał i czekasz na więcej o agentach AI i asystentach kodujących, polubienie i subskrypcja bardzo mi pomogą. Do zobaczenia w następnym filmie.