Everyone I talk to right now is somewhere on the AI development hype curve, and most of the conversation stops at the assistant itself: which model, which IDE, how good the autocomplete is. That’s the wrong altitude. The interesting question isn’t which AI coding tool you hand your engineers. It’s what happens once they have one and start using it for real work at scale across an entire team.
I wrote an executive briefing on exactly that question, comparing two open-source frameworks that have emerged as solutions. I liked the result enough to turn it into something more people could read. This series is that briefing, adapted.
Here’s why it needed writing. Most organizations have already given engineers AI coding assistants, and the productivity story is real. The control story is not. Unstructured “vibe coding” produces fast demos and fragile systems: implicit requirements, decisions that never made it out of a chat window, unreviewed architecture, and quality that quietly degrades as conversations grow longer. I’ve watched teams ship something in an afternoon that would have taken a week, only to spend the next month trying to figure out why nobody can explain what the code actually does.
Two open-source frameworks have emerged as leading solutions to that control problem: BMad Method and GSD Core. Neither replaces Cursor, Claude Code, Codex, or Copilot. They sit atop those tools and impose a delivery system on them: who thinks, what gets written down, how work gets sliced, and how quality is checked before anyone declares code done.
These are not interchangeable “AI agent platforms.” BMad Method is a virtual agile team: specialist agents (PM, architect, analyst, Scrum Master, dev, QA, UX) produce briefs, PRDs, architecture, and stories, ensuring assumptions are documented before code. GSD Core is a context-engineering and spec-driven execution loop (Discuss → Plan → Execute in parallel waves → Verify → Ship) designed to prevent quality collapse as the model’s context window fills.
That’s the part people miss when they treat this as a tooling decision. It isn’t. It’s an operating-model decision. It determines how product intent becomes code, how institutional knowledge survives staff turnover and session resets, and how much process tax your organization is willing to pay for auditability. Get that framing wrong, and you end up running a bake-off between two solutions that address different failure modes, wasting a pilot before it even starts.
The One-Page Verdict
| Question | BMad Method | GSD Core |
|---|---|---|
| Core bet | Simulate a full agile team of specialist AI roles to make decisions explicit before coding. | Keep the AI’s working memory clean so implementation quality doesn’t degrade during long work. |
| Best analogy | A virtual product, architecture, and delivery team with ceremonies and artifacts. | A production line: discuss, plan, execute in parallel waves, verify, and ship. |
| Primary asset | Role-based thinking and durable product/architecture documents. | Context isolation, atomic plans, and verification gates. |
| Fits | Complex, multi-stakeholder, greenfield or regulated work requiring discovery and design. | Clear-enough intent, high implementation volume, and solo or small teams shipping continuously. |
| Doesn’t fit | A two-day bugfix that doesn’t require a PRD, an architect, or a sprint ritual. | Ambiguous product problems that still need research, UX, and stakeholder alignment. |
| Risk if misused | Process theater: tokens and calendar time spent on ceremonies the work didn’t need. | Shipping the wrong thing quickly because discovery was skipped. |
My board-level take: don’t adopt a single corporate standard on day one. Pilot BMad Method on one or two complex initiatives that genuinely need product and architectural rigor. Pilot GSD Core on one or two execution-heavy workstreams where the intent is already known. Keep both optional, measure cycle time, rework, and defect escape, then standardize by work type, not by fashion.
That last part is the whole point of this series. These frameworks aren’t competing for the same job. One makes an organization think before it builds. The other makes an organization ship after it’s thought things through. Most engineering portfolios need both, in different weeks and on different tickets.
The Series
Over the next four posts, I’ll dig into that argument in depth. Here’s where we’re headed:
Part 2 — What BMad Method and GSD Core Actually Are cuts through the pitch decks and GitHub READMEs to explain how each framework works: BMad’s specialist-agent roster and staged workflow, and GSD’s context-isolated, wave-based execution loop.
Part 3 — Where Each One Wins, and Where It Breaks is an honest strengths-and-weaknesses pass on both frameworks, including where BMad’s process tax gets out of hand and where GSD’s speed outruns product clarity.
Part 4 — The Enterprise Tradeoffs, and When to Use Which turns the comparison into decision rules: which one fits which kind of work and why most organizations should run both rather than crown one as the standard.
Part 5 — Risks, Controls, and the 90-Day Path to a Decision closes the series with the guardrails leadership should require either way, plus the pilot plan I’d actually run to resolve this rather than arguing about it in a steering meeting.
If you’re trying to figure out how your organization should govern AI-assisted development, not just adopt a tool, you’ll find this useful. Let’s get into it.
