Here's the rephrased article:
My AI Development Evolved: Why I Moved Beyond BMAD
By Nicolas Dabène — AI-Native E-commerce Architect
Let's get one thing straight from the outset: this piece isn't an attack on BMAD. Far from it. This methodology actually honed my skills as an AI developer. It instilled a crucial discipline that many overlook: structured thought before code generation. Its framework — covering structured briefs, defined roles, and sequential steps — taught me to break down complex tasks, especially when dealing with single agents trying to do too much. That was a game-changer.
However, during a significant PrestaShop initiative in March 2026, which involved orchestrating fourteen specialized agents in parallel, I realized a shift was necessary. I was still applying BMAD's mental model, yet my operational requirements had evolved. I found myself manually directing processes that my architecture could — and should — manage autonomously.
This article explores that exact transformation: not a flaw in BMAD, but an organic progression beyond its foundational principles.
Decoding BMAD's Value Proposition
For those unfamiliar, BMAD (Brief, Method, Agent, Delivery) offers a structured approach to AI-assisted development. Its core philosophy challenges the notion of tossing vague requests at a Large Language Model (LLM). Instead, it advocates for constructing well-defined conversations, complete with specific roles, clear expectations, and precise output specifications.
In practice, this method fundamentally alters your workflow:
- You sidestep generic LLM responses by posing specific, well-framed questions.
- You cultivate a systems-oriented mindset, focusing on distinct roles, responsibilities, and expected outcomes, rather than disparate, one-off prompts.
- You establish continuity across work sessions, eliminating the need to restart from scratch each time.
For projects of moderate scale — perhaps a custom PrestaShop module, an n8n automation flow, or a meticulously structured blog post — BMAD proves highly effective. The initial overhead it introduces (like framing prompts, crafting briefs, and validating each phase) is genuinely productive. It saves countless hours by steering you away from unproductive tangents.
I personally utilized this framework for many months. My project deliverables became notably more consistent. My Claude Code sessions became predictable. Anticipating PrestaShop 9 backward compatibility breaks was no longer an issue, as I proactively integrated such considerations into my briefs.
So, BMAD undeniably works. That much is clear.
The Catalyst for Change
Towards the end of January, I embarked on a comprehensive rebuild of the gmerchantcenter_pro module — Google Merchant Center PRO, version 2.0.0. This involved overhauling its taxonomy system, custom labels, and exclusion rules, alongside an update to the product tags and attributes.
This wasn't a minor undertaking. It encompassed a broad technical landscape: the PrestaShop 9 Admin API, CQRS, API Platform, Symfony 6, and a myriad of Google Merchant Center-specific business rules. The project demanded diverse expertise simultaneously: architectural design, technical implementation, security audits, Marketplace packaging, rigorous testing, and detailed changelog generation.
Under the BMAD paradigm, my orchestration was entirely manual. I'd brief an agent on architectural specifics, then take its output and feed it to an implementation agent. Next, I'd step in to review security, then initiate the packaging process. It was a linear, controlled sequence. I remained the central point for every handoff.
It was during this intense period that the core issue emerged.
I was no longer merely a supervising architect. I had transformed into a human router. My primary function involved copying and pasting outputs from one context to another, rephrasing agent A's work so agent B could interpret it, and holding the entire project's coherence solely within my own mind, as no single agent possessed that holistic view.
BMAD indeed provided structure. Yet, I bore the entire weight of that structure myself.
Embracing Externalized Orchestration
A critical question surfaced: was this manual coordination an inherent, unavoidable complexity, or merely an accidental one I'd accepted out of habit?
The answer became strikingly clear once I articulated my process aloud: I'd receive a request, analyze its interdependencies, determine which tasks could run in parallel versus sequentially, then route, aggregate, and validate. This, I realized, is precisely the role of an orchestrator.
The only difference was, I was performing it manually for every single task, incurring a significant cognitive burden.
Agentic orchestration, as I've adopted it since, offloads this responsibility. A master agent receives the initial request. It intelligently analyzes all dependencies, then dispatches tasks to specialized agents — concurrently when feasible, sequentially when dependencies dictate. It then synthesizes the results, delivering a cohesive output.
The profound change for me is this: my focus is now on what needs to be accomplished, not on the intricate how of its coordination.
The Current Architecture Explained
While a more granular breakdown is available in my March 31st article, here’s an overview highlighting its distinction from BMAD.
The master agent serves as the sole entry point. It doesn't write code or generate content. Its singular purpose is to comprehend the request, dissect dependencies, intelligently route tasks to the appropriate specialists, and ultimately synthesize the final outcome.
We employ 14 specialized PrestaShop agents, each operating within a strictly defined scope. For instance, prestashop-architect handles design, prestashop-module-dev focuses on implementation, prestashop-security conducts audits, prestashop-phpstan performs static analysis, and prestashop-packaging prepares for Marketplace submission. These agents avoid overlap and remain focused on their specific areas of expertise.
"Skills" are Markdown files that encapsulate business rules: PrestaShop 9 conventions, breaking changes between versions, anti-patterns for multi-store setups, or Marketplace validation checklists. Each agent loads its relevant skills before beginning its work. This mechanism effectively replaces the repetitive "context brief" I previously had to manually draft for every BMAD session.
Consider a practical scenario: when I ask to create a PrestaShop admin page featuring a filterable product listing, the master agent analyzes the request and generates a plan like this:
- Step 1 (Sequential):
prestashop-architectestablishes the foundational structure—Symfony controller, Grid components, services, and hooks. - Step 2 (Parallel): Simultaneously,
prestashop-module-devhandles implementation,prestashop-securityaudits permissions, andprestashop-testingdevises the testing strategy. - Step 3 (Sequential):
qa-reviewerconducts final validation prior to delivery.
With BMAD, I would have personally managed this entire sequence. Now, it's intrinsically managed by the architecture itself.
The Enduring Value of BMAD
As I emphasized at the beginning, it's crucial to reiterate:
BMAD teaches you the fundamental discipline of structured thinking. Agentic orchestration, conversely, empowers you to execute more effectively what you've already learned to conceptualize.
If you lack experience in structuring AI requests, if your approach is still "build me a module that does X" without defining context, constraints, or a clear notion of "done" — then orchestration won't be your savior. You'll simply end up with fourteen agents rapidly pulling in disparate directions.
BMAD, or any similar methodology that compels you to frame problems before acting, remains an indispensable initial phase. Not as an ultimate destination, but as the critical foundation for building the reflexes necessary to leverage orchestration successfully.
My own transition wouldn't have been possible without months spent diligently working with BMAD. I wouldn't have even recognized the need for improvement had I not first mastered the underlying principles it instills.
The Fundamental Shift: Who Manages Complexity?
If I had to condense the core difference into a single statement, it would be this:
BMAD: You personally bear the cognitive load of coordination complexity, utilizing the method to bring structure to your mental model.
Agentic Orchestration: You delegate this coordination complexity to the architecture, freeing your mental energy for high-level decisions that cannot be automated.
These are fundamentally distinct paradigms.
Even when applied perfectly, BMAD positions you as the central pivot. You are the one who knows the project's current status, tracks agent outputs, and maintains overall coherence. The method assists you in performing this role effectively, but it's always you doing the heavy lifting.
In an orchestrated multi-agent architecture, the system itself holds and manages overall coherence. The master agent is fully aware of what tasks were performed, by whom, and in what order. The "skills" within the architecture internalize the PrestaShop context you previously had to manually refresh. Dependency flows are analyzed dynamically, not memorized.
This represents a profound shift from being an AI project manager to becoming an AI systems architect. It's a fundamental change in posture, far beyond a mere tool upgrade.
Is This Transition Right for You?
Probably not right away.
Adopting multi-agent orchestration comes with a significant initial investment. Designing the architecture, meticulously defining agent scopes to prevent overlap, and crafting "skills" that embed the correct contextual knowledge can easily require several weeks of dedicated effort before you start seeing value. And critically, attempting this without first internalizing the framing discipline taught by methods like BMAD will likely result in structured complexity that's worse than having no structure at all.
This transition truly makes sense when you encounter a specific signal: you find yourself dedicating more time to coordinating between agents than to generating actual work or making strategic decisions. It's when you recognize yourself as the "human router" within your own AI development stack.
If that scenario doesn't describe your current experience, continue with BMAD or a similar framing method. Focus on optimizing execution and solidifying those essential reflexes.
However, if you resonate with the "human router" description — if you're feeling that manual coordination bottleneck — then this architectural approach warrants serious investigation.
The Road Ahead
I don't view agentic orchestration as the ultimate solution.
What I foresee emerging are agents capable of managing the evolution of their own "skills." Agents that can detect a change in PrestaShop conventions and proactively update their internal rule sets. Agents that intuitively understand, without explicit instruction, that a project has migrated from PS8 to PS9 and that certain patterns are now deprecated.
We haven't reached that point yet. But the trajectory is unmistakable: less human coordination, more sophisticated human governance. It shifts from "I manage the flow" to "I define the rules that govern the flow."
BMAD was a crucial step on this path. Agentic orchestration is the next. The precise form of the subsequent evolution remains unclear — but it will invariably revolve around where we choose to place intelligence: within the developer's mind, embedded in the method, or intrinsically woven into the architecture itself.
The optimal placement evolves as our tools advance. What remains constant is the importance of making high-quality decisions about this placement.
For an in-depth exploration of the architecture itself, refer to my previous article, "Why Multi-Agent Orchestration Is No Longer Optional for PrestaShop."
Want to dive deeper into AI-Native E-commerce architectures and advanced development strategies? Make sure to subscribe to my YouTube channel for more insights and demos. Let's connect on LinkedIn to discuss the future of AI in development!
Top comments (0)