BMad Method

Olá, daqui é o Alex da DEV STORIES DOT EU. Método BMad, episódio 1 de 15. A maioria dos assistentes de programação de IA falha ao terceiro dia porque se esquecem do motivo pelo qual escreveram o código no primeiro dia. Acabas com uma confusão de scripts isolados que não encaixam uns nos outros. Para resolver isto, não precisas de um prompt melhor, precisas de Context Engineering e das quatro fases. Um erro comum é tratar o método BMad como um simples gerador de código. Não é. É um pipeline ágil de Context Engineering. Se pedires simplesmente a um agente de IA para construir uma feature, ele vai tentar adivinhar os limites. O BMad evita isto ao construir e fixar progressivamente o contexto ao longo de quatro fases distintas. O agente nunca se perde porque cada fase fornece regras estritas e documentadas à seguinte. Pega no exemplo da criação de uma aplicação SaaS. Se saltares diretamente para o código, a IA pode escolher uma base de dados que viole os teus requisitos de residência de dados. O Context Engineering impede isso. O pipeline começa com a fase de Análise. Aqui, a IA atua como Business Analyst. Processa as tuas ideias em bruto e produz um Product Requirements Document. Esta fase fixa as restrições principais. Capta as user personas, regras de compliance e os workflows principais. O documento resultante torna-se a base para tudo o resto. A seguir, vem a fase de Planeamento. O agente assume o papel de Product Owner. Pega no documento de requisitos e divide-o em Epics e User Stories. Requisitos abstratos transformam-se em itens discretos e acionáveis. O contexto afunila. A IA já não está a pensar no produto como um todo, mas apenas em unidades de entrega específicas mapeadas para uma timeline clara. É aqui que a coisa fica interessante. A terceira fase é o Solutioning. A IA assume o papel de Architect. Analisa as User Stories da fase de Planeamento e as restrições da fase de Análise para criar o technical design. Define os modelos de dados, os endpoints da API e as estruturas de pastas. Para a tua aplicação SaaS, as restrições de negócio definidas na primeira fase dizem ao Architect, na terceira fase, exatamente quais são os limites. Isto garante que a arquitetura escolhida se encaixa realmente nas regras de negócio originais. Finalmente, chegamos à fase de Implementação. Agora, a IA assume o papel de Developer. O agente Developer não precisa de adivinhar a arquitetura nem de se questionar sobre a business logic. Recebe o blueprint técnico exato do Architect. Escreve o código para satisfazer uma User Story específica, seguindo os modelos de dados e os file paths precisos definidos no passo anterior. Esta chain de contexto é o ponto principal. A informação flui em downstream através de documentação persistente. O output de uma fase torna-se o limite estrito de input para a seguinte. O agente Developer tem sucesso porque o agente Architect pavimentou o caminho, e o Architect teve sucesso porque o Business Analyst mapeou o território. Estás a fazer a engenharia do contexto a todos os níveis para que a IA se foque inteiramente na execução. A característica que define um workflow de IA resiliente não é a rapidez com que gera texto, mas sim o rigor com que impõe limites entre as diferentes fases de pensamento. Se quiseres apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. BMad Method, episódio 2 de 15. Podes pensar que adotar uma nova framework de desenvolvimento de IA exige memorizar uma enorme sequência de comandos específicos e fases rígidas de workflow. Não é o caso. Não precisas de memorizar uma única sequência de comandos nesta framework, porque o sistema inspeciona fisicamente a tua pasta local e diz-te exatamente o que escrever a seguir. Este é o processo de Intelligent Guide e Instalação. Para começar, basta um passo. No teu terminal, corres o comando do package executor npx bmad-method install. Este comando inicializa o workspace e prepara estruturalmente o teu repository. Faz isto criando dois diretórios específicos na tua root folder. O primeiro diretório é underscore bmad. Esta pasta é o cérebro da tua framework local. Contém as skills principais, as definições de prompts e os templates contextuais que a IA usa para fazer o seu trabalho. O segundo diretório é underscore bmad dash output. Este serve como a pasta de destino dedicada. Sempre que a framework gera novos assets, sejam eles documentos de requisitos de produto, especificações de features ou código propriamente dito, eles são depositados neste diretório de output, isolados com segurança do teu source code existente. Aqui está o ponto chave. Assim que essas pastas existem, os developers costumam cometer um erro comum. Presumem que precisam de abrir a documentação oficial, estudar as diferentes fases da framework e memorizar os comandos exatos de terminal necessários para passar de fase em fase. Preocupam-se em saltar um passo acidentalmente ou correr um comando fora de ordem. Não precisas de fazer nada disto. A framework é self-documenting em runtime graças a uma skill built-in chamada bmad-help. O bmad-help é um guia ativo que elimina a carga cognitiva de navegar pela metodologia. Não é um manual estático. Quando o invocas, a skill analisa ativamente o estado atual do teu workspace. Verifica o que está atualmente dentro das tuas pastas para determinar exatamente em que ponto do development lifecycle estás. Considera um cenário concreto. Acabaste de concluir o comando de instalação. O teu workspace está vazio, exceto pelas novas pastas de configuração. Tens uma ideia para um produto de software, mas não fazes ideia de que comando escrever a seguir. Basta acionares a CLI e escreveres bmad-help seguido da tua pergunta em inglês simples. Por exemplo, escreves bmad-help I have an idea for a SaaS, where do I start? A skill processa a tua pergunta, percebe que ainda não há documentos de planeamento na tua pasta de output, e diz-te exatamente o que fazer. Responde com o comando específico que precisas de correr para iniciar a primeira fase. Não te dá uma lista genérica de todos os comandos disponíveis. Dá-te a instrução única e precisa para o teu contexto imediato. À medida que avanças na metodologia, a criar documentos e código, o bmad-help adapta-se. Se terminares de gerar a tua arquitetura e perguntares o que fazer a seguir, ele vê os ficheiros de arquitetura e prescreve o comando para a fase apropriada seguinte. A framework inspeciona fisicamente o teu progresso e guia dinamicamente o teu próximo passo. Nunca tens de adivinhar se estás pronto para escrever código ou se precisas de refinar os teus requisitos primeiro, porque a instalação local lê constantemente o teu environment para te manter no caminho certo. Gostaria de tirar um momento para te agradecer por ouvires, isso ajuda-nos imenso. Tem um excelente dia!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Método BMad, episódio 3 de 15. Se pedires dez ideias a um large language model, normalmente recebes dez ideias perfeitamente medianas e fundamentalmente aborrecidas. O sistema foi desenhado para prever a próxima palavra mais provável, o que significa que gravita em direção ao banal. Para obteres resultados verdadeiramente inovadores, tens de forçar a IA a agir como um coach que extrai os conceitos de ti. É exatamente isso que o workflow Forging Ideas with AI Brainstorming faz. A maioria das pessoas associa o brainstorming com IA a zero-shot prompting. Escreves um pedido de ideias numa chat box e recebes uma lista genérica em troca. Essa abordagem falha porque trata a IA como um oráculo. O coach de brainstorming do Método BMad opera com o princípio oposto. É uma framework de facilitação guiada e multi-turn, em que a IA não gera as ideias principais de todo. Em vez disso, fornece uma fricção cognitiva estruturada para te forçar a pensar de forma lateral. O workflow depende fortemente de dois mecanismos específicos: protocolos anti-bias e domain shifting. Quando inseres um pensamento inicial, o protocolo anti-bias impede que a IA simplesmente concorde contigo. Se sugerires uma solução standard para um problema, a IA está programada para a desafiar. Pode perguntar o que acontece se a tua solução proposta falhar completamente, ou como um concorrente poderia explorar as falhas óbvias na tua lógica. O domain shifting leva isto um passo mais além, forçando-te a ver o teu problema através da lente de uma indústria completamente diferente. Considera um cenário concreto em que queres explorar formas de melhorar o onboarding de developers. Uma IA standard dar-te-ia uma lista sobre escrever melhor documentação e atribuir mentores. O coach de brainstorming do BMad, no entanto, pode iniciar um exercício da técnica SCAMPER. SCAMPER é uma framework que te incentiva a Substituir, Combinar, Adaptar, Modificar, Dar outro uso, Eliminar ou Reverter elementos de um processo. Aqui está o insight principal. A IA não vai percorrer o acrónimo todo de uma vez e despejar uma wall of text em cima de ti. Ela gere o ritmo passo a passo. Pergunta-te como poderias eliminar completamente a fase de leitura de documentação do onboarding. Dás uma resposta com base na tua expertise de domínio. Depois, a IA faz-te um prompt para combinares o onboarding com uma tarefa de engenharia não relacionada, como live incident response. Respondes novamente. A IA mantém a framework estável enquanto tu forneces o verdadeiro insight. Começas o workflow por definir o teu problem space em bruto. A IA responde com uma restrição específica ou uma pergunta direcionada. Tu respondes. A IA processa a tua resposta, aplica o seu check anti-bias, e depois faz push back ou faz domain shifting. Este loop multi-turn continua até teres esgotado as respostas óbvias e começares a produzir conceitos genuinamente novos. A IA atua como uma facilitadora incansável que se recusa a deixar-te contentar com a primeira coisa que te vem à cabeça. O valor de uma IA nas fases iniciais de product design não está na sua capacidade de inventar coisas do zero, mas na sua paciência infinita para aplicar fricção cognitiva estruturada à tua própria expertise. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. BMad Method, episódio 4 de 15. A Amazon é famosa por escrever o press release antes de construir o produto. E se uma IA questionasse implacavelmente esse press release antes mesmo de te deixar tocar na codebase? Escolher o formato de documento certo desde o início dita se constróis uma ferramenta de que as pessoas realmente precisam ou se desperdiças meses em algo que ninguém quer. O BMad Method lida com esta divergência através de dois outputs distintos na fase de análise: o PRFAQ Gauntlet e o Product Brief. Os utilizadores costumam ter dificuldade em escolher o formato. A regra é simples. Se já tens uma forte convicção sobre o que estás a construir e só precisas de alinhamento da equipa, usa o Product Brief. Se precisas de descobrir se o produto sequer merece existir, usa o PRFAQ. O Product Brief é um processo de discovery suave e colaborativo. Pensa nele como uma conversa guiada. Tu e a IA trabalham em conjunto para delinear o espaço do problema, os utilizadores-alvo, as core features e as métricas de sucesso. A IA atua como um co-pilot de apoio. Ela pega nos teus conceitos iniciais, estrutura-os de forma lógica e, educadamente, faz perguntas para preencher os detalhes em falta. É o caminho de menor resistência. Usas isto quando a direção é clara e simplesmente precisas de um documento profissional e organizado para garantir aprovação ou avançar para o technical design. O PRFAQ, que significa Press Release and Frequently Asked Questions, é um mecanismo completamente diferente. Este é um stress test rigoroso, focado no cliente. Força-te a trabalhar de trás para a frente, a partir de um dia de lançamento imaginado. Começas por escrever um press release conciso a anunciar o produto finalizado ao teu público-alvo. Neste ponto, a IA abandona a persona de co-pilot prestável e torna-se num stakeholder cético. Ela lê o teu press release e gera um gauntlet de perguntas brutais e investigativas. Considera um cenário em que queres construir uma nova ferramenta de deploy interna. Escreves um press release a gabar-te de que os deploys agora vão demorar um clique em vez de dez. Num Product Brief, a IA pode simplesmente pedir-te para listares as plataformas suportadas. No PRFAQ gauntlet, a IA vai perguntar como planeias lidar com rollbacks automáticos quando esse único clique fizer o deploy de um bug crítico. Ela vai exigir saber por que motivo a equipa de infraestrutura deve adotar esta ferramenta em vez dos seus scripts existentes e battle-tested. Tens de responder a estas perguntas de forma satisfatória. Se as tuas respostas forem vagas, a IA faz pushback. És forçado a defender a proposta de valor, a usabilidade e a viabilidade técnica antes de se gastar qualquer tempo real de engenharia. Aqui está o insight principal. O Product Brief foca-se no que o produto é, enquanto o PRFAQ foca-se no porquê de o cliente se dever importar e se o teu plano de execução é realista. O Brief constrói consenso. O PRFAQ destrói suposições frágeis. Fazes o deploy do PRFAQ quando uma ideia é cara, controversa ou altamente ambígua. Em última análise, sobreviver ao PRFAQ gauntlet prova que o teu conceito consegue resistir ao escrutínio do mundo real, atuando como uma defesa absoluta contra a construção de features que ninguém realmente pediu. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Método BMad, episódio 5 de 15. A maneira mais rápida de construíres o sistema errado é deixares uma IA alucinar os teus requisitos com base num prompt vago. Precisas de restringir a IA a limites exatos antes de qualquer código ser escrito. Fechar o PRD é o processo que estabelece esses limites. As pessoas confundem frequentemente o planeamento do projeto com o desenho de soluções técnicas. Pensam que o planeamento envolve escolher uma base de dados ou mapear microserviços. Isso está incorreto. O planeamento foca-se inteiramente na lógica de negócio. Não dita qualquer execução técnica. A fase de planeamento foca-se exclusivamente no O Quê e no Porquê. O Como pertence a uma fase completamente diferente. No Método BMad, isto acontece na Fase Dois. O ator responsável é o agente product manager, o John. O John pega nos outputs da fase um, especificamente no teu PRFAQ e documentos de brainstorming aprovados, e consome-os. Inicias este processo usando um comando chamado bmad dash create dash prd. O John pega na visão do PRFAQ e traduz-a num ficheiro de texto rígido chamado PRD dot md. Este documento serve como a fonte absoluta de verdade para o resto do projeto. Para fazer isto, o John divide os requisitos em duas categorias estritas. São elas os Requisitos Funcionais, ou FRs, e os Requisitos Não Funcionais, ou NFRs. Os Requisitos Funcionais definem exatamente o que o sistema tem de fazer. Os Requisitos Não Funcionais definem as restrições operacionais do sistema, como limites de performance, regras de compliance ou disponibilidade. Considera um cenário concreto. Estás a construir um módulo de faturação SaaS. Passas o teu PRFAQ aprovado ao agente PM. O John gera Requisitos Funcionais a ditar que o módulo tem de permitir aos utilizadores fazer upgrade da sua subscrição, e tem de fazer downgrade automático aos utilizadores se um pagamento falhar três vezes. Em seguida, o John gera Requisitos Não Funcionais a ditar que todas as atualizações de status de pagamento se devem refletir na dashboard do utilizador em menos de dois segundos. Aqui está o ponto chave. Repara no que falta nesses requisitos. O John não menciona o Stripe, não menciona PostgreSQL, e não desenha um payload de API. Se o teu PRD menciona uma tecnologia de base de dados específica, o processo falhou. O PRD apenas fecha a expectativa de negócio. Assim que o PRD estiver fechado, a Fase Dois avança para o workflow de UX Design. Este passo pega na lógica de negócio em bruto e mapeia a interação humana. Se um requisito funcional diz que um utilizador precisa de fazer upgrade a uma subscrição, o workflow de UX design dita a sequência exata de ecrãs, botões e mensagens de erro que o utilizador vai encontrar. Tal como o PRD, este workflow de UX faz zero escolhas de framework de frontend. Não quer saber se eventualmente vais usar React ou Vue. Preocupa-se apenas com a user journey passo a passo. Ao forçares o agente PM a gerar um PRD e um UX flow estritos e agnósticos em relação à tecnologia, crias uma âncora. Os Large Language Models desviam-se naturalmente com o tempo. Mais tarde no projeto, os teus agentes de engenharia serão forçados a verificar as suas soluções técnicas contra estes FRs e NFRs exatos. Se uma feature não estiver no PRD, os agentes não a vão construir. O PRD não é um documento de sugestões casuais; é uma fronteira rígida para os teus agentes de IA que isola completamente as tuas necessidades core de negócio da eventual implementação técnica. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um excelente dia!

