O czym jest ten film
- Rozmowa Cole’a Medina i Rasmusa z Brianem, twórcą BMAD — jednego z najpopularniejszych frameworków do pracy z agentami kodującymi.
- Historia powstania BMAD: od frustracji doświadczonych inżynierów, dla których „pętla agentowa” była bezużyteczna, do metody rozbijania pracy na małe „intencje”.
- Dlaczego BMAD nie jest sztywnym gorsetem: konfiguracja przez pliki TOML, wiele punktów wejścia (PRD, product brief, PR-FAQ, burza mózgów, BMAD build).
- Co przynosi wersja 7: podział epików i historii na osobne pliki, wsparcie pracy zespołowej, konektory do Jiry/Linear/Azure, dystrybucja przez marketplace’y skilli.
- Koncepcja „punktu przegięcia”: po przyspieszeniu programistów wąskim gardłem staje się code review po prawej stronie i product management po lewej.
- Teza przewodnia: prawdziwa wartość inżyniera przesuwa się na lewo od kodowania — do decydowania, co i po co budujemy.
- Nowy model organizacji pracy: koniec dwutygodniowych sprintów, epik jako jednostka pracy jednej osoby, małe „pody” po 2–4 inżynierów.
- Krytyka samo-doskonalących się skilli i modeli piszących skille — Opus i Fable wciąż generują rozdęte, słabe skille.
- „Slop apocalypse”: nadmiar komentarzy i braku refaktoryzacji nie wywali kodu, tylko po cichu podniesie zużycie tokenów i spowolni pracę.
- Konkretna recepta na adopcję agentów w zespole: dwutygodniowy „sprint bez presji”, codzienne standupy o technikach zamiast statusów.
Redakcyjne tłumaczenie
Wprowadzenie Cole’a
Brian (zapowiedź): Widzę — i ostatnio przypomina mi o tym zwłaszcza Opus — że może nadchodzić „slop apocalypse”. Uwielbiam to określenie i ludzie zaczęli go używać. Myślę, że coraz więcej osób zacznie się o to rozbijać, ale to się nie objawi zepsutym kodem. Nie objawi się tym, że agent nie umie czegoś zaimplementować. Objawi się większym zużyciem tokenów, większą liczbą cykli i tym, że wszystko po prostu zwolni.
Ale nawet to nie jest szczyt góry. Naprawdę wierzę, że human on the loop jest punktem docelowym — przejście od człowieka w pętli do człowieka nad pętlą, przy zachowaniu kontroli. Zbudowałem BMAD wokół idei, że to ty masz kontrolę, a agent cię przez to prowadzi — używasz go jak partnera.
(Informacja dodatkowa: „slop” to w żargonie AI niskiej jakości, rozwlekła treść generowana maszynowo — po polsku najbliżej „maszynowej sieczki”. „Human in the loop” oznacza człowieka zatwierdzającego każdy krok, „human on the loop” — człowieka nadzorującego autonomiczny proces i interweniującego w razie potrzeby.)
Cole: Z przyjemnością przedstawiam wam tę sesję w formule podcastu z Brianem, twórcą BMAD — jednego z najpopularniejszych i najmocniejszych frameworków dla agentów kodujących na świecie. Razem z Rasmusem, który już wcześniej gościł na tym kanale, zaprosiliśmy Briana do społeczności Dynamous. Teraz przenoszę to nagranie tutaj.
Sesja była świetna. Brian podzielił się mnóstwem praktycznych rzeczy — nie tylko o samym BMAD i swojej wizji, ale też o tym, dokąd zmierza branża inżynierska w kontekście AI, o dobrych praktykach pracy z agentami kodującymi i o tym, jak uniknąć „slop apocalypse”, która naprawdę na nas nadciąga. Pod filmem znajdziecie rozdziały ułatwiające nawigację, ale zachęcam do obejrzenia całości i napisania w komentarzach, co sądzicie o takiej podcastowej formule. Zastanawiam się nad kolejnymi. To kopalnia treści. Oddaję głos sesji.
Skąd wzięło się BMAD
Cole: Witajcie wszyscy na warsztacie ze specjalnym gościem. Jest z nami Brian, twórca BMAD — jednego z najpopularniejszych frameworków do kodowania z AI, jakie kiedykolwiek powstały, i zdecydowanie jednego z tych, które szanuję najbardziej.
Frameworków, które dają ci skille i strategię na każdy etap cyklu życia oprogramowania, jest sporo. Ale przemyślenie i staranność, jakie Brian wkłada w BMAD, są bezkonkurencyjne. Kilka tygodni temu zrobiliśmy z nim warsztat o ogólnej wizji BMAD — dokąd zmierza i dlaczego w ogóle powstał. Padło wtedy tyle świetnych pytań, że nie zdążyliśmy odpowiedzieć na wszystkie, i wielu z was chciało dedykowanej sesji tylko o BMAD.
Mam przygotowane pytania, Rasmus też. Chcę, żebyście dorzucali swoje na bieżąco — to ma być rozmowa. Spokojnie zapełnilibyśmy cztery, pięć godzin. Brian, Rasmus i ja spotkaliśmy się wcześniej, żeby dopracować pytania tak, by rozmowa była ciekawa dla wszystkich i dotknęła naprawdę ważnych rzeczy.
Zacznę od pytań wysokopoziomowych o BMAD i twoją wizję — dla części osób to będzie powtórka. Potem przejdziemy do tego, jak BMAD ma się do innych idei krążących dziś po branży i jak Brian pomaga większym firmom wdrażać BMAD, co jest bardzo ciekawe. Brian, opowiedz na początek: dlaczego w ogóle zbudowałeś BMAD i dokąd to zmierza? Bo wiem, że szykujesz teraz naprawdę fajne zmiany.
Brian: Dzięki. Przede wszystkim uwielbiam społeczność Dynamous, to zaszczyt tu wrócić i widzę sporo znajomych twarzy z poprzedniego razu. Będę zwięzły, bo dużo z tego już było.
BMAD zacząłem — Boże, minął już ponad rok, trudno w to uwierzyć. Zarządzałem wtedy kilkoma zespołami w firmie i próbowałem po prostu zorientować się, jak skłonić własnych inżynierów do korzystania z pętli agentowej w narzędziach takich jak ówczesny Cursor. Doświadczeni inżynierowie próbowali. Świetnie działało to, co dziś na krzywych adopcji nazywa się „spicy autocomplete”. Ale kiedy przychodziło do pętli agentowej, moi naprawdę dobrzy, doświadczeni inżynierowie mówili: „To jest śmieć. Robi błędy. Szybciej zrobię to sam”.
(Informacja dodatkowa: „spicy autocomplete” — ironiczne określenie na podpowiadanie kodu przez model jako „autouzupełnianie na sterydach”, czyli użycie AI bez samodzielnego działania agenta.)
Namawiałem: „No chłopaki, spróbujcie, bo widzę, że inni robią z tym niesamowite rzeczy”. I szczerze — tego tam po prostu nie było. Świetnie sprawdzało się szybkie autouzupełnianie, edycje w wielu miejscach, zadawanie pytań, ale pętla agentowa nie chwytała. Zaskakująco widziałem to praktycznie wszędzie. Rozdźwięk między tym, co mówiono wtedy w internecie i na YouTubie, a tym, co widziałem w rzeczywistości, był ogromny.
Cole: Mówisz o ludziach opowiadających „zbuduj milionową aplikację SaaS w jedną noc, bez doświadczenia”.
Brian: Dokładnie. A tymczasem doświadczeni inżynierowie mówili: „To zabawka, nie da się tego używać” i tak dalej. Nie będę tego powtarzał. Ale to właśnie doprowadziło mnie do obsesji budowania własnej pętli agentowej po nocach, w kółko, żeby sprawdzić, jak daleko dam radę popchnąć agenta.
Zacząłem uczyć się różnych technik. Że jak dołożę tu trochę kontekstu, jak dam plik kontekstowy z regułami… Bo półtora roku temu wszyscy wierzyliśmy, że reguły to srebrna kula. Moje dwa pierwsze, żenujące filmiki na YouTubie wciąż tam są — właśnie o regułach: wrzucasz reguły i agent robi magię. Szybko okazało się, że układanie stosu reguł niczego nie załatwia. Ale fragmenty plików i podawanie agentowi małych kawałków intencji — to działało. Wtedy nie mieliśmy jeszcze słów na wiele z tych rzeczy. Chyba nie funkcjonował nawet termin „vibe coding”, nie mówiąc o „context engineering” czy „intencjach”.
Ale z mojego doświadczenia — 25 lat pracy w korporacjach i z firmami — wiedziałem, że Agile działa, bo ostatecznie sprowadza się do rozbijania dużych pomysłów na mniejsze kawałki. I po prostu mnie olśniło: czemu nie spróbować tego samego? Stąd pomysł na product managera, który przegaduje z tobą pomysł na wysokim poziomie i rozbija go na to, co nazwałem user stories. Wciąż mówię na to „stories”, choć to nie są user stories — to są specyfikacje. Znowu: „spec engineering” i „spec” nie były jeszcze terminami branżowymi. Specyfikacje kojarzyły się z testowaniem — Gherkin, BDD. Nazwałem je historyjkami, ale były to po prostu małe kawałki intencji.
I widziałem, że nawet przy prymitywnych modelach sprzed półtora roku i przy harnessach takich jak Cursor z bardzo małym oknem kontekstowym — jak podałeś mu te małe intencje, obudowane dużą ilością szczegółów, to on to dobrze wykonywał.
(Informacja dodatkowa: „harness” to warstwa uruchomieniowa wokół modelu — narzędzie w rodzaju Cursora, Claude Code czy Codeksa, które daje modelowi dostęp do plików, terminala i pętli działania.)
Udało mi się doprowadzić agenta do zbudowania dość złożonej — jak na tamten czas — aplikacji od początku do końca. Dochodziłem do momentu awarii, sprawdzałem, jakiego kontekstu naprawdę brakuje — może reguł, może dokumentów albo wskazówek — i zaczynałem od początku. I za każdym razem dochodziło dalej. Powoli widziałem, czego naprawdę trzeba, żeby dojść do końca.
Szczerze mówiąc, to nie jest zła technika nawet dziś. Zanim sięgniesz po jakikolwiek framework, po jakiekolwiek skille — wyrzuć to wszystko i zobacz, do czego zdołasz doprowadzić agenta. Sprawdź to sam. Powtarzam to bez przerwy: cokolwiek robią te skille i frameworki, ty jako inżynier możesz się tego nauczyć, po prostu używając swojego harnessa i wybranego modelu. Naucz się, co model potrafi sam z siebie, zobacz, jak daleko go zaprowadzisz, a dopiero potem zacznij dobierać skille, tworzyć własne albo sięgać po frameworki.
Ale wracając do pytania — stąd wyewoluował BMAD. Pierwotnie chodziło tylko o to, żeby pomóc pojedynczym programistom nauczyć się skutecznie używać pętli agentowej. Zaniosłem to do firmy, ale nie dałem inżynierom gotowca — chciałem, żeby sami doszli do tych wniosków. I nadal mocno to doradzam, kiedy konsultuję firmy próbujące przesunąć swoje organizacje dalej na krzywej adopcji.
Wspominałem chyba o dwutygodniowym sprincie, który przeprowadziłem — powiem krótko i zamknę ten wątek. Dajcie swoim inżynierom czas, żeby to przerobili, albo dajcie go sobie. Na początku będzie frustrująco. Może trzeba będzie zwolnić. Ale weź jakiś kawałek pracy — na zielonym albo na brązowym polu — i po prostu spróbuj doprowadzić agenta do końca bez własnoręcznej ingerencji.
(Informacja dodatkowa: „greenfield” to projekt budowany od zera, „brownfield” — praca w istniejącej, zastanej bazie kodu.)
Dziś jest to dużo łatwiejsze niż półtora roku temu. Może wystarczy poprosić i agent zrobi to za pierwszym podejściem albo blisko tego. Może narobi sieczki. Ale nadal warto to przerobić — żeby powalczyć o jakość, nabić powtórzenia i naprawdę nauczyć się pracy z modelem w harnessie, zanim wejdziesz w większe tematy, o których dziś będziemy mówić.
To chyba dobre podsumowanie tego, o czym mówiłem poprzednio. Oczywiście BMAD od tamtej pory ewoluował — jest bardziej modularny, bardziej konfigurowalny. Mamy pomysły w rodzaju pakietu do kreatywnej innowacji i w ogóle każdej branży czy przepływu pracy, gdzie da się pracować sekwencyjnie i gdzie chcesz używać AI jako partnera do myślenia.
Jeszcze jedno. Wielką ideą BMAD nigdy nie było to, żeby AI robiło robotę za ciebie. Brzmi to, jakbym właśnie to opisywał, ale to dotyczy wyłącznie warstwy kodowania. Planowanie, tworzenie tego, co dziś nazywamy specyfikacjami, przemyślenie pracy, ideacja — tu zbudowałem BMAD wokół zasady, że ty masz kontrolę, a agent cię prowadzi jako partner.
Kiedy robię się leniwy, czuję to. Czasem mam ochotę powiedzieć: „Po prostu daj mi odpowiedź, sam wymyśl ten pomysł”. Ale to jest dla mnie brudne uczucie. Wolę zostać przy sterach. Uważam, że to my jesteśmy siłą twórczą w tym wszystkim, że zachowujemy człowieczeństwo i traktujemy agenta jak asystenta albo facylitatora. To niesamowity nauczyciel i niesamowity facylitator. To też idea stojąca za wieloma skillami i przepływami w BMAD — mają cię popychać do bycia lepszym, a tam, gdzie masz lukę w swoich kompetencjach, pozwalają mocniej oprzeć się na modelu.
Zatrzymam się tutaj, bo mógłbym mówić bez końca i zapełnić półtorej godziny.
Cole: Możemy tak każdy. Ale bardzo mi się to podoba, świetnie ujęte. To zresztą także moja filozofia — zawsze mówię, że chcesz zdelegować całe kodowanie agentowi, ale zostać na fotelu kierowcy. Robi się to na dwa sposoby, które działają razem: musisz być zaangażowany w planowanie na wejściu i w walidację na wyjściu. A BMAD ma wbudowane mnóstwo świetnych rzeczy zwłaszcza do tego planowania na starcie.
Przerwa sponsorska
Cole: Sponsorem dzisiejszego materiału jest Manufact i ich open-source’owy framework MCP-use. Większość z nas zakłada, że serwery MCP zwracają tylko tekst albo JSON, ale to zmieniło się w tym roku. MCP Apps to pierwsze oficjalne rozszerzenie protokołu, które pozwala serwerom MCP zwracać interfejsy renderowane bezpośrednio w Claude albo innym wspierającym kliencie. MCP-use bardzo ułatwia budowanie takich serwerów — jedno polecenie i masz serwer razem z widokiem.
Zbudowałem taki sam. To aplikacja MCP w Manufact. W zakładce narzędzi stworzyłem prostą funkcję wyszukiwania repozytorium na GitHubie. Zwraca nie tylko tekst czy surowy JSON — mamy komponent renderowany wprost w Claude, jak widzicie na żywo. Tak jak jedno polecenie ustawia wszystko, tak jedno polecenie wdraża do Manufact. Wdrożyłem ten serwer w mniej niż minutę i mam publiczny adres, którym mogę się podłączyć w aplikacji w rodzaju Claude Desktop.
Po wdrożeniu dostajesz testy między klientami, kontrole publikacji dla sklepu wtyczek ChatGPT i konektorów Claude oraz natywną analitykę MCP — więc masz pewność, że jeden push nie wysadzi reszty. W rozmowie mogę teraz powiedzieć: „Daj mi statystyki tego repo na GitHubie” — narzędzie się wywołuje i zwraca ładnie wyrenderowany widok. MCP-use jest na licencji MIT i ma dziesięć i pół tysiąca gwiazdek na GitHubie, a Manufact ma darmowy plan. Polecam sprawdzić — link w opisie.
Czy BMAD zamyka cię w jednym procesie?
Cole: Chcę od razu przejść do tego, jak ludzie mogą używać BMAD. Częsty zarzut wobec BMAD brzmi, że jesteś wtłoczony w jeden bardzo konkretny proces — bo BMAD jest opiniotwórczy. Ale wiem, że nigdy nie taka była intencja, i że ostatnio rozwijasz go tak, żeby był bardzo „plug and play”, elastyczny i ogólnie lekki. Opowiedz o tym.
Brian: Na początku było to naprawdę tylko sześć skilli i od pierwszego dnia mówiłem: weźcie to, nauczcie się tych idei i wymyślcie własny sposób pracy. Teraz to urosło w coś znacznie większego. Każdy skill jest konfigurowalny. Możesz powiedzieć: „BMAD, dostosuj PRD”.
Używamy plików TOML leżących obok skilli. Możesz w nich podpiąć Jirę albo Linear, wprowadzić wiedzę o wymogach ładu korporacyjnego, które musisz uwzględniać w pewnych raportach, albo wskazać framework, którego chcesz używać. BMAD zapisze te pliki konfiguracyjne za ciebie — na poziomie organizacji albo indywidualnym. Zaletą jest to, że nie modyfikujesz samych skilli i przepływów, więc dalej możesz przyjmować aktualizacje. Trzymamy punkty konfiguracji stabilne między wersjami, żeby się nie zmieniały.
Ale poza tym trzeba powiedzieć jasno: z BMAD możesz używać innych skilli. Chcę, żebyś tworzył własne skille i własne przepływy.
Pierwotnie było to pięć, sześć skilli: zacznij od PRD, zbuduj architekturę. A architekturę mieliśmy dlatego, że wcześnie odkryliśmy, iż dokument mówiący „taka jest struktura kodu” albo „używamy tych sześciu narzędzi” ma konkretny sens: dzięki temu model nie dryfował i nie decydował nagle — przy okazji nieudanego testu jednostkowego i kiedy akurat nie patrzysz — że wstawi zupełnie nową bazę danych. Widziałem takie rzeczy. Wszystko to wyewoluowało z problemów, na jakie sam się nadziałem w tej pętli.
(Informacja dodatkowa: PRD — Product Requirements Document, dokument wymagań produktowych.)
Więc było PRD, architektura, w którymś momencie chyba scrum master, potem rozbijanie ticketów na historyjki — te małe intencje — i implementacja jedna po drugiej. Ale z czasem okazało się, że część ludzi nie chce robić PRD, a wraz z rozgadaniem modeli wielu zaczęła odrzucać sama rozwlekłość tych dokumentów. To zresztą osobny temat i mamy pomysły, jak z tym walczyć.
Nie każdy myśli w kategoriach PRD i nie każdy chce. Dlatego wprowadziliśmy coś, co dziś nazywa się BMAD build, a wcześniej quick dev — przeszło przez kilka nazw. Czasem pracujesz w dużej aplikacji i… po pierwsze, po prostu pogadaj z Claude’em. Jeśli potrzebujesz szybkiej rzeczy, panuje przekonanie, że musisz przejść cały przepływ. Ja używam Claude’a bezpośrednio. Używam Copilota bezpośrednio. Po prostu mówię mu, co trzeba zrobić.
Jeśli mam coś ambitniejszego, ale nie chcę przechodzić przez całe planowanie, używam tego, co nazywaliśmy quick dev. To mała pętla, która z tobą rozmawia, wyciąga twój pomysł, tworzy specyfikację na poczekaniu i przechodzi w naszą pętlę budowania — wszystko w jednym samodzielnym skillu. Dziś nazywa się to BMAD build.
BMAD build jest o tyle ciekawy, że stał się głównymi drzwiami do części budującej w metodzie BMAD. Uważam, że mamy bardzo dobrą pętlę budowania i też jest konfigurowalna. Możesz z nią po prostu porozmawiać o swoim pomyśle albo podać jej intencję w dowolnym formacie — możesz mieć historyjkę albo specyfikację napisaną z użyciem zupełnie innego zestawu skilli, podać ją BMAD build, a on ją weźmie i zbuduje.
Mówiłem też, że PRD nie jest jedynym punktem wejścia. Mamy PR-FAQ, które wzięło się z Amazona. Proces polega na tym, że piszesz komunikat prasowy dla swojego pomysłu, tworzysz FAQ i bronisz tego przed agentem, żeby udowodnić, że rzecz w ogóle warto budować. To bardzo fajne ćwiczenie. W Amazonie stosują to od zawsze — pomysł wyszedł od Bezosa i kogoś jeszcze — i użyli go przy wielu swoich największych hitach. To nie jest dla każdego, ale chodzi o to, żeby użyć agenta do przejścia przez takie procesy i ustalić, czy to w ogóle warto budować.
Czasem nie potrzebujesz PRD. Wiele osób, z którymi rozmawiam, używa po prostu product briefu — chudszego dokumentu, który wciąż opisuje sens rzeczy — i od niego przechodzi przez resztę procesu. Możesz też zacząć od burzy mózgów albo po prostu pogadać z Claude’em o swoim pomyśle. Możesz brać skille z innych frameworków — na przykład bardzo popularny skill „grill me” — utwardzić nimi swój pomysł i podać go do BMAD. BMAD jest konfigurowalny, otwarty, można mieszać i dobierać; istotny jest proces. Zatrzymam się i może powiem trochę o tym, co przychodzi z wersją 7, bo widziałem pytania w tę stronę.
Cole: Świetnie. Bardzo lubię to, jak konfigurowalny jest BMAD, bo większość frameworków do kodowania z AI taka nie jest. I chyba dlatego rośnie duży obóz mówiący: „do diabła z frameworkami, oto zestaw skilli, weź go dla siebie albo zbuduj wszystko od zera”. Widzę w tym wartość, sam tego w dużej mierze uczę, bo do pewnego stopnia zgadzam się, że większość tych frameworków jest zbyt rozdęta. Szczerze — w pewnym momencie tak myślałem też o BMAD. Ale po tym, jak poznałem twoją filozofię i pracę, którą włożyłeś w ostatnie miesiące, widzę, jaki BMAD jest potężny, a jednocześnie elastyczny.
To jest ta ważna równowaga: zbudować coś, co uczy w trakcie przekazywania ludziom, ale co da się też ulepić pod własne przepływy. I wiem, że opowiadałeś mi wcześniej o większych firmach, które po prostu chcą dostać gotowy standard i idą po niego do BMAD. Opowiedz teraz, jak BMAD ewoluuje w wersji 7 i dalej.
Wersja 7: zespoły, konektory i marketplace’y
Brian: Dzięki, że to mówisz, Cole. Naprawdę dziękuję za to, że dałeś BMAD kolejną szansę i faktycznie mu się przyjrzałeś, bo to łatwy cel. Nie wiem, czy byliśmy pierwsi, ale kiedy zaczynaliśmy, nie było skilli, nie było dobrych sposobów myślenia o tych rzeczach. Przeszliśmy przez wiele iteracji, a inni mogli wejść dokładnie we właściwym momencie i zbudować coś od razu w tym punkcie.
Powiem też, że wiele kolekcji skilli jest bardzo opiniotwórczych i faktycznie zamyka cię w swoim podejściu. Mogą mówić, że nie są frameworkiem, ale część z nich sprawia na mnie bardzo frameworkowe wrażenie i przepycha cię przez określony proces. I wiesz co? Nie ma w tym nic złego. Bądźmy szczerzy — posiadanie systemu i myślenie systemowe to dobra rzecz.
Istnieją dwie filozofie skilli. Kiedy je wypuszczono, była jedna idea: to mała, atomowa jednostka, która wzbogaca model i robi jedną rzecz. Ale sposób, w jaki je zbudowano — i to jest genialne, celowo czy nie, choć nie sądzę, żeby dużo o tym myśleli — obejmuje progresywne ujawnianie kontekstu. To osobny temat, w który dziś nie wchodźmy. No i ustawili maksymalny rozmiar treści skilla na coś absurdalnego, bodaj 25 megabajtów. Można w skille wpakować mnóstwo.
Oczywiście sam plik SKILL.md ma być mały i chudy, bo on jest zawsze ładowany. Ale co do reszty można mieć różne filozofie. Kiedyś dzieliłem skille na osobne: tworzenie, edycję i walidację. Było w tym mnóstwo powtórzeń i rozdęcia. To wstydliwa, stara wersja BMAD, od której odeszliśmy. Dziś, wrzucając wszystkie te idee do jednego skilla i bardziej ufając modelowi, można mieć mniej skilli, ale z różnymi ścieżkami przejścia — i robić dużo więcej. Nadal konfigurowalnie.
Uważam, że każdy pakiet skilli ma jakiś przepływ, do którego cię zaprasza, i to jest dobre. Skille nie muszą być malutkimi, atomowymi rzeczami — będąc częścią ekosystemu, mają wspólne elementy i zaczynają dobrze ze sobą współpracować. Nadal wierzę, że to dobry pomysł. Czego nie chcę robić, to zamykać cię w jednym sposobie pracy. Powód jest prosty: nawet dla mnie jeden sposób nie działa. Pracuję nad różnymi typami projektów — czasem robię frontend, czasem architekturę korporacyjną, a w projektach hobbystycznych praca nad BMAD i kolekcjami skilli to coś zupełnie innego niż moje projekty poboczne. Nie chciałbym być zamknięty w jednym trybie pracy i dlatego tak ciężko pracuję nad elastycznością. Czasem idzie wolno, bo to wciąż ewoluuje i musi nadążać za tym, jak ludzie faktycznie pracują.
Cole, pytałeś jeszcze o wersję 7, a ja trochę odbiłem od tematu.
Cole: Tak, wersja 7.
Brian: Nie ogłaszaliśmy jeszcze nic oficjalnie, ale jesteśmy jakieś dwa–trzy tygodnie od premiery. Jedną z najważniejszych rzeczy, na których skupialiśmy się przez ostatnie miesiące, jest wsparcie dla przedsiębiorstw i zespołów. Prawie wszystkie pytania, które teraz dostajemy, dotyczą tego, jak używać BMAD w zespole.
Dziś, kiedy definiujesz rozbicie projektu, BMAD dzieli go na epiki i historyjki — albo same historyjki, jeśli wolisz. Ale zasadniczo siedzi to w jednym pliku i robisz to na poziomie projektu. Pracujemy nad tym, żeby epiki trafiały do osobnych folderów, a każda historyjka była osobnym plikiem. Będzie też można podłączyć Azure albo Linear, jeśli chcesz, albo inny system ewidencji — chcemy to zostawić bardzo otwarte. Sedno jest takie, że przez wcześniejsze utworzenie osobnych plików różne zespoły albo różne osoby mogą pracować nad różnymi rzeczami. Tak działa prawdziwa organizacja. PiloTuję to w firmach z realnymi zespołami i sprawdza się bardzo dobrze. To jedna z największych zmian w kierunku platformy do współpracy.
Skoro o współpracy: chcemy też wspierać śledzenie wszystkich artefaktów powstających podczas planowania. W środowisku korporacyjnym — a zakładam, że wielu z was tu pracuje w zespołach — chcesz móc współpracować z różnymi ludźmi na różnych poziomach. Prawdziwi product managerowie wciąż mają w tym swoje miejsce, podobnie programiści i projektanci. Trzymając wszystko w jednym miejscu — a pamiętajmy, że jedni dobrze radzą sobie z Gitem, a inni nigdy go nie zrozumieją — szukamy sposobów, żeby to spiąć i umożliwić współpracę: jedna osoba pracuje nad PRD, druga nad architekturą.
Chcemy też wspierać projekty rozwiązań tam, gdzie jakieś mniejsze fragmenty trzeba naprawdę rozpracować. A kiedy zbierzesz to wszystko razem w jednym, wspólnym i przeszukiwalnym miejscu, łatwiej potem tworzyć tickety i specyfikacje, bo system znajduje właściwe rzeczy. To duża część tego, co przychodzi z wersją 7.
Jeszcze jedna ważna rzecz: przespaliśmy temat marketplace’ów skilli. Zaczynaliśmy od ciężkiego instalatora, bo nie było skilli ani wspólnego miejsca na pliki. Bardzo niedługo — może nawet przed premierą wersji 7, w tym tygodniu testujemy — wypuścimy kolekcje skilli do NPX Skills od Vercela, do marketplace’u Claude’a i marketplace’u Codeksa. Zaczynamy od tych, ale zostaniemy otwarci na wszystkie. Podzielimy też całość na mniejsze kawałki. Chcesz bardziej kreatywnych rzeczy albo jesteś product managerem i interesuje cię głównie ideacja? Pobierzesz te skille. Chcesz tylko narzędzia deweloperskie albo samą pętlę BMAD? Proszę bardzo. Będziesz mógł wybrać, co chcesz — może całość nie jest ci potrzebna.
Cole: Świetne. Sean zadał zresztą pytanie w tym wątku — chyba właśnie na nie patrzysz. Pyta: jeśli mam własny system ticketowy, czy BMAD pozwoli mi go wykorzystać, na przykład jako MCP albo CLI?
Brian: Absolutnie, w stu procentach chcemy tak zrobić. Wyciągamy wiele takich szczegółów poza metodę BMAD i tworzymy konektory. Będziemy je wypuszczać, ale nawet je chcemy zrobić bardzo konfigurowalnymi pod twoje potrzeby, bo nie ma jednego sposobu używania Jiry, Lineara i tym podobnych narzędzi.
Cole: Super. Podoba mi się, jak dużo myślisz o użyciu zespołowym, bo mam wrażenie, że twórcy frameworków do kodowania z AI myślą o tym stanowczo za mało. Nawet jeśli nie używasz BMAD — a uważam, że warto — samo przyglądanie się mu jako przykładowi, w miarę jak pojawia się wersja 7 i kolejne, to bardzo mocny sposób nauki integracji agentów na poziomie zespołu. I wracając do tego, co mówi Brian: nie musisz się cały zanurzać w opiniotwórcze podejście. BMAD jest po to, żeby być punktem odniesienia i narzędziem dydaktycznym. Bierzesz kawałki albo całość. Wiele firm bierze całość i to jest świetne, bo myślicie o rzeczach, których te firmy naprawdę potrzebują.
Punkt przegięcia: gdzie pojawiają się nowe wąskie gardła
Brian: Jest coś, co nazwałbym punktem przegięcia — może to nie najlepsze słowo. Widziałem to we własnej firmie, widziałem u innych i chyba nawet o tym rozmawialiśmy, Cole, a ty mówisz o tym w swoich szkoleniach.
Bardzo łatwo skupić się najpierw na inżynierach i myślę, że to słuszne, bo to oni są wczesnymi adoptującymi. Rozumieją technologię, rozumieją Gita. Ale przyspieszysz ich tylko do pewnego momentu. Wziąłem swój zespół, przeszliśmy ten proces, bardzo szybko doszliśmy do stu procent pracy w trybie agentowym i przyspieszenia — i bardzo szybko uderzysz w kolejną ścianę. Właściwie dwie: jedną na prawo od punktu przegięcia i jedną na lewo.
Po prawej okazuje się, że programiści pędzą tak szybko, iż wąskim gardłem stają się przeglądy kodu. Drugą rzeczą, którą AI uwidacznia w organizacjach i u ludzi, jest to, że jest wzmacniaczem — ale nie zawsze wzmacniaczem dobra. Jeśli masz kiepskie CI/CD albo kiepskie procesy, albo — no jasne, że nikt z tu obecnych — nie jesteś dobrym inżynierem, to AI to wzmocni. Bardzo ciekawe zjawisko, widziałem je na własne oczy.
Zaczyna się więc świecić lampka: musimy poprawić CI/CD. Chcemy jechać szybciej, więc potrzebujemy pipeline’ów, które dowiozą aż na produkcję, i bramek w nich. Albo: przeglądy kodu są wąskim gardłem — wprowadzamy nowe narzędzia w rodzaju CodeRabbita? Zmieniamy stanowisko w sprawie przeglądów przez dwie osoby? Może wystarczy jedna? Może część rzeczy puszczamy przez pipeline? Może zbudujemy narzędzia albo analizę, które popatrzą na kod i powiedzą: „to zmiana trywialna, poprawka CSS, niech idzie prosto na produkcję” — i wykroimy 20–30% do przeglądu przez człowieka, wykorzystując najlepszych ludzi tam, gdzie naprawdę trzeba pomyśleć, przyłożyć się albo współpracować całym zespołem. To wszystko jest na prawo od punktu przegięcia.
Na lewo jest natomiast obszar, w którym — moim zdaniem — w zespołach i korporacjach ludzie po prostu się nie skupiają, i tu BMAD jest wyjątkowy. Może nie w stu procentach wyjątkowy, ale naprawdę wierzę, że ciekawa część BMAD jest na lewo od budowania kodu. Kocham nasz BMAD build, kocham naszą pętlę biorącą specyfikacje, ale moim osobistym zainteresowaniem jest pomaganie ludziom tworzyć najlepsze możliwe specyfikacje — w miarę jak podnosimy poziom inżynierów, zespołu i product managerów.
Ostatecznie praca polega na rozumieniu biznesu, rozumieniu produktu albo tego, co chcemy zbudować, upewnianiu się, że to właściwa rzecz, wyszukiwaniu ciekawych okazji i wykuwaniu tej specyfikacji — bo to ona idzie do maszyny. A maszyna będzie coraz bardziej zautomatyzowana i coraz bardziej ujednolicona w skali firmy.
Wracając do pytania, czy chcesz być we frameworku: jeśli jesteś w firmie, będziesz we frameworku. Możesz mieć 50 czy 100 tysięcy inżynierów, każdy wymyślający własną fabrykę i własny sposób rozbijania pracy na plan implementacji, ale w pewnym momencie zapytasz: po co? Skoro mamy dobrą, spójną jakościowo specyfikację, a inżynierowie i tak robią zasadniczo to samo, to bardzo szybko dojdziemy do punktu, w którym robisz coś w Jirze, przeciągasz ticket do jakiegoś procesu, agent go podnosi, zaczyna robić, a ty siedzisz nad przeglądem kodu.
Więc jeśli jesteś inżynierem — naprawdę w to wierzę — jesteś ogromnie wartościowy, ale twoje myślenie o tym, na czym polega twoja wartość, musi się zmienić. I to cię awansuje. Widziałem to we własnym zespole. Pół roku temu wiele osób się niepokoiło. Kiedy zaczęli widzieć, jak agent robi ich robotę, zaczęli myśleć: „ile ja teraz jestem wart? Byłem dżokejem ticketów — brałem ticket i byłem dobry w domykaniu go”. Ale zmiana, która zaszła w moich zespołach, jest niesamowita. Oni to teraz kochają, bo zrozumieli, że mogą skupić się na wyższym poziomie. To już nie tylko zadanie architekta czy product managera — oni mogą patrzeć na szerszy obraz, rozumieć produkt i naprawdę rozumieć, co budujemy i dlaczego to ma sens.
Skupienie na lewej stronie punktu przegięcia to słodki punkt BMAD: jak pomóc zespołom współpracować i przesuwać rzeczy przy użyciu AI. Zacznij od inżynierów, ale uderzysz w wąskie gardło — więc potem patrzysz na product management i na to, jak szybciej dostarczać dobre pomysły do zespołu. Bo to staje się wielkim wąskim gardłem: deweloperzy przelatują przez pracę tak szybko, że nagle czekasz, aż biznes nadgoni.
A jeśli jesteś solowym deweloperem, hobbystą czy jednoosobowym przedsiębiorcą — to samo. Masz teraz możliwość używania AI do znacznie więcej niż kodowanie: do ideacji, badań rynku, testowania prototypów, testów A/B. Tyle mocy jest po lewej stronie. To mnie pasjonuje i dlatego jestem takim zwolennikiem facylitacji: wchodź z mocnymi pomysłami, bądź ekspertem, dawaj swoje opinie i pozwól modelowi je utwardzać albo dokładać research.
Zatrzymam się, bo widzę mnóstwo pytań.
Kto pisze specyfikacje i jak zmieniają się role
Rasmus: Myślę, że jesteś na dobrym tropie. Wszystko, co opisujesz po lewej stronie, jest teraz również zadaniem inżyniera — musi zaprojektować ten produkt, który ma powstać, żeby biznes mógł dojść do celu. Praca inżyniera to już nie tylko wysyłanie kodu. To budowanie systemu, który pozwala firmie wysyłać kod — inżynierowanie firmowej pętli budowania, takiej jaką macie w BMAD. Ludzie mogą zbudować własną firmową pętlę, własny generator, jakkolwiek to nazwać.
Widzę tu jednak duże ryzyko i chcę poznać twoje zdanie. Kiedy oddajesz takie zadania nie-inżynierom — pisanie PRD czy specyfikacji — a pisze to ktoś, kto nie rozumie kodu ani systemu, istnieje ryzyko, że te dokumenty będą zawierać zbyt dużo przesądzonych decyzji inżynierskich, zanim trafią do inżyniera. Wtedy to zadanie inżyniera, żeby zanim trafi to do agenta kodującego, doprowadzić rzecz do porządku — bo inaczej mamy „śmieci na wejściu, śmieci na wyjściu”. Jako inżynier musisz zdecydować, gdzie ma się skończyć praca twojego product managera, żebyś mógł ją podjąć i wpuścić w resztę pętli.
Brian: Dokładnie, w stu procentach. Myślę, że w przyszłości — i już zaczynamy to robić — role będą ewoluować. Rekrutując na stanowiska inżynierskie i produktowe, szukamy dziś tego, co nazywamy „systems thinkers”, czyli osób myślących systemowo. Czy jesteś product managerem, czy inżynierem — zatrudniamy myślących systemowo. Dla inżynierów, których już mamy, to bywa bolesne, dla niektórych naturalne, ale to ewolucja, przez którą wszyscy przechodzą.
Zgadzam się z tobą w stu procentach, że ludzie od produktu, projektanci i inżynierowie są potrzebni. To, że AI pozwala nam robić wszystkie te rzeczy samodzielnie, jest świetne jako wsparcie, ale wciąż widzę wartość w tych wszystkich rolach. One po prostu się zmieniają.
W podcaście Lenny’ego — pozdrawiam Lenny’ego, chętnie kiedyś wystąpię — był ostatnio chief product officer Whatnota z dość clickbaitowym tytułem, że nie będzie już zatrudniał product managerów. Ale naprawdę miał na myśli mniej product managerów robiących to, co product managerowie faktycznie powinni robić: myślenie na wyższym poziomie o kierunku.
Możemy pogadać o tym, jak w przyszłości powinny być formowane zespoły. Zwykle zespół agile’owy w wielu firmach liczy pięć do ośmiu osób, ma scrum mastera, a często również przypisanego product managera. Bierzesz epik, pracujesz nad nim przez miesiąc, a wiele osób robi jego różne kawałki.
Z AI wszystko jest tak skompresowane, że możemy planować dużo bardziej z wyprzedzeniem, ale uważam też — chyba mówiłem to poprzednio — że epik jest nową jednostką pracy dla inżyniera. Nie każda firma używa słów „epik” i „historyjka”, ale chodzi o to, że większy blok pracy jest teraz jednostką dla jednej osoby. Wyrzuciliśmy dwutygodniowe sprinty; już tego nie polecam. Traktuję epik jak własną, mini inicjatywę agile’ową: ktoś jest jej właścicielem, może dwie osoby pracują razem, i prowadzą to od początku do końca.
Zaczynamy więc widzieć rozbijanie dużych zespołów scrumowych na mniejsze „pody” po dwóch do czterech inżynierów. Wracając do wątku Lenny’ego: „usunięcie product managerów” oznacza, że niekoniecznie masz product managera przypiętego do każdego zespołu. Zamiast tego budujesz małe pody, w których przynajmniej jedna osoba — może inżynier, może ktoś z tłem produktowym, wszyscy techniczni — potrafi naprawdę pomyśleć i rozumieć, co posiada i za co odpowiada. Te osoby są najlepsze do wymyślania nowych rzeczy i pchania sprawy naprzód. Do tego dochodzi dobry lider.
W modelu podowym jest wciąż miejsce dla juniorów. I pozdrowienia dla firm, które robią to dobrze i nadal wspierają inżynierów wychodzących ze studiów, bo to trudny czas, żeby kończyć studia i próbować wejść do tej branży. Nie będę wskazywał firm, ale te, które przechodzą na model podowy i wspierają juniorów — u nich to działa. Można znaleźć dobrych inżynierów z systemowym nastawieniem prosto po studiach, wychować ich i bardzo szybko stają się skuteczni. To po prostu inne szkolenie inżynierów niż kiedyś. Te małe pody działają dobrze. Mają na własność epik i prowadzą go od początku do końca.
Product managerowie nadal istnieją i wciąż są cenni, ale role się przesuwają. Są nieco bardziej hands-on, jeśli są w podzie, albo działają na wyższym poziomie. A w podzie któryś z inżynierów przejmuje rolę myśliciela systemowego i produktowego. To bardzo ciekawa zmiana.
Rasmus: Zgadzam się. Klucz do tych podów i tego modelu polega na tym, że przypisujesz podowi własność problemu. Ten mały pod jest właścicielem problemu — czy nazwiesz go epikiem, czy historyjką, czy jakkolwiek. Naprawdę mają na własność problem i jego rozwiązanie od początku do końca.
Brian: Dokładnie.
Rasmus: To przesunięcie własności i odpowiedzialności na inżynierów, żeby naprawdę im zależało i żeby rozumieli, co budują — zamiast być dżokejami ticketów.
RPIV a BMAD: te same idee, inne nazwy
Cole: Mamy sporo pytań na czacie. Rasmus, może wybierz jedno, a ja odniosę się do bardziej ogólnego pytania Sandra, bo zadał naprawdę dobre.
Brian, nie wiem, czy wiesz, ale mamy w społeczności kurs Agentic Coding, gdzie uczę wielu z tych filozofii, którymi dzielisz się przez BMAD — pełnego cyklu życia wytwarzania oprogramowania z AI. Sander pyta o związek między RPIV a BMAD. RPIV to jeden z podstawowych akronimów procesu w kursie — research, plan, implement, validate, czyli badanie, planowanie, implementacja, walidacja. To główna pętla rozwojowa, a wokół niej w kursie uczymy tego, o czym tu mówimy — po lewej stronie epików, specyfikacji i ticketów. BMAD to inne podejście do dokładnie tej samej rzeczy, i to bardzo podobne. To jeden z głównych powodów, dla których Brian tu jest: dzielimy wiele wspólnych idei i filozofii wprowadzania AI do cyklu wytwarzania.
Brian: Uwielbiam ten akronim, świetny. I tak, w stu procentach to samo. Patrzę na „research, plan, implement” — u nas nazywamy to analitykiem i analizą, a analiza obejmuje research. Obejmuje też ideę PR-FAQ i w ogóle pytanie: czy powinniśmy to budować i czy budujemy właściwą rzecz?
Pracowałem przez jakiś czas w NASA, w niezależnej weryfikacji i walidacji. IV&V — czyli weryfikacja i walidacja — sprowadza się do pytań: czy budujemy właściwą rzecz i czy zbudowaliśmy ją właściwie? Uważam, że przy tym przyspieszeniu warto mieć to w swoim przepływie. Research i planowanie na wejściu muszą obejmować pytanie, czy w ogóle powinniśmy to budować. Może zrobiłeś to przed RPIV — ale robisz to tak czy inaczej. Masz pomysł i naprawdę warto badać nie tylko „jak to zrobić”, ale i „czy to robić”. Czy jest dopasowanie do rynku? Tak, prototypowanie i budowanie są szybkie, ale wciąż kosztują czas i pieniądze, które mógłbyś przeznaczyć na coś innego.
Mamy dużo takich rzeczy w BMAD, choć analiza jest opcjonalna — jak wszystkie fazy. Ale sedno — plan, implementacja i walidacja — jest kluczowe i jest w BMAD w stu procentach. Inne nazwy, widziałem inne akronimy w innych frameworkach, ale wszystko sprowadza się do tego samego: zrozum, co chcesz, zaplanuj, zaimplementuj i zwaliduj. A walidacja to temat sam w sobie — cała prawa strona.
Rasmus: To osobny problem inżynierski. Trochę to opisałeś: zbuduj CI, zbuduj infrastrukturę testową, żeby wyłapywać rzeczy po tej stronie.
Samodoskonalenie systemu i jakość skilli
Rasmus: Mamy tu pytanie od Seana: jak BMAD radzi sobie z samodoskonaleniem? Jego docelowy przepływ, RPI, ma mechanizm przeglądu systemu, który aktualizuje skille, CLAUDE.md, AGENTS.md i tak dalej. Jak myślisz o samodoskonaleniu, ulepszaniu systemu, poprawie pętli zewnętrznej?
Brian: To coś, w co dopiero teraz naprawdę wchodzimy, rozwijając własne skille. Nie mamy skilli, które same siebie aktualizują, ale to temat, któremu się przyglądamy.
Ciekawy jest nasz BMAD build, bo ma w sobie pętle. Rozmawia z tobą, bierze twój plan albo po prostu przyjmuje go w gotowej postaci i buduje. I tu osobny, bardzo ciekawy temat: sposób, w jaki piszesz specyfikacje, jest bardzo ważny i może dać duże oszczędności. To, jaką dokumentację masz w repozytorium, robi różnicę — i prawdopodobnie nie jest to to, co uważasz za dobre, bo nawet to, co sami głosiliśmy w przeszłości, jest dziś w stu procentach błędne, po prostu przez to, jak wyewoluowały modele i harnessy.
Kiedy masz dobre kryteria akceptacji w specyfikacji, BMAD build zapętla się: próbuje zbudować, uruchamiamy przeciw temu różne „soczewki” przeglądu, po czym automatycznie domyka albo powtarza pętlę i daje dużo lepszy wynik. Różne soczewki przeglądu pomagają twojemu buildowi.
Co do pętli samodoskonalenia, Sean — to świetny pomysł. Jeśli chodzi o budowanie i ulepszanie skilli albo systemów pamięci, technik jest mnóstwo. To wszystko są narzędzia w twojej skrzynce, o których warto wiedzieć. Rasmus, Cole — co wy robicie ze swoimi skillami?
Rasmus: Mam tu swoje zdanie, mamy je też w naszym kursie i stąd bierze się RPIV. W kursie mamy dwa sposoby ulepszania systemu. Jeden jest oportunistyczny i obejmuje cały system — skanuje go pod kątem wad i sposobu, w jaki używasz harnessa, przegląda logi i tak dalej, a potem sugeruje usprawnienia. Drugi to ulepszanie pętli wewnętrznej, które sprawdza pojedynczą pętlę budowania albo pojedynczą pętlę RPIV: twój plan, twoje skille do planowania, implementacji i budowania — porównując je z logami tej sesji.
I żaden z nich nie aktualizuje się automatycznie. Oba tylko sugerują zmiany, którym możesz się przyjrzeć. Nie wierzę w automatycznie aktualizujące się skille — bo o Opusie moglibyśmy rozmawiać kilka godzin. Jeśli uruchomisz taką pętlę na Opusie, po kilku rundach będziesz miał… bardzo taki skill. To nie jest dobry pomysł.
Brian: Czy próbowałeś Hermesa? Nie używałem go dużo, ale słyszałem, że ma samoewoluujące skille.
Rasmus: Używałem Hermesa do pewnego stopnia. Nie używam żadnych mechanizmów samodoskonalenia, nie wierzę w nie. To znaczy działa to jako tako przez pierwsze kilka rund, ale potem gnije, bo dokłada deterministyczne bloki do rzeczy, które nie mają być deterministyczne. Albo robi wszystkie te rzeczy, co do których masz swoje zdanie, i dokłada coś zupełnie innego, niż chciałeś. Jestem bardzo wybredny co do swoich skilli. Mam własną wersję czegoś w rodzaju BMAD, nazywam to PRP — mój własny framework.
Brian: Podniosłeś mnóstwo wątków. Opus — Opus namieszał w wielu rzeczach. Co do budowania skilli w ogóle, powiem tak: nawet Fable, i pewnie Mythos też, nie mają dobrych danych treningowych na temat tego, czym jest dobry skill. Stuprocentowy slop. Nowe modele są trenowane na danych, w których skille już występują, i one wiedzą, czym są skille — a nadal produkują slopowe skille.
(Informacja dodatkowa: Fable i Mythos to nazwy modeli wymienione w rozmowie; Fable to jeden z modeli Anthropic.)
To nie znaczy, że nie da się każe modelowi zrobić dla ciebie świetnego skilla. Możesz kazać mu przejrzeć logi sesji i zbudować skill — zadziała, ale nie będzie optymalny. Nie będzie dobrze napisany, będzie rozdęty i przesadzony.
Zbudowałem BMAD Builder — ma sporo walidacji pomagających pisać skille. Miałem tam też, chyba to wyciąłem, pętlę samodoskonalenia opartą o ewaluacje: zaczynasz od bardzo chudego skilla, uruchamiasz ewaluacje, a przy porażce któregoś testu — rozwój skilli sterowany ewaluacjami — system powoli dokłada nowe rzeczy, aż skill spełnia potrzeby. Wciąż wierzę w tę technikę, ale uważam, że nie jest jeszcze w pełni gotowa, żeby być stuprocentowo skuteczna. Nie działa to najlepiej.
Najlepsze, co znalazłem do tworzenia skilli, to dwa podejścia. Pierwsze: zacznij od modelu, porozmawiaj z nim, użyj czegoś w rodzaju BMAD Buildera — czegoś, co naprawdę cię wypytuje, wyciąga z ciebie odpowiedzi i rozumie, jaka jest twoja definicja dobrego skilla. Ile linii? Nie bądź rozwlekły. Używaj progresywnego ujawniania. Opinii jest mnóstwo — rozmawialiśmy o tym, jak różnie ludzie rozumieją samo pojęcie skilla. Więc zrób to, poświęć czas i ręcznie dopracuj efekt.
Drugie podejście: po prostu rzeźb skille ręcznie. Wiem, że to brzmi archaicznie i barbarzyńsko, ale ja bym zaczął tak. Najpierw po prostu porozmawiaj z modelem. Czy on to robi? Czy w ogóle potrzebujesz tego skilla? Jeśli nie — świetnie. A jeśli okazuje się, że musisz mu powtarzać pewne rzeczy, zacznij od zwykłego pliku markdown i po prostu zapisz te kilka rzeczy.
Mówię to wszystko, bo dokładnie jak ty powiedziałeś o Opusie i Fable: myślałem, że to będą niesamowite modele, które wreszcie napiszą za mnie skille — a ja nienawidzę tego, jak one piszą skille. Choć znowu: te skille mogą działać. Mam obsesję na punkcie jakości i chudości skilli, zwłaszcza że wiem, iż będzie ich używać dużo ludzi, więc myślę o marnowaniu tokenów.
Cole: Ludzie coraz bardziej dbają o efektywność tokenową.
Brian: Są jednak bardzo popularne skille, które uwielbiam i których używam — jak skill „30 dni”. Bardzo go polubiłem. Chyba nie powinienem go polecać, bo podejrzewam, że łamie warunki korzystania z Reddita i paru innych miejsc, ale to świetny skill, jeśli chcesz zbadać, co działo się w ostatnich 30 dniach. Jakoś zbiera dane z Twittera i Reddita, więc pozdrowienia dla autora. Ale jeśli spojrzysz na sam skill — to rozdęty bałagan. Są tam rzeczy, które po prostu marnują uwagę modelu, i aż dziwne, że działa tak dobrze, jak działa. Czasem się zastanawiam, czy nie przesadzam z tą jakością skilli, skoro i tak robią robotę.
Ale jeśli zamierzasz używać skilli w agentach działających na produkcji albo twoja firma się na nich opiera — poświęć czas i napisz je porządnie.
Rasmus: Zgadzam się. Piszę skille codziennie i codziennie je edytuję. Robię to od ponad dwóch lat. Nie zawsze nazywały się skillami, ale od dwóch lat edytuję swoje pliki markdown.
Brian: To w gruncie rzeczy prompty, prawda? Wdałem się kiedyś w spór, czy skille są promptami, czy nie. Co wy sądzicie? To prompty?
Rasmus: Tak. Zawsze mówiłem, że skille, komendy, pliki reguł, prompt systemowy — wszystko to kolejny plik markdown. To po prostu inny sposób ładowania.
Brian: Wszystko to prompty wpychane do maszyny.
Rasmus: Dokładnie.
Brian: Dlatego śmieszy mnie, gdy ludzie mówią, że „prompt engineering umarł”. To jest podstawowy prymityw wszystkiego — czy mówimy o pętlach, harnessach, czy grafach, na końcu prymitywem jest prompt. Co innego mamy do włożenia do maszyny?
Cole: Jeśli chcemy być naprawdę drobiazgowi, jedynym prymitywem, który nie jest promptem, jest hook — bo to jedyna rzecz dokładająca determinizm do kodowania z AI. Ale dosłownie wszystko inne — subagenci, reguły, skille — to tylko prompty, tylko markdown.
Rasmus: To markdown, któremu możesz coś towarzyszyć. Bez trudu wbudujesz w skill mały CLI albo skrypt i nauczysz agenta go używać. Ale to wciąż tylko instrukcja, jak coś zrobić.
Rasmus: Jeszcze jedno, żeby zamknąć wątek samodoskonalenia — jak robię to ja. Uruchamiam swoje pętle mając otwarte dwa projekty: jeden z wszystkimi moimi skillami i drugi, nad którym pracuję. Kiedy zauważam, że coś zrobił źle albo zrobił coś w określony sposób, loguję to jako zgłoszenie wraz z dowodami w repozytorium moich skilli. Potem dochodzę, dlaczego tak zrobił, i poprawiam repozytorium skilli. Bardzo rzadko wchodzę i ręcznie edytuję kod w prawdziwym projekcie. Po prostu wyrzucam wynik i uruchamiam pętlę jeszcze raz — na tym samym problemie, ale z nowym skillem — i sprawdzam, czy działa.
Brian: Świetna technika. Chyba wszyscy powinni się jej nauczyć i robić coś podobnego.
Myślenie systemowe, „taste” i to, kto sobie nie radzi
Cole: Mamy kolejne dobre pytanie od Sandra. Gdybyś miał polecić jedną umiejętność osobom budującym z AI, co by to było? Myślenie systemowe czy umiejętność abstrahowania pomysłów?
Brian: Ciekawe pytanie. Myślenie systemowe kontra abstrahowanie — one są ze sobą naprawdę powiązane. Uważam, że myślenia systemowego można się nauczyć, ludzie mogą się w tym poprawiać. To pojęcie abstrakcyjne, ale nie powiedziałbym, że albo się to ma, albo nie. Powiem natomiast, że to jest wyróżnik, który widzę wśród pracujących inżynierów. Maluję to bardzo grubym pędzlem, ale po niektórych po prostu widać: to są myśliciele systemowi, potrafią abstrahować i myśleć o pracy w systemach.
To bardzo ważna umiejętność do rozwijania, bo jeśli robisz to zawodowo, myślenie systemowe sięga dużo dalej niż to, jak skłonić agenta do posłuszeństwa, jak pisać skille czy jak tworzyć oprogramowanie — sięga tego, jak działają i łączą się byty biznesowe. Uważam, że to świetna umiejętność i naprawdę wymaga abstrahowania. Nie widzę tu więc przeciwstawienia, ale uważam, że to da się w sobie rozwinąć.
Cole: Sander chyba właśnie łączy te dwie rzeczy, a nie przeciwstawia. Dodam coś od siebie: programiści, którzy najbardziej męczą się z adopcją AI i którzy są najbardziej narażeni na utratę pracy, to ci, którzy najbardziej gubią się w szczegółach. Mają obsesję na punkcie składni i języków programowania — czyli rzeczy, którymi w dużej mierze zajmuje się już AI. To ludzie, którzy byli ważni i wciąż do pewnego stopnia są, ale byli naprawdę ważni dlatego, że to do nich zespół szedł z prośbą „napisz mi szybko ten skrypt”. To ci dżokeje ticketów, o których mówiłeś, Brian: brali ticket i przelatywali przez niego, bo umieli napisać cały kod bez zaglądania na Stack Overflow. Potrafią doprowadzić rzecz do końca, świetnie wykonują instrukcje i wiedzą, jak działać.
I to właśnie oni mają teraz największy problem — bo osoby myślące swobodniej i wyżej, czyli systemowo, lepiej prowadzą agentów i mniej ciągnie ich do walki z agentem i robienia wszystkiego samemu.
Jeśli to ty — a byłem taki sam, powiem szczerze, byłem osobą bardzo dumną z tego, ile znam składni TypeScriptu i Pythona…
Brian: To była nasza tożsamość, prawda? Obaj wychodzimy z tej ścieżki zawodowej.
Cole: Dokładnie. Musiałem to porzucić i powiedzieć sobie: nie obchodzi mnie, ile znam języków programowania ani jak łatwo mi zaimplementować programowanie obiektowe czy wzorzec singletona — rzeczy, które agenty rozwalają w drobny mak. Może ważne jest, żebyś umiał rozpoznać, kiedy chcesz użyć danego wzorca projektowego — ale już go nie implementujesz. Musiałem zmusić się do coraz mocniejszego skupienia na myśleniu wyższego rzędu i to się oczywiście opłaciło.
Brian: W większości się zgadzam. Trudna sprawa dla kogoś, kto właśnie wchodzi do branży. Nie wiem, czego uczą na uczelniach. Trochę się boję, bo ktoś mi powiedział, że uczą BMAD na kursie, a ja na to: „Okej, to dziwne”. Mam nadzieję, że uczą czegoś więcej. Zasmuciło mnie, kiedy powiedzieli, że to było coś w rodzaju „vibe coding 101” — nie, nie, to nie jest vibe coding.
Cole: Uczelnie nie ogarniają, co się dzieje. Cóż za niespodzianka.
Brian: Ale mam nadzieję, że nadal uczą wzorców projektowych, bo to właśnie zahacza o myślenie systemowe. Modny termin, który bardzo lubię, to „taste” — i to nadal wiąże się z wychwytywaniem dobrego i złego kodu, zapachów kodu, wzorców. Wyrosłem zawodowo na słuchaniu ludzi takich jak Bob Martin — Wujek Bob, wielu go pewnie zna — który zawsze używał określenia „software craftsmanship”, rzemiosło programistyczne. Uważam, że to wciąż jest aktualne, choć nie w tej samej postaci co dawniej.
(Informacja dodatkowa: „taste” to smak, wyczucie jakości — umiejętność rozpoznania, że coś jest dobrze albo źle zrobione, mimo że działa.)
Nadal ważne jest rozumienie czystego kodu i zasady DRY, i dbanie o te rzeczy — ale niekoniecznie obsesyjne roztrząsanie wszystkich detali. Widzę jednak, i ostatnio przypomina mi o tym zwłaszcza Opus, że może nadchodzić „slop apocalypse”.
„Slop apocalypse”, komentarze i refaktoryzacja
Brian: Dam kluczowy przykład. Zawsze byłem bardzo przeciwny komentarzom w kodzie. Uwielbiam kod samodokumentujący — czyli dobre nazwy zmiennych, może nagłówek funkcji. Ale pracowałem w miejscach, gdzie standardem — to stara rzecz, wiele sklepów javowych kiedyś tak robiło — było pisanie komentarza przy niemal każdej linii. Doprowadzało mnie to do szału. Cieszyłem się, kiedy czysty kod i te wszystkie idee się upowszechniły.
I nagle, wraz z Opusem 5 i jego skłonnością do gadania bez sensu, komentarze zaczęły być wpychane do całego kodu. Wielu ludzi tego nie zauważyło, bo narzędzia do przeglądu kodu w rodzaju CodeRabbita tego nie wyłapywały.
Dlatego samo wiedzenie o takich rzeczach jest ważne. Wiedza o tym, dlaczego komentarze mogą być złe, staje się naprawdę istotna, kiedy zaczynasz dokumentować kod, kod się zmienia, a komentarze nie są aktualizowane — co LLM też będzie robił, uwierz mi. Wtedy zaczyna się napięcie: model walczy sam ze sobą, co jest źródłem prawdy — dokumentacja czy komentarze? — i pojawiają się problemy z uwagą.
Dlatego mówię, że wciąż warto czasem po prostu spojrzeć na kod. Jedną z rzeczy, które chcę wprowadzić do BMAD, jest dobry skill refaktoryzacyjny odpalany na koniec epika, kiedy wszystko już jest zrobione — można to zrobić nawet po tym, jak rzecz jest na produkcji i działa dobrze.
Widzę to w całej branży: ludzie nie wracają i nie refaktoryzują tego, co wchodzi do kodu. I tu, moim zdaniem, zaczną się rozbijać o „slop apocalypse”. To się nie objawi zepsutym kodem ani tym, że agent nie umie czegoś zaimplementować — objawi się większym zużyciem tokenów, większą liczbą cykli i spowolnieniem.
Więc, Cole, zgadzam się z tobą w stu procentach: myślenie systemowe, ale też posiadanie i rozwijanie smaku. Jeśli jesteś product managerem i nigdy nie byłeś programistą, możesz nauczyć się tego smaku — widzę ludzi, którzy to robią. Nie mów agentowi po prostu „stosuj czysty kod”. Po pierwsze, nie musisz mu tego już mówić — to praktycznie nic nie daje, wbrew temu, w co wierzyliśmy rok temu. Ale warto porozmawiać z Claude’em i zapytać: „Claude, czym są koncepcje czystego kodu? Na co powinienem zwracać uwagę?”. Zacznij się tych rzeczy uczyć i sam ich wypatrywać, albo zacznij stroić swoje agenty do przeglądu kodu tak, żeby naprawdę tego szukały — bo to przerażające, na co one nie patrzą.
Rok temu miałem błędne zdanie, że to nie ma znaczenia, bo w pewnym momencie i tak cały kod będzie utrzymywany przez agenta. Ale, jak mówiłeś, Rasmusie, przynajmniej w tej chwili nawet najlepsze modele osiągające 90% na benchmarkach kodowania produkują slop, który będzie się z czasem kumulował. Więc to od nas, inżynierów, zależy ten smak. I nie sądzę, żeby to szybko odeszło. Mogę się mylić, ale bardzo mocno zmieniłem zdanie w tę stronę.
Dark factory, software factory i „human on the loop”
Brian: Dlatego widzę też, że ludzie wycofują się z tezy, że „dark factory” to szczyt góry. Już tak nie mówię. Nie używam nawet określenia „dark factory”, bo jeśli spojrzeć, czym dark factory jest w science fiction, to chyba nikt tego nie chce — bo prawdziwa dark factory oznacza, że cała fabryka sama wymyśla, co robić dalej i co ma sens. Uważam więc, że „software factory” to lepszy termin. Ale nawet to nie jest szczyt. Naprawdę wierzę, że human on the loop jest tym, do czego warto dążyć: przejście od człowieka w pętli do człowieka nad pętlą, przy zachowaniu kontroli.
(Informacja dodatkowa: „dark factory” — fabryka „bez świateł”, działająca całkowicie bez ludzi; w kontekście AI: proces, w którym specyfikacja wchodzi, a gotowy kod wychodzi bez udziału człowieka.)
Rasmus: Sporo eksperymentowałem z dark factories. Zgadzam się, że „software factory” może być lepszym terminem. Wciąż próbuję ustalić, czy to szczyt, czy nie.
Brian: Myślę, że to szczyt dla jednostki. Ale zapytam cię: czy dark factory obejmuje też pisanie specyfikacji i decydowanie, co budować?
Rasmus: Nie. Dark factory to: specyfikacja na wejściu, gotowy kod na wyjściu.
Brian: Właśnie. I to nadchodzi. Dlatego nie nazywam tego już dark factory.
Rasmus: To już jest tutaj — dopóki twoja pętla budowania jest dobra. Wciąż siedzisz po lewej i po prawej stronie tej pętli i wciąż musisz decydować, co faktycznie zostanie zmergowane. Choć w pewnym momencie duża część tego może też zostać zautomatyzowana.
Brian: Zdecydowanie zostanie zautomatyzowana. Nasza wartość jest po lewej — w decydowaniu, co budować i dlaczego.
Rasmus: Prawdziwy problem z w pełni ciemną fabryką, w której cała lewa strona też jest zautomatyzowana, brzmi: kto będzie rozmawiał z klientami?
Brian: Dokładnie. Albo polegasz na jakichś sygnałach.
Rasmus: Czy możemy budować takie systemy? Oczywiście.
Brian: Ale nie sądzę, żebyśmy chcieli w każdym przypadku. To trochę mój purystyczny stosunek do tego, skąd ten termin się wziął — z science fiction. Ale zgadzam się: to nie jest szczyt. Jak mówi Rasmus, jesteśmy tam już teraz i uważam, że każdy może i powinien poeksperymentować z budowaniem własnej software factory, która weźmie specyfikację i doprowadzi ją aż na produkcję. Pytanie brzmi: co musisz zrobić, żeby zagwarantować właściwe bramki i żebyś temu ufał — i to w prawdziwym systemie produkcyjnym w firmie, nie w projekcie hobbystycznym. O czym musisz pomyśleć, żeby spokojnie spać, bez obaw, że to zadanie, które wrzuciłeś we wtorek o piątej po południu — bo Claude uwielbia mówić o wtorkach — sprawi, że w środę wszystko będzie się palić? Ustal, co jeszcze musisz wstawić w proces, żeby tam dojść.
Product taste i to, w czym AI jest wciąż słabe
Rasmus: Chcę odnieść się do jeszcze paru rzeczy. Ja przychodzę z drugiej strony spektrum — cztery lata temu byłem product managerem. Dla mnie „taste” zawsze dotyczył smaku produktowego. To też musi wejść do tego procesu: nie chodzi tylko o to, jak napisany jest kod i jak ma wyglądać — to oczywiście ważne — ale smak produktowy jest równie ważny. Jak twój produkt ma się „czuć”? Jak ma wyglądać? A to są rzeczy, w których AI jest obecnie naprawdę słabe. Jest bardzo słabe w budowaniu interfejsów, które dobrze się „czują”, jeśli nie jesteś skrajnie precyzyjny w tym, czego chcesz.
Więc potrzebujesz smaku produktowego, aż po smak w kodzie. Główne rzeczy, których musiałem się nauczyć przez ostatnie cztery lata, to dokładnie to, co opisałeś: inżynieria systemów, projektowanie architektury, jak wygląda dobry kod. Mam już w swojej pętli krok upraszczania, który opisałeś — automatyczną refaktoryzację w stylu: nie zmieniaj funkcjonalności, po prostu spraw, żeby wyglądało czyściej. W buildzie mam też na końcu zakres przeglądu komentarzy: jeśli komentarz opisuje kod, to komentarz nie powinien tam być — to kod powinien się opisywać.
Brian: To podstępne, co zaczyna się przemycać wraz ze zmianami modeli i harnessów. Nie chcę katować tego martwego konia z komentarzami, ale jestem na to wściekły, bo wcześniej działało dobrze. To zresztą przypomina to, co ktoś powiedział — może Boris albo Karpathy — że za każdym razem, gdy wychodzi nowy model, naprawdę trzeba wyrzucić swój AGENTS.md.
Rasmus: To był Boris.
Brian: Wyrzuć to, co steruje twoimi skillami. Nie musisz wyrzucać wszystkich skilli, ale wyrzuć to, co nimi steruje, zrób od nowa i zobacz, czego potrzebujesz i jakich nowych rzeczy. Nie wszystko robi się lepsze. To wniosek, jaki wyciągnąłem z tej opusowej wpadki, kiedy model zaczął wpychać slopowe komentarze do kodu — a wiem, że z czasem będą one szkodliwe.
Prompty systemowe, zmienność modeli i wielomodelowość
Rasmus: O tym też możemy chwilę pogadać, bo Anthropic wyraźnie usunął 80% swojego promptu systemowego. Chwilę później wypuścili Opusa 5, po czym trochę się wycofali — nie dodając rzeczy z powrotem do promptu systemowego, napisali ogromny wpis blogowy o tym, co trzeba powiedzieć Opusowi, żeby nie dawał ci slopu. Mają tam sporo instrukcji, co zasadniczo powinieneś sam dołożyć z powrotem do swojego promptu systemowego. U mnie ograniczanie promptów sprawdzało się bardzo dobrze przy Sonnecie i Fable, ale za każdym razem, gdy używam Opusa, promptuję dziś więcej niż wcześniej.
Brian: To dyskusyjna sprawa. Myślę, że po części to model, a po części prompt systemowy. Coś w modelu naprawdę wydaje się inne i nie sądzę, żeby chodziło wyłącznie o usunięcie części promptu systemowego. Są repozytoria na GitHubie publikujące to, co uważa się za aktualny prompt systemowy, i faktycznie wygląda na to, że usunięto 80%. A z tego, co zostało w prompcie Anthropica, większość wydaje się dotyczyć workflows. Nie tylko drastycznie go skrócili, ale wstawili całą tę maszynerię do obsługi tych świetnych przepływów. Uwielbiam nową funkcję workflows w Claude — jest magiczna, bardzo fajna. Ale co w takim razie wycięli?
Dosłownie wczoraj albo przedwczoraj wypuścili nowy styl wyjścia, który faktycznie działa — nazywa się „concise”. Ich domyślny zawsze zawierał słowo „concise”, ale wszyscy wiemy, że przy Opusie 5 zwięzły nie był. Nowy przez ten dzień, w którym go używam, działa świetnie. Nie musisz więc wymyślać własnego — jeśli używasz Claude’a i jeszcze nie próbowałeś, sprawdź nowy styl wyjścia „concise”. Jest wspaniały.
Rasmus: A czy on faktycznie się utrzymuje przez kolejne tury?
Brian: To muszę jeszcze zbadać, dopiero zacząłem go używać — chyba wczoraj. Zobaczymy, jak długo się trzyma, bo miałem mnóstwo problemów ze stylami wyjścia i chyba właśnie do tego zmierzasz: po dwóch, trzech turach znowu jest gadatliwy.
Co do promptu systemowego — powiem jedną rzecz o BMAD: nigdy nie budowałem go wyłącznie pod Claude’a. To ma wady, ale ma też zalety, zwłaszcza dla dużych firm. Wiele przedsiębiorstw ma umowę z OpenAI albo z Anthropic. To naturalne i dobre, bo dostajesz rabaty wolumenowe i cały ekosystem — ale jesteś też uwiązany, kiedy oni coś zmienią. Widzę teraz, że wiele firm uświadamia sobie, że potrzebuje zapasowego rozwiązania i wielomodelowości.
To zabawne: większość firm była przez ostatnie 20 lat na jednej chmurze i nie miała z tym problemu. Ale rok w tej zmienności modeli i harnessów uświadamia im, że stawianie wszystkiego na jednego dostawcę to loteria. Po pierwsze, wszyscy działają na dotowanych marżach, trzymają koszty w ryzach i bez przerwy przestawiają dźwignie. Kiedy ostatnio mieliśmy płatny produkt software’owy, który zmieniał się codziennie i to tak drastycznie? To bardzo ciekawa przestrzeń, ale musimy z tym żyć.
BMAD nie jest więc pomyślany jako specyficzny dla Claude’a, choć jego używam najwięcej. Staramy się, żeby działał z chińskimi modelami, z modelami otwartymi, z francuskimi, z Qwenem i Codeksem. Mocno w to wierzę i nie chcę stawiać wszystkiego na jedno. To oznacza, że jeśli ty jesteś całkowicie na Claude Code, możesz przez własną konfigurację wstawić hooki dobrze współpracujące z BMAD albo z twoimi skillami. Używamy technik działających wspólnie dla wszystkich — na przykład popychamy modele do używania subagentów we właściwych miejscach w naszych skillach, ale nie używamy języka specyficznego dla Claude’a czy Codeksa. To może się w przyszłości zmienić, ale prompty systemowe nie uderzyły w nas zbyt mocno — poza rozwlekłością dokumentów, nad czym pracujemy. Staramy się pisać skille tak, żeby nie były zbyt wrażliwe, bo działają praktycznie na wszystkich modelach. Więc kiedy jeden harness albo jeden model położy sprawę — jak trochę stało się przy tym wdrożeniu Opusa — nie odbija się to na nas aż tak.
Uruchamianie skilli i subagenci
Rasmus: Problem, który mam od kilku tygodni w moim frameworku, polega na tym, że Codex i Claude — a to też zależy od modelu Claude’a — zachowują się bardzo różnie, jeśli chodzi o to, kiedy i jak uruchamiają skille i jak dobry musi być twój wyzwalacz, żeby skill faktycznie odpalił wtedy, kiedy chcesz. To samo z agentami: Codex zasadniczo używa subagentów do wszystkiego, nawet gdy nie chcesz, a Claude prawie nigdy ich nie używa.
Brian: Claude jeszcze niedawno wstawił do swojego promptu systemowego coś, co doprowadzało mnie do szału: nawet gdy w moich skillach było napisane „użyj subagentów do X, Y, Z”, Claude miał w prompcie systemowym „używaj subagentów tylko wtedy, gdy użytkownik ci każe”. Kiedy pierwszy raz mi to powiedział, myślałem, że halucynuje, ale widziałem to wielokrotnie, a Paul pokazał mi dokładnie to sformułowanie. Musiałem więc wpisać do swojego AGENTS.md coś w rodzaju: „Napisałem te wszystkie cholerne skille, więc mówię ci — używaj subagentów, kiedy tylko uznasz to za stosowne, a jeśli skill ci to mówi, załóż, że to ja ci to każę”. Sformułowałem to pewnie lepiej, ale pomogło i ten komunikat przestał się pojawiać.
I tu właśnie sedno: budujemy te narzędzia, będąc na łasce zmiennych kaprysów. Nadążanie za tym jest, szczerze, wyzwaniem. Różnica między Codeksem a Claude’em jest taka, że oba są mocno opiniotwórcze i mają inne filozofie. Jeśli używasz obu, naprawdę to widać. Claude’a mogę skłonić do wcielania się w różne persony i odgrywania ról, co lubię — wiem, że niektórzy tego nie znoszą. A Codex, nawet jak twój skill mówi „nazywasz się tak i tak i robisz to”, po prostu nie chce wejść w personę. I to jest w porządku — może wolisz jeden styl od drugiego. Ciekawe wyzwanie.
Rasmus: Uważam to za skrajnie irytujące i trudne. Musiałem zaadresować to na wielu poziomach, zwłaszcza przy Claudzie, bo mam skille, których chcę używać zawsze — na przykład mój skill do PR-ów przy każdym pull requeście. Musiałem to umieścić na wielu poziomach: dopisać do promptu systemowego, wpisać do CLAUDE.md — i w projekcie, i globalnie — i w wyzwalaczu skilla. I dalej nie robi tego za każdym razem.
Brian: Nigdy zbytnio nie polegałem na automatycznym odpalaniu skilli, choć miałem z tym mniej problemów. Traktuję je bardziej jak komendy — uruchamiam skill wtedy, kiedy chcę. Do tego stopnia, że w części naszych skilli zmieniamy opis tak, żeby prawie nigdy nie odpalały się automatycznie, bo tak mają być używane.
W BMAD mamy persony. Możesz z personą rozmawiać, i kiedy mówię analitykowi, że chcę zrobić burzę mózgów, on wewnętrznie po prostu wywołuje odpowiedni skill po nazwie — i to działa prawie w stu procentach. Ale jeśli chcę popracować nad PRD, po prostu wpisuję /prd. Przywykłem do tego, choć uwielbiam wejście głosowe — i tu robi się problematycznie. Ogólnie jednak uważam to za niezawodne: jeśli znam nazwę skilla i powiem „chcę stworzyć to” albo „popracować nad tamtym”, to przeważnie trafia. Ale irytujące, jeśli nie trafi.
Rasmus: W normalnym użyciu, kiedy siedzę w jednej sesji i przechodzę przez coś krok po kroku, to nie problem. Problemem jest to, że moje skille są zbudowane w dwóch warstwach. Mam skille prymitywne i skille kompozycyjne. Prymitywne to build, „stwórz PRD”, „stwórz specyfikację”, „implementuj”, „waliduj” — jakkolwiek się nazywają. A skille kompozycyjne wywołują tamte w określonej kolejności, czyli są rodzajem orkiestratora.
I to przy uruchomieniu skilla kompozycyjnego mam ten problem — bo wtedy odwracam wzrok. Chcę wtedy, żeby po prostu wykonał instrukcję, którą mu dałem, aż PR będzie gotowy, przejdzie przez X pętli przeglądu i będzie gotowy dla mnie do obejrzenia. W tym cyklu pojawia się problem. Kiedy siedzę z agentem, problemu nie ma, bo znam nazwy swoich skilli i wywołuję je, gdy trzeba. Ale kiedy uruchamiam to w trybie autonomicznym, mam ten problem cały czas.
Brian: Człowieku, to mógłby być temat na całą osobną rozmowę. Chętnie bym o tym z wami pogadał, ale wiem, że zostało nam jakieś dziewięć minut.
Jak przekonać seniora, który nie myśli systemowo
Cole: Będziemy musieli zrobić kolejny warsztat, jest jeszcze tyle tematów. Zakończmy pytaniem z czatu. Eric pyta: jak mentorować seniorów, którzy nie myślą systemowo, żeby przyjęli frameworki takie jak BMAD czy RPIV? Chodzi o ludzi, którzy bardzo grzęzną w szczegółach albo są dumni z tego, że znają składnię, że umieją każdą komendę w Linuksie i te naprawdę skomplikowane komendy Gita, o które prosi twój agent kodujący, a ty mówisz „no dobra, dawaj”. Jak wyciągnąć ich z tej koleiny albo pomóc zmienić nastawienie?
Brian: Powtórzę, co mówiłem na początku, bo obiecuję: widziałem, że to ma transformacyjny efekt. Kiedy rozmawiam z firmami, także we własnej firmie, mówię: dajcie mi najpierw waszych sceptyków — a to zwykle są seniorzy albo ludzie, którzy opierają swoją wartość na znajomości wnętrzności Node’a albo jakichś niszowych rzeczy w Pythonie czy Javie.
I zmuś wszystkich do przejścia przez ten proces: presja sprintu jest zdjęta na najbliższe dwa tygodnie, każdy będzie miał tylko jedno zadanie. Normalnie byłaby to historyjka, która wcześniej zajęłaby ci trzy–cztery dni, ale przez dwa tygodnie to jedyne, co robisz. I robisz to, co opisywałem na początku: nie dajesz im frameworka, nie dajesz gotowców, tylko każesz przez to przejść.
Kiedy zrobiłem to z zespołem, dorzuciliśmy jeszcze parę szczegółów. Robiliśmy codzienne standupy — piętnastominutowe spotkanie na początku dnia, gdy wszyscy są online — ale zamiast codziennego raportu statusu, w co większość standupów się zamieniła (dygresja), każdy dzielił się technikami i tym, czego się nauczył. Do trzeciego, czwartego dnia wytworzył się taki poziom ekscytacji ludzi odkrywających rzeczy na własną rękę, że pod koniec tygodnia czy dwóch większość samodzielnie wymyśliła zasadniczo to, co głosimy z Cole’em. Ludzie sami dochodzą do tych wniosków, jeśli im na to pozwolisz.
To zresztą idea artykułu, który kiedyś napisałem — Rasmus przypomniał mi, że go napisałem, bo zapomniałem — pod tytułem „to problem z przyzwoleniem, nie problem z agentem”. Wielu inżynierów po prostu nie ma czasu, żeby próbować tego raz za razem i wyrobić sobie mięsień. Nie dołączają do społeczności Cole’a, nie oglądają naszych filmów, nie siedzą na naszych Discordach i tego nie chłoną. My wszyscy na tej rozmowie jesteśmy w bańce ludzi, których to obchodzi i którzy to kochają. Ale wielu ludzi ma po prostu pracę od dziewiątej do siedemnastej, ma zobowiązania sprintowe i musi dowieźć.
Daj im więc na to szansę, ale czasem trzeba być stanowczym: „to jedyne, co będziesz robił przez najbliższe dwa tygodnie, musisz spróbować. A na koniec masz mi pokazać, że agent potrafi zbudować i domknąć tę historyjkę samodzielnie, ze zwalidowanym wynikiem”. A jeśli ktoś zrobi to szybciej, niech zrobi to jeszcze raz, wydajniej, i poszuka innych rzeczy.
To prowadzi do eksplozji kreatywności. Ludzie zaczynają myśleć: „cholera, czy naprawdę muszę codziennie rano robić całą tę segregację błędów i przeglądać logi, czy możemy stworzyć do tego agenty?”. Transformacja wykracza daleko poza samą umiejętność używania agenta — uwalnia kreatywność. Ludzie zaczynają tworzyć własne skille, przemyśliwać na nowo narzędzia pod swoje potrzeby, używać Slacka w ciekawy sposób do łączenia różnych rzeczy. To jest tak transformujące, że to uwielbiam.
Powiem jeszcze, że są ludzie negatywnie nastawieni do AI — i słuchajcie, AI ma swoje problemy. To nie jest magia, za jaką sam pewnie brałem to rok temu. Blask opadł, są problemy, są rzeczy, o których mówiliśmy dziś, które trzeba rozwiązać. I są ludzie, którzy chcą, żeby ich rzemiosłem było inżynierstwo oprogramowania. Nie mam im tego za złe. To jak ktoś, kto chce być stolarzem: mógłby użyć maszyny CNC, ale chce narzędzi ręcznych. Nie ma nic złego w byciu takim rzemieślnikiem, jeśli to kochasz — i pewnie nadal będzie na to zapotrzebowanie. Albo: nie rób z pracy tego, co kochasz, bo praca wyssie miłość ze wszystkiego. Jeśli chcesz rzeźbić kod bez AI — rób to. Ale bądź świadom, że zawód poszedł dalej i myślę, że dojdziemy do punktu, w którym trudno będzie tego uniknąć.
Rasmus: Dodam, że jeśli jesteś liderem w firmie i tego słuchasz — zyskasz o wiele więcej, dając te dwa tygodnie. Wyobraź sobie: kiedy te dwa tygodnie miną, wszystko, czego przez ten czas nie wysłaliście, będzie można wysłać o tyle szybciej. Nadgonicie i wystrzelicie do przodu.
Brian: Zwrot z inwestycji jest bardzo dobry.
Cole: Zgadza się. I wszystko, co Brian tu mówi, widziałem u firm, z którymi pracuję. Ludzie się od tego uzależniają — wstępne szkolenie jest jak narkotyk wprowadzający. Firma zmusza programistów do pracy z tymi narzędziami, a oni bardzo szybko je pokochają. Zaczynają budować skille, dzielić się nimi między sobą i budować wspólne repozytorium swoich skilli, subagentów i tym podobnych. To dobry moment, żeby się zatrzymać. To był pięciominutowy mistrzowski wykład Briana o tym, jak nakłonić zespół albo organizację do adopcji agentów kodujących.
Brian: Pięć minut, miliony dolarów zmiany w pięć minut.
Cole: Właśnie tak. Jesteśmy praktycznie na czasie. Jeśli zostały pytania, wrzućcie je w społeczności, w razie potrzeby dopytam Briana. Wygląda na to, że będziemy potrzebować trzeciej sesji.
Brian: Cole, Rasmus — mam nadzieję, że kiedyś przyjdziecie do mojego podcastu i będziemy mogli kontynuować rozmowę. Chętnie dowiem się więcej o tym, co robicie. Te tematy są niesamowicie ciekawe do dyskusji. Dziękuję wam bardzo, to było świetne.
Cole: Dziękuję, Brianie. Dziękuję, Rasmusie. I dziękuję wszystkim za pytania. Sam uczę się razem z wami. Nagranie pojawi się nieco później niż zwykle, bo zmieniłem pewne ustawienia, które wydłużą przetwarzanie. Jeszcze raz dzięki wszystkim, życzę wam wspaniałego weekendu i do zobaczenia w społeczności.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zanim sięgniesz po framework, spróbuj bez niego
Na czym polega: Brian buduje BMAD od lat, a mimo to zaleca, żeby najpierw wyrzucić wszystkie skille i frameworki i zobaczyć, jak daleko dojdziesz z samym modelem i harnessem. Dopiero gdy zobaczysz, gdzie agent zawodzi, dokładasz brakujący kontekst i budujesz proces wokół realnych, a nie wyobrażonych braków.
Jak stosować: Weź jedno zadanie, które normalnie zajęłoby ci kilka dni, i próbuj doprowadzić agenta do końca bez ręcznej ingerencji. Kiedy się wywali, zanotuj, jakiego kontekstu zabrakło — reguły, dokumentu, kryterium akceptacji — dołóż to i zacznij od nowa. Iteruj, aż dojdzie do końca.
Na co uważać: To kosztuje czas i na początku będzie frustrujące. Nie rób tego pod presją terminu — potrzebujesz przestrzeni na porażki, bo dopiero one pokazują, czego naprawdę brakuje w twoim kontekście.
2.Twoja wartość przesuwa się na lewo od kodowania
Na czym polega: Kiedy pętla „specyfikacja na wejściu, kod na wyjściu” zaczyna działać, przewagę daje nie umiejętność pisania kodu, tylko decydowanie, co i dlaczego budować, oraz zdolność wykucia dobrej specyfikacji. Brian obserwował to we własnym zespole: ludzie, którzy byli „dżokejami ticketów”, musieli przedefiniować swoją wartość.
Jak stosować: Zacznij świadomie inwestować czas w to, co dzieje się przed kodowaniem: rozumienie biznesu, ocenę czy rzecz w ogóle warto budować, jakość kryteriów akceptacji. Jeśli prowadzisz zespół, po przyspieszeniu programistów od razu patrz na przepustowość strony produktowej.
Na co uważać: To nie znaczy, że kompetencje techniczne przestają mieć znaczenie — bez nich nie ocenisz, czy specyfikacja jest wykonalna i czy wynik jest dobry. Chodzi o przesunięcie akcentu, nie o porzucenie warsztatu.
3.„Slop apocalypse” objawi się rachunkiem, nie awarią
Na czym polega: Kumulacja maszynowej sieczki — nadmiarowych komentarzy, martwego kodu, nieaktualnej dokumentacji — nie wywali twojej aplikacji. Podniesie zużycie tokenów, wydłuży cykle i po cichu spowolni pracę, bo model będzie walczył sam ze sobą o to, co jest źródłem prawdy.
Jak stosować: Traktuj rosnące zużycie tokenów i liczbę cykli na podobne zadania jako wskaźnik degradacji bazy kodu. Dodaj do procesu krok refaktoryzacji na koniec epika, a nie po każdej historyjce — Brian planuje dokładnie taki skill w BMAD.
Na co uważać: Standardowe narzędzia do przeglądu kodu (Brian wymienia CodeRabbit) tego nie wyłapują, bo nie traktują nadmiarowych komentarzy jako defektu. Musisz świadomie dostroić swoje agenty przeglądowe pod ten konkretny typ problemu.
4.Komentarze opisujące kod to dług, nie dokumentacja
Na czym polega: Opus 5 zaczął masowo wstawiać komentarze do kodu. Problem pojawia się później: kod się zmienia, komentarz nie, i model dostaje sprzeczne sygnały. Rasmus rozwiązał to osobnym krokiem przeglądu komentarzy w swojej pętli.
Jak stosować: Dodaj na końcu pętli budowania krok, który usuwa komentarze opisujące to, co kod i tak mówi. Zasada: jeśli komentarz opisuje kod, komentarz jest zbędny — kod powinien się opisywać sam.
Na co uważać: Nie wylewaj dziecka z kąpielą — komentarze wyjaśniające dlaczego coś zrobiono w nieoczywisty sposób są cenne. Krok czyszczący musi rozróżniać „co robi ten kod” od „dlaczego tak”.
5.Nie ufaj samo-aktualizującym się skillom
Na czym polega: Zarówno Rasmus, jak i Brian odrzucają automatyczne aktualizowanie skilli przez model. Działa to nieźle przez pierwsze kilka rund, a potem gnije: system dokłada deterministyczne bloki tam, gdzie determinizm jest niepożądany, i wprowadza rzeczy sprzeczne z twoimi intencjami.
Jak stosować: Zbuduj mechanizm, który sugeruje usprawnienia, ale nie wprowadza ich sam. Rasmus ma dwa poziomy: opcjonalny skan całego systemu (łącznie z logami harnessa) i przegląd pojedynczej pętli względem logów tej sesji. Ty zatwierdzasz zmiany.
Na co uważać: Im dłużej pętla działa bez nadzoru, tym trudniej zauważyć degradację — zmiany są drobne i każda z osobna wygląda rozsądnie. Regularnie czytaj swoje skille w całości, a nie tylko diffy.
6.Modele wciąż piszą złe skille
Na czym polega: Mimo że nowe modele mają w danych treningowych pojęcie skilla, produkują skille rozdęte i nieoptymalne. Zadziałają, ale będą marnowały uwagę i tokeny. Brian próbował nawet eval-driven development dla skilli — jego zdaniem technika jest słuszna, ale jeszcze niedojrzała.
Jak stosować: Dwa sprawdzone podejścia. Albo użyj narzędzia, które wypytuje cię o twoją definicję dobrego skilla (limit linii, brak rozwlekłości, progresywne ujawnianie) i potem ręcznie dopracuj wynik, albo pisz skille ręcznie od zwykłego pliku markdown. Najpierw sprawdź, czy skill jest w ogóle potrzebny — może model radzi sobie bez niego.
Na co uważać: Rozdęty skill może działać zaskakująco dobrze (Brian daje przykład popularnego skilla „30 dni”), więc łatwo uznać, że jakość nie ma znaczenia. Ma — proporcjonalnie do liczby uruchomień. Dla skilli produkcyjnych albo używanych przez cały zespół chudość zwraca się wielokrotnie.
7.Epik jako jednostka pracy i pody 2–4 osób
Na czym polega: Brian porzucił dwutygodniowe sprinty. Traktuje epik jako mini-inicjatywę, którą jedna osoba lub para prowadzi od początku do końca, a duże zespoły scrumowe rozbija na pody po 2–4 inżynierów posiadających problem na własność.
Jak stosować: Przypisz podowi własność problemu, nie zestawu ticketów. Zadbaj, żeby przynajmniej jedna osoba w podzie myślała produktowo i systemowo — może to być inżynier, nie musi być product manager.
Na co uważać: Model działa tylko przy realnym przekazaniu odpowiedzialności. Jeśli pod „posiada” epik, ale decyzje produktowe dalej zapadają gdzie indziej, otrzymasz te same wąskie gardła w mniejszym opakowaniu. Brian podkreśla też, że w tym modelu jest miejsce dla juniorów — nie traktuj go jako pretekstu do rezygnacji z ich zatrudniania.
8.Dwutygodniowy sprint bez presji jako sposób na sceptyków
Na czym polega: Najskuteczniejsza metoda Briana na przekonanie seniorów: zdejmij presję sprintu na dwa tygodnie, daj każdemu jedno zadanie, które normalnie zajęłoby 3–4 dni, i wymagaj, żeby agent doprowadził je do końca samodzielnie i ze zwalidowanym wynikiem. Codzienne standupy zamień z raportów statusu na wymianę technik.
Jak stosować: Zacznij od najbardziej sceptycznych seniorów. Nie dawaj im frameworka — mają dojść do wniosków sami. Kto skończy wcześniej, powtarza zadanie efektywniej. Po dwóch tygodniach większość samodzielnie odtworzy to, czego i tak byś ich uczył.
Na co uważać: To wymaga stanowczości i realnego zdjęcia zobowiązań — połowiczna wersja („róbcie to obok sprintu”) nie zadziała, bo problemem jest brak czasu, nie brak chęci. I bądź gotów zaakceptować, że część ludzi świadomie wybierze rzemiosło bez AI.
9.Wielomodelowość jako zabezpieczenie przed zmiennością dostawców
Na czym polega: Brian celowo nie buduje BMAD wyłącznie pod Claude’a. Firmy przyzwyczajone do jednego dostawcy chmury odkrywają, że w przypadku modeli i harnessów to ryzykowne — dostawcy działają na dotowanych marżach i bez przerwy przestawiają dźwignie. Jedno wdrożenie modelu potrafi zepsuć działający proces.
Jak stosować: Pisz skille w języku neutralnym wobec dostawcy — bez odwołań specyficznych dla jednego harnessa. Rzeczy specyficzne dla twojego środowiska (hooki, konfiguracja) trzymaj w warstwie konfiguracyjnej, żeby dały się wymienić.
Na co uważać: Neutralność ma koszt — rezygnujesz z części możliwości konkretnego harnessa. Brian zauważa też realne różnice filozofii: Claude wchodzi w persony, Codex nie; Codex nadużywa subagentów, Claude ich unika. Neutralny zapis nie usuwa tych różnic, tylko ogranicza szkody przy zmianie.
10.Po każdym nowym modelu wyrzuć to, co steruje twoimi skillami
Na czym polega: Za Borisem: przy każdym nowym modelu warto wyrzucić swój AGENTS.md i to, co steruje skillami, zrobić na nowo i sprawdzić, co jest faktycznie potrzebne. Nie wszystko robi się lepsze — Opus 5 zaczął dokładać komentarze, których wcześniej nie było.
Jak stosować: Traktuj wydanie modelu jako trigger do audytu warstwy sterującej. Sprawdź, które instrukcje przestały być potrzebne (Brian: „nie musisz już mówić agentowi »stosuj czysty kod«”), a jakie nowe problemy trzeba zaadresować. Sprawdzaj też nowe funkcje harnessa — Brian chwali styl wyjścia „concise” jako lepszy niż samodzielne kombinowanie.
Na co uważać: Nie wyrzucaj samych skilli, tylko warstwę, która nimi steruje. I sprawdzaj, czy nowe ustawienia utrzymują się przez wiele tur rozmowy — Brian i Rasmus zgodnie zauważają, że style wyjścia bywają zapominane po dwóch, trzech turach.