Crew or Briefing Tape? Where the Structure Lives in BMAD and GitHub Spec Kit

BMAD and GitHub Spec Kit are not competing tools. They are competing answers to one question, and the right answer depends on your real bottleneck.

Every serious spy agency solves the same problem: pulling off the same job every time, under pressure, without anyone improvising the plan. There are two proven ways to do it. The first is the crew, a team of specialists coordinated through a handler in the van, who calls the cues and checks every move before it goes live. The second is the briefing tape, a single precise document that any competent agent can follow alone to complete the mission exactly.

Watch an episode of The Bear and you see the crew model at full intensity. Carmy drags a chaotic sandwich shop toward a real brigade system, with station assignments, "heard," and a mise en place ritual before service, because the menu has outgrown what any one cook can hold in their head. The structure in that kitchen lives in the roles and the handoffs. A briefing tape puts the structure somewhere else entirely: on tape, portable, indifferent to who presses play.

Agentic software development has arrived at the same fork. Teams that have outgrown throwing prompts at a coding agent need structure, and two of the most visible options put that structure in opposite places. BMAD and GitHub Spec Kit are not competing tools; they are competing bets on where the structure of agentic development should live, and most teams are picking one without knowing which bet they have made.

Two Answers to the Same Problem

Start with what the two methods agree on, because it is most of the story. Both exist to end freestyling, the practice of throwing prompts at an AI coding agent and accepting whatever comes back. Both replace that with a structured process that captures intent before code, keeps the work reviewable, and makes the outcome repeatable rather than lucky.

The failure they are both fighting is specific. Every new chat session is Groundhog Day for the project plan, and the agent produces a karaoke cover of the architecture: every note plausible, the song quietly wrong. The underlying mistake is blunt: we treat coding agents like a Magic 8-Ball when we should treat them like Commander Data, brilliant and entirely literal.

Freestyling does not fail because the model is weak; it fails because nothing remembers what you meant.

They diverge on one decision, and it is the decision that matters. Given that you need structure, where should it live.

One method puts the structure into a document that any agent can execute. The other puts it into a team of specialized agents that execute a process. Everything else about the two follows from that single choice.

The Briefing Tape: What GitHub Spec Kit Actually Is

GitHub Spec Kit is a toolkit, and that word is the whole philosophy. It gives you a lean sequence, specify what you want, plan how to build it, break it into tasks, then implement, and a project-wide constitution of rules that every specification inherits. The specification is the artifact that carries the structure, and the developer stays in the orchestrator's seat.

That four-step sequence describes Spec Kit as GitHub open-sourced it in September 2025. The project has moved fast since, reaching v1.1.0 with more than 130,000 GitHub stars as of early October 2026. The per-feature loop now closes with a converge step after implementation, and the toolkit ships separate processes for bug fixing and idea assessment. That last addition signals a team that knows not every change deserves the full ceremony.

Its defining property is that it is agent-agnostic. The same spec can be executed by Copilot, by Claude Code, by Cursor, or by whatever agent a team already uses, because the structure lives in the document rather than in any one tool. That makes Spec Kit a fast way to standardize the quality of AI-assisted work across a team without adopting a whole new way of working. It is light on ceremony and, by the same token, light on help when the coordination itself is the hard part.

Manfred Riem, the project's lead maintainer, calls the AI "a very capable intern," while stressing that it is still an intern. Spec Kit's design follows directly from that view. The developer writes the brief, the agent does the work, and a human decides what ships.

The Crew: What BMAD Actually Is

BMAD makes the opposite bet. Instead of one artifact that any agent executes, it stands up a team of specialized agents that mirror an agile organization, an analyst, a product manager, an architect, a scrum master, a developer, and a quality agent, each with a defined role and a defined moment to act. The structure lives in the process and the roles, not in a single document.

Two mechanisms carry the method. In the planning phase, the analyst, product, and architect agents collaborate to produce detailed requirements and architecture before any code is written. In the development phase, a scrum master agent compiles those plans into hyper-detailed story files that hand the developer agent everything it needs to implement without losing the thread, with a quality agent checking the result.

The story file is the clever part, because it is how the method fights the context loss that breaks long AI builds. A developer agent that opens a story file already knows what to build, how to build it, and why. It never has to reconstruct the plan from a stale chat history.

BMAD is heavier than Spec Kit by design, and it scales up to complex, multi-team work and even beyond software, for the same reason a full crew can run an elaborate heist. The current v6 documentation organizes the method around six core agent roles across four workflow phases. Its own README pitches the approach at territory as far afield as creative writing and business strategy.

The Real Distinction: Where the Structure Lives

Lay the two side by side and the feature lists stop mattering. Spec Kit puts the structure in the artifact and lets the developer orchestrate any agent against it. BMAD puts the structure in a process run by specialized agents and lets the method orchestrate the work.

That is the entire decision, and it is not a decision about tools. It is a decision about where your team's real bottleneck sits.