Olá, daqui é o Alex da DEV STORIES DOT EU. Método BMad, episódio 6 de 15. Se atribuíres a dois agentes de IA a tarefa de construir duas features diferentes sem um documento de arquitetura partilhado, eles vão inevitavelmente declarar guerra ao código um do outro. Eles vão fazer escolhas técnicas em conflito que vão quebrar a tua aplicação. O mecanismo para travar isto é a Fase 3 de Solutioning, focando-se especificamente em prevenir conflitos de agentes com a arquitetura. Os humanos que trabalham num projeto de software falam uns com os outros. Partilham suposições a tomar um café ou através de mensagens de chat. Agentes de IA a operar em paralelo não têm uma consciência partilhada. Eles operam em context windows completamente isoladas. Dá ao Agente A a tarefa de implementar um dashboard de utilizador, e ele pode decidir que uma REST API e Redux são a melhor opção. Dá ao Agente B a tarefa de construir uma página de settings de utilizador, e ele pode decidir de forma independente fazer spin up de GraphQL e Zustand. Quando essas duas features tentarem fazer merge para a main branch, vais enfrentar um problema de integração massivo. Ambos os agentes fizeram exatamente o que pediste, mas as suas otimizações isoladas criaram um caos sistémico. Os developers muitas vezes querem saltar a documentação formal de arquitetura porque parece overhead corporativo. Se estiveres a montar um script pequeno e isolado, isso é aceitável. O Método BMad inclui um Quick Flow especificamente para tarefas pequenas que ignora deliberadamente esta fase. Mas para projetos complexos, saltar a fase de arquitetura garante agent drift. Não podes confiar no comportamento default dos large language models para se alinharem acidentalmente na mesma tech stack em sessões diferentes. Para forçar o alinhamento técnico, o método usa um workflow específico chamado bmad create architecture. Executas este workflow antes de ser escrita uma única linha de código da aplicação. Ele analisa os requirements do teu projeto e gera Architecture Decision Records. Os Architecture Decision Records são ficheiros de texto estruturados e leves. Eles capturam as escolhas técnicas definitivas para o projeto. Um record dita a library de state management. Outro especifica o pattern exato para data fetching. Um terceiro define a testing framework. Eles estabelecem as regras rígidas e inflexíveis do sistema. Aqui está o insight principal. Na engenharia de software tradicional, um architecture decision record é principalmente um log histórico para ajudar novos developers humanos a entenderem as escolhas passadas. Num sistema de IA multi-agent, é um mecanismo de controlo ativo. Os large language models não têm memória do que outro modelo decidiu, a não ser que tu alimentes explicitamente essa informação no seu prompt context. Quando corres o workflow de arquitetura, os documentos resultantes são guardados diretamente no repositório do teu projeto. Mais tarde, quando fazes deploy do Agente A para construir o dashboard e do Agente B para construir as settings, o sistema alimenta estes exatos mesmos decision records a ambos os agentes antes de eles começarem a escrever código. Os ficheiros de arquitetura atuam como a ground truth definitiva. O Agente A lê o record que dita Redux e REST, e constrói de acordo. O Agente B lê exatamente o mesmo record, e também constrói com Redux e REST. Os limites arquiteturais forçam modelos independentes a agir como uma equipa coesa. Ao remover o peso da escolha durante a fase de implementação da feature, tu reduzes drasticamente as alucinações e evitas dependências em conflito. Os documentos de arquitetura num workflow de IA não são apenas notas passivas para humanos; são constraints programáveis que forçam agentes não-determinísticos a construir um sistema determinístico. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Método BMad, episódio 7 de 15. Os agentes de IA, por defeito, seguem as melhores práticas genéricas, o que significa que escrevem código parecido com uma resposta típica do Stack Overflow, e não com a tua codebase. Se queres que eles programem exatamente como a tua equipa de engenharia sénior, tens de impor as tuas próprias regras. É isso que a Constituição do Project Context faz. No fundo, trata-se de um ficheiro chamado project-context.md. Colocas este ficheiro na raiz do teu repositório. Pensa nele como o documento principal que rege qualquer IA que interaja com o teu projeto. Quando um agente lê o teu repositório, carrega este ficheiro primeiro para perceber os limites inegociáveis da tua arquitetura. Podes criar este ficheiro manualmente, ou podes gerar um ponto de partida ao correr o comando bmad-generate-project-context no teu terminal. De qualquer forma, o documento tem de conter duas secções específicas. Estas são a Tech Stack e as Critical Rules. A secção da Tech Stack é simples, mas exige precisão. Não te limites a listar React ou Node. Tens de especificar as versões exatas, o paradigma de routing e as bibliotecas de styling. Se estiveres a usar Next.js com o App Router e Tailwind, diz exatamente isso. A IA usa isto para filtrar os seus vastos dados de treino até à sintaxe específica que o teu projeto exige. Agora, a segunda parte disto é a secção de Critical Rules. Presta atenção a esta parte. Um erro muito comum que os developers cometem é preencher esta secção com conselhos genéricos, como escrever clean code ou usar princípios DRY. Não faças isso. A IA já conhece clean code genérico. Precisas de escrever os padrões não óbvios e específicos do projeto que o agente nunca conseguiria adivinhar sozinho. É aqui que estabeleces leis arquitetónicas rígidas. Por exemplo, escreves uma regra que exige TypeScript em strict mode para todos os novos ficheiros. Instruis o agente que todos os testes de integração têm de usar Mock Service Worker. Mais importante ainda, podes proibir comportamentos. Se o teu projeto tiver um singleton de API client customizado, escreves explicitamente uma regra que diz para nunca usar o fetch nativo ou o Axios diretamente, mas importar sempre o API client customizado da pasta de network utilities. Quando a IA gera uma nova feature, cruza o seu output com estas regras. Como o project context está no topo da hierarquia do prompt, estas instruções sobrepõem-se às tendências de base da IA. Se um agente tentar escrever um API fetch direto, a constituição do project context força-o a reescrever essa lógica usando o teu custom wrapper antes sequer de fazer o output do código. O objetivo deste ficheiro não é ensinar a IA a programar, mas sim a programar aqui, neste repositório específico. Se gostas destes episódios e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. Gostava de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um ótimo dia!

