I trusted the BMAD framework in claude Code. 2 weeks of work evaporated.

Note: AI tools assisted with structuring this post. The experiences, testing, and opinions are entirely my own.

The git reset took ten seconds. Convincing myself to run it took the better part of a day.

It was a brownfield project I cared about. I’d been running BMAD-Method for a few weeks, watching it produce clean discovery docs, sensible architectural sketches, working code. Each week the framework had earned a little more of my trust. I’d been delegating more freely. We called it the autopilot phase. We laughed about it.

Until I went to look at the API contract layer in week two and realized I was looking at Flask.

Flask is a fine framework. It was the wrong fit for this project — we’d already committed to async streaming patterns elsewhere in the codebase, and Flask was going to fight us on that for the next eight months. I hadn’t asked the framework what it was picking. I’d just delegated the call. By the time I caught it, the implementer agent had built six features around the assumption. The reviewer was already signing off on PRs that took Flask as a given. The integrator had merged the most recent of those into main the night before.

To rip Flask out meant ripping out what those agents had built on top of it.

So we started over.

That’s the part I usually skip when I tell this story. The two weeks lost is the headline. The thing I don’t say out loud as often is: the framework didn’t fail me. I failed to ask. I’d gotten comfortable with autopilot in a context that had no business being on autopilot.

The mistake wasn’t picking BMAD-Method. BMAD does what it claims to do. The mistake was slower than that. I’d stopped reading the seams between agents.

Here’s the thing about chained-agent frameworks. When one orchestrator makes decisions across many specialized agents, each agent treats the previous one’s output as ground truth. Information moves down the chain like a current. There’s no checkpoint where a human is forced to look. If I’m not actively watching the seams, I’m not catching anything.

That’s the part the trend pieces don’t say out loud.

Multi-agent buys you parallel processing and specialization. It also buys you opacity. A monolithic agentic framework can make a wrong call in week one, and the chain just keeps going. The right call would have been visible. The wrong call is invisible — and stays invisible until the friction is loud enough to hear. By that point the wrong choice is load-bearing.

After the rollback, I rebuilt the workflow. Not because BMAD was the problem, but because I needed boundaries I could actually see. Five specialized agents this time — planner, spec-writer, implementer, reviewer, integrator. Each one’s output had to be in a format the next could consume. Each handoff became a moment I could step in.

The trade was real: more places I had to read carefully, slower cycles. The upside was the only thing that mattered after losing two weeks. I could see decisions when they happened.

People want to know if it’s worth it.

The honest answer is that the multi-agent setup costs more in three places nobody publishes about.

The first is agent prompt maintenance. Each model update or plugin change or codebase convention shift can drift one agent out of sync with the others. Someone has to own that, and on a small team it usually falls to whoever built the fleet — which means the person who can least afford the time.

The second shows up in handoff debugging. When something breaks between two agents — when the spec-writer outputs something the implementer can’t parse, or the reviewer misses a class of issue — the failure isn’t in any single agent. It’s in the boundary between them. Diagnosing those failures is a different skill than debugging single-agent bugs, and it’s one most engineers learn the hard way.

The third is onboarding. A new engineer joining a team that runs single-agent Claude Code is productive in their first session. A new engineer joining a multi-agent fleet needs three to four days before the boundaries make sense. They read the handoff specs, watch a workflow run end-to-end, and fail at a couple of handoffs before understanding why the boundaries are where they are.

None of these show up on a pricing page. They show up in engineer time, and they compound with every agent you add.

But here’s the part I want to be honest about, because this is where I lose some readers.

I don’t think most teams adopting multi-agent right now actually need it.

The trend pieces pitch multi-agent as the next level — fleet up, specialize, ship faster. What I’d say to my own engineering team (what I am saying to friends who ask) is more conservative. Multi-agent isn’t free. It’s a deliberate response to a specific class of problem. If your tasks are short-cycle, if your rollback cost is low, if your wrong decisions surface in hours not weeks, single agent is fine. Better than fine. Let the model do the work.

The diagnostic question I use now, before I add a single specialist agent: will I detect a wrong turn faster than I can roll it back?

If the answer is yes — if I’d catch it in a code review or a unit test or a smoke check — single agent. The friction of a five-agent handoff buys nothing.

If the answer is no — if a wrong decision in week one defines what’s possible in week eight, like that brownfield refactor — then I pay the multi-agent tax deliberately, with my eyes open and the handoff structures I designed rather than inherited. I am trading speed for visibility, and that’s the right trade for that kind of work.

That’s the position I hold.

It costs me, sometimes. I’ve watched engineers I respect look skeptical when I tell them their multi-agent setup is over-engineered. I’ve had founders ask me how to add more specialist agents to their stack and answered “you probably don’t need them yet” — and watched them go ask someone else. There’s a fashion around multi-agent right now that’s hard to push back on without sounding like a contrarian for sport.

Sometimes I wonder if I’m just calibrating to my own scar tissue. The two weeks lost was real, but maybe other teams wouldn’t lose two weeks. Maybe their detection lag is shorter than mine, or their architecture more forgiving. When I push back on someone’s multi-agent setup, I’m pushing back from one CTO’s experience on a seven-person team. I try to remember that when the urge to be certain shows up.

But the two weeks I lost weren’t to BMAD. They were to me, not reading the seams of a system I’d stopped watching. The lesson from those two weeks isn’t “use a five-agent fleet.” The lesson is: if you’re going to delegate decisions to a framework, design checkpoints where you can see the decisions before they become load-bearing.

What I’m watching for next.

The Claude Code skills primitive is starting to make this easier. A skill is a unit of behavior an agent loads on demand — version-controlled and testable like any other code. Defining handoff formats and review checklists as skills means the discipline lives in markdown instead of tribal knowledge. I built one called karpathy-coder that ships Python validators, a review agent, a slash command, and a pre-commit hook — specifically to surface the silent-assumption class of mistake that cost me those two weeks. It’s open-source if you want it: github.com/alirezarezvani/claude-skills.

Jesse Vincent’s Superpowers plugin (in Anthropic’s marketplace since January) generalizes the same idea. It encodes subagent-driven development with built-in code review and structured planning. It doesn’t eliminate coordination tax. It makes the tax cheaper to pay — which is the right direction.

What the trend pieces miss, I think, is that “multi-agent” is the architecture, not the answer. The answer is whatever discipline keeps you from delegating decisions you weren’t ready to delegate.

Pay the tax deliberately. Or pay it in two weeks of work.

(I wrote a different version of this on Medium last month, more structured, with the SEO and the Q&A block. This one is the unguarded version — the parts I usually trim out.)

If you’ve lost time to a framework you trusted, hit reply. I want to hear what your detection lag was. Mine was the better part of two weeks.

— Reza

If this resonated, the deep-dives go further than I can in a free post. $7/mo, $60/yr, or just hit reply — I read every email.