The artifact-centric bet has a strength that is easy to undersell. A document outlives the session, the agent, and sometimes the developer who wrote it. When the structure lives in the spec, a team can swap one coding agent for another next quarter and lose nothing, and a new hire can read the intent instead of reverse-engineering it from commits.

The role-centric bet earns its keep differently. A process carries things a document cannot: sequencing, separation of concerns, and a check at every handoff. When an architect agent must settle the design before a story file exists, and a quality agent reviews before anything counts as done, the method enforces discipline that a single spec can only describe.

The question is never which framework is better; it is which failure you are actually having.

If the thing that goes wrong in your AI-assisted work is unclear intent and inconsistent output across different agents and developers, your bottleneck is the artifact, and the method that governs the artifact will help you most. If the thing that goes wrong is coordination, shallow planning, and context lost across the many steps of a complex build, your bottleneck is the process, and the method that supplies roles and context handoffs will help you most. Picking the framework before you have named the bottleneck is how teams end up with elaborate ceremony around simple work, or a single thin document stretched across a build that needed a team.

This is the same selection discipline a good architect applies to any build. Nobody serious picks a message queue because it headlined a keynote; they pick it because the problem has an asynchronous shape. The habit that matters is matching the structure to the shape of the problem rather than to the most visible option on the shelf.

When to Choose Which

Start with the shape of the work, not the logo on the repo. Three questions do most of the sorting. How well scoped is the work, how many hands must coordinate to finish it, and does the risk live mostly in planning or mostly in execution?

Reach for the artifact-centric method, Spec Kit, when the work is incremental or well scoped. It fits a team that already has coding agents it likes and wants consistency across them, and it fits when the priority is standardizing AI output quality quickly without adopting a new operating model. It also assumes a developer who is comfortable staying in the orchestrator's seat, writing the brief and owning the review.

Picture a platform team adding features to a mature service, with developers split between Copilot and Claude Code. Their problem is not coordination, because the architecture already exists and the boundaries are known. Their problem is that five people prompting five ways produce five flavors of code, and a shared spec with a shared constitution fixes exactly that.

Reach for the role-centric method, BMAD, when the work is complex and greenfield. It earns its overhead when planning depth and an explicit separation of product, architecture, and implementation add real value, and when multiple people or teams must coordinate across a long build. It also fits work that spans domains beyond software, where a fixed set of roles carries more weight than any single document.

Now picture a new product line with a six-month horizon and three teams contributing. No single spec can hold the requirements, the architecture, and the sequencing of that build at once. That is a crew problem, and handing it to a lone agent with a single tape ends with a smoking cassette and a blown mission.

The migration path tends to run in one direction. Teams commonly start with the lighter method and move to the heavier one as the work grows roles and coordination needs. That pattern is itself evidence that the right answer is set by the work and not fixed for all time.

Which leads to the point that matters most. Choosing the method is itself a design decision, and making it by fit rather than by star count or conference buzz is the actual skill. Picking a framework by GitHub stars is the engineering equivalent of hiring a contractor by the size of their truck.

The Fair Counterargument

The fair objection is that this whole category may be structure for its own sake. There is a real historical echo here, Model-Driven Development, which promised to generate working systems from formal models and mostly did not survive contact with real projects. Both of these methods add real overhead, often an hour or several of process per feature, and that overhead does not always earn its keep. For a large share of routine and incremental work, disciplined prompting and a careful human review will beat either framework on both speed and sanity.

Critics have sharper labels for the same worry. Practitioner guides catalog the "sea of markdown" and "reinvented waterfall" complaints, and one 2026 review concludes that Spec Kit gets you a clean spec and a first generation, "then leaves you on your own." A reader on Microsoft's developer blog asked the oldest question in software: can anyone ever know exactly what is needed up front?

Structure is a cost you pay early to avoid a bigger cost later, and sometimes the bigger cost never arrives.

The tooling is also young. These are fast-moving open-source projects, and betting a team's entire operating model on a particular framework at a particular version is its own kind of risk. Spec Kit alone shipped six tagged releases in under two weeks this past spring.

None of this argues for going back to freestyling. It argues for proportion. Apply structure in proportion to the complexity and the coordination cost of the work, treat the method as something you can change as the tooling matures, and do not mobilize a full crew for a sandwich.

Match the Team to the Mission

Every good spy agency already knows the rule: you do not assemble a full crew to change a lightbulb, and you do not run a vault job off a single tape. The frameworks will keep multiplying and trading stars, and next year's leaderboard will look nothing like this one. That churn tells a leader nothing about which structure their own work needs. The skill that lasts is naming the bottleneck first and matching the method to the shape of the work, a judgment no framework makes for you.

So here is what you now know. The choice between BMAD and Spec Kit is a choice about where the structure lives, in the artifact or in the process. The right answer is set by the work rather than by the trend, and picking by fit is the part that is, and stays, the team's own job.