BMad Method

Cześć, tu Alex z DEV STORIES DOT EU. Metoda BMad, odcinek 1 z 15. Większość asystentów AI do pisania kodu wykłada się trzeciego dnia, ponieważ zapominają, po co w ogóle napisali ten kod pierwszego dnia. Kończysz z bałaganem odizolowanych skryptów, które w ogóle do siebie nie pasują. Żeby to rozwiązać, nie potrzebujesz lepszego prompta, potrzebujesz Context Engineeringu i czterech faz. Częstym błędem jest traktowanie metody BMad jako prostego generatora kodu. A wcale tak nie jest. To zwinny pipeline Context Engineeringu. Jeśli po prostu poprosisz agenta AI o zbudowanie feature'a, będzie on zgadywał jego granice. BMad temu zapobiega, stopniowo budując i blokując kontekst w czterech odrębnych fazach. Agent nigdy nie gubi wątku, ponieważ każda faza przekazuje ścisłe, udokumentowane reguły do następnej. Weźmy na przykład tworzenie aplikacji SaaS. Jeśli przejdziesz od razu do kodu, AI może wybrać bazę danych, która narusza twoje wymagania dotyczące rezydencji danych. Context Engineering temu zapobiega. Pipeline zaczyna się od fazy analizy. Tutaj AI pełni rolę analityka biznesowego. Przetwarza twoje surowe pomysły i tworzy Product Requirements Document. Ta faza blokuje kluczowe ograniczenia. Zbiera persony użytkowników, zasady compliance i główne workflowy. Powstały dokument staje się fundamentem dla całej reszty. Kolejna jest faza planowania. Agent wchodzi w rolę Product Ownera. Bierze dokument wymagań i rozbija go na epics i user stories. Abstrakcyjne wymagania zamieniają się w konkretne, gotowe do realizacji zadania. Kontekst się zawęża. AI nie myśli już o całym produkcie, a jedynie o konkretnych jednostkach do dostarczenia, zmapowanych na przejrzystej osi czasu. Tutaj robi się ciekawie. Trzecia faza to Solutioning. AI przejmuje rolę Architekta. Analizuje user stories z fazy planowania i ograniczenia z fazy analizy, aby stworzyć techniczny design. Decyduje o modelach danych, endpointach API i strukturze folderów. W przypadku twojej aplikacji SaaS, ograniczenia biznesowe zdefiniowane w pierwszej fazie mówią Architektowi w trzeciej fazie, jakie dokładnie istnieją granice. To gwarantuje, że wybrana architektura faktycznie pasuje do pierwotnych reguł biznesowych. W końcu docieramy do fazy implementacji. Teraz AI wchodzi w rolę Developera. Agent Developer nie musi zgadywać architektury ani zastanawiać się nad logiką biznesową. Otrzymuje dokładny techniczny blueprint od Architekta. Pisze kod, aby zrealizować konkretne user story, trzymając się precyzyjnych modeli danych i ścieżek plików zdefiniowanych w poprzednim kroku. Ten chain kontekstu to całe sedno sprawy. Informacje przepływają dalej dzięki trwałej dokumentacji. Output jednej fazy staje się ścisłym inputem dla kolejnej. Agent Developer odnosi sukces, ponieważ agent Architekt utorował mu drogę, a Architekt odniósł sukces, ponieważ Analityk Biznesowy zmapował teren. Projektujesz kontekst na każdym poziomie, dzięki czemu AI skupia się wyłącznie na egzekucji. Cechą charakterystyczną odpornego workflow AI nie jest to, jak szybko generuje tekst, ale to, jak ściśle egzekwuje granice na różnych etapach myślenia. Jeśli chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU na platformie Patreon. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórzcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 2 z 15. Możesz pomyśleć, że wdrożenie nowego frameworka AI wymaga zapamiętania ogromnej sekwencji konkretnych komend i sztywnych faz workflow. Wcale tak nie jest. Nie musisz zapamiętywać ani jednej sekwencji komend w tym frameworku, ponieważ system fizycznie sprawdza twój lokalny folder i dokładnie podpowiada, co wpisać dalej. To jest Intelligent Guide i proces instalacji. Rozpoczęcie pracy wymaga tylko jednego kroku. W terminalu uruchamiasz komendę package executora npx bmad-method install. Ta komenda inicjalizuje workspace i strukturalnie przygotowuje twoje repozytorium. Robi to, tworząc dwa konkretne katalogi w twoim folderze root. Pierwszy katalog to underscore bmad. Ten folder to mózg twojego lokalnego frameworka. Zawiera on podstawowe skille, definicje promptów i szablony kontekstowe, których AI używa do swojej pracy. Drugi katalog to underscore bmad dash output. Służy on jako dedykowany folder docelowy. Za każdym razem, gdy framework generuje nowe assety – niezależnie od tego, czy są to dokumenty wymagań produktu, specyfikacje funkcji, czy sam kod – trafiają one do tego katalogu output, bezpiecznie odizolowane od twojego istniejącego kodu źródłowego. I tu jest kluczowa sprawa. Kiedy te foldery już istnieją, developerzy często popełniają pewien błąd. Zakładają, że muszą otworzyć oficjalną dokumentację, przestudiować poszczególne fazy frameworka i zapamiętać dokładne komendy w terminalu, potrzebne do przechodzenia między fazami. Martwią się, że przypadkowo pominą jakiś krok albo odpalą komendę w złej kolejności. Nie musisz robić żadnej z tych rzeczy. Framework jest self-documenting w runtime, dzięki wbudowanemu skillowi o nazwie bmad-help. Bmad-help to aktywny przewodnik, który eliminuje obciążenie poznawcze podczas nawigowania po metodologii. To nie jest statyczny manual. Kiedy go wywołasz, ten skill aktywnie sprawdza obecny stan twojego workspace'u. Sprawdza, co aktualnie znajduje się w twoich folderach, aby dokładnie określić, w którym miejscu development lifecycle się znajdujesz. Weźmy konkretny scenariusz. Właśnie wykonałeś komendę instalacyjną. Twój workspace jest pusty, z wyjątkiem nowych folderów konfiguracyjnych. Masz pomysł na software, ale nie masz pojęcia, jaką komendę wpisać dalej. Po prostu odpalasz CLI i wpisujesz bmad-help, a po nim swoje pytanie w zwykłym języku angielskim. Na przykład wpisujesz: bmad-help I have an idea for a SaaS, where do I start? Skill przetwarza twoje pytanie, zauważa, że w twoim folderze output nie ma jeszcze żadnych dokumentów planistycznych, i mówi ci dokładnie, co masz zrobić. Odpowiada konkretną komendą, którą musisz uruchomić, aby zainicjować pierwszą fazę. Nie podaje ci generycznej listy wszystkich dostępnych komend. Daje ci jedną, precyzyjną instrukcję dla twojego obecnego kontekstu. W miarę twoich postępów w metodologii, budowania dokumentów i kodu, bmad-help się adaptuje. Jeśli skończysz generować architekturę i zapytasz, co robić dalej, zobaczy pliki architektury i wskaże komendę dla kolejnej odpowiedniej fazy. Framework fizycznie sprawdza twój progres i dynamicznie kieruje twoim kolejnym ruchem. Nigdy nie musisz zgadywać, czy jesteś gotowy do pisania kodu, czy musisz najpierw doprecyzować wymagania, ponieważ lokalna instalacja stale czyta twoje środowisko, aby utrzymać cię na właściwej ścieżce. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie – to bardzo nam pomaga. Trzymaj się!

