Last time, I described where each framework focuses its effort: BMad up front, on explicit human-shaped roles, and GSD downstream, on keeping the execution environment clean. That design intent is exactly where the real strengths and weaknesses come from. Neither framework is uniformly good, and pretending otherwise is how a pilot ends up disappointing everyone. Here’s the honest accounting for both.
Where BMad wins
- It covers the full product lifecycle, not just coding: discovery, requirements, architecture, UX, implementation, and testing. Most “AI coding” conversations quietly assume the hard part is writing code. BMad treats that as one stage among several.
- Specialist perspectives counter the “one generalist chatbot invents a product” failure mode. A PM agent is prompted to ask why. An architect is prompted to constrain. QA is prompted to attack the plan rather than rubber-stamp it.
- The durable artifacts, including briefs, PRDs, architecture docs, and stories, create an audit trail that executives and auditors recognize. You can hand a PRD to someone who’s never touched the code, and they’ll understand what was decided and why.
- Scale-adaptive paths reduce, though don’t eliminate, the risk of over-processing on small work, since Quick Dev exists for exactly that.
- The module system is extensible. A company can add test architecture or custom agents without building its own framework from scratch.
- It maps cleanly onto the language teams already speak. If your organization runs Scrum or something SAFe-like, BMad’s vocabulary lowers political friction rather than adding a new one.
- It’s human-in-the-loop by design. Judgment isn’t handed to the model; it’s structured so that a human still has to weigh in at each stage.
Where BMad breaks
- The process tax is real. Full-Method planning can consume days of tokens and attention before a single line of production code is written.
- Quality still depends on the human partner. Weak product sense, paired with a fluent PM agent, produces a polished, confident, and incorrect PRD. The framework won’t catch that for you.
- Context rot isn’t BMad’s primary design target. Long implementation sessions can still degrade unless teams reset and hand off via story files as the method intends.
- The learning curve and operational overhead are nontrivial. Many agents, many workflows, many modules. Adoption tends to fail if only one enthusiast on the team truly understands how it all fits together.
- Version and ecosystem churn, the v4 stable line versus newer lines, and multiple modules create real support and standardization risk.
- Persona theater can replace the engineering discipline if leadership starts treating agent names as a stand-in for actual review, testing, and architecture ownership.
- It’s not a security or compliance product. It doesn’t replace Static Application Security Testing (SAST), secrets management, access control, or change-management policy, and nothing in the framework claims otherwise.
Where GSD wins
- It directly addresses the single most common technical failure in AI coding: quality collapse as context expands. That’s the problem it was built to solve, and it solves it.
- Atomic plans and wave-based parallelism can meaningfully increase throughput for well-specified work without dragging everything through one long, increasingly brittle session.
- Verification is a first-class phase, not an afterthought bolted on at the end. Work isn’t “done” just because the model claims it implemented the list.
- The ceremony is lower, and the command surface is concise, which means faster time-to-value for engineers who already know what they’re building.
- Durable planning files give you session-to-session continuity without requiring a full multi-role agile simulation.
- The runtime-agnostic posture reduces lock-in to any single coding assistant vendor, which matters more than it seems once you’ve been burned by a vendor pivot.
- It has strong community traction right now, which matters for hiring familiarity and long-term maintenance, not just enthusiasm.
Where GSD breaks
- It’s weaker as a discovery and stakeholder-alignment system. GSD assumes there’s already enough product clarity to discuss a phase. If that clarity doesn’t exist, GSD won’t create it.
- It doesn’t simulate product, UX, or enterprise architecture functions. Those still require actual humans or another method layered on top.
- Verification quality is only as good as the acceptance criteria defined in the plan. A vague plan produces a confident, incorrect “green” check, and that false confidence is arguably worse than an honest failure.
- Parallel waves can multiply token costs and increase merge-conflict risk if dependency analysis is sloppy to begin with.
- It’s a less natural fit for regulated documentation packs, PRDs, ADRs, and traceability matrices unless the organization deliberately adds that layer on top.
- The creator posture is anti-ceremony by design. That’s a feature for a startup and a cultural clash in an enterprise that relies on named roles and stage gates.
- Like BMad, it’s not an application-security or SDLC-governance platform, and it was never intended to be.
Lay both lists side by side, and a pattern jumps out: BMad’s weaknesses are mostly about cost and the discipline required to run it well, while GSD’s weaknesses are mostly about what it assumes is already true before it starts. That’s not a coincidence. It’s the same design tradeoff from the last post, just visible from the failure side instead of the feature side.
Knowing where each one wins and breaks is still an abstract exercise until you map it to actual enterprise decisions: which team, what kind of work, which budget line. That’s where I’m headed next.
