O czym jest ten film
- Jack Dorsey (współtwórca Twittera i Blocka) wypuścił Buzz — komunikator opisywany jako „zabójca Slacka”, w którym agenci AI są pełnoprawnymi członkami zespołu.
- Kluczowa cecha to otwartość: Buzz jest open source i zbudowany na otwartym protokole Nostr.
- Harness pod każdym agentem jest wymienny (Claude Code, Codex, Goose, open code) — a cały kontekst rozmów przechodzi razem z przełączeniem modelu.
- Audio huddle z agentami — rozmowa głosowa na żywo, w której agent zna kontekst całego czatu.
- Głęboka integracja z Gitem: agenci pracują w równoległych work tree, tworzą projekty, wdrażają aplikacje na żywo i odsyłają zrzuty ekranu.
- Buzz działa na „relayach” (serwerach hostowanych samodzielnie lub przez Block) i ma własny hosting Git — celuje więc nie tylko w Slacka, ale i w GitHuba.
- Zamknięta pętla kontekstu: dane z własnych aplikacji wracają przez API do czatu i zasilają agentów.
- Współdzielony compute — lokalne modele uruchamiane na jednej maszynie i udostępniane całemu zespołowi; w planach płatności w Bitcoin Lightning.
- To wciąż oprogramowanie na wczesnym etapie (alfa/beta): bywa wolne, a workflowy i zadania cykliczne nie zawsze działają.
- Werdykt: warto próbować takich narzędzi, żeby uczyć się przyszłości pracy — nawet jeśli ostatecznie zostaniesz przy Slacku.
Redakcyjne tłumaczenie
Wstęp: „zabójca Slacka” od Jacka Dorseya
Greg Isenberg: Jack Dorsey właśnie wypuścił Buzz i produkt kompletnie zawojował sieć. Tak, to ten sam Jack Dorsey, który współtworzył Twittera i Blocka. Buduje coś, co ludzie nazywają „zabójcą Slacka”. Dlaczego to ma dla ciebie znaczenie? Nazywają go zabójcą Slacka, bo to trochę agentowa wersja Slacka. Możesz prowadzić rozmowy ze współpracownikami — tyle że są nimi agenci. Możesz „wciągnąć” agentów do huddle’a. Możesz sprawić, by software powstawał na bieżąco, poprzez agentów.
W tym odcinku rozłożymy to na czynniki pierwsze — żebyś zrozumiał, czym jest Buzz, po co go używać i jakie są najlepsze triki. Moja teza jest taka: to zapowiedź przyszłości pracy. Do końca odcinka będziesz wiedział, czy to coś dla ciebie i jak z tego korzystać.
(Informacja dodatkowa: gościem rozmowy jest współtwórca firmy Wasp — dostawcy full-stackowego frameworka deweloperskiego. W automatycznym transkrypcie jego imię pojawia się w kilku wariantach; poniżej używamy „Vinnie”).
Vinnie: Ludzie nauczą się, jak używać Buzza. Moim zdaniem jego najlepszy punkt zastosowania to teraz solopreneurzy i małe zespoły. Nauczą się, jak z jego pomocą burzyć mózgi, trzymać spójny kontekst między agentami, budować produkty i rozwiązania, ideować — i po prostu szybciej wypuszczać rzeczy w świat oraz być bardziej produktywnym.
Greg: Chcę z tego wynieść zrozumienie, czym Buzz jest, dlaczego to ważne i jakie są dobre praktyki, żeby faktycznie kazać agentom coś dla mnie robić. Na koniec chcę wiedzieć, czy powinienem tego używać — czy po prostu zostać przy Slacku. I podziel się przy okazji najlepszymi praktykami, których nigdzie jeszcze nie było, żebyśmy mieli przewagę.
Otwartość jako główny argument
Vinnie: Zacznę od tego, że „zabójca Slacka” to dobra fraza, ale dla mnie prawdziwym atutem Buzza od samego początku jest jego otwartość.
Po pierwsze: to Slack z agentami w środku. Wielu ludziom to przypomina Slacka — tam też masz agentów, ale przez integracje. W Buzzie agenci są pełnoprawnymi obywatelami: to członkowie twojego zespołu, a nie dodatek czy funkcja z boku. To integralna część aplikacji.
Domyślnie dostajesz zestaw gotowych agentów, ale pod spodem kryje się coś naprawdę mocnego — możesz je edytować i dodawać nowe. Kiedy dajesz agentowi instrukcje, to w praktyce jak system prompt. Najfajniejsza rzecz pod spodem to harness. Wszyscy pewnie używamy Codeksa, Claude Code, może czegoś w rodzaju open code do kodowania i pracy. Tutaj harness pod każdym agentem jest wymienny. Mogę wejść i powiedzieć: chcę Claude Code, chcę Codeksa, chcę Goose’a. Już samo to było dla mnie momentem „okej, to jest bardzo fajne”.
Dlaczego to takie ważne? AI pędzi w zawrotnym tempie — dziś jest ten model, jutro tamten. Osobiście dopada mnie zmęczenie modelami: właśnie się do czegoś przyzwyczaiłem i nie chcę nawet słyszeć o modelu X, bo wciąż siedzę na modelu Y. A tu masz warstwę ponad tym wszystkim i możesz się przełączać — i co najlepsze, nic nie tracisz w tym procesie. Zmieniasz harness pod agentem, a cały kontekst z czatów, wszystko, o czym rozmawialiście, aplikacje, które budujesz — to wszystko przechodzi razem do nowego harnessu i nowego modelu.
Greg: To ogromna sprawa, bo wielu z nas odbija się jak piłeczka między modelami i harnessami, a to męczące, kiedy zaczynasz od zera. Do tego musisz jeszcze rozumieć, w czym dany model jest dobry i jaki kontekst mu dać. Fakt, że jest to wbudowane natywnie w produkt, mówi mi, że twórcy myślą o tym, jak ludzie dziś pracują — przyznają, że modele wciąż będą się zmieniać, ale ty nie chcesz tracić czasu na dodawanie kontekstu od nowa, bo próbujesz prowadzić startup i zarabiać.
Vinnie: Dokładnie. I możesz zabrać ze sobą wszystko. Jeśli zbudowałeś umiejętności (skills), pliki i foldery, to o ile są w katalogu globalnym i dostępne globalnie, a nie przypięte do konkretnego projektu, Buzz ma do nich dostęp. Instalujesz umiejętności agentów normalnie, zmieniasz harnessy i modele, a twoi agenci w czacie mają do wszystkiego dostęp.
Głosowe huddle z agentami
Vinnie: Mamy audio huddle z agentem. Możesz prowadzić rozmowę głosową z agentami — są w czacie, odpowiadają, więc możesz zadzwonić do kogoś, wciągnąć agenta i się komunikować, a on dostaje kontekst całego czatu. Sam jeszcze tego nie testowałem, ale na YouTube są dobre filmy, które to pokazują.
Greg: Tweetowałem o tym. To, czego mi brakuje w budowaniu w erze AI, to poczucie, że tylko każę agentom coś robić — czy to przez WhisperFlow, czy pisząc. To ciągłe „w tę i we w tę”. Fajne w huddle’ach jest to, że są na żywo. Kiedy jestem w trybie kreatywnym, potrzebuję interakcji na żywo, żeby naprawdę wydobyć to, co dzieje się w mojej głowie. Pewnie jest wielu ludzi takich jak ja. Moim marzeniem — też o tym tweetowałem — jest móc kiedyś „faceteimować” z agentami. To dla mnie święty Graal przyszłości pracy. Fajnie, że Buzz zaczyna to ruszać. Czy jest dobre — trzeba przetestować; widzowie, dajcie znać w komentarzach.
Integracja z Gitem i budowanie aplikacji na żywo
Vinnie: Tuż pod powierzchnią masz agentów i pewnie chcesz, żeby wykonywali pracę. Git jest dość ściśle zintegrowany. Kiedy agenci kodują, tworzą projekty, zakładają gałęzie funkcyjne (feature branches) i pracują w równoległych work tree. Dzięki temu nie grzebią bezpośrednio w tym, co masz lokalnie na komputerze — robią kopię w work tree i tam działają. Mogą więc pracować równolegle. Rozmawiasz z kolegą z zespołu o UI albo designie strony i po prostu mówisz agentowi: „postaw trzy różne wersje landing page’y na bazie pomysłów, o których gadaliśmy”.
Dodali też widok projektów — w ustawieniach są eksperymenty, gdzie włączasz workflowy i projekty. To w praktyce twoje aplikacje, które kodujesz razem z agentami. Możesz integrować się z GitHubem, ale pod spodem mają własny hosting Gita. Możesz pushować do zdalnych repozytoriów, które faktycznie leżą na twoim relayu.
(Informacja dodatkowa: „relay” to termin z protokołu Nostr — serwer pośredniczący, który przechowuje i przekazuje wiadomości. W Buzzie relay jest miejscem, gdzie żyją twoje czaty, dane i kod).
Buzz działa na relayach — serwerach, które hostujesz sam albo które hostuje dla ciebie Buzz/Block. Kod trafia do zdalnych repozytoriów na twoim relayu. Widać, że próbują wziąć na cel coś więcej niż Slacka — celują też w GitHuba.
Greg: Dla nietechnicznej publiczności: mam wrażenie, że w erze AI nawet moi nietechniczni znajomi zaczynają używać GitHuba. Pięć czy dziesięć lat temu, jeśli byłeś nietechniczny, ledwo wiedziałeś, co to GitHub — słowo „repo” kojarzyło się z odbieraniem samochodu. Teraz, gdy wszyscy jesteśmy w jakimś sensie techniczni, coś takiego wbudowanego natywnie ma dużo sensu.
Vinnie: Ciekawe jest to, że nie musisz o tym wiele wiedzieć — agenci ogarniają to za ciebie. Prosiłem: „postaw prosty CRM w full-stackowym frameworku Wasp i wdroż go na Railway”. Jest tu trochę wiedzy technicznej — wskazuję konkretny framework i hosting — ale on to zrobił: wypchnął do zdalnych repozytoriów, wdrożył na żywo w sieci, a nawet przysłał zrzuty ekranu. „O, tu masz swój CRM”. I to wszystko, zanim jeszcze zajrzałem, co robi. Zrobił to za mnie, dał linki i podgląd.
Greg: To szaleństwo. Trochę to bagatelizujemy, a spójrz, co zbudowaliśmy — i to już jest na żywo w internecie.
Vinnie: Miałem już konto na Railway i trochę znam się na full-stacku, ale niewiele mu powiedziałem — po prostu „wrzuć to online”. Teraz mam w pełni działający dashboard CRM, którym mogę się podzielić z zespołem. Potem dodajesz ich do czatu, rozmawiacie o brakujących funkcjach, o tym, co się nie podoba, dochodzicie do wniosków i mówisz agentom: „róbcie” — i oni to robią.
Greg: Dlaczego to duża sprawa: potrafisz tworzyć software na bieżąco, w praktyce zautomatyzowany, wysokiej jakości, gotowy do wdrożenia, którym da się zarządzać w czytelnym widoku. Pomyśl o swoim biznesie — powiedzmy, prowadzisz agencję, a oferty są jej krwiobiegiem. Wyobraź sobie, że tworzysz oferty na bazie danych klienta: pitchujesz NFL, wrzucasz kontekst — notatki ze spotkania z Granoli albo skądkolwiek — a agenci na tej podstawie generują oferty unikalne dla danego klienta. Masz kontekst z jednej strony, wiesz, jak wchodzi, jak zostaje postawiony w sieci i jak to obejrzysz.
(Informacja dodatkowa: Granola to popularne narzędzie do automatycznego notowania ze spotkań).
Zamknięta pętla kontekstu: dane z aplikacji zasilają agentów
Vinnie: Dokładnie. W jednym z filmów, które wrzuciłem na Twittera, robiłem to samo, tyle że od strony marketingu. Zbudowałem tablicę wyników tweetów dla mojego zespołu — ile tweetujemy, jakie są nasze najlepsze tweety. Wszystkie te dane zbierała ta full-stackowa aplikacja. Potem pomyślałem: zamiast tylko budować to w Buzzie, niech Buzz również sięga do tej aplikacji, pobiera informacje, a my dostajemy dzienne przeglądy i digesty i burzymy mózgi nad tym, co w naszej strategii na Twitterze działa, a co nie.
Powiedziałem mu: „zbudujmy publiczne API i workflow”. Codziennie sprawdza to API i odsyła liczby. Efekt widać w kanale ze statystykami tweetów — dane płyną z dashboardu przez API na zewnątrz i lądują w kanale. Potem odpowiadam agentowi (jednym z nich jest Fizz): „Fizz, powiedz mi, co łączy moje udane tweety z ostatnich siedmiu dni”. To jest ta okrężna pętla — wrzucasz informacje, wyciągasz je przez aplikacje, a wszystko wpada w kontekst twoich agentów.
Greg: To mnie interesuje, bo to ta „nudna robota”, którą ma każdy biznes — a jeśli zdobędziesz tu nieuczciwą przewagę, to właśnie ona oddziela dobry biznes od słabego.
Vinnie: I to właśnie lubię w otwartości Buzza — takie integracje robi się bardzo łatwo. W Slacku, żeby to wszystko postawić, potrzebowałbyś tokenów API, tworzenia aplikacji na ich platformie, wszystko jest zamknięte i musisz nauczyć się ich struktury. Tu, bo zbudowano to na otwartych protokołach, uruchamiasz takie rzeczy naprawdę łatwo i masz szalony silnik kontekstu, który pomaga ci pracować. Gdybym chciał, mógłbym poprosić Fizza: „podłącz się do API X, żebyśmy mogli tweetować prosto z Buzza” — pewnie zrobilibyśmy to w 15 minut.
Kiedyś robiłem to w sesji z Claude Code albo ChatGPT — dosłownie eksportowałem czy kopiowałem dane tweetów i wklejałem do ChatuGPT w przeglądarce. Tu jest to super, bo pobiera informacje z API X, trzyma je w oknie kontekstu agentów, mogę o tym rozmawiać, a potem z kolegami zastanawiać się nad kolejnymi tweetami i innymi kątami marketingowymi.
Widać też agenta przy pracy — jeśli lubisz podglądać takie rzeczy w terminalu, tu widzisz wywołania narzędzi. Pobiera informacje z kanałów, sprawdza nowsze statystyki, dostaje wynik. To dzieje się „za kurtyną”, ale zaraz powinniśmy dostać odpowiedź.
Jak rozmawiać z agentami
Greg: Są jakieś wskazówki, jak najlepiej do nich mówić? Widzę, że napisałeś krótkie, zwięzłe pytanie.
Vinnie: Dziś są całkiem dobrzy w wyłapywaniu intencji za pytaniem, więc po prostu rozmawiaj z nimi jak z normalną osobą. Nie mam żadnego specjalnego podejścia. To, co widzisz, jest ładniejsze niż to, co zwykle piszę — normalnie mam literówki i piszę „daj mi ten sos”, a oni i tak sobie radzą, bo mają cały ten kontekst. Jestem raczej bezpośredni i zwięzły w promptach.
Jest odpowiedź. Pokazuje, co zrobiłem: „Wypróbowałem Buzz Jacka. Wdrożyłem open SaaS na OpenShift. Po raz pierwszy udało mi się self-hostować”. Raportuję jako początkujący, co się udało. Zadziałało — moje dwa najlepsze tweety zebrały ponad milion wyświetleń, a te słabsze były w dolnej połowie, łącznie jakieś 88 tysięcy. Wniosek: „nowość daje zasięg, tarcie daje zaangażowanie”. To naprawdę niezła rada — i to jest moc trzymania tego wszystkiego w Buzzie: takie rzeczy stają się proste i odkrywcze.
Otwarty protokół i płatności w Bitcoinie
Greg: Przy okazji — pojawiła się opinia, że nikt nie wspomina, że Buzz ma „tylne drzwi” do natywnych płatności w Bitcoinie. Co to znaczy?
Vinnie: Buzz jest zbudowany na otwartym protokole — trochę to przemilczałem. Nazywa się Nostr. Znając Jacka Dorseya, wielkiego fana Bitcoina — Nostr jest ściśle sprzężony z Bitcoin Lightning, bardzo szybkim i niemal bezprowizyjnym sposobem płacenia i przesyłania Bitcoina. Moje przypuszczenie: skoro Buzz stoi na otwartym Nostrze, będzie można zintegrować płatności w Bitcoin Lightning. Albo agenci będą płacić za compute — ten pomysł współdzielonej mocy, o którym mówiliśmy — albo ludzie będą płacić i „napiwkować” innych za wykonane zadania.
Wyobrażam sobie dużą, otwartą społeczność — nie wiem, czemu ciągle wracam do grafików — powiedzmy projektantów. Potrzebujesz świetnego logo, a generatory obrazów AI tego nie dają. Prosisz ludzi o pomysły, ktoś ze społeczności graficznej na Buzzie podrzuca ci genialne logo, a ty dajesz mu napiwek: „dzięki za pomysł” i pracujesz dalej. Na razie tego nie ma, ale myślę, że przyjdzie.
(Informacja dodatkowa: Nostr — „Notes and Other Stuff Transmitted by Relays” — to zdecentralizowany, otwarty protokół komunikacyjny. Lightning Network to warstwa nad Bitcoinem umożliwiająca szybkie mikropłatności o niskich opłatach).
Współdzielony compute i lokalne modele
Vinnie: Wspomniałeś o współdzielonym compute — to wraca do otwartości Buzza i naprawdę mnie zaskoczyło. Jest ustawienie compute, które włączasz, a ono automatycznie proponuje lokalne modele LLM do pobrania na twój komputer — i możesz je dosłownie współdzielić z resztą zespołu.
Powiedzmy, że dopiero zaczynasz — jesteś studentem, masz świetny pomysł na biznes, mało czasu i pomocy, i nie stać cię na te plany Max Pro z „nieograniczonym” budżetem tokenów. Możesz zebrać się ze znajomymi, kupić przyzwoity laptop, Maca Studio albo mocnego Maca mini, włączyć współdzielenie compute i wszyscy korzystacie z tego jednego modelu działającego na jednej maszynie, mimo że czatujecie z różnych komputerów. To prosty przykład, ale widać, jak torują drogę do prawdziwej wolności wyboru modelu i wykorzystania mocy modeli open source i lokalnych, które są coraz silniejsze i zaczynają konkurować z modelami frontierowymi od Anthropic czy OpenAI.
Greg: Dlaczego w ogóle warto się tym bawić i czemu lokalne modele są ważne w kontekście przyszłości pracy?
Vinnie: Wybór modelu jest ważny w zależności od tego, co chcesz robić. To ta sama idea, co z danymi: Slack kontroluje twoje dane, a one są bardzo cenne. Siedzisz i wypracowujesz naprawdę fajne pomysły, iterujesz nad nimi, wkładasz w to sporo pracy i myśli — a potem jedna firma kontroluje te wszystkie dane. Jeśli zmęczysz się Slackiem i chcesz przejść gdzie indziej, przeniesienie danych bywa trudne albo wręcz niemożliwe. Zostajesz uwięziony.
Tak samo jest z modelami. Dziś nieograniczony plan kosztuje 200 dolarów miesięcznie, jutro może 2000 — nie wiemy. Możliwość wyboru w przyszłości jest bardzo ważna dla integralności i trwałości każdego biznesu, bo to twoje dane. Niektóre modele mają restrykcje na to, o co w ogóle wolno je zapytać. Rządy nakładają odgórne wymogi na to, co można z modelami robić — widzieliśmy modele wycofywane po kilku dniach używania. Budujesz biznes na tych narzędziach, więc powinieneś mieć elastyczność, wolność i kontrolę.
Kontekst jako fundament
Greg: Wielki wniosek jest taki, że wielu z nas nie uświadomiło sobie, jak bardzo Slack i podobne produkty stały się naszym centrum treści i kontekstu. Uczymy się, że żeby wycisnąć z modeli maksimum, trzeba dać im jak najwięcej kontekstu. Fajne w Buzzie jest to, że mówi: „rozumiemy, że to twój fundament kontekstu, i pomożemy ci pójść w wielu kierunkach — projekty zintegrowane z GitHubem, lokalny współdzielony compute, huddle z agentem”. Cokolwiek wybierzesz, kontekst jest w centrum.
Vinnie: Dokładnie. Myślę, że trafili w sedno. Ludzie w komentarzach wspominali open claw — kiedyś był momentem „wow”: okej, można nakłonić agentów do sporej produktywnej pracy. Ale czułem, że czegoś brakowało — właśnie tego współdzielonego kontekstu, bo pracujemy w zespołach i z innymi ludźmi. „Zespół” może oznaczać nawet twoich pozostałych agentów. Teraz masz możliwość rozszerzenia swojego globalnego okna kontekstu i udostępnienia go wszystkim w zespole — łącznie z agentami.
(Informacja dodatkowa: „open claw” to potoczna nazwa jednego z wcześniejszych, głośnych narzędzi agentowych).
Konfiguracja agentów — praktyczne wskazówki
Greg: Konfiguracja i zarządzanie agentami — jest tu jakiś „sos”, coś, co ludzie powinni wiedzieć poza tym, co już powiedziałeś?
Vinnie: Zależy, jak głęboko lubisz wchodzić. Szczerze, pewnie nie musisz robić wiele. Ja korzystam wyłącznie z Claude Code jako harnessu, ale są adaptery, więc możesz podpiąć open code, Goose czy inne. Pierwsze, co zrobiłem, to przypiąłem agentów do modeli. Fizz to model Fable, a Honey to Sonnet, bo do pewnych zadań nie potrzebuję mocy Fable’a i nie chcę tak szybko przepalać tokenów. To moja główna rada — poza tym po prostu zacznij eksperymentować.
(Informacja dodatkowa: Fable, Sonnet — nazwy modeli AI o różnej mocy i koszcie; w Buzzie każdemu agentowi można przypisać inny model).
Stworzyłem też „chief agent officera”. Jeśli zacznę tworzyć więcej agentów z bardziej wyspecjalizowanymi instrukcjami, mogę oddelegować mu samo delegowanie: „mam takie zadanie, kto jest do niego najlepszy?”. Możesz mieć copywritera, brainstormera, recenzenta kodu — i łatwo zapomnieć, kto jest kim, więc niech agent to rozdziela.
Umiejętności, ograniczenia i dla kogo to jest
Vinnie: Ludzie pytali na Twitterze o umiejętności (skills). Wszystko, czego używasz pod spodem w Claude Code, jest dostępne dla agentów Buzza, o ile jest zainstalowane globalnie. Nic nie tracisz — to też bardzo miłe.
Zaznaczę jednak: to oprogramowanie w becie, może nawet w alfie — wczesna wersja preview. Niektóre rzeczy nie działają najlepiej. Próbowałem tworzyć workflowy i zadania cykliczne — nie zawsze wychodziły. Bywa też wolno w porównaniu z pracą bezpośrednio w Claude Code czy Codeksie, i myślę, że to przez komunikację z twoim serwerem/relayem tam i z powrotem. Dlatego uważam, że na razie to naprawdę dobre narzędzie dla solopreneurów i małych zespołów iterujących nad niewielkim software’em i pomysłami. Do naprawdę złożonej inżynierii oprogramowania może się nie nadawać. Ale jeśli szukasz czegoś, co wnosi wartość i zbiera całą twoją wiedzę w jednym centralnym narzędziu — to świetny wybór.
Czy powinieneś to wypróbować?
Greg: Jeśli jesteś founderem, małym zespołem, powiedzmy zero–dziesięć milionów dolarów przychodu, i używasz dziś Slacka — czy powinieneś pobrać Buzz i spróbować?
Vinnie: Jestem przekonany — próbuję namówić mój zespół w Waspie, żebyśmy używali tego wewnętrznie właśnie z tego powodu. Jesteśmy małym startupem, firmą tworzącą narzędzie deweloperskie. Wiele rzeczy omawiamy na Discordzie, mamy tam też społeczność. Warto wspomnieć: możesz tworzyć kanały prywatne i publiczne. Możesz zaprosić ludzi ze swojej społeczności, żeby z tobą czatowali, a osobno mieć prywatne kanały dla zespołu — i ten kontekst jest współdzielony. To ogromna rzecz: jeśli ktoś wchodzi na czat i mówi „chcielibyśmy to naprawić”, naprawa z agentem jest o jedno „@” dalej. Mówisz „Fizz, weźmy ten bug” i można od razu, na miejscu, to zaprototypować. Dla małych zespołów to zdecydowanie warte sprawdzenia.
Greg: Moja teza: to bardzo fajne i wyraźnie dotyka tego, jak wygląda przyszłość pracy w świecie, gdzie masz więcej pracowników-agentów niż ludzkich współpracowników. Owszem, jest wcześnie, wygląda, jakby dopiero muskali powierzchnię. Nie wiem, czy wiesz, Vinnie, ale jestem współzałożycielem firmy LCA — Late Checkout Agency — która projektuje jedne z największych na świecie natywnie AI aplikacji (nie Buzza, ale firmy tego typu). Kiedy widzę coś takiego, myślę: jest blisko, jeszcze nie tam, ale blisko.
Nie mam żadnego powiązania z Buzzem, Blockiem ani Jackiem Dorseyem, ale uważam, że warto próbować takich narzędzi — nauczysz się czegoś. Nawet jeśli nie zostaniesz przy Buzzie, może po prostu skonfigurujesz Slacka lepiej pod siebie, bo się tu czegoś nauczyłeś. Albo pokochasz Buzz i zapomnisz o Slacku. Tak czy inaczej, wygrywasz — nie da się tu przegrać. Jedną z najważniejszych rzeczy w erze AI i agentów jest po prostu ubrudzenie sobie rąk, uczenie się, jak te narzędzia działają, i podglądanie, jak można żyć w przyszłości. Bo to ludzie, którzy żyją w przyszłości, potrafią zaglądać za róg i tworzyć produkty, których ludzie naprawdę chcą.
Vinnie: Zgadza się. Tym, co może uczynić z nich silnego gracza, jest to, że Buzz jest open source i zbudowany na otwartym protokole. Każdy, kto ma pomysł, jak to ulepszyć, może to zrobić. „Rój umysłów” będzie tego używał i jednocześnie nad tym pracował: „to mi nie działa”, „podoba mi się to z innego narzędzia — dodam to tutaj”. To może zadziałać na ich korzyść i sprawić, że stanie się narzędziem, do którego ludzie domyślnie wracają. Ale wszystko zmienia się tak szybko, że kto wie.
Greg: Amen. Vinnie, dzięki wielkie za wpadnięcie, oprowadzenie i podzielenie się „sosem”. Linki do ciebie będą w opisie. Chętnie zaproszę cię znowu. Widzowie na YouTubie — dajcie znać w komentarzach, czy się podobało i co mam poruszyć następnym razem. Jakieś ostatnie słowa?
Vinnie: Jeśli będą chcieli, żebym wrócił, mogę pokazać fajne rzeczy o tym, jak używać otwartego protokołu, na którym stoi Buzz — można wejść naprawdę głęboko. Jest tam sporo mocnych rzeczy, o których obaj napomykaliśmy w tweetach. Warto sprawdzić.
Greg: Dajcie znać, żyjemy, by służyć — jeśli tego chcecie, pójdziemy głębiej. Dzięki, Vinnie. Miejcie kreatywny dzień, do zobaczenia następnym razem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Agenci jako pełnoprawni członkowie zespołu, nie wtyczki
Na czym polega: Buzz umieszcza agentów AI w samym rdzeniu komunikatora — są „obywatelami” zespołu obok ludzi, a nie doklejaną integracją jak w Slacku.
Jak stosować: Traktuj agentów jak współpracowników w kanałach: przypisuj im role (copywriter, recenzent kodu, brainstormer), rozmawiaj z nimi w wątkach i wciągaj do dyskusji zespołowych.
Na co uważać: To narzędzie wczesnej wersji (alfa/beta). Do złożonej inżynierii oprogramowania może się nie nadawać; sprawdza się przy małych produktach i szybkich iteracjach.
2.Wymienny harness bez utraty kontekstu
Na czym polega: Pod każdym agentem możesz podmienić silnik (Claude Code, Codex, Goose, open code), a cała historia rozmów i budowanych aplikacji przechodzi razem z przełączeniem.
Jak stosować: Gdy pojawi się lepszy model, przełącz harness zamiast zaczynać od zera — leczy to „zmęczenie modelami” i pozwala testować nowości bez ryzyka utraty kontekstu.
Na co uważać: Różne modele mają różne mocne strony i koszty; samo przeniesienie kontekstu nie zwalnia z dobrania modelu do zadania.
3.Przypinanie agentów do modeli dla kontroli kosztów
Na czym polega: Każdemu agentowi można na stałe przypisać inny model — mocny (np. Fable) do trudnych zadań, tańszy (np. Sonnet) do prostszych.
Jak stosować: Zbuduj kilku agentów o różnych „mózgach”: droższy do wymagającej pracy, tańszy do rutyny, żeby nie przepalać tokenów tam, gdzie nie trzeba.
Na co uważać: To główna rada praktyczna gościa — bez świadomego przypinania łatwo puścić kosztowny model do banalnych zadań i szybko spalić budżet.
4.Zamknięta pętla kontekstu z własnych aplikacji
Na czym polega: Agenci mogą budować aplikację, wystawiać jej publiczne API, a potem cyklicznie pobierać z niej dane z powrotem do czatu — dane zasilają kontekst agentów.
Jak stosować: Zamiast ręcznie eksportować i wklejać dane do czatu, zbuduj workflow, który sam pobiera je przez API i wrzuca do kanału — potem po prostu pytasz agenta o wnioski.
Na co uważać: Workflowy i zadania cykliczne bywały zawodne w wersji, którą testował gość — zweryfikuj, czy zaplanowane zadania faktycznie się wykonują.
5.Praca w równoległych work tree z integracją Gita
Na czym polega: Agenci kodują w osobnych gałęziach i kopiach roboczych (work tree), nie ruszając lokalnych plików, i mogą pracować równolegle — np. postawić trzy wersje landing page’a naraz.
Jak stosować: Zlecaj równoległe warianty („zrób trzy wersje na bazie naszej rozmowy”) i porównuj efekty, zamiast iterować sekwencyjnie nad jedną wersją.
Na co uważać: Buzz ma własny hosting Gita na relayach; upewnij się, gdzie faktycznie ląduje twój kod, jeśli zależy ci na integracji z zewnętrznym GitHubem.
6.Otwartość obniża próg integracji
Na czym polega: Dzięki oparciu na otwartych protokołach (Nostr) podłączanie zewnętrznych usług i API jest dużo prostsze niż w zamkniętym Slacku, gdzie trzeba tokenów i aplikacji na ich platformie.
Jak stosować: Automatyzuj „nudną robotę” biznesu (oferty, raporty, digesty), która potrafi dać nieuczciwą przewagę — łatwe integracje sprawiają, że opłaca się to zrobić.
Na co uważać: Otwartość i self-hosting oznaczają większą odpowiedzialność za konfigurację relayów i danych — to nie jest w pełni „zarządzane” jak SaaS.
7.Współdzielony compute i modele lokalne
Na czym polega: Możesz uruchomić lokalny model na jednej mocnej maszynie i udostępnić go całemu zespołowi, obniżając koszt drogich planów z „nieograniczonymi” tokenami.
Jak stosować: Dla małego, budżetowego zespołu: jeden Mac Studio/mini z lokalnym modelem obsługujący kilka osób pracujących z różnych komputerów.
Na co uważać: Modele lokalne dopiero doganiają frontierowe — do najtrudniejszych zadań jakość może nie wystarczyć; dobieraj model do wymagań.
8.Kontrola nad danymi i uniknięcie vendor lock-in
Na czym polega: Komunikator staje się fundamentem kontekstu firmy; zamknięte platformy utrudniają migrację danych, a ceny i restrykcje modeli mogą się zmienić z dnia na dzień.
Jak stosować: Traktuj przenaszalność danych i wybór modelu jako element strategii — buduj tak, byś mógł zmienić dostawcę bez utraty dorobku.
Na co uważać: To argument kierunkowy, nie gwarancja — sam Buzz też jest wczesny; realną niezależność daje dopiero świadome trzymanie danych i skryptów po swojej stronie.
9.Rozmawiaj z agentami zwyczajnie, ale zwięźle
Na czym polega: Współcześni agenci dobrze wychwytują intencję, zwłaszcza gdy mają bogaty kontekst — nie trzeba specjalnych sztuczek promptowych.
Jak stosować: Pisz krótkie, konkretne polecenia jak do człowieka; bogaty kontekst kanału robi resztę roboty za ciebie.
Na co uważać: „Zwięźle” działa tylko wtedy, gdy kontekst jest naprawdę bogaty — przy ubogim kontekście lakoniczny prompt da słabe wyniki.
10.Największa wartość to nauka przyszłości pracy
Na czym polega: Nawet jeśli nie zostaniesz przy Buzzie, wypróbowanie go uczy, jak będzie wyglądać praca z agentami — i może poprawić sposób, w jaki używasz obecnych narzędzi.
Jak stosować: Poświęć czas na „ubrudzenie rąk” tym i podobnymi narzędziami; wyciągnięte wnioski przenieś choćby na lepszą konfigurację Slacka.
Na co uważać: Autorzy sami przyznają, że produkt „dopiero muska powierzchnię”, bywa wolny i niedopracowany — podchodź do niego jak do eksperymentu i nauki, nie jak do gotowego zamiennika krytycznych narzędzi.