The wins-and-breaks list from last post is still one level removed from a real decision. Nobody adopts a framework in the abstract. They adopt it for a specific team, a specific budget, and a specific piece of work. So let’s get concrete about what each framework actually costs an enterprise and which situations call for which one.
What each one actually costs you
A few factors matter more than the rest once you’re past the pitch:
- Cost shape. BMad front-loads token and calendar costs into planning. GSD spreads its costs across parallel execution and verification instead. The same total spend can land very differently on a budget line, depending on which shape your finance team expects.
- Audit and traceability. BMad is stronger here: PRDs, architecture docs, stories, and role handoffs provide a business-readable paper trail. GSD is adequate for engineering history but weaker for something you’d hand to an auditor or investor.
- Talent model. BMad works if you have product and architecture owners willing to partner with agents. GSD works if you have strong implementers who can write clear decisions and acceptance criteria. Neither works if you don’t have the human half of that pairing.
- Change-management load. BMad’s is higher: training, playbooks, and explicit rules for when to skip ceremony. GSD’s is lower to start, but it still needs coding standards for plans, waves, and verify-before-merge once you’re running it for real.
Vendor lock-in is low for both, since they are open-source and support multiple runtimes. The real lock-in risk isn’t the vendor; it’s the process itself: BMad’s role conventions and GSD’s artifact conventions each become ingrained habits once a team’s used to them.
BMad’s real pros and cons
At its best, BMad gives leadership a clear delivery narrative: requirements, design, build, test, and reduces the silent assumption-to-code gap that causes the most expensive rework in AI-assisted programs. It also supports brownfield onboarding well, since it forces a “what’s actually here” pass before anyone touches existing code.
At its worst, it’s easy to over-adopt. Mandating the full Method for every ticket, including those that don’t need it, is exactly what kills the productivity case. It can also look like a headcount substitute, which it isn’t. It amplifies existing roles; it doesn’t retire the accountability that comes with them. And token burn during planning can genuinely surprise a finance team if nobody’s tracking web-LLM versus IDE usage.
GSD’s real pros and cons
At its best, GSD protects implementation quality exactly where most AI coding programs fail: during long sessions. It increases shipping cadence for well-bounded work without standing up anything resembling a virtual department, and verification-before-ship aligns with how engineering leaders already want their teams to operate.
At its worst, it won’t rescue a program that doesn’t know what problem it’s solving, and it can quietly institutionalize speed without product discipline if it’s the only system in place. Parallelism without solid branching and review standards quickly becomes an integration mess, and it doesn’t come with ready-made language for steering committees or stage-gate reviews the way BMad does.
So which one, when
Use BMad when the work involves a new product or platform with incomplete requirements, when multiple stakeholders need to agree on scope and architecture before spending ramps up, or when you’re inheriting a brownfield system and need to reconstruct verified context before making any changes. Don’t force the full Method onto a known defect or a well-specified story already in a mature backlog; that’s what Quick Dev is for.
Use GSD when the intent is already clear, the constraint is execution quality and speed, the work decomposes cleanly into phases with explicit acceptance criteria, or your team is already losing quality after thirty or sixty minutes of accumulated context in whatever AI runtime they’re using. Don’t rely on GSD as your only system if the company is still deciding who the customer is or which architecture to bet on. It will faithfully execute a poor spec, which is worse than no spec at all.
The combination most enterprises should actually run
These frameworks are complementary, not mutually exclusive. Across practitioner comparisons, the pattern that appears again and again is the same: BMad, or an equivalent human product and architecture process, handles discovery, PRD, and system design. GSD Core takes over for phase execution once decisions are sufficiently locked to implement. Human review, automated tests, and security scanning remain mandatory on every path, with no exceptions. Quick Dev and small GSD phases absorb incidental work, so the heavy path stays reserved for work that actually needs it.
If you want a single intake rule to hand your team: if they can’t state the user, the constraint, and the definition of done on a single page, start in BMad. If they can, start in GSD.
That’s the decision framework. What’s left is the part every executive eventually asks about anyway: what could go wrong and what you should require before you let either of these near production. That’s in the next post.
