BMAD Ate My Month: When Spec-Driven Development Is Too Much

On September 5 I deleted 1,782 files from my autopilot's repository in one commit. Agents, templates, workflow configs, a PRD (Product Requirements Document), an architecture document, a story backlog longer than most novels. About 16 MB of process, and not one line of product.

Typing that commit message felt better than anything I shipped that month.

Some context if you are new here. The autopilot is an autonomous coding system I built and have been running for months: it receives GitHub webhooks and runs headless Claude Code sessions that write, review, and merge pull requests without me at the keyboard. I have told its story before, from building it to the day it ran out of tokens. This post is about the question those posts skipped: how work should be planned before an agent ever sees it.

The industry has an answer to that question. SDD (Spec-driven development): write the specification first, make it the contract, and let the agents implement against it. BMAD is that idea at full weight, an entire agile organization in software, with AI analysts, architects, product managers, and developers, and a workflow that runs them in order. For four weeks, it planned my product.

This post is about what that month cost, and the embarrassingly small thing that actually fixed the problem BMAD was supposed to fix. If you run coding agents and your PRs keep turning into hostage negotiations, this is for you. I got this wrong twice before getting it right, and both wrong answers looked smart at the time.

The failure that started everything

You know this failure. You have probably committed it this week.

You are busy, the agent is capable, so you file a one-line issue: remove this, add that, make it configurable. The agent reads your line and builds either the wrong thing or a monument to the right one. Then the reviewer model, the expensive one you hired precisely to catch problems, catches the problem. In review. After the work exists. After the money is spent.

My worst case: a cleanup that should have been a quiet deletion collected sixty comments across ten review rounds. Two models arguing with each other, round after round, every round billed to me. Then I closed the pull request without merging it.

Sixty comments. Ten rounds. Nothing shipped. And the whole argument was downstream of one line I wrote in thirty seconds.

Attempt 1: the machine tried to fix itself

My autopilot's answer to "the PRs are too big" was, I swear, more autopilot.

It generated a size gate: a scope agent that estimated the diff an issue would produce, and above a budget carved the work into ordered sub-issues. Almost six thousand lines of new code, to enforce a line budget on future code. I did not design this. The machine did, and the design was even accurate about the disease. Its own PR body diagnosed that large PRs drive the review churn.

And still it was attacking the symptom. The gate measured work after the intent was already written badly. Splitting work after it exists is triage, not planning. By the time there is a diff to estimate, the mistake is old. It was made in the issue.

I never merged it. The dangerous part is how reasonable it looked.

Attempt 2: BMAD

I found BMAD through a podcast on spec-driven development. One of the guests was a BMAD contributor, and everything he said sounded solid. I wanted solid. I was tired of arguing with my own pull requests.

So the day after rejecting the machine's six-thousand-line fix, I installed a 1,782-file one.

BMAD planned my product the way an enterprise plans a satellite launch. A 13,397-word PRD. A 19,867-word architecture spine. An epics.md backlog that reached 43,062 words. Nine epics, 86 stories, every one with acceptance criteria. Reading the plan felt like adult supervision had finally arrived.

Five days in, an implementation-readiness assessment found one critical omission and three major planning defects, and blocked all further implementation. Sit with that. The plan failed a review of the plan. The fix, approved the same day, grew the plan to 91 stories. The product had not moved.

Then the loop started, and I met the real bill. A typical story burned one to two million tokens. One story hit around thirty million. Thirty million tokens, one story. Maybe I misconfigured something; honestly, I probably did. But look at what my config had to become in self-defense: a four-million-token budget per story, a 210-minute session timeout, a hard cap of seven review cycles, nudge budgets for sessions that stall without a result. Those are not settings. Those are restraining orders.

To be fair, bmad-loop itself is genuinely well built. The TUI is impressive. The quality bar is real; the reviews caught real defects. In four weeks, 23 stories were implemented and reviewed through it. Six more finished their code and parked themselves as "awaiting operator", waiting for things only a human can do.

But my product was young and changed constantly, and every change created homework. Update the PRD. Update the architecture. Update the backlog. The documents needed to be current before the code was allowed to move, so the code moved at the speed of the documents.

I was supposed to operate an autonomous system. I had become its secretary.

My verdict is not that BMAD is bad. BMAD is solid. Too solid. For an established product with a stable spec, that bar might be exactly right. For a product still finding its shape, the bar killed the only metric that mattered: time to release. On September 5 the whole kit left in one commit, and the release line moved forward the same day.

Attempt 3: steal the good part, skip the religion

Here is what actually worked, and what I would tell you to do instead of either of my failures.

I did not adopt another framework. I took the one thing from the spec-driven world that had earned its keep, Spec Kit's way of expressing intent, and forced it into add-autopilot-issue, the skill I already used to file work. Spec Kit is compact where BMAD is encyclopedic, and it asks quite exactly the right questions: what changes, for whom, how you will know it worked.

The mechanics that now run my intake, all of them small:

• Every story issue carries a pinned spec reference: Spec: owner/repo@sha:path#user-story-N, full 40-character SHA required. Coder and reviewer read that exact version, so neither can move the goalposts mid-session by editing the spec.
• One user story becomes one issue. Two or more become a parent epic issue with one issue per story and an epic/NNN-<slug> integration branch.
• A story with more than 12 tasks gets split before it is filed.
• Reviews run against the pinned spec with a BLOCKING/SHOULD/NIT rubric, so "I don't like it" and "this violates the spec" stop being the same comment.

And one rule no code enforces, because it is mine: when I write an issue, I aim for work around 300 lines of non-test code. Small enough that a session cannot wander, small enough that a review cannot spiral.

That is the entire fix. A reworked skill and a pinned line of text. The smallest thing I tried, and the only one still on main.

Decided before it starts

Three attempts, one lesson wearing three costumes. The quality and cost of an autonomous coding session are decided before it starts: by how precisely the intent is expressed, and by how small the work arrives. The size gate tried to enforce that in code, after intent. BMAD tried to enforce it in documents, on top of intent. What worked was just doing it: saying precisely what I want, in pieces small enough to survive contact with review.

One more observation, offered as observed because I have not measured it and it is clearly not linear: the better the intent is expressed, the cheaper the model that can execute it.

And a verdict, for whoever is weighing BMAD right now. I did not dabble. I ran the full, fundamental approach, the way it is meant to be run, and for me it did not work: too long, too expensive. For an enterprise with a stable spec and a tolerance for ceremony, that same weight may be exactly right. My projects move fast, and BMAD could not keep up with them. So the experiment is closed. I will not run it on any of my projects for now; more flexible approaches carry its best idea at a fraction of the cost.

That is what those 1,782 deleted files were. Not a failed tool.

A closed experiment.