Your Framework Is the Intake, Not the Factory

Part 2 of 3. Planning frameworks feed the factory. What they produce matters more than which one you pick.

Taylor Swift's Eras Tour lands in a new stadium almost every week. The city changes, the venue changes, and so does the local crew hanging the rigging and running the lights. Each crew brings its own habits, its own load-in quirks, and its own opinions about where the coffee goes.

The show comes together anyway, because every crew works from the same written production book and show script. Cue sheets, stage plots, and set lists travel with the tour. The local rituals do not. The portable plan makes the show work, not any one crew's way of working.

A software factory runs on the same logic. A planning framework is one crew's working style. The artifacts it produces are the portable plan the factory actually runs on.

Teams building a factory are now asked to pick a framework, usually framed as heavy BMAD versus lean Spec Kit. Consultants working inside a client's SDLC often cannot impose either one. The way out of that argument is to see the framework for what it is: the intake, and the artifacts it produces matter more than the brand on the box.

The Framework Sits Upstream of the Factory

In Part 1, I argued that humans belong at intent and approval, and that verification is the real constraint on how much a factory can do safely. Intake is where the intent control point lives. The quality of what goes in determines what the factory can be trusted to do.

Look at any software factory that works and the same shape appears. Something produces a scoped piece of work, an issue, a ticket, a spec. The factory takes it, builds, tests, reviews, and returns a pull request for approval. The loop in the middle is where the agents live, and it is remarkably similar from one organization to the next.

The planning that produces the input sits upstream of that loop. One practitioner who built and then rebuilt a factory made this explicit: the factory does not plan, it takes a planning document in and splits it into tickets.

A factory can only be as disciplined as the work order it receives.

That is exactly the slot BMAD and Spec Kit occupy. They are not the factory. They are two different ways of turning intent into the thing the factory runs on.

Stripe shows the output side of this shape. Its Minions agents merge over 1,300 pull requests a week, and its "blueprints" wrap deterministic steps around bounded agent loops. The agents execute with guardrails. Someone still decides what the work order says.

"Bloated" Is an Old Verdict

The common shorthand says BMAD is heavy and Spec Kit is light. It describes the BMAD of a year ago better than the BMAD of today. Recent releases renamed its quick path to Build and made it the standard way to implement, added a core skill that distills any input into a spec, and moved toward an epic-per-folder structure where individual stories are written only when someone is about to build them. Its maintainers now say plainly that if you are building a to-do app, you should skip the method and just ask the model.

Spec Kit, meanwhile, has picked up weight of its own. Thoughtworks teams using it in existing codebases found the project context kept growing until it threatened to crowd the agent's working memory, and moved reusable guidance out into skills to cope. The two projects are converging on the same idea from opposite directions: a short, specific spec per unit of work, with everything else loaded only when needed.

Each project has also spent a year shedding the reputation it earned in its first six months.

For enterprises, the most relevant Spec Kit feature is its extensions and presets. Presets let a team shape specs to its own compliance formats and organizational standards, which matters to anyone working inside an established SDLC. A regulated team can require its risk-review section in every spec without forking the tool. Both projects change month to month, so treat every detail here as dated as of writing. Declaring a winner now would be like picking a favorite wave at high tide.

Four Artifacts That Outlive Any Method

Strip away the commands and the agent personas and both methods exist to produce a small set of documents. Those documents are what the factory actually consumes, and they are what an enterprise should insist on, whichever method, or no method, produced them.

The first is a scoped spec for each unit of work that says what is in and what is explicitly out. The out-of-scope list does more steering than most teams expect. The second is a standing rules file for the codebase, what Spec Kit calls a constitution: scope, conventions, technology versions, and the things the agents must never change, including the rules file itself.

The third is a set of acceptance scenarios kept away from the agents that build the code, so the builder cannot tune its work to pass the test it can see. The fourth is an explicit escalation rule: which kinds of change a person must approve before they ship.

The hidden scenarios deserve a plain explanation. Agents are eager to please, and an eager builder with a visible test will optimize for the test. It will write code that passes, which is not the same as code that works.

A builder that can see the exam will study the exam, not the subject.

None of this requires a new process. Each artifact maps onto something the organization already has: a requirements document, coding standards, a test plan owned by quality engineering, and a change approval policy. Adopting the four is a change in rigor, not a new bureaucracy, and that makes it an easier sell to a client who cannot swap out their delivery process.

The Fair Objection

The strongest pushback against all of this deserves a direct answer.

The fair objection is that "standardize the artifacts, not the method" sounds tidy and ignores why methods exist. A shared framework gives a team a common vocabulary, makes onboarding faster, and gives newer engineers and business-side contributors guardrails they would not invent on their own. BMAD's maintainers make exactly this case: the structure forces conversations and questions that people skip when left to themselves. Without a method, artifact quality drifts from team to team.

That is true, and it changes the advice rather than overturning it. Where a team has no working method, adopting one is the fastest route to good artifacts, and either of these is a reasonable choice. Where an organization already has a delivery process, layering a second one on top usually produces two sets of documents and one set of confused people. In both cases, judge the method by whether it reliably produces the four artifacts, and keep it replaceable, because both projects are changing month to month.

The Plan Travels

Every city gets a different crew and the tour still opens on time, because the plan travels and the rituals stay behind: the plan, not the crew's ritual, is what to standardize.

The framework debate will keep going, and the projects will keep converging. None of that changes what the factory needs as input. Pick a method if it helps, keep it swappable, and make the four artifacts non-negotiable.