O czym jest ten film
- Webinar prowadzi Zoe Barns z zespołu wdrożeń „superinteligencji” w SpaceX SI; główny wykład daje Ryan, starszy inżynier polowy z Chicago, pracujący z klientami nad wdrażaniem AI do procesów inżynierskich.
- Główna teza: firmy doklejają AI do wciąż liniowego procesu (zgłoszenie → segregacja → specyfikacja → projekt → budowa → review → QA → wdrożenie), zamiast przeprojektować sam sposób współpracy ludzi i botów.
- Przykład otwierający: zgłoszony błąd naprawiony i scalony w mniej niż półtorej godziny przez dwie osoby i dwa boty w jednym wątku — zamiast jednego–dwóch dni w klasycznym trybie.
- Boty przejmują pierwszy krok: przed zaangażowaniem człowieka bot ocenia zasadność zgłoszenia i scala duplikaty w systemie ticketowym (Linear).
- Skala problemu: około 214 zgłoszeń dziennie; sprowadzenie czasu cyklu z pełnego dnia do godziny zmienia setki dni pracy w setki godzin.
- Kluczowa idea: pakowanie eksperckiego osądu (jak odtwarzać błędy, co znaczy „gotowe”) w bota z umiejętnościami, pamięcią i barierami, uruchamianego równolegle w wielu kanałach.
- Krzywa dojrzałości: bot eksploracyjny dla siebie (1–5 agentów) → boty zespołowe (10–20) → BDK, czyli bot przeniesiony do kodu, z ewaluacjami, wersjonowaniem i telemetrią.
- Pokaz na repozytoriach Grafany: bot kierujący zgłoszenia do właściwego repozytorium (z podawanymi procentami pewności) oraz bot odtwarzający błędy na własnej maszynie w chmurze.
- Porównanie z surowymi API: BDK daje gotowe elementy składowe, czekanie na potwierdzenie człowieka, zarządzanie sekretami i wdrożenie jednym poleceniem na Slacka czy Teamsy.
- Na koniec: bezpieczeństwo (listy dozwolonych, kontrola ruchu wychodzącego), pierwsze kroki z BDK oraz autonomiczna „drużyna” botów prowadząca grę mobilną Rankum.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nie doklejaj AI do starego procesu — przebuduj przepływ
Na czym polega: Firmy wplatają AI w kolejne etapy liniowej „sztafety”, ale sama kolejka zostaje. Zysk skalowy pojawia się dopiero, gdy ludzie i boty pracują równolegle w jednym wątku, a działający prototyp powstaje, zanim spisze się pełne wymogi.
Jak stosować: Wybierz jeden powtarzalny przepływ — na przykład zgłoszenie błędu — i pozwól botowi wykonać pierwszą wersję rozwiązania (odtworzenie problemu, zrzut ekranu, propozycja poprawki), a ludziom zostaw decyzje: „czy to w ogóle problem?” i „czy wygląda dobrze?”.
Na co uważać: Równoległość rozmywa odpowiedzialność — od początku ustal, kto scala i akceptuje wynik, bo inaczej wątek zamieni się w chaos.
2.Daj botowi pierwszy ruch: segregacja i scalanie duplikatów
Na czym polega: W pokazanym przykładzie bot wchodzi do wątku, zanim dotknie go człowiek: ocenia, czy zgłoszenie jest realnym błędem, a duplikaty dopisuje do istniejącego zgłoszenia w Linearze zamiast tworzyć kolejne.
Jak stosować: Podłącz bota do kanału zgłoszeń i systemu ticketowego; wpisz w jego umiejętności kryteria uznania błędu za zasadny oraz zasadę scalania duplikatów. Dokumentacja zostaje w systemie ticketowym — Slack służy do pracy, nie do archiwum.
Na co uważać: Bot musi znać granice własnej kompetencji (kiedy zamknąć, a kiedy przekazać człowiekowi), inaczej zacznie po cichu zamykać zgłoszenia, których nikt nie przeczytał.
3.Pomnóż czas cyklu przez wolumen — dopiero wtedy widać stawkę
Na czym polega: Zespół dostaje około 214 zgłoszeń dziennie. Przy cyklu „pełny dzień” to równowartość 200 dni pracy; przy cyklu godzinę — 200 godzin. Ta prosta arytmetyka decyduje, czy proces da się udźwignąć.
Jak stosować: Zmierz dzisiejszy średni czas od zgłoszenia do scalenia zmiany i pomnóż go przez dzienną liczbę zgłoszeń. Wynik to argument, który uzasadnia (albo podważa) inwestycję w automatyzację.
Na co uważać: Szybki cykl nie zwalnia z jakości — przypadki brzegowe (jak ikona przy bardzo długiej nazwie) nadal musi wyłapać człowiek albo uczony na tym bot.
4.Pakuj w bota osąd eksperta, nie tylko instrukcje
Na czym polega: Istotą skalowania jest spisanie „rzemiosła” — jak odtwarzać błędy, co znaczy „gotowe” — jako zestawu umiejętności, kontekstu, pamięci i barier, które można uruchamiać równolegle w wielu kątałach. Wtedy jeden inżynier mnoży się w kilkanaście wątków.
Jak stosować: Wypisz czynności, które wykonujesz mechanicznie w każdym zadaniu, i przenieś je do bota jako umiejętności; z każdą jego wpadką dokładaj nową regułę („od teraz wszystko uruchamiaj lokalnie”).
Na co uważać: To proces iteracyjny, nie jednorazowy projekt — bot bez barier zbudowanych na własnych błędach będzie te wpadki powtarzać.
5.Wchodź po schodach dojrzałości: eksploracja → bot zespołowy → kod
Na czym polega: Nie da się z dnia na dzień zaufać tysiącom autonomicznych agentów. Naturalna droga: najpierw bot eksploracyjny dla siebie (1–5 agentów), potem udostępnienie zespołowi (10–20), a na końcu — jeśli potrzebna przewidywalność — przełożenie na kod w BDK.
Jak stosować: Zacznij od jednego bota rozwiązującego Twój codzienny problem; gdy działa, kliknij „udostępnij zespołowi” i pozwól kolegom go używać oraz ulepszać.
Na co uważać: Nie każda automatyzacja zasługuje na kod — w pokazanej organizacji około 90% botów to boty zespołowe; BDK wchodzi dopiero tam, gdzie liczy się powtarzalność.
6.Steruj botem rozmową, a błędy zamieniaj w umiejętności
Na czym polega: Dzięki pamięci botów nie trzeba pisać plików konfiguracyjnych — wystarczy zwykły język („dodaj umiejętność: zawsze pokazuj wariant jasny i ciemny”). Bot zapamiętuje regułę i sam rozpoznaje, kiedy jej użyć — często lepiej niż przy wyborze umiejętności z samego opisu w kodzie.
Jak stosować: Traktuj każdą wpadkę bota jako materiał na nową umiejętność: powiedz wprost, czego zabrakło i jak ma postępować następnym razem.
Na co uważać: Umiejętności kumulują się bez wersjonowania — co jakiś czas przeglądaj ich listę, bo sprzeczne reguły potrafią się wzajemnie wykluczać.
7.Tam, gdzie liczy się determinizm — BDK i ewaluacje
Na czym polega: Bot kierujący zgłoszenia musi działać tak samo za każdym razem. W BDK bot żyje w kodzie: routing podaje prawdopodobieństwa (np. 73% kontra 27%), zestaw ewaluacji sprawdza na próbce zgłoszeń, czy trafiają we właściwe repozytoria (w pokazie: 48 na 50), a panel pokazuje logi, ślady decyzji i to, kto wdrożył ostatnią wersję.
Jak stosować: Wygeneruj zestaw testowy z historii zgłoszeń (może to zrobić za Ciebie bot), ustaw próg akceptacji i wbuduj weryfikację w proces wdrażania zmian w bocie — jak w zwykłym CI.
Na co uważać: Ewaluacje są tak dobre, jak dobrane przypadki — zbiór złożony wyłącznie z „czystych” zgłoszeń nie przygotuje bota na prawdziwe niedopowiedzenia użytkowników.
8.Łańcuchuj wyspecjalizowane boty
Na czym polega: W jednym wątku mogą współpracować boty o różnych rolach: jeden klasyfikuje i kieruje zgłoszenie, drugi odtwarza błąd — a oba można zawęzić do konkretnego repozytorium albo platformy (iOS kontra backend).
Jak stosować: Zamiast jednego „bota do wszystkiego” twórz wąskie role i łącz je w sekwencję: wersję sztywną (routing) oddaj BDK, elastyczną (odtwarzanie błędów) zostaw w Grok Bocie.
Na co uważać: Każde ogniwo łańcucha musi mieć precyzyjnie ograniczone narzędzia i uprawnienia — błąd na etapie kierowania przenosi się na cały łańcuch.
9.Skróć start agenta: gotowe środowiska w chmurze
Na czym polega: Środowiska agentowe w chmurze trzymają dla repozytorium zależności, zmienne środowiskowe, sekrety i połączenia MCP — agent nie pobiera pakietów ani nie konfiguruje wszystkiego od zera przy każdym zadaniu.
Jak stosować: Przygotuj takie środowisko dla często automatyzowanego repozytorium i dodaj botowi umiejętność korzystania z niego zamiast budowania wszystkiego lokalnie.
Na co uważać: Sekrety w takim środowisku wymagają tych samych zasad dostępu co poświadczenia ludzi — agent z uprawnieniami do repozytorium to też wektor ryzyka.
10.Bezpieczeństwo ustaw, zanim bot trafi do zespołu
Na czym polega: W ustawieniach Grok Bota dostępne są m.in. kontrola wykonywania operacji na lokalnej maszynie, udostępnianie szablonów, reguły ruchu wychodzącego i listy dozwolonych połączeń MCP — komplet narzędzi do dopasowania bota do standardów bezpieczeństwa firmy.
Jak stosować: Zacznij od wąskiej listy dozwolonych integracji i stopniowo ją poszerzaj; sam przegląd ustawień może nawet przeprowadzić z Tobą bot.
Na co uważać: Autonomiczne boty z dostępem do repozytoriów i środków (np. budżetu reklam) powinny działać w odizolowanej piaskownicy i mieć ograniczony „zasięg rażenia” na wypadek błędu.
Redakcyjne tłumaczenie
Wprowadzenie
Zoe Barns: Szanując Wasz czas — materiału jest sporo, a nagranie i tak do Was trafi. Nazywam się Zoe Barns i bardzo się cieszę, że możemy się dziś spotkać. Witam na webinarie „Skalowanie przepływów inżynierskich z Grok Bot i Cursor”. Pracuję w zespole wdrożeń superinteligencji w SpaceX SI, a towarzyszy mi Ryan. Ryan, przedstawisz się w skrócie?
Ryan: Cześć, jestem Ryan, starszy inżynier polowy w SpaceX, pracuję z Chicago. Pokażę Wam dziś sporo z tego, co widzimy u klientów i u nas wewnątrz — trochę zakulisowych szczegółów.
Zoe: Mamy przed sobą jakieś 50–55 minut. Ryan poprowadzi temat, a Wy śmiało wrzucajcie pytania na czat — będę je zbierać i część zadam na żywo. Ryan, twój ruch.
Ryan: Zaczynajmy. Najpierw standardowe zastrzeżenie prawne: to, co pokażę, odzwierciedla nasze plany — i może się zmienić. Nie będę tego czytać na raz.
Od sztafety do wspólnej pracy
Jestem inżynierem polowym, a wcześniej byłem założycielem firmy, product managerem i inżynierem — sporo ról widziałem od środka. Na co dzień pomagam klientom wplatać AI w ich obowiązki: w pisanie kodu, w Grok Bota, o którym zaraz będzie. I rzecz, którą widzę najczęściej, jest taka: przed erą AI wszystko płynęło liniowo. Wpadało zgłoszenie — ktoś je składał, ktoś inny sortował, może product manager pisał specyfikację poprawki. Potem projektanci: w Figmie albo po stronie backendu — architektura i tym podobne. Dopiero na końcu budowa. Ta kolejność była wymuszona historycznie: samo pisanie kodu trwało długo i kosztowało dużo wysiłku, więc wszystko musiało być ustalone wcześniej. Potem review, QA, wdrożenie.
Dziś większość firm ma ten sam przebieg, tylko z AI wplecionym w poszczególne etapy — czasem jednym zestawem narzędzi, o którym dziś opowiemy, czasem rozproszonym i spajanym przez MCP (Informacja dodatkowa: MCP — otwarty protokół pozwalający łączyć modele językowe z zewnętrznymi narzędziami i danymi.). I nawet ci, którzy już przyspieszyli każdy etap, wciąż pracują w tej sztafecie: ktoś zgłasza, ktoś sortuje, ktoś robi makiety i review, ktoś buduje, ktoś sprawdza. Nawet z AI w środku potrafi to zająć dwa tygodnie.
U nas robi się to inaczej — i o tym jest cała ta rozmowa: da się to naprawdę przyspieszyć, jeśli przemyśli się organizację pracy, tak żeby nie była liniowa, tylko żeby wiele osób działało razem z botami. Chcę pokazać przykład; wybrałem prosty, bez fajerwerków.
Błąd naprawiony w półtorej godziny
Znalazłem błąd i go zgłosiłem. Pierwsza rzecz: do wątku wskakuje bot, zanim ktokolwiek zdąży go dotknąć — przegląda treść zgłoszenia i mówi, czy zgadza się, że to problem do naprawienia. Potem do wątku wchodzi projektantka i starszy inżynier. To naprawdę prosty przypadek: brakuje małej ikonki sygnalizującej, że rozmówca jest botem zespołu.
Projektantka zabiera głos, a wtedy nasz inżynier przywołuje bota zespołowego — nazwa, którą to niewygodnie wymówić, więc powiem po prostu: bota zespołowego. Inżynier zbudował go z myślą o odtwarzaniu problemów: ogarnia sortowanie zgłoszeń na Slacku, błędy w Linearze i tym podobne. Bot bierze się do roboty, pokazuje zrzut ekranu problemu i zrzut proponowanej poprawki, a inżynier pyta projektantkę: „Jak to wygląda?”. I to jest ładny moment — projektantka odpowiada: „Pominęliście przypadek brzegowy: co z bardzo długą nazwą i dosuniętą do prawej ikoną?”. Bot przyznaje, że pytanie jest trafne. Widać też, jak inżynier na żywo koryguje bota — mówi mu, czego następnym razem nie robić. Na koniec sprawdzamy przypadek brzegowy po wciśnięciu klawisza Command — nadal wygląda dobrze. Inżynier mówi: „Dobra robota, Grok Bot”, poprawka zostaje scalona, ja dziękuję.
Kiedyś ten przepływ zająłby dzień, może dwa. I łatwo o wpadkę: scalić za pierwszym razem, bez sprawdzania skrótu klawiszowego — i nagle mamy dwa PR-y, dwa review i tak dalej. U nas od zgłoszenia o 8:41 do scalenia minęły niecałe półtorej godziny. Cała tajemnica to człowiek, dwa boty i drugi człowiek, którzy pracują razem w wątku już nie liniowym. Można od razu zbudować prototyp i dopiero z niego cofać się do wymogów — a to przyspiesza wszystko ogromnie.
Zoe: Przyszło pytanie: czy w ogóle jeszcze używacie narzędzi ticketowych, czy wszystko dzieje się w Slacku?
Ryan: Bardzo dobre pytanie. Tak, to trafia do Lineara (Informacja dodatkowa: Linear — popularne w zespołach inżynierskich narzędzie do zarządzania zgłoszeniami i projektami.). Sporo osób używa dziś takich systemów głównie jako dokumentacji — i to nadal jest ważne. Gdyby ten sam problem zgłosiły jeszcze dwie osoby, bot nie tylko przeprowadzi sortowanie, ale i scali duplikaty. Dzięki temu nie zdarza się sytuacja, w której dwadzieścia osób zgłasza, powstaje dwadzieścia zgłoszeń i ktoś musi je sprzątać — bot dopisuje kolejne przypadki do tego jednego. Wszystko jest udokumentowane, a przy okazji można wejść prosto do Lineara i działać stamtąd przez Cursora.
Setki zgłoszeń dziennie
Tych wątków mamy mnóstwo każdego dnia. Ten jeden zajął godzinę i pół pełnego cyklu, ale — jak widzieliście — inżynier John (u nas są dwaj Johnowie, więc: ten od inżynierii) zaprojektował swojego bota tak, że wystarczy go o coś zapytać. Pod spodem siedzi cały zestaw umiejętności i reguł. W pozostałej części sesji zbudujemy oba te boty w Grok Bocie — to świetne na start, niezależnie od tego, jak wygląda Wasza organizacja. Potem rozłożę na części to, co dzieje się za kulisami, bo ten bot potrafi uruchomić repozytorium niemal bez instrukcji. Na przykład pokazał poprawkę w wariancie jasnym i ciemnym — zakładam, że najpierw zrobił jeden, a ktoś dodał umiejętność: „zapomniałeś o ciemnym, następnym razem pokaż oba”.
Zrobiliśmy szybki przegląd: 74 zgłoszenia z wewnętrznego feedbacku, ponad sto na X, sporo od klientów. Słuchamy tego wszystkiego, więc śmiało piszcie. Liczby wyciągnął mi mój Grok Bot. Punkt jest taki: jeśli dostajemy 214 takich rzeczy dziennie, to przy cyklu „pełny dzień” mamy równowartość 200 dni pracy zamiast 200 godzin — i to przestaje dać się udźwignąć. Tak właśnie produkt wygląda dziś lepiej niż miesiąc temu.
Widzieliście pewnie wpis Lauren o tym, jak wdraża dwa tysiące dobrych PR-ów — myślę, że po publikacji było jeszcze więcej. To staje się możliwe dlatego, że gdy raz stworzysz takiego bota i otoczysz go właściwymi barierami, możesz pomnożyć siebie wiele razy i odpalić wiele takich wątków równolegle.
Pakowanie osądu w bota
Wielka idea przy skalowaniu organizacji inżynierskiej: trzeba umieć wyrazić część „osądową” pracy. Na przykład: jak odtwarzamy błędy? Czym jest „gotowe”? To rzeczy, które wszyscy robimy od zawsze — inżynierowie i nie tylko. Teraz można je zapakować w rodzaj specjalisty: umiejętność wykonywania danej pracy, kontekst, trochę pamięci i bariery. A potem uruchamiać to wielowątkowo, w wielu kanałach naraz.
Od 2× do 10×: krzywa produktywności
Jeśli bywaliście na innych naszych rozmowach, znacie tę krzywą — pokazuje koncepcyjnie, jak rośnie produktywność. Sedno: nawet mając AI w edytorze i popychając agentów do przodu, zostajesz przy modelu, w którym człowiek napędza każdą jednostkę pracy. Różnica jest taka, że John mógł spać, zanim ktokolwiek się odezwał — a agent był już rozbudzony i gotowy wykonać pierwsze podejście. To właśnie pozwala przejść z zysku rzędu 2× na 5× i 10×: automatyzujesz coraz bardziej złożone zadania dzięki takiemu „opakowaniu”. Przestajesz automatyzować pojedyncze zadanie — jak ów bot zespołowy — a zaczynasz wręcz obsadzać stanowisko: „zatrudniasz” inżyniera, który umie odtworzyć problem, napisać do Ciebie na Slacku i dopytać, jeśli ma wątpliwości. Widzieliśmy też wartości znacznie wyższe niż na tej krzywej.
Krzywa dojrzałości: od eksploracji do kodu
Nie da się z dnia na dzień wypuścić w świat tysięcy agentów i zaufać im przy naprawdę złożonych zadaniach. Zaufanie buduje się etapami. Podkradłem ten slajd od Lauren — podoba mi się jej zdanie: „Powinnaś być bardziej ambitna”. Bo faktycznie: ludzie odpalają pięciu, dziesięciu agentów; ktoś na czacie napisał, że ma stu — i pewnie używa podobnych technik.
Naturalna droga wygląda tak: zaczynasz eksploracyjnie. Grok Bot zmienił to, że możesz dać botowi wskazówki i zarazem trochę samodzielności — pokażę, co to znaczy: ma własny komputer, własną przeglądarkę, własne połączenia. To etap na pierwsze jeden–pięć agentów. Potem — niedawno to wydaliśmy — boty zespołowe, czyli faza współdzielenia. Z dziesięciu stworzonych botów wybierasz ten, który Twoim zdaniem przyda się całemu zespołowi. U nas na przykład John-projectant mógłby w przyszłości przywołać tego bota zespołowego i przeprowadzić dokładnie taki wątek — być może bez udziału inżyniera, zależnie od jakości oprzyrządowania i wewnętrznych praktyk. To przenosi Cię w okolice dziesięciu–dwudziestu agentów.
I jeszcze jedna warstwa: cała platforma jest ułożona piętrowo. Grok Boty mają dostęp do agentów chmurowych, a agenci chmurowi do kolejnych możliwości. Mamy coś, co nazywa się BDK — Bot Development Kit, zestaw do budowy botów (dokumentacja trafi na czat). BDK pozwala wziąć to, co zrobiłeś w botach, i — gdy dojdziesz do etapu, na którym chcesz to zamienić w kod — odtworzyć przepływ eksploracyjnego Grok Bota w kodzie. Ewaluacje dostajesz w pakiecie. To bywa bardzo pomocne.
Zoe: Ciekawe pytanie: skoro Grok Boty mają długożyjący kontekst, co najlepiej działa, żeby faktycznie wykonywały zadania — jakie wejścia, narzędzia, umiejętności?
Ryan: Najzabawniejsze, że wciąż jest tu sporo roboty inżynierskiej. Zaleta Grok Bota: rozmawiasz z nim zwykłym językiem. Nie tworzysz pliku umiejętności wysyłanego na GitHuba — dzięki pamięci możesz po prostu mówić i w ten sposób dodawać bariery. Zaraz pokażę, jak tworzyłem dzisiejszy pokaz: kilka razy bot się pomylił, a ja mówiłem tylko „dodaj umiejętność, żeby to robić”, „dodaj umiejętność, żeby tamto”. I każde takie skorygowanie to czysty zysk: dzięki pamięci bot pamięta umiejętności i — co ciekawe — lepiej niż w kodzie wie, kiedy ich używać. W kodzie opisujesz umiejętność i model wybiera na podstawie opisu; tu jest po prostu znacznie lepszy w rozpoznawaniu, kiedy i jak z nich korzystać.
Interfejs: boty jako współpracownicy, nie rozmowy
Pokażę interfejs — pewnie pojawią się pytania. Zakładam, że większość Was go widziała, ale dla porządku krótki przegląd.
Mamy bota podstawowego. Potrafi być naprawdę proaktywny — to taki dyrygent, szef sztabu. Przy okazji, dla bywalców cyklu: poza Jarvisem, moim botem orkiestrującym, nazywam boty nudnie, po prostu od tego, co robią. Inni dają zabawne nazwy i generują ikonki — bawcie się, jak chcecie.
Trochę rzeczy przygotowałem wcześniej, ale najwięcej chcę pokazać, jak działamy z tymi botami na Slacku i czym różnią się poszczególne ich rodzaje. Bota podstawowego pierwsze pytanie brzmi: „Jestem Twoim asystentem, pomogę Ci w pracy — jak mam Cię nazywać?”. I po prostu rozmawia. Powiedziałem: „Najpierw połącz mnie z GitHubem” — i to wszystko, co z tym botem zrobiłem.
Ważna rzecz: to, na co patrzycie, to nie pojedyncze rozmowy, jak w narzędziach do kodowania. To byty. Żyją długo, mają swoje zajęcie, potrafią scalać wiele PR-ów — można o nich myśleć jak o współpracownikach. Mają własne dane i potrafią ustalać rutyny: mogę powiedzieć „w każdy poniedziałek o 8:00 chcę podsumowanie zeszłego tygodnia i tego, co mnie czeka”. Zwykły język — i każdego ranka to robi.
Przy okazji: to konto demonstracyjne. Jeśli starczy czasu, pokażę swoje prawdziwe — mam aplikację mobilną, którą od około dwóch miesięcy w pełni autonomicznie prowadzi zespół botów. Codziennie rano wrzucam je do rozmowy grupowej na daily: opowiadają, nad czym pracowały, jakie wymyśliły reklamy i publikują je na Instagramie — całą masę rzeczy. Boty potrafią też rozmawiać ze sobą; mają notatki i bibliotekę stron oraz plików, które same wytworzyły. A przede wszystkim: mają komputer. To przeglądarka w chmurze, którą mogę przejąć ja albo one — więc potrafią wszystko. Mogę nauczyć takiego bota grać w Wordle. Albo — co zrobimy w tym pokazie — przeglądać dashboardy w Grafanie.
Zoe: Pytań o interfejs brak. Grafana — śmiało.
Pokaz: kierowanie zgłoszeń i odtwarzanie błędów w Grafanie
Najpierw smaczek: prezentacja, którą właśnie oglądacie, jest w Figmie. Wziąłem bota, podłączyłem go do Figmy przez „połącz aplikacje” — a tam można sięgnąć po umiejętności stworzone przez kolegów, po Jirę, Grafanę, Notion, Slacka, Teams, Outlooka. Cokolwiek macie, boty da się do tego podpiąć — wtedy prośba o codzienne podsumowanie faktycznie da się spełnić.
Druga fajna rzecz: przy części próśb bot sam dorzuca diagramy, a można o nie też poprosić wprost. Poprosiłem o diagram repozytoriów Grafany. Grafana — dla nieznających — to biblioteka open source do wykresów. Wybrałem ją z dwóch powodów: kiedyś tam pracowałem i mam tam dobrych znajomych, no i dlatego, że to jeden z najczęstszych wczesnych przypadków użycia — i dla Grok Bota, i dla botów z BDK.
Grafana ma mnóstwo repozytoriów: metryki, logi, ślady — każdy interfejs w osobnym repo, a każda baza pod danym interfejsem w jeszcze innym. Gdy prowadzisz to wszystko jako open source, zgłoszenie może wpaść do dowolnego z nich. Albo wpada alert, który trzeba skierować do właściwego zespołu; albo PR do właściwego zespołu. I nawet ci, którzy już zaufali AI, mówią: „Ufam mojemu AI w ramach jednego repozytorium, ale jak to przeskalować na całą organizację? Mamy 800 repozytoriów. Dostaję prośbę na Slacku czy Teamsach — skąd moje AI ma wiedzieć, dokąd ją skierować?”. To bardzo częsty problem.
Więc stworzyłem nowego bota i nazwałem go po prostu botem od routingu, bo kieruje zgłoszenia. Pierwsze, co zrobiłem, to poprosiłem go, żeby pogadał z botem od prezentacji, wziął pełną listę repozytoriów objętych pokazem — i żeby to było jego zajęcie. Widzicie, że już działa: rozmawia z tamtym botem i ustala, co jest przestrzenią poszukiwań. Ciekawostka na poziomie meta: wie to, bo dałem mu tę prezentację, a slajdy z repozytoriami są właśnie w tej prezentacji.
Do routingu wrócimy później — to da się usystematyzować i pokażę, jak zrobić coś bardziej deterministycznego. Teraz coś mniej jednoznacznego: bot do odtwarzania problemów. Stworzyłem bota, który ma po prostu być dobry w reprodukowaniu zgłoszeń. Zapytał, co ma robić; opublikowałem go jako bota zespołowego (do tego wrócimy). Najpierw test: bez żadnych szczegółów, od zera — czy umiesz odtworzyć ten problem? Idzie i wyszukuje zgłoszenie. Powiedziałem: „Połączmy się z GitHubem” — okazało się, że połączenie było, ale chwilowo niedostępne. I tu ciekawostka: ponieważ bot ma własny komputer, poszedł na tę maszynę i w gruncie rzeczy powiedział: „chcę znaleźć to zgłoszenie i je odtworzyć”. Grafana hostuje publiczną wersję „play” swojej strony — i bot spróbował odtworzyć problem właśnie tam. Musiałem go skierować: „Nie, rób wszystko lokalnie” — i dodałem umiejętność, że w przyszłości wszystko ma robić lokalnie. To właśnie odpowiedź na pytanie o bariery: nie było sposobu, żeby wiedział, że ma zacząć lokalnie. Od tej pory nie będzie właził na publiczną stronę, tylko uruchomi kod u siebie.
Potem zaczyna działać lokalnie. Tu koncept, w który nie wejdziemy głęboko: ponieważ ma własny komputer, spróbował pobrać wszystkie pakiety i użyć moich poświadczeń GitHubowych, żeby zbudować projekt u siebie. Ale mamy coś takiego jak środowisko agenta chmurowego — przez Cursora. Dla Twojego repozytorium tworzymy takie środowisko, żeby przy każdym zadaniu nie startować od zera: zależności, zmienne środowiskowe, sekrety, połączenia MCP — wszystko gotowe, bez konfigurowania na żywo. To repozytorium już miało swoje środowisko, więc dodałem umiejętność, żeby z niego korzystał. Przewijam dalej — dotarł do końca i odtworzył problem. To prawdziwe zgłoszenie z repozytorium Grafany; naprawili je błyskawicznie, ale było i można je obejrzeć publicznie. Chodziło o to, że wielokropki utrudniały odczytanie nazw. I proszę: w reprodukcji widać te trzy kropki.
To startuje na eksploracyjnym końcu krzywej. Jeśli chcesz odtwarzać coś lokalnie, dla jednego repo — świetnie. A gdy chcesz rozszerzyć to na wszystkie repozytoria: klikam „udostępnij”, „udostępnij zespołowi” — i teraz, po dodaniu paru barier, bot awansuje z osobistego na zespołowy. Każdy w zespole, kto wejdzie, widzi zestaw botów; ja widzę boty stworzone przez kolegów. I wszyscy mają dostęp do odtwarzania zgłoszeń w tych ośmiu repozytoriach.
Kiedy Grok Bot, a kiedy BDK
Zoe: Wcześniejsze pytanie: skąd wiadomo, kiedy budować bota w Grok Bocie, a kiedy sięgnąć po BDK?
Ryan: Świetnie wypada jako przejście do następnej części. W fazie eksploracyjnej — jak tu, z prostą reprodukcją — Grok Bot wystarcza. Pracuję teraz nad zgłoszeniem w naszym głównym repo Grok Bota: aplikacja ma być odporniejsza na bardzo skomplikowane konfiguracje VPN. Odtworzenie tamtego zgłoszenia było proste — uruchom repo, pokaż. Żeby odtworzyć to VPN-owe, bot musi użyć swojej maszyny wirtualnej i znaleźć sposób na odtworzenie naprawdę złożonych konfiguracji sieciowych, żeby porządnie przetestować. W takim wypadku dajesz botowi trochę swobody — wszystko działa w odizolowanej piaskownicy, można dodać wszelkiego rodzaju ograniczenia „zasięgu rażenia”; mamy kontrole, więc jest zupełnie bezpiecznie. Bot sam ogarnia, jakie pakiety pobrać, żeby zasymulować określony rodzaj VPN-a. Tu Grok Bot ma sens, a udostępnienie zespołowi to to samo — po prostu każdy ma dostęp.
BDK wchodzi, gdy chcesz pójść dalej. Oddalmy się na chwilę: w przykładzie z początku mamy tak naprawdę dwa rodzaje botów. Sandy to agent od sortowania zgłoszeń — dlatego routing zostawiłem na później, bo to klasyczne zadanie dla BDK; a bot zespołowy Johna jest zbudowany w Grok Bocie, bo w tej funkcji nieustannie pojawiają się nowe rzeczy i bot potrzebuje elastyczności. Bot Sandy jest bardzo sztywny: odpowiada na każde pojedyncze zgłoszenie, to pierwsza linia kontaktu, która mówi, co się stało. Tam potrzebujemy determinizmu i weryfikowalności — czyli ewaluacji. Przy bardzo dużej skali zaczynamy się zastanawiać choćby nad tym, na którym modelu to uruchomić. Pokażę, jak wygląda wersja w kodzie. Przewidywalne koszty? Oba podejścia to dają — ale BDK rozwijasz lokalnie, w kodzie. I dla czegoś, co wymaga routingu, możesz zbudować zestaw ewaluacji sprawdzających: czy to zawsze trafi we właściwe miejsce?
Pokażę oba obok siebie. Oto kolejne repozytorium-testowy Slack. Tego bota zespołowego, którego stworzyłem wcześniej, mogę teraz poprosić, żeby napisał na kanale; ponieważ został dodany do Slacka, wchodzi i komunikuje: „odtworzyłem zgłoszenie”, komentuje — i reprodukcję widać na Slacku. Wersja BDK: sklonowałem dokładnie to samo, reprodukcja nadal jest, ale ten bot żyje w kodzie. A kod wygląda niemal jak Ruby on Rails — tylko że to „boty na szynach”. W standardzie dostajesz całą gamę elementów: narzędzia, umiejętności, połączenia MCP, połączenia do hostów, subagenty, kanały, hooki — wszystko to ograniczasz do konkretnego bota, a ewaluacje masz w komplecie. Dzięki temu masz pewność, że umiejętności dodane do tego bota dotyczą tylko jego.
Nie wiem, czy nie zagmatwałem — w skrócie: czysta determinizm albo ewaluacje → BDK zamiast Grok Bota. Bo w tym wątku dzieją się dwie rzeczy naraz. Wpadło zgłoszenie: „nazwy usług ucięte — czy Pyroscope gubi część nazwy?”. Pierwszy bot klasyfikuje, czy to błąd, i — co ważne — podaje procenty swojej decyzji: mniej więcej 73% szans, że to repozytorium A, 27%, że B, zero reszty. I choć mam obok bota do reprodukcji, ta wersja jest znacznie lepsza, gdy w scenariuszu incydentu chcesz zrozumieć, dlaczego coś poszło akurat tam. A żeby naprawić na przyszłość: wchodzisz w to repozytorium w kodzie, choćby w same instrukcje, piszesz kod, który lepiej steruje botem, i wdrażasz nową wersję — a wszystko ląduje w panelu: logi, metryki, ślady, obserwowalność i odpowiedź na pytanie, dlaczego agenci podejmowali te, a nie inne decyzje.
Co do ewaluacji: to właśnie zrobiłem. Kazałem Grok Botowi przejść po wszystkich tych repozytoriach i wziąć tytuł zgłoszenia z jednego z nich — a skoro pochodzi z danego repo, znana jest prawidłowa odpowiedź. Z tego zbudowałem zestaw testów sprawdzających, czy przy danym promptcie systemowym bot kieruje poprawnie. Możesz tych przypadków zrobić dziesięć, sto, tysiąc. I zauważcie: to znowu dwa boty BDK w jednym wątku, rozmawiające ze sobą — jeden od routingu, drugi od reprodukcji. W ten sposób łączysz agentów w łańcuch: jeden kieruje, drugi odtwarza, a można zejść jeszcze niżej — do bota wyspecjalizowanego w odtwarzaniu zgłoszeń jednego konkretnego repozytorium. Zależnie od organizacji potrzeby bywają inne dla aplikacji na iOS niż dla backendu. Da się to zawężać i optymalizować na różnych poziomach.
Zoe: Pytanie z czatu: gdzie jest ten panel?
Ryan: Zaraz pokażę — to instancja demonstracyjna, więc sprawdzę, co mogę pokazać. Panel, wdrożeni agenci… to powinno być w porządku. Te boty możesz uruchamiać lokalnie — to też widok z mojego terminala. Dla tego repozytorium wpisuję npm run eval; odpala całą serię testów wyglądającą niemal jak zwykły zestaw testów — sprawdza, dokąd wszystko zostało skierowane. U mnie: 48 na 50 zaliczonych. Wygląda na to, że parę rzeczy muszę poprawić. A gdy skończysz, komenda będzie w stylu bdk deploy plus nazwa bota. Po wdrożeniu bot pojawia się w oknie Cursora, w sekcji wdrożonych agentów. Klikasz i widzisz: ile miał sesji, jakie konektory MCP, jakie logi, kto wdrożył ostatnio — tu bieżące wdrożenie od Aniny. Gdyby ktoś zmienił kod i wdrożył ponownie albo gdyby to siedziało w Waszym pipeline CI/CD, wszystko zobaczycie właśnie tutaj.
Można też otworzyć pojedynczą sesję. Nie wiem, czy to prawdziwe dane, ale zobaczycie na przykład ślad danego uruchomienia: użytkownik zainicjował, bot myślał, asystent pomagał, te wywołania narzędzi itd. — i nawet rozmowę tego agenta. U korzenia BDK siedzą nasi agenci chmurowi i — technicznie rzecz biorąc — SDK Cursora; całe wnioskowanie stopniowo znika pod warstwami abstrakcji, aż do momentu, w którym możesz wejść i — teraz jest to tryb tylko do podglądu, ale lokalnie — porozmawiać z agentem: „jak poprawiłbyś siebie w przyszłości?”. I zobaczyć surowe dane.
Dlaczego nie zwykłe API
Wracając do slajdu — ludziom, którym to pokazywałem, bardzo pomaga on zrozumieć, czemu wartość BDK jest taka nieoczywista. Wszystko to da się zrobić na surowych API: weź API Groka albo Claude’a i teoretycznie połącz w łańcuch. Tylko że po Twojej stronie przybywa wtedy mnóstwo „hydrauliki” do skręcenia. Chcesz przepływ: wzbogać zgłoszenie w Jirze, ustal właścicieli, otwórz PR, wrzuć wynik CI do Jiry. Nawet na zwykłych automatyzacjach Cursora musisz wyjście jednego kroku podać jako wejście następnego, potem kolejnego. Chcesz człowieka w procesie? Musisz to wpleść pośrednio. W BDK mówisz wprost: „Bocie, jesteś bytem — czekaj tutaj dzień, tydzień, ile trzeba, aż ktoś potwierdzi, i wtedy idź dalej z kolejnymi krokami”. Do tego sam musiałbyś zarządzać sekretami i poświadczeniami — a tu wdrażasz prosto na Slacka; jeszcze jedna komenda w stylu bdk slack add i bot jest w Waszym Slacku albo Teamsach.
Czyli: pełna definicja przepływu pracy. Na surowych API, sklejone w łańcuch, dojdziecie do etapu 5×. Ale gdy zaczynasz korzystać z BDK i Grok Botów, gdy agenci BDK rozmawiają ze sobą i współpracują — wchodzisz w fazę „obsadzania stanowisk”, w której wiele rzeczy dzieje się równolegle.
Pamięć botów
Zoe: Kilka pytań o trwałą pamięć w Grok Bocie — jak do tego podchodzicie?
Ryan: Nie warto dziś wchodzić zbyt głęboko, ale zrobiliśmy w tle bardzo dużo, żeby boty miały system zarządzania pamięcią, z którego potrafią korzystać. Osobiście nie natrafiłem na żaden problem — a używam ich bardzo dużo — ani z kontekstem, ani z zarządzaniem nim.
Zoe: I to jest jedna z zalet Grok Bota: wszystko jest wbudowane. Mało nad tym pracujemy, bo bot sam utrzymuje własne wspomnienia i umiejętności — pamięta, nad czym wcześniej pracowaliśmy i jak wykonywać zadania sprawnie i skutecznie.
Podsumowanie ścieżki
Ryan: Podsumowując: tę krzywą przechodzi się tak — zaczynasz eksploracyjnie, testujesz Grok Bota lokalnie i doprowadzasz do tego, żeby robił to, czego chcesz. Gdy robi coś wartościowego, co Twoim zdaniem przyda się zespołowi, rozszerzasz go na bota zespołowego. A dalej — jak Ci wystarcza, to wystarcza. Mamy mnóstwo osób, które zostają na etapie botów zespołowych; z odpowiednimi barierami da się utrzymywać nawet setki i tysiące takich botów. Dla szczególnych zadań możesz pójść krok dalej: usystematyzować, zamienić w kod, dodać weryfikację i wersjonowanie.
Na koniec kilka zwycięstw z różnych obszarów: pokazałem, jak wziąć duże repozytorium, skierować zgłoszenie we właściwe miejsce, użyć botów zespołowych i agentów chmurowych, żeby włączyć agenta do pracy — przebudowywać, przekierowywać, pokazywać efekt — a w razie potrzeby sięgnąć po BDK do zadań bardziej deterministycznych, objętych ewaluacjami. Widzimy to w wielu branżach: „inżynieria” wygląda zupełnie inaczej w rekrutacji, w travel techu i w telekomie. Kazałem mojemu Grok Botowi przejrzeć nasze notatki, zanonimizować je i wyłuskać sukcesy: przejmowanie przekazań, które kiedyś były liniową sztafetą, i zastępowanie ich botami zespołowymi wraz z ich zdolnością do wywoływania agentów chmurowych i pisania kodu — czyli do znacznie bardziej wyrafinowanych rzeczy. Statystyki: usprawnione procesy, zaoszczędzony czas i pieniądze — i po prostu łatwiejsze życie.
Więc: wypróbujcie to w piątek albo w poniedziałek. Poszperajcie w Grok Botach i zobaczcie, co się da — a jeśli robicie coś regularnie, co może być potrzebne całemu zespołowi, spróbujcie zamienić to w bota. Namów kolegów, żeby go używali i pomagali Wam go rozwijać. Z doświadczenia: gdy ludzie dochodzą do tej fazy — czy to z botem, który deleguje pisanie kodu, czy z takim, który nie — właśnie tam wyciągają większość tej wartości: usprawnione systemy i łatwiejsze życie. A przyjemnie jest zobaczyć, jak wszyscy korzystają z bota, który dobrze zbudowałeś. To naprawdę ładny cykl. Potem, jeśli chcesz, przerabiasz go na agenta BDK. To wszystko, co mam.
Pytania końcowe
Zoe: Dzięki, Ryan! Częsty wątek: wskazówki dotyczące barier i bezpieczeństwa — bardzo na czasie u klientów korporacyjnych.
Ryan: Dobre pytanie. To jeden z obszarów, nad którymi jako organizacja ciągle pracujemy. W ustawieniach jest zakładka Grok Bota — a w niej cała masa opcji: wykonywanie operacji na lokalnym komputerze, udostępnianie szablonów, bardzo dużo kontroli nad kierunkiem i ruchem wychodzącym. Mnóstwo da się tu ustawić — może zacznij od listy dozwolonych adresów i stopniowo ją rozszerzaj, albo od listy dozwolonych konektorów MCP. Dokumentację wrzucimy na czat. Polecam po prostu przejść przez te ustawienia — może nawet z pomocą samego Grok Bota — i dopasować je do standardów bezpieczeństwa obowiązujących w Waszej firmie.
Zoe: I ładne na koniec: jaki najłatwiejszy pierwszy krok w BDK?
Ryan: Linki są na czacie. Moją pierwszą rzeczą w BDK był agent do review PR-ów. Waham się to mówić, bo mamy też Bug Bota, który jest — ogólnie rzecz biorąc — lepszy od większości agentów do review PR-ów. Ale to świetny pierwszy bot: bardzo dobrze zdefiniowane zadanie i od razu widać, jak wszystkie te pojęcia przekładają się na elementy BDK. Dokumentacja jest pod ścieżką „docs/BDK” — znajdziesz tam mapowanie koncepcji na poszczególne kawałki. To potrafi się robić bardzo zaawansowane; polecam zacząć od botów zespołowych i zobaczyć, dokąd Was zaprowadzą. U nas chyba 90% botów to boty zespołowe, boty BDK robimy okazjonalnie — choć własny produkt chętnie testujemy na sobie, i to dużo.
Zoe: I ostatnie, fajniejsze pytanie: najciekawsze, najbardziej kreatywne użycie Grok Bota, jakie widziałeś? Ktoś pytał o przypadek, w którym myśli się o setkach botów.
Ryan: Muszę się zastanowić… Ponieważ boty mają własną maszynę, można — technicznie — zainstalować Grok Bota na maszynie Grok Bota. Jak w „Incepcji”. Nie wiem, po co im to było potrzebne, ale uznałem, że dość ciekawe. A tak — już wcześniej o tym zasygnalizowałem — pokażę szybko moich botów na porannym daily. Stworzyłem grę mobilną, Rankum. Codziennie rano o 3:56, zanim wstanę, robią odprawkę. Widać, że wydają pieniądze i kręcą reklamy na Instagramie. Jest agent od analityki, agent od łatania błędów, tester, inżynier od retencji — i wszyscy razem tworzą tę grę. Jestem już chyba gdzieś koło dziesięciu tysięcy pobrań. Mam tu przykład tworzenia reklam na Instagram: ja w tym nie uczestniczyłem. Sam ogarnął Remotion, oczywiście poprosił mnie o wgranie danych do Facebooka — i robi to wszystko na własną rękę, bo ustawiłem pętlę: „oto mój koszt instalacji, zrób tak, żeby był niższy”. Dajesz im cel i pętlę informacji zwrotnej — a one sobie radzą.
Zoe: Usłyszeliście to tutaj pierwsi: pobierajcie Rankum i patrzcie, jak radzą sobie boty Ryana.
Ryan: A każde zgłoszenie w App Store obsłuży mi bot, który automatycznie tworzy do niego PR.
Ryan: A Ty? Widziałaś coś kreatywnego w tę ostatnią minutę?
Zoe: Nie tak kreatywnego jak Twój system. Dużo myślę ostatnio o pętlach informacji zwrotnej. Mam boty, które pomagają mi między innymi robić review własnej pracy — nawet przeglądają rozmowy, w których uczestniczę, i dają mi feedback, żebym w przyszłości była lepsza. Chcę używać Grok Bota do tego, żeby być lepsza w tym, co robię na co dzień. Ale to dużo prostsze niż pełen zespół rozwijający aplikację.
Ryan: Na razie. (śmiech) No i to tyle — dzięki za słuchanie i za udział, na czacie było mnóstwo dobrych pytań. Odezwijcie się, komentujcie na X — chętnie pomóżemy Wam w Waszej podróży z Grok Botem.
Zoe: Dziękuję wszystkim! Do usłyszenia.