Olá, daqui é o Alex da DEV STORIES DOT EU. Método BMad, episódio 8 de 15. Antes de deixares uma IA escrever centenas de linhas de código, há um passo crítico que tens de executar para evitar um sprint catastrófico. Esse passo é o Breaking Work Down e o Gate Check. Nesta fase do workflow, tens um Product Requirements Document finalizado e um Architecture design concluído. Agora precisas de tickets. É aqui que o agente Project Manager entra em ação. O seu trabalho é executar o processo de criação de epics e stories. O agente PM lê o documento de requisitos, mas não opera no vácuo. Ele cruza essas necessidades de negócio com as restrições definidas na tua documentação de arquitetura. O agente PM traduz features de alto nível em epics. A seguir, divide esses epics em user stories específicas e acionáveis. Ele redige os acceptance criteria e o contexto técnico para cada tarefa. Ao consultar os documentos de arquitetura, o PM garante que os data models e as interações de componentes exigidos pela story existem mesmo no plano técnico. Isto garante que cada ticket serve um requisito de negócio real, respeitando rigorosamente os limites do system design. O output deste passo é um backlog totalmente preenchido. Aqui está o insight principal. Assim que esse backlog existe, a tentação de começar imediatamente a gerar código é enorme. As pessoas costumam saltar o passo seguinte por pura impaciência. Querem ver software a funcionar, por isso enviam os novos tickets diretamente para desenvolvimento. Não faças isto. Saltar o readiness check é como acabas a queimar tokens de API caros em código que não pode ser integrado. É por isso que o agente Architect volta a entrar em cena para executar a fase de check implementation readiness. Esta é a tua derradeira rede de segurança. Funciona como um gate check rigoroso antes de qualquer programação começar. O Architect lê cada epic e user story gerada pelo PM e valida-as diretamente contra a arquitetura. O Architect procura pré-requisitos técnicos em falta, contradições arquitetónicas ou suposições silenciosas. Verifica se cada data structure mencionada numa story tem um database schema correspondente. Verifica se os service endpoints necessários estão mesmo definidos. Considera um cenário específico. Corres o gate check, e o Architect sinaliza um epic para uma nova feature de notificações de utilizador. O ticket pressupõe o uso de uma API de mensagens de terceiros específica. No entanto, o Architect aponta que esta integração nunca foi discutida ou aprovada nos Architecture Decision Records. O gate check interrompe o processo imediatamente. Acabaste de poupar horas de tempo de desenvolvimento desperdiçado a tentar construir uma feature contra uma dependência não aprovada ou não documentada. Esta colaboração entre necessidades de negócio e realidade técnica é o cerne desta fase. O agente PM define o trabalho com base no que o utilizador precisa. O agente Architect verifica o trabalho com base no que o sistema consegue mesmo suportar. Só avanças quando o Architect dá o sign-off, provando que o backlog é totalmente implementável. Um product requirement perfeito é completamente inútil se a system architecture subjacente não o conseguir suportar, e este gate check é a única prova objetiva de que os teus tickets estão mesmo prontos para build. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Método BMad, episódio 9 de 15. Não dizes simplesmente a uma IA para construir uma aplicação. Se pedires a um language model para implementar uma feature inteira de um produto ou um Epic de uma só vez, vais obter lógica a meio gás, ficheiros em falta e um emaranhado de código. Para obteres um output production-grade da IA, tens de impor exatamente a mesma disciplina que esperas de uma equipa de engenharia humana de alto desempenho. Hoje vamos olhar para o Build Cycle e o Sprint Tracking, que é o loop mecânico e disciplinado de execução da fase quatro de implementação. O maior erro que os developers cometem com ferramentas de IA é pedir demasiado de uma só vez. O build cycle depende inteiramente de uma execução rigorosa, uma story de cada vez. Fazes o tracking do state, pegas numa única story, executas, validas e atualizas o teu state. Este processo requer personas distintas a lidar com partes específicas do pipeline, garantindo que nenhum contexto se perde e que o scope não fica bloated. O ciclo começa com o sprint planning. Corres o prompt bmad sprint planning, que gera um ficheiro chamado sprint status yaml. Este ficheiro é a tua source of truth absoluta. Ele lista explicitamente todas as stories da tua sprint atual e marca o seu status como pending, in progress ou done. Este documento mantém a IA ancorada. Impede que o modelo alucine progresso ou se esqueça de dependências, porque a IA tem de ler constantemente este ficheiro para perceber o state atual do projeto. Assim que a tua sprint estiver planeada, inicias o execution loop. Primeiro, chamas a persona de Scrum Master, o Bob, usando o prompt bmad create story. Instruis o Bob a olhar para o ficheiro sprint status yaml e a pegar no primeiro item pending. O Bob não escreve qualquer código da aplicação. Em vez disso, ele gera um ficheiro markdown altamente focado, dedicado exclusivamente a essa única user story. Este documento descreve os acceptance criteria específicos, as restrições técnicas e os cenários de teste necessários para concluir a tarefa. A seguir, entregas esse ficheiro isolado da story à persona de Developer, a Amelia. Usas o prompt bmad dev story para iniciar este passo. A Amelia lê o ficheiro da story, analisa a codebase atual e implementa a lógica. Como o seu contexto é artificialmente reduzido apenas às instruções do Bob e aos ficheiros relevantes da aplicação, ela não vai reescrever acidentalmente módulos não relacionados, nem desviar-se do scope da tarefa imediata. Depois de a Amelia escrever o código, a story ainda não está done. Invocas o prompt bmad code review. Isto funciona como um quality gate automatizado. O processo de review verifica o código da Amelia contra os rigorosos acceptance criteria definidos no ficheiro da story do Bob. Ele traz à superfície edge cases em falta, falhas de lógica ou inconsistências de formatação. Corriges quaisquer problemas encontrados durante esta review. Só quando o código passa é que atualizas o ficheiro sprint status yaml, mudando manualmente a story de in progress para completed. Depois, fazes o loop de volta ao Bob para puxar o próximo item pending. Aqui está o insight principal. O poder deste loop não está na geração de código em si, mas na estrita separation of concerns que força a IA a planear, executar e rever como passos distintos e isolados. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Método BMad, episódio 10 de 15. Às vezes, o processo agile completo é um exagero para um fix localizado. Tens um bug report confuso no Jira e só queres que seja resolvido e revisto sem verificares manualmente cada passo. Vê como passar desse ticket em bruto para um pull request revisto numa única run autónoma usando a track Quick Dev para Zero-Blast Changes. Muitas vezes, as pessoas veem o Quick Dev apenas como um prompt de código genérico, onde atiras um ticket para um large language model e esperas pelo melhor. Não é. O Quick Dev isola explicitamente a clarificação de intenção da execução. Dá ao sistema uma fronteira rígida para trabalhar, em vez de deixar a definição do problema misturar-se diretamente no passo de geração de código. A track agile standard depende muito de checkpoints rígidos. Fazes uma pausa, verificas o plano, verificas os testes e verificas a implementação. O Quick Dev elimina esses checkpoints. Confia mais no modelo e guarda a tua atenção humana para momentos de alto impacto. Só usas esta track para alterações com zero blast radius. Mecanicamente, isto significa que as modificações devem ser isoladas num único componente ou função. A alteração não pode modificar interfaces públicas, schemas de base de dados, ou reescrever funções utilitárias partilhadas que sejam usadas por outros domínios. Se uma alteração mexer no core state management, pertence à track standard. Considera o cenário em que passas um link de um bug ticket fragmentado do Jira para a tool bmad-quick-dev. A primeira coisa que o sistema executa é a compressão de intenção. Lê os comentários dispersos, os steps to reproduce e as queixas do utilizador. Força o modelo a resolver contradições antes de tocar em qualquer código. Se o ticket tiver instruções contraditórias, o passo de compressão sintetiza-as num único objetivo definitivo. Este output é plain text, definindo exatamente o que o fix implica e, de forma crítica, quais são as fronteiras do fix. Aqui está o insight principal. Como a intenção agora está comprimida e isolada, a fase de execução autónoma tem uma especificação rigorosa a seguir. O sistema escreve o fix, gera ou atualiza os testes localizados e corre um self-review face a essa intenção comprimida inicial. Faz um loop por estes passos continuamente. Podes afastar-te enquanto ele trabalha, e voltas para encontrar um pull request terminado. O Quick Dev é rápido, mas quando uma run autónoma falha, tens de diagnosticar as camadas de falha com precisão. Olhas para onde o processo quebrou. Se o código final resolve um problema completamente errado, a falha aconteceu na layer de compressão de intenção. O ticket do Jira provavelmente era demasiado ambíguo, fazendo com que o modelo alucinasse o objetivo. Corriges isto reescrevendo o input inicial. Se a intenção estiver correta, mas os novos testes falharem ou a build quebrar, a falha está na layer de execução. Corriges as falhas de execução dando um nudge ao modelo para fazer retry ao bloco de lógica específico. Se a layer de execução falhar duas vezes seguidas, o problema já não é o prompt. O blast radius da alteração era simplesmente maior do que pensavas inicialmente, e tens de voltar à track standard com checkpoints. A autonomia só funciona quando a fronteira da tarefa é menor que a context window do modelo que a está a resolver. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Método BMad, episódio 11 de 15. A maioria das frameworks de IA para código parte do princípio de que estás a começar de um diretório completamente vazio. Elas querem gerar o scaffolding, ditar a arquitetura e controlar todo o processo desde o primeiro dia. Mas quando largas um agente de IA num enorme monólito de Rails com cinco anos e convenções de nomenclatura não documentadas, essa abordagem de folha em branco estraga tudo. Fazer o onboarding de codebases estabelecidas é como fazes o BMad funcionar com o que já tens. Uma suposição frequente que os developers fazem é que o BMad serve estritamente para desenvolvimento greenfield. Isso é incorreto. O BMad não força um rewrite nem impõe uma estrutura externa. Ele foi construído para se adaptar, respeitando e descobrindo a tua arquitetura existente para se integrar de forma limpa. No entanto, ingerir um repositório estabelecido requer um workflow específico para evitar que a IA adote o teu technical debt. O primeiro passo de todos é limpar os artefactos. Os modelos de IA são essencialmente motores avançados de pattern-matching. Se os apontares para um repositório cheio de blocos de código comentados, chamadas de API deprecated e nomes de ficheiros inconsistentes, o agente vai assumir que esses são os standards aceites. Antes de introduzires o agente, tens de remover o dead code, forçar as tuas regras de linting e garantir que a tua test suite está realmente a passar. Estás a definir o standard de base. Quanto mais limpo for o estado do input, melhor o agente se vai alinhar com as tuas intenções reais. Assim que o repositório estiver limpo, mapeias-o usando um comando chamado bmad-generate-project-context. É aqui que a adaptação acontece. Em vez de escreveres manualmente páginas de documentação sobre como a tua aplicação está estruturada, corres esta tool para analisar os teus padrões legacy. Lembra-te daquele monólito de Rails com cinco anos. O gerador de contexto lê a file tree, faz o parse das abstrações e deduz as tuas regras não documentadas. Ele determina se a tua equipa prefere fat models ou service objects. Ele analisa o teu diretório de testes para ver como fazes mock de chamadas à base de dados. Ele pega em todas estas deduções e escreve-as num documento de contexto centralizado. Este ficheiro torna-se o prompt fundacional para a IA. Quando pedes ao agente para construir uma nova feature, ele lê este contexto primeiro. Ele compreende a arquitetura existente e gera código que parece exatamente como se um engenheiro sénior da tua equipa o tivesse escrito. Com o contexto gerado, escolhes como aplicar as atualizações usando o Quick Dev ou o Método Completo. A tua escolha depende inteiramente da complexidade da tarefa. Se estiveres a corrigir um bug localizado ou a adicionar um único query parameter a um endpoint existente, usa o Quick Dev. O agente lê o teu ficheiro de contexto, aplica o patch direcionado, verifica-o contra os teus testes locais e sai. É uma operação rápida e de low-overhead. Agora, a segunda parte disto lida com atualizações complexas. Se precisares de construir um módulo de faturação totalmente novo nesse monólito, mudas para o Método Completo. O agente vai usar o ficheiro de contexto para escrever primeiro um documento de design abrangente. Ele descreve como o novo módulo vai interagir com os teus componentes existentes. Ele escreve failing tests que correspondem ao teu estilo de testes legacy, implementa a business logic e itera até que os testes passem. A framework ajusta o seu rigor com base no que a tarefa exige. Aqui está o ponto-chave. O sucesso de um agente de IA num repositório legacy depende inteiramente da qualidade dos padrões que ele deteta, o que significa que uma limpeza inicial rigorosa e um ficheiro de contexto preciso são as únicas coisas entre a adição perfeita de uma feature e o caos arquitetónico. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um ótimo dia!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Método BMad, episódio 12 de 15. Abres o teu terminal, digitas um comando para formatar o teu código, e recebes um erro completamente genérico. Estás a tentar usar um comando interno do agente, mas o agente ainda nem está a correr. Existem duas maneiras distintas de comandar a tua força de trabalho de IA, e confundi-las é o ponto de atrito mais comum no sistema. Hoje vamos falar sobre comandar agentes: Skills versus Triggers. A primeira categoria são as Skills. Pensa nas Skills como os teus pontos de entrada globais. É o que digitas no terminal do teu IDE ou na linha de comandos para lançar uma ação do zero. Quando digitas bmad-help ou corres um script específico de lançamento de um agente a partir do teu IDE, estás a usar uma Skill. Ela arranca o ambiente. Carrega o contexto necessário. Coloca o agente online. As Skills pertencem ao exterior da conversa com o agente. São os mecanismos que ligam o motor. Isto leva-nos à armadilha mais comum. Assim que o motor está a correr e estás a falar com um agente no chat, as regras mudam. Deixas de usar Skills e começas a usar Triggers. Um Trigger é um código curto digitado diretamente numa sessão de chat ativa para comandar um agente que já está à escuta. Se digitares um trigger do menu do agente no teu terminal normal, o sistema não faz ideia do que queres dizer. Se tentares correr uma Skill do IDE a partir de dentro de um chat com o agente, vai falhar. A fronteira é absoluta. As Skills iniciam a sessão. Os Triggers controlam a sessão ativa. Assim que estás dentro do chat, os Triggers dividem-se em dois tipos: Workflow Triggers e Conversational Triggers. Os Workflow Triggers lançam sequências rígidas e predefinidas. Digitas o trigger, o agente executa um processo específico de vários passos, passo a passo, entrega o output, e a sequência termina. Os Conversational Triggers são muito mais fluidos. Permitem a troca dinâmica de tarefas sem quebrar a persona do agente. Ficas no chat, mas mudas o foco ativo. Considera um cenário concreto. Precisas de documentação nova. Começas por usar uma Skill do IDE para lançar a Paige, a agente Technical Writer. A Skill arranca a Paige, e ela pergunta-te o que precisas. Ela agora está ativa. Agora, em vez de escreveres um prompt enorme a explicar que precisas de um tipo específico de documento formatado de uma maneira específica, simplesmente digitas o conversational trigger W D no prompt ativo do chat. Isto significa Write Docs. A Paige muda imediatamente para o seu modo predefinido de rascunho de documentação. Ela pede as tuas notas brutas, processa-as e gera o texto. Lês o texto e percebes que precisas de um diagrama de arquitetura para o acompanhar. Não fechas o chat. Não lanças uma nova Skill a partir do terminal. Apenas digitas outro conversational trigger, M G, que significa Mermaid Graph. A Paige muda instantaneamente o foco. Ela mantém a personagem como a tua technical writer, guarda o contexto do documento que acabou de escrever, e gera o código do diagrama Mermaid correspondente. Estás a encaminhar dinamicamente as capacidades dela, em tempo real, sem nunca perder o contexto. Aqui está o ponto chave. O verdadeiro poder deste sistema duplo não é apenas ter coisas mais curtas para digitar, mas sim manter um contexto persistente e inteligente enquanto alternas instantaneamente o modo de operação interno de um agente. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Método BMad, episódio 13 de 15. As tuas code reviews com IA são provavelmente demasiado simpáticas. Quando simplesmente pedes a um modelo para procurar bugs, ele dá-te sugestões educadas e verificações de sintaxe genéricas. Para encontrar falhas catastróficas, precisas de motores de diagnóstico especializados e opinionated. Este episódio aborda exatamente isso: Adversarial Review e Edge Case Hunting. As pessoas costumam tratar a code review com IA como uma única passagem de propósito geral. Atiram um diff para um modelo e esperam que ele apanhe tudo. Isso raramente funciona bem. Um prompt genérico não tem um modelo mental específico, o que leva a um feedback superficial. A metodologia BMad resolve isto usando personas especializadas e com um scope bem definido. Vamos analisar duas ferramentas de review distintas que operam com metodologias completamente diferentes. Primeiro, considera o adversarial reviewer. Esta ferramenta é movida pela atitude e altamente cética. Não confia no teu código, na tua infraestrutura, nem nos teus utilizadores. Assume que a tua implementação está fundamentalmente partida e procura ativamente formas de a explorar. Ignora completamente escolhas de estilo, o naming de variáveis ou pequenas otimizações de performance. Em vez disso, procura exclusivamente por falhas na business logic, escalada de privilégios e quebras nas suposições de confiança. O adversarial reviewer olha para os perímetros da tua API e pergunta como é que um ator malicioso poderia fazer bypass ao teu fluxo pretendido. Lê o teu código com um cinismo profundo, tratando cada input como um potencial vetor de ataque e cada fronteira de dados como uma fraqueza. A seguir, temos o edge case hunter. Esta ferramenta opera com a personalidade exatamente oposta. É matematicamente fria, desprovida de contexto e inteiramente mecânica. Não quer saber de utilizadores maliciosos ou de intenções de negócio. Em vez disso, faz um path-tracing rigoroso. Constrói um control flow graph mental do teu código e segue cada branch até à sua conclusão lógica. O edge case hunter foca-se puramente em mutações de estado, boundary conditions e tipos de dados. Procura pelos caminhos de execução obscuros que causam falhas silenciosas, memory leaks ou unhandled exceptions. Para veres a diferença, aplica ambas as ferramentas a um único pedaço de código, como um diff complexo de autenticação. Primeiro, passas este código para o adversarial reviewer. Como opera à base de cinismo, ignora a sintaxe mecânica e deteta uma restrição de business logic em falta. Repara que, embora o token de autenticação seja validado corretamente, o sistema confia implicitamente no user role embutido nesse token sem verificar a base de dados em tempo real. O adversarial reviewer sinaliza isto como uma vulnerabilidade crítica de confiança. Agora, passas exatamente o mesmo diff de autenticação para o edge case hunter. Esta ferramenta ignora completamente a lógica de confiança do token. Em vez disso, através de derivação mecânica de paths, rastreia o ciclo de vida de cada variável. Encontra uma função de validação profundamente aninhada que não tem um type check explícito. Aponta uma type coercion implícita não tratada. Se o payload de input contiver um objeto null em vez de uma string naquele index específico, a aplicação vai lançar uma unhandled exception e crashar. Aqui está o ponto-chave. Não usas estas ferramentas para apanhar typos. Usas estas ferramentas para impor duas frameworks analíticas distintas na tua codebase. Uma ataca as tuas suposições sobre a confiança do sistema e o comportamento humano. A outra ataca as tuas suposições sobre caminhos de execução e estados de dados. Ao separar o atacante cínico do path-tracer mecânico, deixas de depender de um bug-finding genérico e começas a expor vulnerabilidades estruturais profundas antes mesmo de chegarem a produção. Obrigado por ouvires. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Método BMad, episódio 14 de 15. Se inserires um documento de cinquenta páginas diretamente num large language model, ele vai sofrer quase imediatamente de cegueira de contexto. Ele omite detalhes do meio do texto, alucina factos e degrada a sua própria capacidade de raciocínio. Para corrigir isto, precisas de um truque de compressão lossless. Hoje, vamos abordar a Gestão de Contexto: Distillation e Sharding. Muitos developers pensam que distillation é apenas summarization. Isso é incorreto. A summarization descarta dados intencionalmente para dar a um humano uma visão geral rápida. A distillation é um processo de compressão lossless e verificável. Aqui está a ideia principal. A tool de distillation pega na prosa humana prolixa, remove as transições, os adjetivos e o filler de conversação, e converte-a num formato de bullets altamente denso. Este formato é construído estritamente para leitura por máquina. Tu manténs todos os factos, mas reduzes drasticamente o número de tokens. Pensa naquele enorme whitepaper técnico de cinquenta páginas. Se o passares pela tool de distillation, consegues obter algo como um rácio de compressão de três ponto dois para um. O tamanho total do payload cai em mais de dois terços, mas o modelo mantém o acesso a todas as especificações técnicas e decisões arquitetónicas. A IA lê os raw data mais rapidamente e processa a lógica com mais precisão, sem se afogar em parágrafos formatados para humanos. Isso resolve a densidade do texto, mas o volume total ainda pode ser grande demais para caber perfeitamente num único contexto de prompt. É aqui que a tool de shard de documentos entra em ação. O sharding divide mecanicamente o teu distilled whitepaper em ficheiros de texto menores e independentes, com base em limites lógicos, como capítulos ou secções distintas. Corres o comando de shard, apontas para o teu documento pesado, e ele faz o output de uma sequência numerada de ficheiros leves. Em vez de forçares a IA a manter todo o whitepaper na memória de trabalho, agora tens peças modulares. Assim que tiveres vinte ficheiros de shard num diretório, o sistema precisa de uma forma de navegar por eles. Tratas disso com a tool de index de documentos. Apontas o comando de index para a pasta que contém os teus novos shards. A tool faz o scan do diretório e gera um único ficheiro de master index. Este ficheiro master funciona como um mapa de routing, listando cada shard juntamente com uma breve descrição do que contém. Na prática, dás primeiro este index leve ao language model. O modelo lê o mapa, determina que capítulo específico contém a informação necessária para responder a um prompt, e depois pede apenas esse shard específico. O raciocínio mantém-se afiado porque a context window permanece totalmente focada nos dados relevantes. A coisa mais útil a lembrar aqui é que uma context window massiva não é desculpa para despejar raw files num prompt. Estruturar os teus inputs através de distillation mecânica e indexed shards força o modelo a ler sistematicamente em vez de fazer um scan às cegas. Se achas estes episódios úteis e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por agora. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex do DEV STORIES DOT EU. BMad Method, episódio 15 de 15. Nunca peças a um language model para simplesmente melhorar algo. Pedidos vagos geram revisões genéricas e preguiçosas. Se queres melhorias estruturais, precisas de forçar o modelo a seguir uma reasoning framework rígida ou, melhor ainda, criar três personas de IA diferentes e observá-las a debater as falhas. Este é exatamente o domínio da Advanced Elicitation e do Party Mode. Uma armadilha comum ao refinar outputs, como um Product Requirements Document recém-gerado, é fazeres um prompt para o modelo rever e melhorar o seu próprio trabalho. Os language models são desenhados para serem úteis e prestáveis. Quando pedes uma melhoria geral, o modelo normalmente altera alguns adjetivos, reestrutura uma frase e devolve-a. Ele não vai reescrever a lógica principal. A Advanced Elicitation resolve isto aplicando modelos mentais formais e reconhecidos ao output da IA. Paras de pedir feedback geral. Em vez disso, instruis o modelo a executar uma framework cognitiva específica. Considera a análise Pre-mortem. Alimentas o modelo com o teu documento de requisitos recém-gerado. Instruis o modelo a assumir que o projeto foi construído, lançado e é um fracasso absoluto e catastrófico. O modelo tem então de trabalhar de trás para a frente para diagnosticar exatamente o que causou a falha, baseando-se apenas no documento atual. Como restringiste o prompt a um estado de falha específico, o modelo ignora as suas guardrails de cortesia e procura agressivamente lacunas lógicas. Outra framework poderosa é a Inversion. Em vez de perguntares como tornar uma migração de base de dados segura, pedes ao modelo para delinear os passos exatos necessários para garantir a máxima perda de dados durante a migração. Reasoning frameworks nomeadas produzem resultados muito superiores porque forçam o modelo a sair dos seus caminhos default de geração de texto altamente prováveis e a entrar em caminhos analíticos altamente específicos. Assim que identificares essas falhas garantidas, tens de desenhar o fix. Poderias pedir a uma única persona para resolver o problema, mas questões de arquitetura complexas exigem tensão. Isto leva-nos ao Party Mode. A tool de Party Mode orquestra uma discussão em grupo multi-agent. Já não estás a interagir com um único assistente. Configuras uma sala virtual cheia de personas específicas e especializadas, entregas-lhes o problema e afastas-te para as deixar debater. É assim que a lógica flui. Inicias a tool de Party Mode e defines os teus participantes. Podes instanciar um Senior Solutions Architect, um Security Engineer paranoico e um Frontend Developer pragmático. Passas-lhes as vulnerabilidades descobertas durante a tua análise Pre-mortem. A tool depois gere o loop de conversação de forma autónoma. O Architect propõe um fix robusto e complexo. A tool passa esse output ao Security Engineer, que ataca a proposta à procura de potenciais vetores de exploit. A tool passa então o contexto ao Developer, que se queixa da complexidade de implementação e sugere uma abordagem mais simples. Eles iteram sobre estes argumentos, desafiando-se mutuamente sem a tua intervenção, até chegarem a um consenso ou atingirem um limite de turnos definido. Podes observar o debate e extrair a solução final, battle-tested, da transcrição. Esta abordagem transforma-te de um mero escritor de prompts num diretor de reasoning engines. Usas a Advanced Elicitation para quebrar sistematicamente as tuas próprias ideias, e o Party Mode para desenhar a reconstrução através de fricção sintética. A mudança mais valiosa ao trabalhar com language models é perceber que a discordância planeada produz sempre uma arquitetura técnica melhor do que a conformidade imediata e educada. Como este é o último episódio da série, encorajamos-te vivamente a ler a documentação oficial do BMad, a tentar orquestrar estes debates hands-on, ou a visitar devstories dot eu para sugerir tópicos para a nossa próxima série. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Fica bem!