Cześć, tu Alex z DEV STORIES DOT EU. Metoda BMad, odcinek 3 z 15. Jeśli poprosisz duży model językowy o dziesięć pomysłów, zazwyczaj dostaniesz dziesięć idealnie uśrednionych, totalnie nudnych pomysłów. System jest zaprojektowany tak, by przewidywać najbardziej prawdopodobne kolejne słowo, co sprawia, że ciąży ku banalności. Żeby uzyskać naprawdę innowacyjne rezultaty, musisz zmusić AI, by zadziałało jak trener, który wyciągnie te koncepcje z ciebie. Właśnie to robi workflow Forging Ideas with AI Brainstorming. Większość ludzi utożsamia burzę mózgów z AI z zero-shot promptingiem. Wpisujesz prompta z prośbą o pomysły w oknie czatu, a w zamian dostajesz generyczną listę. Takie podejście nie działa, bo traktuje AI jak wyrocznię. Trener burzy mózgów w metodzie BMad działa na zupełnie odwrotnej zasadzie. To kierowany, wieloetapowy framework facylitacji, w którym AI w ogóle nie generuje głównych pomysłów. Zamiast tego zapewnia ustrukturyzowane tarcie poznawcze, żeby zmusić cię do myślenia lateralnego. Ten workflow mocno opiera się na dwóch konkretnych mechanizmach: protokołach anti-bias i domain shiftingu. Kiedy wpisujesz początkową myśl, protokół anti-bias sprawia, że AI nie może po prostu się z tobą zgodzić. Jeśli zaproponujesz standardowe rozwiązanie problemu, AI jest zaprogramowane tak, by je zakwestionować. Może zapytać, co się stanie, jeśli twoje rozwiązanie całkowicie zawiedzie, albo jak konkurencja mogłaby wykorzystać oczywiste luki w twojej logice. Domain shifting idzie o krok dalej, zmuszając cię do spojrzenia na problem przez pryzmat zupełnie innej, niezwiązanej z tematem branży. Weźmy konkretny scenariusz, w którym chcesz poszukać sposobów na lepszy onboarding developerów. Standardowe AI dałoby ci listę o pisaniu lepszej dokumentacji i przydzielaniu mentorów. Jednak trener burzy mózgów BMad może zainicjować ćwiczenie z wykorzystaniem techniki SCAMPER. SCAMPER to framework, który promptuje cię do zastępowania, łączenia, adaptowania, modyfikowania, znajdowania innego zastosowania, eliminowania lub odwracania elementów procesu. I tu pojawia się kluczowa sprawa. AI nie przejdzie przez cały akronim na raz i nie zasypie cię ścianą tekstu. Zarządza tempem krok po kroku. Pyta cię, jak całkowicie wyeliminować etap czytania dokumentacji podczas onboardingu. Odpowiadasz bazując na swojej wiedzy domenowej. Następnie AI promptuje cię, żeby połączyć onboarding z zupełnie innym zadaniem inżynierskim, na przykład z live incident response. Znowu odpowiadasz. AI trzyma się ram frameworka, podczas gdy ty dostarczasz faktycznych pomysłów. Zaczynasz workflow od zdefiniowania swojej przestrzeni problemu. AI odpowiada konkretnym ograniczeniem albo celnym pytaniem. Ty odpowiadasz. AI przetwarza twoją odpowiedź, nakłada swój anti-bias check, a następnie kontruje albo robi domain shift. Ta wieloetapowa pętla trwa, dopóki nie wyczerpiesz oczywistych odpowiedzi i nie zaczniesz tworzyć naprawdę nowatorskich koncepcji. AI działa jak niestrudzony facylitator, który nie pozwala ci zadowolić się pierwszą rzeczą, jaka przyjdzie ci do głowy. Wartość AI na wczesnych etapach projektowania produktu nie polega na umiejętności wymyślania rzeczy od zera, ale na nieskończonej cierpliwości w aplikowaniu ustrukturyzowanego tarcia poznawczego do twojej własnej wiedzy. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Metoda BMad, odcinek 4 z 15. Amazon słynie z tego, że pisze press release przed zbudowaniem produktu. Co by było, gdyby AI bezlitośnie kwestionowało ten press release, zanim w ogóle pozwoli ci dotknąć codebase'u? Wybór odpowiedniego formatu dokumentu na wczesnym etapie decyduje o tym, czy zbudujesz narzędzie, którego ludzie faktycznie potrzebują, czy zmarnujesz miesiące na coś, czego nikt nie chce. Metoda BMad radzi sobie z tym dylematem za pomocą dwóch różnych outputów fazy analizy: PRFAQ Gauntlet i Product Brief. Użytkownicy często mają problem z tym, który format wybrać. Zasada jest prosta. Jeśli masz już mocne przekonanie co do tego, co budujesz, i potrzebujesz tylko alignmentu w zespole, użyj Product Brief. Jeśli musisz dopiero ustalić, czy produkt w ogóle zasługuje na to, by istnieć, użyj PRFAQ. Product Brief to łagodny, oparty na współpracy proces discovery. Pomyśl o tym jak o moderowanej rozmowie. Ty i AI wspólnie nakreślacie problem space, docelowych użytkowników, kluczowe feature'y i metryki sukcesu. AI działa tu jak wspierający co-pilot. Bierze twoje wstępne koncepcje, logicznie je strukturyzuje i grzecznie zadaje pytania, żeby uzupełnić brakujące detale. To linia najmniejszego oporu. Używasz go, gdy kierunek jest jasny i po prostu potrzebujesz profesjonalnego, uporządkowanego dokumentu, żeby dostać zielone światło albo przejść do technical designu. PRFAQ, czyli Press Release and Frequently Asked Questions, to zupełnie inny mechanizm. To rygorystyczny stress test w podejściu customer-first. Zmusza cię do pracy wstecz, zaczynając od wyobrażonego dnia premiery. Zaczynasz od napisania zwięzłego press release'u, w którym ogłaszasz gotowy produkt swojej grupie docelowej. W tym momencie AI porzuca rolę pomocnego co-pilota i staje się sceptycznym stakeholderem. Czyta twój press release i generuje serię brutalnych, dociekliwych pytań. Wyobraź sobie scenariusz, w którym chcesz zbudować nowe, wewnętrzne narzędzie do deployu. Piszesz press release, w którym chwalisz się, że deploye będą teraz wymagać jednego kliknięcia zamiast dziesięciu. W Product Briefie AI mogłoby po prostu poprosić cię o wylistowanie wspieranych platform. W PRFAQ Gauntlet AI zapyta, jak planujesz obsłużyć zautomatyzowane rollbacki, gdy to jedno kliknięcie zdeployuje krytycznego buga. Będzie żądać wyjaśnień, dlaczego zespół infrastruktury powinien przejść na to narzędzie zamiast używać swoich obecnych, sprawdzonych w boju skryptów. Musisz odpowiedzieć na te pytania w satysfakcjonujący sposób. Jeśli twoje odpowiedzi będą ogólnikowe, AI nie odpuści. Jesteś zmuszony obronić value proposition, użyteczność i wykonalność techniczną, zanim poświęcisz na to jakikolwiek realny czas inżynieryjny. Oto kluczowy wniosek. Product Brief skupia się na tym, czym jest produkt, podczas gdy PRFAQ skupia się na tym, dlaczego klienta miałoby to w ogóle obchodzić i czy twój plan realizacji jest realistyczny. Brief buduje konsensus. PRFAQ niszczy słabe założenia. Sięgasz po PRFAQ, gdy pomysł jest drogi, kontrowersyjny lub bardzo niejednoznaczny. Ostatecznie, przetrwanie PRFAQ Gauntlet dowodzi, że twój koncept wytrzyma zderzenie z rzeczywistością, działając jako absolutna obrona przed budowaniem feature'ów, o które nikt tak naprawdę nie prosił. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Metoda BMad, odcinek 5 z 15. Najszybszym sposobem na zbudowanie niewłaściwego systemu jest pozwolenie AI na halucynowanie wymagań na podstawie luźnego promptu. Musisz ograniczyć AI do ścisłych granic, zanim powstanie jakikolwiek kod. Zamrożenie PRD to proces, który buduje te granice. Ludzie często mylą planowanie projektu z projektowaniem rozwiązań technicznych. Myślą, że planowanie polega na wyborze bazy danych lub mapowaniu mikrousług. To błąd. Planowanie dotyczy wyłącznie logiki biznesowej. Nie narzuca żadnych decyzji technicznych. Faza planowania skupia się wyłącznie na tym „Co” i „Dlaczego”. Kwestia „Jak” należy do zupełnie innej fazy. W metodzie BMad dzieje się to w Fazie Drugiej. Odpowiedzialnym aktorem jest agent Product Managera, John. John bierze output z fazy pierwszej, a konkretnie twój zatwierdzony PRFAQ i dokumenty z burzy mózgów, i je przetwarza. Uruchamiasz ten proces za pomocą komendy bmad dash create dash prd. John bierze wizję z PRFAQ i przekłada ją na ścisły plik tekstowy o nazwie PRD dot md. Ten dokument służy jako absolutne źródło prawdy dla reszty projektu. W tym celu John rozbija wymagania na dwie ścisłe kategorie. Są to wymagania funkcjonalne, czyli FR, oraz wymagania niefunkcjonalne, czyli NFR. Wymagania funkcjonalne dokładnie określają, co system musi robić. Wymagania niefunkcjonalne definiują ograniczenia operacyjne systemu, takie jak progi wydajności, zasady compliance czy dostępność. Weźmy konkretny scenariusz. Budujesz moduł rozliczeniowy SaaS. Przekazujesz swój zatwierdzony PRFAQ agentowi PM. John zwraca wymagania funkcjonalne, które mówią, że moduł musi pozwalać użytkownikom na upgrade subskrypcji i musi automatycznie robić downgrade, jeśli płatność nie powiedzie się trzy razy. Następnie John zwraca wymagania niefunkcjonalne, które mówią, że wszystkie aktualizacje statusu płatności muszą być widoczne w dashboardzie użytkownika w ciągu dwóch sekund. Oto kluczowy wniosek. Zwróć uwagę na to, czego brakuje w tych wymaganiach. John nie wspomina o Stripe, nie wspomina o PostgreSQL i nie projektuje payloadu API. Jeśli twój PRD wspomina o konkretnej technologii bazy danych, proces zakończył się fiaskiem. PRD zamraża wyłącznie oczekiwania biznesowe. Kiedy PRD jest już zamrożony, Faza Druga przechodzi do workflow projektowania UX. Ten krok bierze surową logikę biznesową i mapuje interakcje z człowiekiem. Jeśli wymaganie funkcjonalne mówi, że użytkownik musi zrobić upgrade subskrypcji, workflow projektowania UX dyktuje dokładną sekwencję ekranów, przycisków i komunikatów o błędach, na które natrafi użytkownik. Podobnie jak PRD, ten workflow UX nie podejmuje żadnych decyzji dotyczących frameworków frontendowych. Nie obchodzi go, czy ostatecznie użyjesz Reacta, czy Vue. Skupia się tylko na ścieżce użytkownika krok po kroku. Zmuszając agenta PM do wygenerowania ścisłego, niezależnego od technologii PRD i flow UX, tworzysz punkt zaczepienia. Duże modele językowe naturalnie dryfują z czasem. Na późniejszym etapie projektu, twoi agenci inżynieryjni będą zmuszeni weryfikować swoje rozwiązania techniczne z tymi konkretnymi FR i NFR. Jeśli jakiegoś feature'a nie ma w PRD, agenci go nie zbudują. PRD nie jest luźnym dokumentem z sugestiami; to sztywna granica dla twoich agentów AI, która całkowicie izoluje twoje kluczowe potrzeby biznesowe od ostatecznej implementacji technicznej. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Trzymaj się!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 6 z 15. Jeśli zlecisz dwóm agentom AI zbudowanie dwóch różnych feature'ów bez wspólnego dokumentu architektury, nieuchronnie wypowiedzą wojnę kodowi tego drugiego. Podejmą sprzeczne decyzje techniczne, które wysypią twoją aplikację. Mechanizmem, który ma temu zapobiec, jest Faza 3: Solutioning, która skupia się na zapobieganiu konfliktom między agentami za pomocą architektury. Ludzie pracujący nad projektem programistycznym rozmawiają ze sobą. Dzielą się założeniami przy kawie albo na czacie. Agenci AI działający równolegle nie mają wspólnej świadomości. Działają w całkowicie odizolowanych context windows. Daj Agentowi A zadanie zaimplementowania dashboardu użytkownika, a może on uznać, że najlepiej sprawdzi się REST API i Redux. Daj Agentowi B zadanie zbudowania strony ustawień użytkownika, a może on niezależnie zdecydować o postawieniu GraphQL i Zustand. Kiedy te dwa feature'y spróbują się zmergować do main brancha, napotkasz ogromny problem z integracją. Obaj agenci zrobili dokładnie to, o co prosiłeś, ale ich odizolowane optymalizacje wywołały systemowy chaos. Developerzy często chcą pominąć formalną dokumentację architektury, bo wydaje się to korporacyjnym overheadem. Jeśli na szybko klepiesz mały, odizolowany skrypt, jest to akceptowalne. Metoda BMad zawiera Quick Flow specjalnie dla małych tasków, który celowo pomija tę fazę. Ale w przypadku złożonych projektów, pominięcie fazy architektury gwarantuje agent drift. Nie możesz polegać na domyślnym zachowaniu dużych modeli językowych i liczyć, że przypadkowo zgrają się na ten sam stack technologiczny w różnych sesjach. Aby wymusić spójność techniczną, metoda wykorzystuje konkretny workflow o nazwie bmad create architecture. Odpalasz ten workflow, zanim powstanie choćby jedna linijka kodu aplikacji. Analizuje on wymagania twojego projektu i generuje Architecture Decision Records. Architecture Decision Records to lekkie, ustrukturyzowane pliki tekstowe. Zapisane są w nich ostateczne decyzje techniczne dla projektu. Jeden rekord określa bibliotekę do state managementu. Inny precyzuje dokładny wzorzec data fetchingu. Trzeci definiuje framework testowy. Ustanawiają one twarde, nieugięte zasady systemu. I tu jest kluczowa sprawa. W tradycyjnej inżynierii oprogramowania, Architecture Decision Record to przede wszystkim historyczny log, który pomaga nowym developerom zrozumieć przeszłe decyzje. W wieloagentowym systemie AI, jest to aktywny mechanizm kontroli. Duże modele językowe nie pamiętają, co zdecydował inny model, chyba że jawnie wrzucisz te informacje do ich prompt contextu. Kiedy odpalasz workflow architektury, wynikowe dokumenty są zapisywane bezpośrednio w twoim repozytorium projektu. Później, kiedy deployujesz Agenta A do zbudowania dashboardu i Agenta B do zbudowania ustawień, system przekazuje dokładnie te same decision records obu agentom, zanim zaczną pisać kod. Pliki architektury działają jako ostateczne ground truth. Agent A czyta rekord narzucający Redux i REST, i buduje zgodnie z nim. Agent B czyta dokładnie ten sam rekord i również buduje z wykorzystaniem Reduxa i RESTa. Granice architektoniczne zmuszają niezależne modele do działania jako spójny zespół. Zdejmując ciężar wyboru w fazie implementacji feature'a, drastycznie redukujesz halucynacje i zapobiegasz konfliktom zależności. Dokumenty architektury w AI workflow to nie tylko pasywne notatki dla ludzi; to programowalne ograniczenia, które zmuszają niedeterministycznych agentów do zbudowania deterministycznego systemu. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 7 z 15. Agenci AI domyślnie trzymają się ogólnych dobrych praktyk, co oznacza, że piszą kod, który wygląda jak przeciętna odpowiedź ze Stack Overflow, a nie jak twój codebase. Jeśli chcesz, żeby kodowali dokładnie tak, jak twój zespół seniorów, musisz narzucić własne zasady. Tym właśnie zajmuje się Project Context Constitution. W gruncie rzeczy jest to plik o nazwie project-context.md. Umieszczasz go w roocie twojego repozytorium. Pomyśl o nim jako o nadrzędnym dokumencie dla każdego AI, które wchodzi w interakcję z twoim projektem. Kiedy agent czyta twoje repozytorium, najpierw ładuje ten plik, żeby zrozumieć nieprzekraczalne granice twojej architektury. Możesz utworzyć ten plik ręcznie lub wygenerować punkt wyjścia, odpalając komendę bmad-generate-project-context w terminalu. Tak czy inaczej, dokument musi zawierać dwie konkretne sekcje. Są to Tech Stack i Critical Rules. Sekcja Tech Stack jest prosta, ale wymaga precyzji. Nie wpisujesz po prostu Reacta czy Node'a. Podajesz dokładne wersje, paradygmat routingu i biblioteki do stylowania. Jeśli używasz Next.js z App Routerem i Tailwindem, napisz dokładnie to. AI używa tego, żeby przefiltrować swoje ogromne dane treningowe pod kątem konkretnej składni, jakiej wymaga twój projekt. Druga część to sekcja Critical Rules. Zwróć na ten fragment szczególną uwagę. Bardzo częstym błędem programistów jest wypełnianie tej sekcji ogólnymi poradami w stylu "pisz czysty kod" albo "stosuj zasady DRY". Nie rób tego. AI już zna ogólne zasady czystego kodu. Musisz zapisać nieoczywiste, specyficzne dla twojego projektu wzorce, których agent nigdy nie odgadłby sam. To tutaj ustalasz twarde prawa architektoniczne. Na przykład piszesz regułę, która wymusza strict mode w TypeScripcie dla każdego nowego pliku. Instruujesz agenta, że wszystkie testy integracyjne muszą używać Mock Service Workera. Co najważniejsze, możesz zakazywać pewnych zachowań. Jeśli twój projekt ma customowy singleton klienta API, wprost piszesz regułę, która mówi, żeby nigdy nie używać bezpośrednio natywnego fetcha ani Axiosa, tylko zawsze importować customowego klienta API z folderu network utilities. Kiedy AI generuje nowy feature, weryfikuje swój output z tymi regułami. Ponieważ project context znajduje się na samym szczycie hierarchii promptów, te instrukcje nadpisują domyślne tendencje AI. Jeśli agent próbuje napisać bezpośredni fetch do API, Project Context Constitution wymusza na nim przepisanie tej logiki z użyciem twojego customowego wrappera, zanim w ogóle zwróci kod. Celem tego pliku nie jest uczenie AI programowania, ale nauczenie go, jak programować tutaj, w tym konkretnym repozytorium. Jeśli podobają ci się te odcinki i chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU na Patreonie. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Miłego dnia!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 8 z 15. Zanim pozwolisz AI napisać setki linii kodu, musisz wykonać jeden krytyczny krok, aby zapobiec katastrofalnemu sprintowi. Ten krok to Breaking Work Down i Gate Check. Na tym etapie workflow masz już sfinalizowany Product Requirements Document i gotowy projekt architektury. Teraz potrzebujesz ticketów. W tym momencie do akcji wkracza agent PM. Jego zadaniem jest realizacja procesu tworzenia epiców i User Stories. Agent PM czyta dokument wymagań, ale nie działa w próżni. Zestawia te potrzeby biznesowe z ograniczeniami zdefiniowanymi w dokumentacji architektury. Agent PM przekłada wysokopoziomowe feature'y na epici. Następnie dzieli te epici na konkretne, wykonalne User Stories. Opracowuje acceptance criteria i kontekst techniczny dla każdego zadania. Opierając się na dokumentacji architektury, PM upewnia się, że modele danych i interakcje komponentów wymagane przez dane story faktycznie istnieją w planie technicznym. To gwarantuje, że każdy ticket odpowiada na rzeczywiste wymagania biznesowe, jednocześnie ściśle trzymając się granic narzuconych przez design systemu. Wynikiem tego kroku jest w pełni wypełniony backlog. I tu pojawia się kluczowa kwestia. Kiedy ten backlog już istnieje, pokusa, by natychmiast zacząć generować kod, jest ogromna. Ludzie nagminnie pomijają kolejny krok z czystej niecierpliwości. Chcą zobaczyć działający soft, więc wrzucają nowe tickety prosto do developmentu. Nie rób tego. Pominięcie readiness check to prosty sposób na przepalenie drogich tokenów API na kod, którego nie da się zintegrować. Właśnie dlatego do akcji wraca agent Architekta, aby przeprowadzić fazę check implementation readiness. To twoje ostateczne zabezpieczenie. Działa to jako rygorystyczny Gate Check przed rozpoczęciem jakiegokolwiek programowania. Architekt czyta każdego epica i każde User Story wygenerowane przez PM-a i waliduje je bezpośrednio z Architekturą. Architekt szuka brakujących technicznych wymagań, sprzeczności w architekturze lub cichych założeń. Weryfikuje, czy każda struktura danych wymieniona w danym story ma odpowiadający jej schemat bazy danych. Sprawdza, czy niezbędne endpointy serwisów są faktycznie zdefiniowane. Wyobraź sobie konkretny scenariusz. Uruchamiasz Gate Check, a Architekt oflagowuje epica dotyczącego nowego feature'a powiadomień dla użytkowników. Ticket zakłada użycie konkretnego, zewnętrznego messaging API. Architekt zauważa jednak, że ta integracja nigdy nie była omawiana ani zatwierdzona w Architecture Decision Records. Gate Check natychmiast zatrzymuje proces. Właśnie zaoszczędziłeś godziny zmarnowanego czasu na development, próbując zbudować feature w oparciu o niezatwierdzoną lub nieudokumentowaną zależność. Ta współpraca między potrzebami biznesowymi a techniczną rzeczywistością to sedno tej fazy. Agent PM definiuje pracę na podstawie tego, czego wymaga użytkownik. Agent Architekta weryfikuje tę pracę na podstawie tego, co system jest w stanie faktycznie obsłużyć. Idziesz dalej dopiero, gdy Architekt to zatwierdzi, udowadniając, że backlog jest w pełni implementowalny. Idealne wymaganie produktowe jest całkowicie bezużyteczne, jeśli architektura systemu pod spodem nie jest w stanie go obsłużyć, a ten Gate Check to jedyny obiektywny dowód na to, że twoje tickety są faktycznie gotowe do developmentu. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 9 z 15. Nie możesz po prostu powiedzieć AI, żeby zbudowało aplikację. Jeśli poprosisz model językowy o zaimplementowanie całego feature'a albo Epica naraz, dostaniesz niedopracowaną logikę, brakujące pliki i totalny bałagan w kodzie. Żeby uzyskać od AI kod na poziomie production-grade, musisz narzucić dokładnie taką samą dyscyplinę, jakiej oczekujesz od świetnego zespołu inżynierów. Dzisiaj bierzemy na warsztat The Build Cycle i Sprint Tracking, czyli mechaniczną, zdyscyplinowaną pętlę realizacji fazy czwartej: implementacji. Największym błędem, jaki popełniają developerzy przy pracy z narzędziami AI, jest proszenie o zbyt wiele naraz. Build cycle opiera się całkowicie na rygorystycznym realizowaniu zadań w modelu one-story-at-a-time. Śledzisz state, bierzesz pojedyncze story, wykonujesz je, walidujesz i aktualizujesz swój state. Ten proces wymaga odrębnych person obsługujących konkretne części pipeline'u, co gwarantuje, że żaden kontekst nie zostanie utracony, a scope nie zostanie rozdmuchany. Cykl zaczyna się od sprint planningu. Uruchamiasz prompt bmad sprint planning, który generuje plik o nazwie sprint status yaml. Ten plik to twoje absolutne source of truth. Wprost wylistowuje każde story w twoim obecnym sprincie i oznacza jego status jako pending, in progress lub done. Ten dokument trzyma AI w ryzach. Zapobiega to halucynowaniu postępów przez model albo zapominaniu o zależnościach, ponieważ AI musi stale czytać ten plik, żeby zrozumieć aktualny state projektu. Kiedy twój sprint jest zaplanowany, odpalasz execution loop. Najpierw angażujesz personę Scrum Mastera, Boba, używając promptu bmad create story. Instruujesz Boba, żeby zajrzał do pliku sprint status yaml i wziął pierwszy item ze statusem pending. Bob nie pisze żadnego kodu aplikacji. Zamiast tego generuje bardzo sfokusowany plik markdown, dedykowany wyłącznie temu jednemu user story. Ten dokument określa konkretne acceptance criteria, techniczne ograniczenia i scenariusze testowe wymagane do ukończenia taska. Następnie przekazujesz ten wyizolowany plik ze story do persony Developera, Amelii. Używasz promptu bmad dev story, żeby zainicjować ten krok. Amelia czyta plik ze story, analizuje obecny codebase i implementuje logikę. Ponieważ jej kontekst jest sztucznie zawężony tylko do instrukcji Boba i odpowiednich plików aplikacji, nie przepisze przypadkowo niepowiązanych modułów ani nie wyjdzie poza scope bieżącego taska. Kiedy Amelia napisze kod, story nie jest jeszcze done. Wywołujesz prompt bmad code review. Działa to jak automatyczny quality gate. Proces review weryfikuje kod Amelii pod kątem rygorystycznych acceptance criteria zdefiniowanych w pliku ze story od Boba. Wychwytuje brakujące edge case'y, błędy w logice albo niespójności w formatowaniu. Naprawiasz wszystkie problemy znalezione podczas tego review. Dopiero kiedy kod przejdzie pomyślnie, aktualizujesz plik sprint status yaml, ręcznie zmieniając status story z in progress na completed. Następnie wracasz w pętli do Boba, żeby zaciągnąć kolejny item ze statusem pending. Oto kluczowy wniosek. Siła tej pętli nie tkwi w samym generowaniu kodu, ale w rygorystycznym separation of concerns, które zmusza AI do planowania, egzekucji i robienia review jako odrębnych, wyizolowanych kroków. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 10 z 15. Czasami pełny proces agile to przesada dla lokalnej poprawki. Masz chaotyczny ticket z błędem w Jirze i chcesz go po prostu naprawić i zrobić review bez ręcznego weryfikowania każdego kroku. Oto jak przejść od takiego surowego ticketa do pull requesta po review w jednym, autonomicznym runie, korzystając z Quick Dev Track for Zero-Blast Changes. Ludzie często postrzegają Quick Dev po prostu jako zwykły prompt, w którym wrzucasz ticketa do dużego modelu językowego i liczysz na najlepsze. Wcale tak nie jest. Quick Dev wyraźnie izoluje doprecyzowanie intencji od egzekucji. Daje systemowi twardą granicę, w ramach której ma działać, zamiast wplatać definicję problemu bezpośrednio w etap generowania kodu. Standardowy track agile'owy mocno opiera się na ścisłych checkpointach. Robisz pauzę, weryfikujesz plan, weryfikujesz testy i weryfikujesz implementację. Quick Dev pozbywa się tych checkpointów. Bardziej ufa modelowi i oszczędza twoją uwagę na momenty o największym znaczeniu. Używasz tego tracka tylko do zmian o zerowym blast radius. W praktyce oznacza to, że modyfikacje muszą być odizolowane do pojedynczego komponentu lub funkcji. Zmiana nie może zmieniać publicznych interfejsów, modyfikować schematów bazy danych ani przepisywać współdzielonych funkcji utility używanych przez inne domeny. Jeśli zmiana dotyka głównego state managementu, jej miejsce jest na standardowym tracku. Wyobraź sobie scenariusz, w którym przekazujesz link do pofragmentowanego ticketa z błędem w Jirze do narzędzia bmad-quick-dev. Pierwszą rzeczą, którą wykonuje system, jest kompresja intencji. Czyta rozrzucone komentarze, kroki do reprodukcji i skargi użytkowników. Zmusza model do rozwiązania sprzeczności, zanim w ogóle dotknie kodu. Jeśli ticket ma sprzeczne instrukcje, krok kompresji syntetyzuje je w jeden, ostateczny cel. Ten output to plain text, który dokładnie definiuje, z czym wiąże się poprawka i, co kluczowe, jakie są jej granice. I tu pojawia się kluczowy wniosek. Ponieważ intencja jest teraz skompresowana i odizolowana, faza autonomicznej egzekucji ma ścisłą specyfikację, której musi się trzymać. System pisze poprawkę, generuje lub aktualizuje lokalne testy i odpala self-review w oparciu o tę początkową, skompresowaną intencję. Powtarza te kroki w pętli. Odchodzisz od komputera, gdy system pracuje, i wracasz do gotowego pull requesta. Quick Dev jest szybki, ale gdy autonomiczny run się wywali, musisz dokładnie zdiagnozować warstwy błędu. Sprawdzasz, gdzie proces się wysypał. Jeśli końcowy kod rozwiązuje zupełnie inny problem, błąd nastąpił w warstwie kompresji intencji. Ticket w Jirze był prawdopodobnie zbyt niejednoznaczny, przez co model wyhalucynował cel. Naprawiasz to, przepisując początkowy input. Jeśli intencja jest poprawna, ale nowe testy nie przechodzą lub build się wywala, błąd leży w warstwie egzekucji. Błędy egzekucji naprawiasz, nakierowując model, by zrobił retry dla konkretnego bloku logiki. Jeśli warstwa egzekucji wywali się dwa razy z rzędu, problemem nie jest już prompt. Blast radius tej zmiany był po prostu większy, niż początkowo zakładałeś, i musisz cofnąć się do standardowego tracka z checkpointami. Autonomia działa tylko wtedy, gdy granice zadania są mniejsze niż okno kontekstowe modelu, który je rozwiązuje. To wszystko w tym odcinku. Dzięki za wysłuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Metoda BMad, odcinek 11 z 15. Większość frameworków AI do kodowania zakłada, że zaczynasz od całkowicie pustego katalogu. Chcą wygenerować scaffolding, dyktować architekturę i kontrolować cały proces od pierwszego dnia. Ale kiedy wrzucisz agenta AI do ogromnego, pięcioletniego monolitu w Railsach z nieudokumentowanymi konwencjami nazewnictwa, to podejście czystej karty wszystko psuje. Onboarding istniejących codebase'ów to sposób na to, by BMad współpracował z tym, co już masz. Programiści często zakładają, że BMad służy wyłącznie do projektów greenfield. To nieprawda. BMad nie wymusza przepisywania kodu ani nie narzuca zewnętrznej struktury. Został stworzony tak, by się dostosować – szanuje i odkrywa twoją obecną architekturę, żeby czysto się z nią zintegrować. Jednak przetworzenie istniejącego repozytorium wymaga określonego workflow, żeby zapobiec przejęciu twojego długu technicznego przez AI. Pierwszym krokiem jest uporządkowanie artefaktów. Modele AI to w zasadzie zaawansowane silniki do pattern matchingu. Jeśli wskażesz im repozytorium pełne zakomentowanych bloków kodu, deprecated wywołań API i niespójnego nazewnictwa plików, agent założy, że to są akceptowane standardy. Przed wpuszczeniem agenta musisz usunąć dead code, wymusić reguły lintingu i upewnić się, że twój test suite faktycznie przechodzi. Wyznaczasz w ten sposób standard bazowy. Im czystszy stan wejściowy, tym lepiej agent dopasuje się do twoich rzeczywistych intencji. Kiedy repozytorium jest już czyste, mapujesz je za pomocą komendy bmad-generate-project-context. To właśnie tutaj dzieje się adaptacja. Zamiast ręcznie spisywać strony dokumentacji o strukturze twojej aplikacji, odpalasz to narzędzie, żeby przeskanowało twoje legacy patterns. Wróćmy myślami do tego pięcioletniego monolitu w Railsach. Generator kontekstu czyta drzewo plików, parsuje abstrakcje i dedukuje twoje nieudokumentowane zasady. Określa, czy twój zespół preferuje fat models, czy service objects. Analizuje twój katalog z testami, żeby zobaczyć, jak mockujesz wywołania do bazy danych. Zbiera wszystkie te wnioski i zapisuje je w scentralizowanym dokumencie kontekstowym. Ten plik staje się podstawowym promptem dla AI. Kiedy prosisz agenta o zbudowanie nowego feature'a, najpierw czyta on ten kontekst. Rozumie istniejącą architekturę i generuje kod, który wygląda dokładnie tak, jakby napisał go senior z twojego zespołu. Mając wygenerowany kontekst, wybierasz sposób wprowadzania zmian, używając Quick Dev albo Full Method. Twój wybór zależy wyłącznie od złożoności zadania. Jeśli naprawiasz zlokalizowanego buga albo dodajesz pojedynczy query parameter do istniejącego endpointu, użyj Quick Dev. Agent czyta twój plik kontekstowy, nakłada konkretnego patcha, weryfikuje go z twoimi lokalnymi testami i kończy działanie. To szybka operacja z małym overheadem. Druga część tego mechanizmu obsługuje złożone aktualizacje. Jeśli musisz wbudować całkowicie nowy moduł bilingowy w ten monolit, przełączasz się na Full Method. Agent wykorzysta plik kontekstowy, żeby najpierw napisać obszerny design document. Opisuje w nim, jak nowy moduł będzie wchodził w interakcje z twoimi obecnymi komponentami. Pisze failujące testy, które pasują do twojego legacy testing style, implementuje logikę biznesową i iteruje, aż testy przejdą. Framework skaluje swój rygor w zależności od tego, czego wymaga zadanie. I tu jest kluczowy wniosek. Sukces agenta AI w legacy repository zależy wyłącznie od jakości wzorców, które wykryje. To oznacza, że rygorystyczne początkowe czyszczenie i dokładny plik kontekstowy to jedyne rzeczy, które stoją między bezproblemowym dodaniem feature'a a architektonicznym chaosem. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Trzymaj się!

