BMad Method

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 1 von 15. Die meisten AI Coding Assistants scheitern am dritten Tag, weil sie vergessen haben, warum sie den Code am ersten Tag geschrieben haben. Am Ende hast du ein Chaos aus isolierten Skripten, die nicht zusammenpassen. Um das zu lösen, brauchst du keinen besseren Prompt, du brauchst Context Engineering und die vier Phasen. Ein häufiger Fehler ist, die BMad-Methode als einfachen Code-Generator zu betrachten. Das ist sie nicht. Sie ist eine agile Context-Engineering-Pipeline. Wenn du einen AI-Agenten einfach nur bittest, ein Feature zu bauen, rät er die Boundaries. BMad verhindert das, indem es den Kontext schrittweise in vier verschiedenen Phasen aufbaut und fixiert. Der Agent verliert nie den Überblick, weil jede Phase der nächsten strenge, dokumentierte Regeln vorgibt. Nehmen wir als Beispiel die Entwicklung einer SaaS-Applikation. Wenn du direkt zum Code springst, wählt die KI vielleicht eine Datenbank, die gegen deine Data-Residency-Anforderungen verstößt. Context Engineering verhindert das. Die Pipeline beginnt mit der Analysephase. Hier agiert die KI als Business Analyst. Sie verarbeitet deine rohen Ideen und erstellt ein Product Requirements Document. Diese Phase fixiert die Core Constraints. Sie erfasst User Personas, Compliance-Regeln und die wichtigsten Workflows. Das resultierende Dokument bildet die Grundlage für alles Weitere. Als Nächstes folgt die Planungsphase. Der Agent wechselt in die Rolle des Product Owners. Er nimmt das Requirements Document und bricht es in Epics und User Stories herunter. Aus abstrakten Requirements werden konkrete, umsetzbare Items. Der Kontext verengt sich. Die KI denkt nicht mehr an das gesamte Produkt, sondern nur noch an spezifische Deliverables, die auf eine klare Timeline gemappt sind. Hier wird es spannend. Die dritte Phase ist das Solutioning. Die KI übernimmt die Rolle des Architects. Sie schaut sich die User Stories aus der Planungsphase und die Constraints aus der Analysephase an, um das technische Design zu erstellen. Sie entscheidet über Datenmodelle, API Endpoints und Ordnerstrukturen. Für deine SaaS-Applikation sagen die in Phase eins definierten Business Constraints dem Architect in Phase drei ganz genau, welche Boundaries existieren. Das stellt sicher, dass die gewählte Architektur auch wirklich zu den ursprünglichen Business Rules passt. Schließlich erreichen wir die Implementierungsphase. Jetzt übernimmt die KI die Developer-Rolle. Der Developer-Agent muss weder die Architektur erraten noch über die Business Logic rätseln. Er bekommt den exakten technischen Blueprint vom Architect. Er schreibt den Code, um eine spezifische User Story zu erfüllen, und folgt dabei den präzisen Datenmodellen und Dateipfaden, die im vorherigen Schritt definiert wurden. Diese Context-Kette ist der springende Punkt. Informationen fließen durch persistente Dokumentation downstream. Der Output einer Phase wird zur strikten Input-Boundary für die nächste. Der Developer-Agent ist erfolgreich, weil der Architect-Agent den Weg geebnet hat, und der Architect war erfolgreich, weil der Business Analyst das Gebiet kartiert hat. Du betreibst Context Engineering auf jedem Level, damit sich die KI voll und ganz auf die Execution konzentrieren kann. Das entscheidende Merkmal eines resilienten AI-Workflows ist nicht, wie schnell er Text generiert, sondern wie strikt er Boundaries über verschiedene Denkphasen hinweg durchsetzt. Wenn du die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Danke fürs Zuhören und viel Erfolg beim Entwickeln!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad Method, Folge 2 von 15. Du denkst vielleicht, dass die Einführung eines neuen AI Development Frameworks bedeutet, dass du dir eine riesige Abfolge spezifischer Commands und starrer Workflow-Phasen merken musst. Das stimmt aber nicht. Du musst dir in diesem Framework keine einzige Command-Abfolge merken, weil das System deinen lokalen Folder physisch inspiziert und dir genau sagt, was du als Nächstes eintippen musst. Das ist der Intelligent Guide und Installationsprozess. Der Einstieg erfordert nur einen einzigen Schritt. In deinem Terminal führst du den Package Executor Command npx bmad-method install aus. Dieser Command initialisiert den Workspace und bereitet dein Repository strukturell vor. Das macht er, indem er zwei spezifische Verzeichnisse in deinem Root-Folder erstellt. Das erste Verzeichnis ist underscore bmad. Dieser Ordner ist das Gehirn deines lokalen Frameworks. Er enthält die Core Skills, Prompt-Definitionen und kontextbezogenen Templates, die die AI für ihre Arbeit nutzt. Das zweite Verzeichnis ist underscore bmad dash output. Das dient als dedizierter Destination-Folder. Wann immer das Framework neue Assets generiert – egal ob das Product Requirement Documents, Feature Specifications oder tatsächlicher Code sind –, werden sie in diesem Output-Directory abgelegt, sicher isoliert von deinem bestehenden Source Code. Hier ist die entscheidende Erkenntnis. Sobald diese Ordner existieren, machen Entwickler oft einen typischen Fehler. Sie gehen davon aus, dass sie die offizielle Documentation aufrufen, die verschiedenen Phasen des Frameworks studieren und die exakten Terminal-Commands auswendig lernen müssen, die nötig sind, um von Phase zu Phase zu wechseln. Sie machen sich Sorgen, versehentlich einen Schritt zu überspringen oder einen Command in der falschen Reihenfolge auszuführen. Du musst nichts davon tun. Das Framework ist zur Runtime selbstdokumentierend, dank eines Built-in Skills namens bmad-help. Bmad-help ist ein aktiver Guide, der den Cognitive Load bei der Navigation durch die Methodik eliminiert. Es ist kein statisches Manual. Wenn du ihn aufrufst, schaut sich der Skill aktiv den aktuellen State deines Workspaces an. Er checkt, was aktuell in deinen Ordnern ist, um genau zu bestimmen, wo du dich im Development Lifecycle befindest. Stell dir ein konkretes Szenario vor. Du hast gerade den Installation-Command abgeschlossen. Dein Workspace ist leer, bis auf die neuen Configuration-Folders. Du hast eine Idee für ein Softwareprodukt, aber keine Ahnung, welchen Command du als Nächstes eintippen sollst. Du triggerst einfach die CLI und tippst bmad-help ein, gefolgt von deiner Frage in ganz normalem Englisch. Zum Beispiel tippst du: bmad-help I have an idea for a SaaS, where do I start? Der Skill verarbeitet deine Frage, erkennt, dass es noch keine Planning Documents in deinem Output-Folder gibt, und sagt dir genau, was zu tun ist. Er antwortet mit dem spezifischen Command, den du ausführen musst, um die erste Phase zu initiieren. Er gibt dir keine generische Liste aller verfügbaren Commands. Er gibt dir die eine präzise Anweisung für deinen unmittelbaren Kontext. Während du dich durch die Methodik bewegst und Documents und Code erstellst, passt sich bmad-help an. Wenn du das Generieren deiner Architektur abgeschlossen hast und fragst, was als Nächstes zu tun ist, sieht er die Architektur-Files und schreibt den Command für die nächste passende Phase vor. Das Framework inspiziert deinen Fortschritt physisch und gibt deinen nächsten Schritt dynamisch vor. Du musst nie raten, ob du bereit bist, Code zu schreiben, oder ob du deine Requirements erst noch verfeinern musst, denn die lokale Installation liest konstant dein Environment, um dich auf dem richtigen Weg zu halten. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken, das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 3 von 15. Wenn du ein Large Language Model nach zehn Ideen fragst, bekommst du meistens zehn perfekt gemittelte, im Grunde langweilige Ideen. Das System ist darauf ausgelegt, das wahrscheinlichste nächste Wort vorherzusagen, was bedeutet, dass es zum Alltäglichen tendiert. Um wirklich innovative Ergebnisse zu erzielen, musst du die KI dazu zwingen, als Coach zu agieren, der die Konzepte stattdessen aus dir herausholt. Genau das macht der Forging Ideas with AI Brainstorming Workflow. Die meisten Leute setzen AI-Brainstorming mit Zero-Shot Prompting gleich. Du tippst eine Anfrage für Ideen in eine Chatbox und bekommst als Antwort eine generische Liste. Dieser Ansatz scheitert, weil er die KI als Orakel behandelt. Der Brainstorming-Coach der BMad-Methode arbeitet nach dem gegenteiligen Prinzip. Es ist ein geführtes Multi-Turn Facilitation Framework, bei dem die KI die Kernideen gar nicht erst generiert. Stattdessen erzeugt sie strukturierte kognitive Reibung, um dich zum Querdenken zu zwingen. Der Workflow verlässt sich stark auf zwei spezifische Mechanismen: Anti-Bias Protocols und Domain Shifting. Wenn du einen ersten Gedanken eingibst, verhindert das Anti-Bias Protocol, dass die KI dir einfach zustimmt. Wenn du eine Standardlösung für ein Problem vorschlägst, ist die KI so programmiert, dass sie diese hinterfragt. Sie könnte fragen, was passiert, wenn deine vorgeschlagene Lösung komplett scheitert, oder wie ein Konkurrent die offensichtlichen Schwächen in deiner Logik ausnutzen könnte. Domain Shifting geht noch einen Schritt weiter, indem es dich dazu zwingt, dein Problem aus der Perspektive einer völlig anderen Branche zu betrachten. Stell dir ein konkretes Szenario vor, in dem du nach Wegen suchst, das Developer Onboarding zu verbessern. Eine Standard-KI würde dir eine Liste darüber geben, wie man bessere Dokumentationen schreibt und Mentoren zuweist. Der Brainstorming-Coach von BMad hingegen könnte eine SCAMPER-Technik-Übung initiieren. SCAMPER ist ein Framework, das dich dazu auffordert, Elemente eines Prozesses zu ersetzen, zu kombinieren, anzupassen, zu modifizieren, für andere Zwecke zu nutzen, zu eliminieren oder umzukehren. Hier ist die entscheidende Erkenntnis. Die KI rattert nicht das gesamte Akronym auf einmal herunter und überhäuft dich mit einer Wall of Text. Sie übernimmt das Pacing Schritt für Schritt. Sie fragt dich, wie du die Phase des Dokumentationlesens beim Onboarding komplett eliminieren könntest. Du gibst eine Antwort basierend auf deiner Domain Expertise. Danach promptet dich die KI, das Onboarding mit einem völlig anderen Engineering Task zu kombinieren, wie zum Beispiel Live Incident Response. Du antwortest erneut. Die KI hält das Framework stabil, während du die eigentlichen Erkenntnisse lieferst. Du startest den Workflow, indem du deinen rohen Problem Space definierst. Die KI antwortet mit einer spezifischen Einschränkung oder einer gezielten Frage. Du antwortest. Die KI verarbeitet deine Antwort, wendet ihren Anti-Bias Check an und gibt dann Kontra oder shiftet die Domain. Dieser Multi-Turn Loop geht weiter, bis du die offensichtlichen Antworten ausgeschöpft hast und anfängst, wirklich neue Konzepte zu produzieren. Die KI agiert als unermüdlicher Facilitator, der es nicht zulässt, dass du dich mit dem Erstbesten zufriedengibst, das dir in den Sinn kommt. Der Wert einer KI in den frühen Phasen des Product Designs liegt nicht in ihrer Fähigkeit, Dinge von Grund auf neu zu erfinden, sondern in ihrer unendlichen Geduld, strukturierte kognitive Reibung auf deine eigene Expertise anzuwenden. Das war’s für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 4 von 15. Amazon ist bekannt dafür, die Pressemitteilung zu schreiben, bevor das Produkt gebaut wird. Was wäre, wenn eine KI diese Pressemitteilung unerbittlich hinterfragen würde, bevor du überhaupt die Codebase anfassen darfst? Die Wahl des richtigen Dokumentformats entscheidet frühzeitig darüber, ob du ein Tool baust, das die Leute wirklich brauchen, oder Monate mit etwas verschwendest, das niemand will. Die BMad-Methode löst diese Diskrepanz durch zwei verschiedene Outputs der Analysephase: das PRFAQ Gauntlet und das Product Brief. User tun sich oft schwer bei der Wahl des Formats. Die Regel ist simpel. Wenn du bereits eine klare Vorstellung davon hast, was du baust, und nur noch Team-Alignment brauchst, nutze das Product Brief. Wenn du herausfinden musst, ob das Produkt überhaupt eine Daseinsberechtigung hat, nutze das PRFAQ. Das Product Brief ist ein sanfter, kollaborativer Discovery-Prozess. Stell es dir wie ein geführtes Gespräch vor. Du und die KI arbeiten zusammen, um den Problem Space, die Zielgruppe, die Core Features und die Success Metrics zu umreißen. Die KI agiert dabei als unterstützender Co-Pilot. Sie nimmt deine groben Konzepte, strukturiert sie logisch und stellt höfliche Fragen, um fehlende Details zu ergänzen. Es ist der Weg des geringsten Widerstands. Du nutzt es, wenn die Richtung klar ist und du einfach ein professionelles, strukturiertes Dokument brauchst, um dir das Go zu holen oder ins Technical Design überzugehen. Das PRFAQ, was für Press Release and Frequently Asked Questions steht, ist ein völlig anderer Mechanismus. Das ist ein rigoroser, Customer-First-Stresstest. Er zwingt dich, von einem fiktiven Launch Day aus rückwärts zu arbeiten. Du beginnst damit, eine prägnante Pressemitteilung zu schreiben, die das fertige Produkt deiner Zielgruppe ankündigt. An diesem Punkt legt die KI ihre hilfsbereite Co-Pilot-Persona ab und wird zu einem skeptischen Stakeholder. Sie liest deine Pressemitteilung und generiert einen Spießrutenlauf aus brutalen, bohrenden Fragen. Stell dir ein Szenario vor, in dem du ein neues internes Deployment-Tool bauen willst. Du schreibst eine Pressemitteilung, in der du damit prahlst, dass Deployments jetzt nur noch einen Klick statt zehn brauchen. In einem Product Brief würde die KI dich vielleicht einfach bitten, die unterstützten Plattformen aufzulisten. Im PRFAQ Gauntlet wird die KI fragen, wie du automatisierte Rollbacks handhaben willst, wenn dieser eine Klick einen kritischen Bug deployed. Sie wird wissen wollen, warum das Infrastruktur-Team dieses Tool anstelle seiner bestehenden, battle-tested Scripts nutzen sollte. Du musst diese Fragen zufriedenstellend beantworten. Wenn deine Antworten vage sind, gibt die KI Kontra. Du bist gezwungen, die Value Proposition, die Usability und die technische Machbarkeit zu verteidigen, bevor echte Engineering-Zeit investiert wird. Hier ist die entscheidende Erkenntnis. Das Product Brief fokussiert sich darauf, was das Produkt ist, während das PRFAQ sich darauf fokussiert, warum es den Kunden interessieren sollte und ob dein Execution Plan realistisch ist. Das Product Brief schafft Konsens. Das PRFAQ zerstört schwache Annahmen. Du setzt das PRFAQ ein, wenn eine Idee teuer, kontrovers oder sehr unklar ist. Letztendlich beweist das Überleben des PRFAQ Gauntlets, dass dein Konzept dem Real-World-Check standhält, und dient als absoluter Schutz davor, Features zu bauen, nach denen eigentlich niemand gefragt hat. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 5 von 15. Der schnellste Weg, das falsche System zu bauen, ist, eine KI deine Requirements basierend auf einem losen Prompt halluzinieren zu lassen. Du musst die KI auf exakte Grenzen beschränken, bevor überhaupt Code geschrieben wird. Das PRD zu finalisieren, ist der Prozess, der diese Grenzen zieht. Leute verwechseln oft Projektplanung mit technischem Solutioning. Sie denken, zur Planung gehört es, eine Datenbank auszuwählen oder Microservices zu entwerfen. Das ist falsch. Bei der Planung geht es komplett um die Business Logic. Sie gibt null technische Umsetzung vor. Die Planungsphase fokussiert sich ausschließlich auf das Was und das Warum. Das Wie gehört in eine völlig andere Phase. In der BMad-Methode passiert das in Phase Zwei. Der verantwortliche Akteur ist der Product Manager Agent, John. John nimmt die Outputs aus Phase Eins, genauer gesagt dein freigegebenes PRFAQ und deine Brainstorming-Dokumente, und konsumiert sie. Du triggerst diesen Prozess mit einem Command namens bmad dash create dash prd. John nimmt die Vision aus dem PRFAQ und übersetzt sie in eine strikte Textdatei namens PRD dot md. Dieses Dokument dient als absolute Source of Truth für den Rest des Projekts. Dafür bricht John die Requirements in zwei strikte Kategorien herunter. Das sind Functional Requirements, oder FRs, und Non-Functional Requirements, oder NFRs. Functional Requirements definieren exakt, was das System tun muss. Non-Functional Requirements definieren die operativen Einschränkungen des Systems, wie Performance-Grenzwerte, Compliance-Regeln oder Verfügbarkeit. Stell dir ein konkretes Szenario vor. Du baust ein SaaS-Billing-Modul. Du fütterst den PM Agent mit deinem freigegebenen PRFAQ. John gibt Functional Requirements aus, die besagen, dass das Modul den Usern ein Upgrade ihrer Subscription erlauben muss, und dass es User automatisch downgraden muss, wenn ein Payment dreimal fehlschlägt. Dann gibt John Non-Functional Requirements aus, die besagen, dass alle Payment-Status-Updates innerhalb von zwei Sekunden im User-Dashboard sichtbar sein müssen. Hier ist die wichtigste Erkenntnis. Achte mal darauf, was in diesen Requirements fehlt. John erwähnt kein Stripe, er erwähnt kein PostgreSQL, und er designt keinen API Payload. Wenn dein PRD eine spezifische Datenbanktechnologie erwähnt, ist der Prozess gescheitert. Das PRD nagelt nur die Business-Erwartungen fest. Sobald das PRD steht, geht Phase Zwei in den UX Design Workflow über. Dieser Schritt nimmt die rohe Business Logic und mappt die menschliche Interaktion. Wenn ein Functional Requirement besagt, dass ein User eine Subscription upgraden muss, diktiert der UX Design Workflow die exakte Abfolge von Screens, Buttons und Error Messages, auf die der User stoßen wird. Genau wie das PRD trifft dieser UX Workflow null Frontend-Framework-Entscheidungen. Es ist ihm völlig egal, ob du am Ende React oder Vue benutzt. Er kümmert sich nur um die Schritt-für-Schritt User Journey. Indem du den PM Agent zwingst, ein striktes, technologieagnostisches PRD und einen UX Flow zu generieren, erschaffst du einen Anker. Large Language Models driften von Natur aus mit der Zeit ab. Später im Projekt werden deine Engineering Agents gezwungen sein, ihre technischen Solutions gegen genau diese FRs und NFRs zu prüfen. Wenn ein Feature nicht im PRD steht, werden die Agents es nicht bauen. Das PRD ist kein lockeres Vorschlagsdokument; es ist eine starre Grenze für deine AI Agents, die deine Core Business Needs komplett von der späteren technischen Implementierung isoliert. Ich möchte mir kurz einen Moment nehmen, um dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad Method, Folge 6 von 15. Wenn du zwei AI Agents beauftragst, zwei verschiedene Features zu bauen, ohne ein gemeinsames Architekturdokument zu haben, werden sie unweigerlich Krieg gegen den Code des jeweils anderen führen. Sie werden widersprüchliche technische Entscheidungen treffen, die deine Application zerschießen. Der Mechanismus, um das zu stoppen, ist Phase 3 Solutioning. Dabei geht es speziell darum, Agent-Konflikte durch Architektur zu verhindern. Menschen, die an einem Softwareprojekt arbeiten, reden miteinander. Sie tauschen Annahmen bei einem Kaffee oder über Chat-Nachrichten aus. AI Agents, die parallel arbeiten, haben kein gemeinsames Bewusstsein. Sie operieren in völlig isolierten Context Windows. Gib Agent A die Aufgabe, ein User Dashboard zu implementieren, und er entscheidet vielleicht, dass eine REST API und Redux am besten passen. Gib Agent B die Aufgabe, eine User Settings Page zu bauen, und er entscheidet sich vielleicht unabhängig davon, GraphQL und Zustand hochzuziehen. Wenn diese beiden Features dann in den Main Branch gemerged werden sollen, hast du ein massives Integrationsproblem. Beide Agents haben genau das getan, was du verlangt hast, aber ihre isolierten Optimierungen haben ein systemisches Chaos verursacht. Developer wollen formale Architektur-Dokumentation oft überspringen, weil es sich wie Corporate Overhead anfühlt. Wenn du nur ein kleines, isoliertes Script zusammenhackst, ist das auch völlig okay. Die BMad Method beinhaltet einen Quick Flow speziell für kleine Tasks, der diese Phase ganz bewusst überspringt. Aber bei komplexen Projekten garantiert das Überspringen der Architektur-Phase einen Agent Drift. Du kannst dich nicht auf das Default-Verhalten von Large Language Models verlassen, dass sie sich über verschiedene Sessions hinweg zufällig auf denselben Tech Stack einigen. Um das technische Alignment zu erzwingen, nutzt die Methode einen speziellen Workflow namens bmad create architecture. Du führst diesen Workflow aus, bevor auch nur eine einzige Zeile Application Code geschrieben wird. Er analysiert deine Project Requirements und generiert Architecture Decision Records. Architecture Decision Records sind leichtgewichtige, strukturierte Textdateien. Sie halten die definitiven technischen Entscheidungen für das Projekt fest. Ein Record gibt die State Management Library vor. Ein anderer spezifiziert das genaue Pattern für das Data Fetching. Ein dritter definiert das Testing Framework. Sie etablieren die harten, unumstößlichen Regeln des Systems. Hier ist die entscheidende Erkenntnis. Im traditionellen Software Engineering ist ein Architecture Decision Record in erster Linie ein historisches Log, das neuen menschlichen Developern hilft, frühere Entscheidungen zu verstehen. In einem Multi-Agent AI System ist er ein aktiver Kontrollmechanismus. Large Language Models haben keine Erinnerung daran, was ein anderes Model entschieden hat, es sei denn, du fütterst diese Information explizit in ihren Prompt Context. Wenn du den Architektur-Workflow ausführst, werden die resultierenden Dokumente direkt in deinem Project Repository gespeichert. Wenn du später Agent A deployest, um das Dashboard zu bauen, und Agent B, um die Settings zu bauen, füttert das System beide Agents mit genau diesen Decision Records, bevor sie anfangen, Code zu schreiben. Die Architektur-Files fungieren als die ultimative Ground Truth. Agent A liest den Record, der Redux und REST vorgibt, und baut alles entsprechend auf. Agent B liest exakt denselben Record und baut ebenfalls mit Redux und REST. Die architektonischen Grenzen zwingen unabhängige Models dazu, als ein zusammenhängendes Team zu agieren. Indem du ihnen während der Feature-Implementierungsphase die Last der Entscheidung abnimmst, reduzierst du Halluzinationen drastisch und verhinderst Dependency-Konflikte. Architektur-Dokumente in einem AI Workflow sind nicht einfach nur passive Notizen für Menschen; sie sind programmierbare Constraints, die nicht-deterministische Agents dazu zwingen, ein deterministisches System zu bauen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 7 von 15. KI-Agenten orientieren sich standardmäßig an generischen Best Practices. Das bedeutet, sie schreiben Code, der eher wie eine durchschnittliche Stack-Overflow-Antwort aussieht und nicht wie deine Codebase. Wenn du willst, dass sie genau so programmieren wie dein Senior Engineering Team, musst du deine eigenen Regeln durchsetzen. Genau das macht die Project Context Constitution. Im Kern ist das eine Datei namens project-context.md. Du legst sie im Root deines Repositorys ab. Stell sie dir als das ultimative Regelwerk für jede KI vor, die mit deinem Projekt interagiert. Wenn ein Agent dein Repository liest, lädt er diese Datei zuerst, um die nicht verhandelbaren Grenzen deiner Architektur zu verstehen. Du kannst diese Datei manuell erstellen, oder du generierst dir einen Startpunkt, indem du den Befehl bmad-generate-project-context in deinem Terminal ausführst. So oder so muss das Dokument zwei spezifische Abschnitte enthalten. Das sind der Tech Stack und die Critical Rules. Der Tech-Stack-Abschnitt ist eigentlich simpel, erfordert aber Präzision. Du listest nicht einfach nur React oder Node auf. Du gibst die genauen Versionen, das Routing-Paradigma und die Styling-Libraries an. Wenn du Next.js mit dem App Router und Tailwind benutzt, dann schreib genau das rein. Die KI nutzt das, um ihre riesigen Trainingsdaten auf die spezifische Syntax herunterzufiltern, die dein Projekt braucht. Der zweite Teil davon ist der Critical-Rules-Abschnitt. Pass hier gut auf. Ein sehr häufiger Fehler von Entwicklern ist, diesen Abschnitt mit generischen Ratschlägen wie schreibe Clean Code oder nutze DRY-Prinzipien zu füllen. Mach das nicht. Die KI kennt generischen Clean Code bereits. Du musst die nicht offensichtlichen, projektspezifischen Patterns aufschreiben, die der Agent niemals von selbst erraten könnte. Hier legst du strenge Architektur-Regeln fest. Zum Beispiel schreibst du eine Regel, die Strict Mode TypeScript für jede neue Datei vorschreibt. Du weist den Agenten an, dass alle Integration Tests Mock Service Worker verwenden müssen. Am wichtigsten ist, dass du Verhaltensweisen verbieten kannst. Wenn dein Projekt ein Custom API Client Singleton hat, schreibst du explizit eine Regel, die besagt: Nutze niemals natives fetch oder Axios direkt, sondern importiere immer den Custom API Client aus dem Network Utilities Ordner. Wenn die KI ein neues Feature generiert, gleicht sie ihren Output mit diesen Regeln ab. Weil der Project Context ganz oben in der Prompt-Hierarchie steht, überschreiben diese Anweisungen die Baseline-Tendenzen der KI. Wenn ein Agent versucht, einen direkten API Fetch zu schreiben, zwingt ihn die Project Context Constitution dazu, diese Logik mit deinem Custom Wrapper neu zu schreiben, bevor er den Code überhaupt ausgibt. Das Ziel dieser Datei ist nicht, der KI das Programmieren beizubringen, sondern ihr beizubringen, wie sie hier programmiert, in diesem spezifischen Repository. Wenn dir diese Episoden gefallen und du die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad Method, Folge 8 von 15. Bevor du eine AI Hunderte Zeilen Code schreiben lässt, musst du einen entscheidenden Schritt durchführen, um einen katastrophalen Sprint zu verhindern. Dieser Schritt ist das Breaking Work Down und der Gate Check. In dieser Phase des Workflows hast du ein finales Product Requirements Document und ein fertiges Architecture Design. Jetzt brauchst du Tickets. Hier kommt der Project Manager Agent ins Spiel. Seine Aufgabe ist es, den Create Epics and Stories Prozess auszuführen. Der PM Agent liest das Requirements Document, arbeitet aber nicht im luftleeren Raum. Er gleicht diese Business Needs mit den Constraints ab, die in deiner Architecture Documentation definiert sind. Der PM Agent übersetzt High-Level Features in Epics. Dann schneidet er diese Epics in spezifische, umsetzbare User Stories. Er entwirft die Acceptance Criteria und den technischen Kontext für jeden Task. Durch den Abgleich mit den Architecture Documents stellt der PM sicher, dass die für die Story erforderlichen Data Models und Component Interactions im technischen Plan auch wirklich existieren. Das garantiert, dass jedes Ticket einem echten Business Requirement dient und sich gleichzeitig strikt an die Grenzen des System Designs hält. Der Output dieses Schritts ist ein vollständig gefüllter Backlog. Hier ist die wichtigste Erkenntnis: Sobald dieser Backlog existiert, ist die Versuchung riesig, sofort mit dem Generieren von Code zu beginnen. Aus reiner Ungeduld überspringen Leute routinemäßig den nächsten Schritt. Sie wollen funktionierende Software sehen, also pushen sie die neuen Tickets direkt ins Development. Mach das nicht. Wenn du den Readiness Check überspringst, verbrennst du am Ende teure API-Tokens für Code, der sich nicht integrieren lässt. Deshalb kommt der Architect Agent wieder ins Spiel, um die Check Implementation Readiness Phase durchzuführen. Das ist dein ultimatives Sicherheitsnetz. Es fungiert als strenger Gate Check, bevor überhaupt mit dem Programmieren begonnen wird. Der Architect liest jedes einzelne Epic und jede User Story, die vom PM generiert wurden, und validiert sie direkt gegen die Architecture. Der Architect sucht nach fehlenden technischen Prerequisites, architektonischen Widersprüchen oder stillschweigenden Annahmen. Er verifiziert, dass jede in einer Story erwähnte Data Structure ein entsprechendes Database Schema hat. Er checkt, ob die notwendigen Service Endpoints auch wirklich definiert sind. Stell dir ein konkretes Szenario vor: Du führst den Gate Check aus, und der Architect markiert ein Epic für ein neues User Notification Feature. Das Ticket geht von der Nutzung einer bestimmten Third-Party Messaging API aus. Der Architect weist jedoch darauf hin, dass diese Integration in den Architecture Decision Records nie besprochen oder approved wurde. Der Gate Check stoppt den Prozess sofort. Du hast dir gerade stundenlange, verschwendete Development-Zeit gespart, in der du versucht hättest, ein Feature gegen eine nicht genehmigte oder undokumentierte Dependency zu bauen. Diese Zusammenarbeit zwischen Business Needs und technischer Realität ist der Kern dieser Phase. Der PM Agent definiert die Arbeit basierend auf dem, was der User braucht. Der Architect Agent verifiziert die Arbeit basierend auf dem, was das System tatsächlich unterstützen kann. Du machst erst weiter, wenn der Architect sein Sign-off gibt und damit beweist, dass der Backlog komplett implementierbar ist. Ein perfektes Product Requirement ist völlig nutzlos, wenn die zugrunde liegende System Architecture es nicht unterstützen kann, und dieser Gate Check ist der einzige objektive Beweis dafür, dass deine Tickets tatsächlich ready to build sind. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad Method, Folge 9 von 15. Du sagst einer AI nicht einfach, dass sie eine Anwendung bauen soll. Wenn du ein Language Model bittest, ein komplettes Product Feature oder ein Epic auf einmal zu implementieren, bekommst du unausgereifte Logik, fehlende Files und ein absolutes Code-Chaos. Um production-grade Output von einer AI zu erhalten, musst du exakt dieselbe Disziplin durchsetzen, die du von einem leistungsstarken menschlichen Engineering-Team erwartest. Heute schauen wir uns den Build Cycle und das Sprint Tracking an – das ist der mechanische, disziplinierte Loop der Ausführung von Phase vier, der Implementation. Der größte Fehler, den Developer mit AI-Tools machen, ist, zu viel auf einmal zu verlangen. Der Build Cycle basiert vollständig auf einer strikten Ausführung von genau einer Story nach der anderen. Du trackst den State, du schnappst dir eine einzelne Story, du führst sie aus, du validierst sie und du updatest deinen State. Dieser Prozess erfordert klar definierte Personas, die spezifische Teile der Pipeline übernehmen. So stellst du sicher, dass kein Context verloren geht und der Scope nicht aufgebläht wird. Der Cycle beginnt mit dem Sprint Planning. Du führst den bmad sprint planning prompt aus, der ein File namens sprint status yaml generiert. Dieses File ist deine absolute Source of Truth. Es listet explizit jede Story in deinem aktuellen Sprint auf und markiert ihren Status als pending, in progress oder done. Dieses Dokument erdet die AI. Es verhindert, dass das Model Fortschritte halluziniert oder Dependencies vergisst, weil die AI dieses File ständig lesen muss, um den aktuellen State des Projekts zu verstehen. Sobald dein Sprint geplant ist, startest du den Execution Loop. Zuerst aktivierst du die Scrum Master Persona, Bob, indem du den bmad create story prompt nutzt. Du weist Bob an, sich das sprint status yaml File anzusehen und das oberste pending Item auszuwählen. Bob schreibt keinen Application Code. Stattdessen generiert er ein hochfokussiertes Markdown-File, das ausschließlich dieser einen User Story gewidmet ist. Dieses Dokument skizziert die spezifischen Acceptance Criteria, technischen Constraints und Test-Szenarien, die nötig sind, um den Task abzuschließen. Als Nächstes übergibst du dieses isolierte Story-File an die Developer Persona, Amelia. Du nutzt den bmad dev story prompt, um diesen Schritt einzuleiten. Amelia liest das Story-File, analysiert die aktuelle Codebase und implementiert die Logik. Weil ihr Context künstlich auf Bobs Anweisungen und die relevanten Application Files eingegrenzt ist, wird sie nicht versehentlich unbeteiligte Module umschreiben oder aus dem Scope des aktuellen Tasks herausfallen. Nachdem Amelia den Code geschrieben hat, ist die Story noch nicht done. Du rufst den bmad code review prompt auf. Das fungiert als automatisiertes Quality Gate. Der Review-Prozess prüft Amelias Code gegen die strikten Acceptance Criteria, die in Bobs Story-File definiert sind. Dabei werden fehlende Edge Cases, Logikfehler oder Formatierungsinkonsistenzen aufgedeckt. Du behebst alle Issues, die während dieses Reviews gefunden werden. Erst wenn der Code durchgeht, updatest du das sprint status yaml File und änderst die Story manuell von in progress auf completed. Dann loopst du zurück zu Bob, um dir das nächste pending Item zu ziehen. Hier ist die wichtigste Erkenntnis: Die Power dieses Loops liegt nicht in der Code Generation selbst, sondern in der strikten Separation of Concerns, die die AI dazu zwingt, das Planen, Ausführen und Reviewen als separate, isolierte Schritte durchzuführen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad Method, Folge 10 von 15. Manchmal ist der komplette agile Prozess für einen lokalen Fix einfach Overkill. Du hast einen unübersichtlichen Jira Bug Report und willst einfach nur, dass er gefixt und gereviewt wird, ohne jeden Schritt manuell zu verifizieren. Hier erfährst du, wie du mit dem Quick Dev Track für Zero-Blast Changes in einem einzigen, autonomen Run von diesem rohen Ticket zu einem gereviewten Pull Request kommst. Viele sehen Quick Dev einfach als einen generischen Code Prompt, bei dem man ein Ticket auf ein Large Language Model wirft und auf das Beste hofft. Das ist es aber nicht. Quick Dev isoliert die Klärung des Intents explizit von der Execution. Es gibt dem System eine harte Grenze, an der es sich abarbeiten kann, anstatt die Problemdefinition direkt in den Code Generation Step einfließen zu lassen. Der Standard Agile Track verlässt sich stark auf strikte Checkpoints. Du machst Pause, verifizierst den Plan, verifizierst die Tests und verifizierst die Implementierung. Quick Dev streicht diese Checkpoints komplett. Es vertraut dem Model mehr und spart deine menschliche Aufmerksamkeit für die entscheidenden Momente. Du nutzt diesen Track ausschließlich für Zero-Blast-Radius Changes. Mechanisch gesehen bedeutet das, dass Modifikationen auf eine einzelne Component oder Funktion isoliert sein müssen. Die Änderung darf keine Public Interfaces verändern, keine Database Schemas modifizieren und keine Shared Utility Functions umschreiben, die von anderen Domains genutzt werden. Wenn eine Änderung das Core State Management anfasst, gehört sie auf den Standard Track. Stell dir das Szenario vor, in dem du einen Link zu einem fragmentierten Jira Bug Ticket an das bmad-quick-dev Tool übergibst. Das Erste, was das System ausführt, ist die Intent Compression. Es liest die verstreuten Kommentare, die Steps to Reproduce und die User-Beschwerden. Es zwingt das Model, Widersprüche aufzulösen, bevor es überhaupt Code anfasst. Wenn das Ticket widersprüchliche Anweisungen hat, synthetisiert der Compression Step sie zu einem einzigen, definitiven Ziel. Dieser Output ist Plain Text und definiert exakt, was der Fix beinhaltet und, ganz entscheidend, wo die Grenzen des Fixes liegen. Hier ist die entscheidende Erkenntnis. Weil der Intent jetzt komprimiert und isoliert ist, hat die autonome Execution-Phase eine strikte Spezifikation, der sie folgen kann. Das System schreibt den Fix, generiert oder updatet die lokalisierten Tests und führt ein Self-Review gegen diesen initialen komprimierten Intent durch. Es loopt kontinuierlich durch diese Schritte. Du gehst weg, während es arbeitet, und kommst zu einem fertigen Pull Request zurück. Quick Dev ist schnell, aber wenn ein autonomer Run fehlschlägt, musst du die Failure Layers genau diagnostizieren. Du schaust dir an, wo der Prozess abgebrochen ist. Wenn der finale Code ein komplett falsches Problem löst, passierte der Fehler auf dem Intent Compression Layer. Das Jira Ticket war wahrscheinlich zu mehrdeutig, was dazu geführt hat, dass das Model das Ziel halluziniert hat. Du fixt das, indem du den initialen Input neu schreibst. Wenn der Intent korrekt ist, aber die neuen Tests fehlschlagen oder der Build bricht, liegt der Fehler im Execution Layer. Du fixt Execution-Fehler, indem du das Model anstupst, diesen spezifischen Logikblock neu zu versuchen. Wenn der Execution Layer zweimal hintereinander fehlschlägt, ist das Problem nicht mehr der Prompt. Der Blast Radius der Änderung war einfach größer als du anfangs dachtest, und du musst auf den Standard Track mit Checkpoints zurückfallen. Autonomie funktioniert nur, wenn die Grenze der Task kleiner ist als das Context Window des Models, das sie löst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad Method, Folge 11 von 15. Die meisten AI Coding Frameworks gehen davon aus, dass du mit einem komplett leeren Directory startest. Sie wollen das Scaffolding generieren, die Architektur vorgeben und den gesamten Prozess von Tag eins an kontrollieren. Aber wenn du einen AI Agent auf einen riesigen, fünf Jahre alten Rails-Monolithen mit undokumentierten Naming Conventions loslässt, macht dieser Blank-Slate-Ansatz alles kaputt. Beim Onboarding Established Codebases geht es darum, wie du BMad mit dem zum Laufen bringst, was du bereits hast. Eine häufige Annahme von Developern ist, dass BMad ausschließlich für Greenfield Development gedacht ist. Das ist falsch. BMad erzwingt keinen Rewrite und drückt dir keine externe Struktur auf. Es wurde gebaut, um sich anzupassen, deine bestehende Architektur zu respektieren und zu analysieren, damit es sich sauber integriert. Das Einlesen eines etablierten Repositorys erfordert jedoch einen spezifischen Workflow, um zu verhindern, dass die AI deine Technical Debt übernimmt. Der allererste Schritt ist das Aufräumen von Artefakten. AI Models sind im Grunde hochentwickelte Pattern-Matching-Engines. Wenn du sie auf ein Repository loslässt, das voll ist mit auskommentierten Code Blocks, deprecated API Calls und inkonsistentem File Naming, wird der Agent davon ausgehen, dass das die akzeptierten Standards sind. Bevor du den Agent einführst, musst du Dead Code entfernen, deine Linting-Regeln durchsetzen und sicherstellen, dass deine Test Suite auch wirklich durchläuft. Du legst damit den Baseline-Standard fest. Je sauberer der Input State ist, desto besser wird sich der Agent an deinen tatsächlichen Absichten orientieren. Sobald das Repository sauber ist, mappst du es mit einem Command namens bmad-generate-project-context. Genau hier passiert die Anpassung. Anstatt manuell seitenweise Dokumentation darüber zu tippen, wie deine Application strukturiert ist, führst du dieses Tool aus, um deine Legacy Patterns zu scannen. Denk nochmal an diesen fünf Jahre alten Rails-Monolithen. Der Context Generator liest den File Tree, parst die Abstraktionen und leitet deine undokumentierten Regeln ab. Er findet heraus, ob dein Team Fat Models oder Service Objects bevorzugt. Er analysiert dein Testing Directory, um zu sehen, wie du Database Calls mockst. Er nimmt all diese Ableitungen und schreibt sie in ein zentrales Context Document. Dieses File wird zum grundlegenden Prompt für die AI. Wenn du den Agent bittest, ein neues Feature zu bauen, liest er zuerst diesen Context. Er versteht die bestehende Architektur und generiert Code, der exakt so aussieht, als hätte ihn ein Senior Engineer aus deinem Team geschrieben. Wenn der Context generiert ist, wählst du, wie du Updates anwenden willst – entweder mit Quick Dev oder der Full Method. Deine Wahl hängt komplett von der Komplexität der Task ab. Wenn du einen lokalisierten Bug fixt oder einen einzelnen Query Parameter zu einem bestehenden Endpoint hinzufügst, nutze Quick Dev. Der Agent liest dein Context File, wendet den gezielten Patch an, verifiziert ihn anhand deiner lokalen Tests und beendet sich. Das ist eine schnelle Operation mit wenig Overhead. Der zweite Teil hiervon behandelt komplexe Updates. Wenn du ein komplett neues Billing Module in diesen Monolithen einbauen musst, wechselst du zur Full Method. Der Agent nutzt das Context File, um zuerst ein umfassendes Design Document zu schreiben. Darin wird skizziert, wie das neue Module mit deinen bestehenden Components interagieren wird. Er schreibt Failing Tests, die zu deinem Legacy Testing Style passen, implementiert die Business Logic und iteriert, bis die Tests durchlaufen. Das Framework skaliert seine Gründlichkeit basierend darauf, was die Task erfordert. Hier ist die wichtigste Erkenntnis. Der Erfolg eines AI Agents in einem Legacy Repository hängt komplett von der Qualität der Patterns ab, die er erkennt. Das bedeutet, dass ein rigoroses initiales Cleanup und ein akkurates Context File die einzigen Dinge sind, die zwischen einer nahtlosen Feature Addition und architektonischem Chaos stehen. Ich möchte mir kurz die Zeit nehmen, dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad Method, Folge 12 von 15. Du öffnest dein Terminal, tippst einen Command ein, um deinen Code zu formatieren, und bekommst einen komplett generischen Error. Du versuchst, einen internen Agent Command zu nutzen, aber der Agent läuft noch gar nicht. Es gibt zwei verschiedene Wege, deine AI-Workforce zu steuern, und sie zu vermischen, ist der häufigste Reibungspunkt im System. Heute geht es um Commanding Agents: Skills versus Triggers. Die erste Kategorie sind Skills. Stell dir Skills als deine globalen Entry Points vor. Das ist das, was du in dein IDE-Terminal oder deine Command Line eintippst, um eine Action von null auf zu starten. Wenn du bmad-help eintippst oder ein bestimmtes Agent Launch Script aus deiner IDE triggerst, nutzt du einen Skill. Er bootet das Environment. Er lädt den nötigen Context. Er bringt den Agent online. Skills haben ihren Platz außerhalb der Agent Conversation. Sie sind die Mechanismen, die die Engine starten. Das bringt uns zu der typischen Falle. Sobald die Engine läuft und du mit einem Agent chattest, ändern sich die Regeln. Du hörst auf, Skills zu nutzen, und fängst an, Triggers zu verwenden. Ein Trigger ist ein kurzer Code, den du direkt in eine aktive Chat Session eintippst, um einen Agent zu steuern, der bereits zuhört. Wenn du einen Agent Menu Trigger in dein Standard-Terminal eintippst, hat das System keine Ahnung, was du meinst. Wenn du versuchst, einen IDE-Skill aus einem Agent Chat heraus auszuführen, schlägt das fehl. Die Grenze ist absolut. Skills starten die Session. Triggers steuern die aktive Session. Sobald du im Chat bist, gibt es Triggers in zwei Varianten: Workflow Triggers und Conversational Triggers. Workflow Triggers starten starre, vordefinierte Sequenzen. Du tippst den Trigger ein, der Agent führt einen bestimmten mehrstufigen Prozess Schritt für Schritt aus, liefert den Output, und die Sequenz endet. Conversational Triggers sind viel flexibler. Sie erlauben dynamisches Task-Switching, ohne die Agent Persona zu brechen. Du bleibst im Chat, aber du verlagerst den aktiven Fokus. Stell dir ein konkretes Szenario vor. Du brauchst neue Documentation. Du fängst an, indem du einen IDE-Skill nutzt, um Paige, den Technical Writer Agent, zu launchen. Der Skill bootet Paige, und sie fragt, was du brauchst. Sie ist jetzt aktiv. Anstatt jetzt einen riesigen Prompt zu schreiben, der erklärt, dass du einen bestimmten Dokumenttyp in einem bestimmten Format brauchst, tippst du einfach den Conversational Trigger W D in den aktiven Chat Prompt ein. Das steht für Write Docs. Paige wechselt sofort in ihren vordefinierten Documentation Drafting Mode. Sie fragt nach deinen Raw Notes, verarbeitet sie und generiert den Text. Du liest den Text und merkst, dass du noch ein Architecture Diagram dazu brauchst. Du schließt den Chat nicht. Du launchst keinen neuen Skill aus dem Terminal. Du tippst einfach einen weiteren Conversational Trigger ein, M G, was für Mermaid Graph steht. Paige schwenkt sofort um. Sie bleibt in ihrem Character als dein Technical Writer, behält den Context des Dokuments, das sie gerade geschrieben hat, und generiert den passenden Mermaid-Diagramm-Code dazu. Du routest ihre Capabilities dynamisch on the fly, ohne jemals den Context zu verlieren. Hier ist die wichtigste Erkenntnis. Die wahre Power dieses dualen Systems ist nicht nur, dass du weniger tippen musst, sondern dass du einen persistenten, intelligenten Context beibehältst, während du den internen Operating Mode eines Agents sofort switchst. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 13 von 15. Deine AI Code Reviews sind wahrscheinlich viel zu nett. Wenn du ein Model einfach nur nach Bugs suchen lässt, liefert es dir höfliche Vorschläge und generische Syntax-Checks. Um katastrophale Fehler zu finden, brauchst du spezialisierte, opinionated Diagnostic Engines. Genau darum geht es in dieser Folge: Adversarial Review und Edge Case Hunting. Oft behandelt man AI Code Reviews als einen einzigen, General-Purpose-Pass. Man wirft einem Model einen Diff hin und hofft, dass es alles findet. Das funktioniert selten gut. Einem generischen Prompt fehlt ein spezifisches mentales Model, was zu oberflächlichem Feedback führt. Die BMad-Methode löst das durch den Einsatz eng definierter, spezialisierter Personas. Wir schauen uns zwei verschiedene Review-Tools an, die mit völlig unterschiedlichen Methoden arbeiten. Schauen wir uns zuerst den Adversarial Reviewer an. Dieses Tool ist attitude-driven und extrem skeptisch. Es misstraut deinem Code, deiner Infrastruktur und deinen Usern. Es geht davon aus, dass deine Implementierung grundlegend kaputt ist, und sucht aktiv nach Wegen, wie sie exploited werden kann. Es ignoriert stilistische Entscheidungen, Variable Naming oder kleinere Performance-Optimierungen komplett. Stattdessen jagt es ausschließlich nach Business Logic Gaps, Privilege Escalations und kaputten Trust Assumptions. Der Adversarial Reviewer schaut sich deine API-Perimeter an und fragt sich, wie ein Bad Actor deinen vorgesehenen Flow umgehen könnte. Er liest deinen Code mit tiefem Zynismus und behandelt jeden Input als potenziellen Attack Vector und jede Data Boundary als Schwachstelle. Als Nächstes haben wir den Edge Case Hunter. Dieses Tool arbeitet mit der exakt gegenteiligen Persönlichkeit. Es ist mathematisch kalt, komplett ohne Kontext und rein mechanisch. Es interessiert sich nicht für böswillige User oder Business Intent. Stattdessen führt es striktes Path-Tracing durch. Es baut einen mentalen Control Flow Graph deines Codes auf und folgt jedem einzelnen Branch bis zu seinem logischen Ende. Der Edge Case Hunter fokussiert sich rein auf State Mutations, Boundary Conditions und Data Types. Er sucht nach den obskuren Execution Paths, die Silent Failures, Memory Leaks oder Unhandled Exceptions verursachen. Um den Unterschied zu sehen, wende beide Tools auf ein einziges Stück Code an, wie zum Beispiel einen komplexen Authentication-Diff. Du übergibst diesen Code zuerst dem Adversarial Reviewer. Weil er auf Zynismus basiert, ignoriert er die mechanische Syntax und entdeckt ein fehlendes Business Logic Constraint. Er merkt, dass das Authentication Token zwar korrekt validiert wird, das System aber implizit der User Role vertraut, die in diesem Token eingebettet ist, ohne die Live-Datenbank zu checken. Der Adversarial Reviewer flaggt das als kritische Trust Vulnerability. Jetzt übergibst du genau denselben Authentication-Diff an den Edge Case Hunter. Dieses Tool ignoriert die Token Trust Logic komplett. Stattdessen trackt es über mechanische Path Derivation den Lifecycle jeder Variable. Es findet eine tief verschachtelte Validation Function, der ein expliziter Type Check fehlt. Es weist auf eine unhandled implicit Type Coercion hin. Wenn der Input Payload an diesem spezifischen Index ein Null-Objekt anstelle eines Strings enthält, wird die Application eine Unhandled Exception werfen und crashen. Hier ist die entscheidende Erkenntnis. Du benutzt diese Tools nicht, um Typos zu finden. Du benutzt sie, um deiner Codebase zwei völlig verschiedene analytische Frameworks aufzuzwingen. Das eine attackiert deine Annahmen über System Trust und menschliches Verhalten. Das andere attackiert deine Annahmen über Execution Paths und Data States. Indem du den zynischen Angreifer vom mechanischen Path-Tracer trennst, verlässt du dich nicht mehr auf generisches Bug-Finding, sondern fängst an, tiefe strukturelle Vulnerabilities aufzudecken, bevor sie jemals Production erreichen. Danke fürs Einschalten. Bis zum nächsten Mal!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 14 von 15. Wenn du ein fünfzigseitiges Dokument direkt in ein Large Language Model einspeist, leidet es fast sofort unter Context Blindness. Es lässt Details aus der Mitte des Textes weg, halluziniert Fakten und verschlechtert sein eigenes Reasoning. Um das zu beheben, brauchst du einen verlustfreien Komprimierungstrick. Heute geht es um Context Management: Distillation und Sharding. Viele Entwickler denken, Distillation sei einfach nur eine Zusammenfassung. Das ist falsch. Bei einer Zusammenfassung werden absichtlich Daten weggeworfen, um einem Menschen einen schnellen Überblick zu geben. Distillation ist ein verifizierbarer, verlustfreier Komprimierungsprozess. Hier ist die entscheidende Erkenntnis. Das Distillator-Tool nimmt ausführlichen menschlichen Text, entfernt die Übergänge, Adjektive und Füllwörter und wandelt ihn in ein extrem dichtes Stichpunktformat um. Dieses Format ist strikt für maschinelles Lesen gemacht. Du behältst jeden einzelnen Fakt, aber reduzierst den Token Count drastisch. Nimm mal dieses riesige fünfzigseitige technische Whitepaper. Wenn du es durch das Distillator-Tool jagst, kannst du eine Komprimierungsrate von etwa drei Komma zwei zu eins erreichen. Die gesamte Payload-Größe sinkt um mehr als zwei Drittel, und trotzdem behält das Modell Zugriff auf jede technische Spezifikation und Architekturentscheidung. Die KI liest die Rohdaten schneller und verarbeitet die Logik präziser, ohne in für Menschen formatierten Absätzen zu ertrinken. Das löst das Problem der Textdichte, aber das Gesamtvolumen könnte immer noch zu groß sein, um sauber in einen einzigen Prompt-Kontext zu passen. Hier kommt das Shard-Document-Tool ins Spiel. Sharding zerlegt dein destilliertes Whitepaper mechanisch in kleinere, eigenständige Textdateien, basierend auf logischen Grenzen wie Kapiteln oder bestimmten Abschnitten. Du führst den Shard-Command aus, richtest ihn auf dein schweres Dokument, und er gibt eine nummerierte Sequenz von leichtgewichtigen Dateien aus. Anstatt die KI zu zwingen, das gesamte Whitepaper im Arbeitsspeicher zu halten, hast du jetzt modulare Einzelteile. Sobald du zwanzig Shard-Dateien in einem Directory liegen hast, braucht das System einen Weg, um durch sie zu navigieren. Das machst du mit dem Index-Documents-Tool. Du richtest den Index-Command auf den Ordner, der deine neuen Shards enthält. Das Tool scannt das Directory und generiert ein einziges Master-Index-File. Dieses Master-File fungiert als Routing-Map und listet jeden Shard zusammen mit einer kurzen Beschreibung seines Inhalts auf. In der Praxis übergibst du diesen leichtgewichtigen Index zuerst an das Language Model. Das Modell liest die Map, bestimmt, welches spezifische Kapitel die benötigten Informationen enthält, um einen Prompt zu beantworten, und fordert dann nur diesen spezifischen Shard an. Das Reasoning bleibt scharf, weil das Context Window komplett auf die relevanten Daten fokussiert bleibt. Das absolut Wichtigste, was du dir hier merken solltest, ist, dass ein riesiges Context Window keine Ausrede dafür ist, einfach Raw-Files in einen Prompt zu werfen. Die Strukturierung deiner Inputs durch mechanische Distillation und indizierte Shards zwingt das Modell dazu, systematisch zu lesen, anstatt blind zu scannen. Wenn du diese Folgen nützlich findest und die Show unterstützen möchtest, kannst du auf Patreon nach DevStoriesEU suchen. Das war's für diese Folge. Vielen Dank fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. BMad-Methode, Folge 15 von 15. Bitte ein Language Model niemals, einfach nur etwas besser zu machen. Vage Requests führen zu faulen, generischen Überarbeitungen. Wenn du strukturelle Verbesserungen willst, musst du das Modell in ein starres Reasoning Framework zwingen oder, noch besser, drei verschiedene AI-Personas spawnen und beobachten, wie sie die Fehler diskutieren. Genau das ist die Domäne von Advanced Elicitation und Party Mode. Eine häufige Falle bei der Optimierung von Outputs, wie beispielsweise einem neu generierten Product Requirements Document, ist es, das Modell zu prompten, seine eigene Arbeit zu überprüfen und zu verbessern. Language Models sind darauf ausgelegt, hilfreich und kooperativ zu sein. Wenn du um eine allgemeine Verbesserung bittest, ändert das Modell typischerweise ein paar Adjektive, strukturiert einen Satz um und liefert ihn zurück. Es wird die Kernlogik nicht neu schreiben. Advanced Elicitation löst dieses Problem, indem es formale, anerkannte mentale Modelle auf den AI-Output anwendet. Du hörst auf, nach allgemeinem Feedback zu fragen. Stattdessen weist du das Modell an, ein spezifisches kognitives Framework auszuführen. Nehmen wir die Pre-Mortem-Analyse. Du fütterst das Modell mit deinem frisch generierten Requirements Document. Du weist es an, anzunehmen, dass das Projekt bereits gebaut und gelauncht wurde und ein absolutes, katastrophales Fiasko ist. Das Modell muss dann rückwärts arbeiten, um genau zu diagnostizieren, was den Fehler verursacht hat, und sich dabei ausschließlich auf das aktuelle Dokument stützen. Weil du den Prompt auf einen spezifischen Fehlerzustand beschränkt hast, umgeht das Modell seine höflichen Guardrails und sucht aggressiv nach Logiklücken. Ein weiteres leistungsstarkes Framework ist Inversion. Anstatt zu fragen, wie man eine Datenbankmigration sicher macht, bittest du das Modell, die exakten Schritte aufzuzeigen, die erforderlich sind, um maximalen Datenverlust während der Migration zu garantieren. Benannte Reasoning Frameworks liefern deutlich überlegene Ergebnisse, weil sie das Modell aus seinen Default-Pfaden der Textgenerierung zwingen und in hochspezifische analytische Pfade lenken. Sobald du diese garantierten Fehler identifiziert hast, musst du den Fix designen. Du könntest eine einzelne Persona bitten, das Problem zu lösen, aber komplexe Architekturprobleme erfordern Reibung. Das bringt uns zum Party Mode. Das Party Mode Tool orchestriert eine Multi-Agent-Gruppendiskussion. Du interagierst nicht mehr mit einem einzelnen Assistenten. Du konfigurierst einen virtuellen Raum voller spezifischer, spezialisierter Personas, übergibst ihnen das Problem und trittst einen Schritt zurück, um sie diskutieren zu lassen. So läuft die Logik ab: Du startest das Party Mode Tool und definierst deine Teilnehmer. Du instanziierst vielleicht einen Senior Solutions Architect, einen paranoiden Security Engineer und einen pragmatischen Frontend Developer. Du übergibst ihnen die Vulnerabilities, die du in deiner Pre-Mortem-Analyse entdeckt hast. Das Tool steuert dann den Conversation Loop völlig autonom. Der Architect schlägt einen robusten, komplexen Fix vor. Das Tool leitet diesen Output an den Security Engineer weiter, der den Vorschlag auf potenzielle Exploit-Vektoren hin angreift. Anschließend gibt das Tool den Context an den Developer weiter, der sich über die Komplexität der Implementierung beschwert und einen einfacheren Ansatz vorschlägt. Sie iterieren über diese Argumente und fordern sich gegenseitig heraus, ohne dass du eingreifen musst, bis sie entweder einen Konsens erreichen oder ein definiertes Turn Limit erreichen. Du kannst die Debatte beobachten und die finale, praxiserprobte Lösung aus dem Transcript extrahieren. Dieser Ansatz shiftet dich von der Rolle als Prompt Writer zum Director von Reasoning Engines. Du nutzt Advanced Elicitation, um deine eigenen Ideen systematisch zu brechen, und den Party Mode, um den Rebuild durch synthetische Reibung zu engineeren. Der wertvollste Shift bei der Arbeit mit Language Models ist die Erkenntnis, dass gezielt herbeigeführte Meinungsverschiedenheiten immer eine bessere technische Architektur hervorbringen als sofortige, höfliche Zustimmung. Da dies die letzte Folge der Serie ist, empfehlen wir dir dringend, die offizielle BMad-Dokumentation zu lesen, diese Debatten selbst hands-on zu orchestrieren oder devstories dot eu zu besuchen, um Themen für unsere nächste Serie vorzuschlagen. Ich möchte mir kurz einen Moment nehmen, um dir fürs Zuhören zu danken – es hilft uns sehr. Hab einen tollen Tag!