Cześć, tu Alex z DEV STORIES DOT EU. Metoda BMad, odcinek 12 z 15. Otwierasz terminal, wpisujesz komendę, żeby sformatować kod, i dostajesz całkowicie generyczny błąd. Próbujesz użyć wewnętrznej komendy agenta, ale agent nawet jeszcze nie działa. Są dwa różne sposoby na wydawanie komend swojemu zespołowi AI, a ich mieszanie to najczęstsze źródło problemów w systemie. Dzisiaj omówimy wydawanie komend agentom: Skille kontra Triggery. Pierwsza kategoria to Skille. Pomyśl o Skillach jako o swoich globalnych entry pointach. To właśnie je wpisujesz w terminalu w swoim IDE albo w command line, żeby odpalić akcję od zera. Kiedy wpisujesz bmad-help albo odpalasz konkretny skrypt startowy agenta ze swojego IDE, używasz Skilla. To on uruchamia środowisko. Ładuje potrzebny kontekst. Sprawia, że agent jest online. Skille żyją poza konwersacją z agentem. To mechanizmy, które odpalają silnik. I tu dochodzimy do częstej pułapki. Kiedy silnik już działa, a ty czatujesz z agentem, zasady się zmieniają. Przestajesz używać Skilli i zaczynasz używać Triggerów. Trigger to krótki kod wpisywany bezpośrednio w aktywnej sesji czatu, żeby wydać komendę agentowi, który już nasłuchuje. Jeśli wpiszesz trigger z menu agenta w standardowym terminalu, system nie będzie miał pojęcia, o co ci chodzi. Jeśli spróbujesz odpalić Skilla z IDE wewnątrz czatu z agentem, to po prostu nie zadziała. Granica jest absolutna. Skille startują sesję. Triggery kontrolują aktywną sesję. Kiedy jesteś już w czacie, Triggery dzielą się na dwa rodzaje: Workflow Triggers i Conversational Triggers. Workflow Triggers odpalają sztywne, predefiniowane sekwencje. Wpisujesz trigger, agent wykonuje konkretny, wieloetapowy proces krok po kroku, zwraca output i sekwencja się kończy. Conversational Triggers są znacznie bardziej płynne. Pozwalają na dynamiczne przełączanie się między taskami bez psucia persony agenta. Zostajesz w czacie, ale zmieniasz aktywny kontekst. Weźmy konkretny scenariusz. Potrzebujesz nowej dokumentacji. Zaczynasz od użycia Skilla w IDE, żeby odpalić Paige, agentkę Technical Writer. Skill uruchamia Paige, a ona pyta, czego potrzebujesz. Jest teraz aktywna. Teraz, zamiast pisać potężny prompt wyjaśniający, że potrzebujesz konkretnego typu dokumentu sformatowanego w określony sposób, po prostu wpisujesz conversational trigger W D w aktywnym prompcie czatu. To skrót od Write Docs. Paige natychmiast przełącza się w swój predefiniowany tryb tworzenia dokumentacji. Prosi o twoje surowe notatki, przetwarza je i generuje tekst. Czytasz tekst i zdajesz sobie sprawę, że potrzebujesz do niego diagramu architektury. Nie zamykasz czatu. Nie odpalasz nowego Skilla z terminala. Po prostu wpisujesz kolejny conversational trigger, M G, co jest skrótem od Mermaid Graph. Paige natychmiast się przestawia. Pozostaje w roli twojego technical writera, trzyma kontekst dokumentu, który właśnie napisała, i generuje pasujący kod diagramu Mermaid. Dynamicznie sterujesz jej możliwościami w locie, bez utraty kontekstu. Oto kluczowy wniosek. Prawdziwa siła tego podwójnego systemu to nie tylko krótsze komendy do wpisywania, ale utrzymanie stałego, inteligentnego kontekstu przy jednoczesnym błyskawicznym przełączaniu wewnętrznego trybu działania agenta. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Metoda BMad, odcinek 13 z 15. Twoje AI code reviews są prawdopodobnie o wiele za miłe. Kiedy po prostu prosisz model o poszukanie bugów, dostajesz grzeczne sugestie i ogólne syntax checks. Żeby znaleźć katastrofalne błędy, potrzebujesz wyspecjalizowanych, opinionated silników diagnostycznych. Ten odcinek pokrywa dokładnie to: Adversarial Review i szukanie edge case'ów. Ludzie często traktują AI code review jako pojedyncze, uniwersalne przejście. Rzucają diffem w model i mają nadzieję, że wyłapie wszystko. To rzadko działa dobrze. Generyczny prompt nie ma konkretnego modelu mentalnego, co prowadzi do płytkiego feedbacku. Metodologia BMad rozwiązuje to, używając ściśle określonych, wyspecjalizowanych person. Przyjrzymy się dwóm różnym narzędziom do code review, które działają w oparciu o zupełnie inne metodologie. Po pierwsze, weźmy na warsztat adversarial reviewera. To narzędzie kieruje się nastawieniem i jest bardzo sceptyczne. Nie ufa twojemu kodowi, twojej infrastrukturze ani twoim użytkownikom. Zakłada, że twoja implementacja jest fundamentalnie zepsuta i aktywnie szuka sposobów, jak można ją wyeksploatować. Całkowicie ignoruje kwestie stylistyczne, nazewnictwo zmiennych czy drobne optymalizacje wydajności. Zamiast tego poluje wyłącznie na luki w logice biznesowej, eskalacje uprawnień i złamane założenia dotyczące zaufania. Adversarial reviewer patrzy na perymetry twojego API i pyta, jak atakujący mógłby ominąć twój zamierzony flow. Czyta twój kod z głębokim cynizmem, traktując każdy input jako potencjalny wektor ataku, a każdą granicę danych jako słabość. Następnie mamy łowcę edge case'ów. To narzędzie ma dokładnie odwrotną osobowość. Jest matematycznie chłodne, pozbawione kontekstu i całkowicie mechaniczne. Nie obchodzą go złośliwi użytkownicy ani intencje biznesowe. Zamiast tego wykonuje ścisły path-tracing. Buduje mentalny control flow graph twojego kodu i podąża za każdym pojedynczym branchem do jego logicznego końca. Łowca edge case'ów skupia się wyłącznie na mutacjach stanu, warunkach brzegowych i typach danych. Szuka nieoczywistych ścieżek wykonania, które powodują silent failures, wycieki pamięci albo unhandled exceptions. Żeby zobaczyć różnicę, zastosuj oba narzędzia do jednego fragmentu kodu, na przykład do skomplikowanego diffa z autentykacją. Najpierw przekazujesz ten kod do adversarial reviewera. Ponieważ opiera się na cynizmie, ignoruje mechaniczną składnię i wyłapuje brakujący constraint w logice biznesowej. Zauważa, że chociaż token autentykacyjny jest poprawnie walidowany, system niejawnie ufa roli użytkownika zaszytej w tym tokenie, bez sprawdzania bazy danych na żywo. Adversarial reviewer flaguje to jako krytyczną podatność związaną z zaufaniem. Teraz przekazujesz dokładnie tego samego diffa z autentykacją do łowcy edge case'ów. To narzędzie całkowicie ignoruje logikę zaufania do tokena. Zamiast tego, poprzez mechaniczne wyprowadzanie ścieżek, śledzi cykl życia każdej zmiennej. Znajduje głęboko zagnieżdżoną funkcję walidującą, w której brakuje jawnego type checka. Wskazuje na nieobsłużoną niejawną koercję typów. Jeśli wejściowy payload zawiera obiekt null zamiast stringa pod tym konkretnym indeksem, aplikacja rzuci unhandled exception i scrashuje się. Oto kluczowy wniosek. Nie używasz tych narzędzi do wyłapywania literówek. Używasz ich, żeby wymusić na swoim codebase dwa odrębne analityczne frameworki. Jeden atakuje twoje założenia dotyczące zaufania do systemu i ludzkich zachowań. Drugi atakuje twoje założenia dotyczące ścieżek wykonania i stanów danych. Oddzielając cynicznego atakującego od mechanicznego path-tracera, przestajesz polegać na generycznym szukaniu bugów i zaczynasz ujawniać głębokie strukturalne podatności, zanim w ogóle trafią na produkcję. Dzięki za wysłuchanie. Do następnego razu!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 14 z 15. Jeśli wrzucisz pięćdziesięciostronicowy dokument bezpośrednio do dużego modelu językowego, niemal natychmiast doświadczy on ślepoty kontekstowej. Gubi szczegóły ze środka tekstu, halucynuje fakty i traci zdolność logicznego wnioskowania. Aby to naprawić, potrzebujesz triku na bezstratną kompresję. Dzisiaj omówimy zarządzanie kontekstem: destylację i sharding. Wielu programistów uważa, że destylacja to po prostu podsumowanie. To błąd. Podsumowanie celowo odrzuca dane, żeby dać człowiekowi szybki przegląd sytuacji. Destylacja to weryfikowalny, bezstratny proces kompresji. Oto kluczowa sprawa. Narzędzie distillator bierze rozwlekłą ludzką prozę, wycina z niej zdania przejściowe, przymiotniki i konwersacyjne wypełniacze, a następnie konwertuje ją do bardzo gęstego, wypunktowanego formatu. Ten format jest stworzony ściśle pod odczyt maszynowy. Zachowujesz każdy pojedynczy fakt, ale drastycznie obniżasz liczbę tokenów. Weźmy na warsztat ten potężny, pięćdziesięciostronicowy whitepaper. Jeśli przepuścisz go przez narzędzie distillator, możesz osiągnąć współczynnik kompresji rzędu trzy przecinek dwa do jednego. Całkowity rozmiar payloadu spada o ponad dwie trzecie, a model wciąż zachowuje dostęp do każdej specyfikacji technicznej i decyzji architektonicznej. AI czyta surowe dane szybciej i przetwarza logikę dokładniej, nie tonąc w sformatowanych dla człowieka akapitach. To załatwia sprawę gęstości tekstu, ale całkowita objętość wciąż może być zbyt duża, żeby gładko zmieścić się w kontekście pojedynczego promptu. I tu do gry wkracza narzędzie shard document. Sharding mechanicznie dzieli twój wydestylowany whitepaper na mniejsze, samodzielne pliki tekstowe w oparciu o logiczne granice, takie jak rozdziały czy odrębne sekcje. Odpalasz komendę shard, wskazujesz jej swój ciężki dokument, a ona wypluwa ponumerowaną sekwencję lekkich plików. Zamiast zmuszać AI do trzymania całego whitepapera w pamięci roboczej, masz teraz modułowe kawałki. Kiedy masz już dwadzieścia plików shard siedzących w katalogu, system potrzebuje sposobu, żeby po nich nawigować. Ogarniasz to za pomocą narzędzia index documents. Kierujesz komendę index na folder zawierający twoje nowe shardy. Narzędzie skanuje katalog i generuje jeden główny plik index. Ten główny plik działa jak mapa routingu, wylistowując każdy shard wraz z krótkim opisem tego, co zawiera. W praktyce, najpierw karmisz tym lekkim plikiem index model językowy. Model czyta mapę, ustala, który konkretnie rozdział zawiera informacje potrzebne do odpowiedzi na prompt, a następnie żąda tylko tego konkretnego shardu. Wnioskowanie pozostaje ostre, ponieważ context window skupia się wyłącznie na istotnych danych. Najbardziej przydatną rzeczą, o której musisz tu pamiętać, jest to, że ogromne context window to nie wymówka, żeby wrzucać surowe pliki do promptu. Strukturyzacja twoich inputów poprzez mechaniczną destylację i zaindeksowane shardy zmusza model do systematycznego czytania zamiast ślepego skanowania. Jeśli uważasz te odcinki za przydatne i chcesz wesprzeć program, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. BMad Method, odcinek 15 z 15. Nigdy nie proś modelu językowego, żeby po prostu coś ulepszył. Niejasne polecenia skutkują leniwymi, ogólnikowymi poprawkami. Jeśli chcesz ulepszeń strukturalnych, musisz wtłoczyć model w sztywny reasoning framework, a jeszcze lepiej, wygenerować trzy różne persony AI i obserwować, jak dyskutują o błędach. To właśnie domena Advanced Elicitation i Party Mode. Częstą pułapką przy dopracowywaniu outputów, takich jak świeżo wygenerowany Product Requirements Document, jest promptowanie modelu, żeby przejrzał i ulepszył swoją własną pracę. Modele językowe są zaprojektowane tak, żeby były pomocne i ugodowe. Kiedy prosisz o ogólne ulepszenie, model zazwyczaj podmieni kilka przymiotników, przebuduje zdanie i ci je zwróci. Nie przepisze głównej logiki. Advanced Elicitation rozwiązuje to, aplikując formalne, uznane modele mentalne do outputu AI. Przestajesz prosić o ogólny feedback. Zamiast tego instruujesz model, żeby wykonał konkretny cognitive framework. Weźmy za przykład analizę pre-mortem. Wrzucasz do modelu swój świeżo wygenerowany dokument wymagań. Instruujesz go, żeby założył, że projekt został zbudowany, zdeployowany i okazał się absolutną, katastrofalną porażką. Model musi wtedy pracować wstecz, żeby dokładnie zdiagnozować, co spowodowało porażkę, opierając się tylko na obecnym dokumencie. Ponieważ ograniczyłeś prompt do konkretnego stanu porażki, model omija swoje grzeczne guardraile i agresywnie szuka luk w logice. Innym potężnym frameworkiem jest Inversion. Zamiast pytać, jak sprawić, by migracja bazy danych była bezpieczna, prosisz model o wypisanie dokładnych kroków wymaganych do zagwarantowania maksymalnej utraty danych podczas migracji. Nazwane reasoning frameworki dają o wiele lepsze rezultaty, ponieważ zmuszają model do wyjścia z jego domyślnych, wysoce prawdopodobnych ścieżek generowania tekstu i wejścia w bardzo specyficzne ścieżki analityczne. Kiedy już zidentyfikujesz te gwarantowane punkty awarii, musisz zaprojektować fixa. Mógłbyś poprosić pojedynczą personę o rozwiązanie problemu, ale złożone problemy architektoniczne wymagają napięcia. To prowadzi nas do Party Mode. Narzędzie Party Mode orkiestruje dyskusję grupową wielu agentów. Nie wchodzisz już w interakcję z pojedynczym asystentem. Konfigurujesz wirtualny pokój pełen konkretnych, wyspecjalizowanych person, wręczasz im problem i robisz krok w tył, żeby pozwolić im się kłócić. Oto jak wygląda flow logiki. Uruchamiasz narzędzie Party Mode i definiujesz swoich uczestników. Możesz zainstancjonować Senior Solutions Architecta, paranoicznego Security Engineera i pragmatycznego Frontend Developera. Przekazujesz im podatności odkryte podczas twojej analizy pre-mortem. Narzędzie następnie autonomicznie zarządza pętlą konwersacji. Architekt proponuje solidnego, złożonego fixa. Narzędzie przekazuje ten output Security Engineerowi, który atakuje propozycję, szukając potencjalnych wektorów pod exploity. Następnie narzędzie przekazuje kontekst Developerowi, który narzeka na złożoność implementacji i sugeruje prostsze podejście. Iterują po tych argumentach, rzucając sobie wyzwania bez twojej interwencji, aż osiągną konsensus albo dobiją do zdefiniowanego limitu tur. Ty tylko obserwujesz debatę i wyciągasz z transkryptu sfinalizowane, przetestowane w boju rozwiązanie. To podejście zmienia cię z osoby piszącej prompty w dyrektora silników rozumowania. Używasz Advanced Elicitation do systematycznego psucia własnych pomysłów, a Party Mode do inżynierii odbudowy poprzez syntetyczne tarcie. Najcenniejszą zmianą w pracy z modelami językowymi jest uświadomienie sobie, że wyinżynierowana niezgoda zawsze produkuje lepszą architekturę techniczną niż natychmiastowe, grzeczne posłuszeństwo. Jako że to ostatni odcinek serii, gorąco zachęcamy cię do przeczytania oficjalnej dokumentacji BMad, spróbowania orkiestracji tych debat hands-on, albo odwiedzenia DEV STORIES DOT EU, żeby zasugerować tematy do naszej kolejnej serii. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Trzymaj się!