Human on the Loop: What I Learned from BMAD's Founder About the Future of AI Coding

Where BMAD actually came from

Brian didn't start BMAD as a product. He was managing engineering teams and trying to get his own experienced engineers to adopt the early agent loops in tools like Cursor. The reaction was blunt: it was fine for autocomplete, but as an autonomous loop, his best engineers called it trash, slower than doing the work themselves. Meanwhile, online hype claimed anyone could ship a "million-dollar SaaS app overnight." The gap between those two realities is what pushed him to spend nights experimenting on his own, long before terms like context engineering or spec engineering existed.

His actual insight came from twenty-five years in enterprise software, not from AI: agile works because it breaks big ideas into small pieces. So instead of writing bigger prompts or piling on more rules (which, he admits, felt like a magic bullet a year and a half ago and mostly wasn't), he started breaking work into small, specific intents, close to what we'd now call specs, and feeding the agent one at a time. That's the seed BMAD grew from.

I recently sat in on a long conversation with Brian, the founder of BMAD, one of the more thoughtful frameworks out there for using AI coding agents well. It covered a lot of ground, but a few ideas from it have stuck with me since.

The real philosophy: staying in control

The part that stood out most to me is what BMAD is actually optimizing for. It's not "let the agent do everything." The coding itself gets delegated, but the planning, the framing of what to build and why, stays firmly in the human's hands, with the agent acting more like a thinking partner than an autopilot.

Brian described feeling almost guilty on the days he's tempted to just ask the agent for the answer instead of working through the idea himself. That resonated. The goal isn't hands-off, it's staying the creative force while offloading the mechanical parts.

Before any framework, do this first

One piece of advice worth repeating: before adopting any framework or skill collection, spend real time just talking to a plain model through your harness of choice with nothing else in the way. See what it can already do on its own. Only pick up frameworks or write your own skills once you've felt the actual gap yourself.

Brian's framing for why so few engineers do this was blunt but fair: it's a permission problem, not an agent problem. Most people don't have unstructured time at work to fumble through this on their own, they have sprint commitments. When he gave a team two straight weeks with no sprint pressure, one task each, and no framework, something interesting happened: by day three or four, people were reinventing the exact practices he'd have taught them anyway, just because they were given the room to hit the wall themselves.

Where frameworks are actually headed

BMAD has moved away from a single rigid sequence (PRD, then architecture, then stories) toward something more modular: multiple entry points depending on how you think, a full product requirements doc, a leaner product brief, even an Amazon-style "press release and FAQ" exercise for testing whether an idea is worth building at all, and a lighter "quick build" path for smaller tasks that skips heavy planning entirely.

The next version is aimed squarely at teams: splitting large chunks of work into separate files so multiple people can work on different pieces without collision, integrations with systems like Jira and Linear, and distributing skill collections through marketplaces instead of one heavy installer.

The inflection point nobody warns you about

Once a team actually speeds up, Brian described hitting a wall almost immediately, in two directions. On one side, code review becomes the bottleneck, which pushes teams toward better CI/CD gates and smarter triage of what even needs human review. On the other side, and more interesting to me, AI turns out to amplify whatever process already existed, including the bad parts. A weak process doesn't get quietly patched over by AI, it gets exposed faster.

That pressure is reshaping team structure, too: instead of five-to-eight person scrum teams with a dedicated product manager, Brian's seeing a shift toward small two-to-four person pods that own a larger unit of work end to end, more like a self-contained mini agile team than a set of tickets. The title on the door matters less than whether someone on that pod is actually thinking in systems.

The slop apocalypse

This is the phrase that's going to stick with me longest. Brian's warning is that degraded output from a model change doesn't always show up as broken code. Sometimes there's no visible sign at all: just more tokens spent, more review cycles, and everything getting slower over time.

His concrete example: a model update reintroduced excessive code comments even under explicit "clean code" instructions, something that had been solved a year earlier. It's a small thing on its own, but multiplied across a codebase and compounded over time, it becomes real drag. His advice whenever a major model update ships is blunt: rebuild your agent instructions from scratch rather than assuming last year's setup still holds, because not everything about a new model release is actually an improvement.

Human on the loop, not the dark factory

I've heard "dark factory," full spec-in, code-out automation with no human involved, described as the end goal for a while now. Brian pushed back on that framing directly, and I think he's right: even if it's technically achievable, there's still a real question of who's deciding what's worth building and who's actually talking to customers. Full automation of the planning side isn't obviously something anyone wants, even if it's possible.

What he's aiming for instead is human on the loop: staying involved enough to set direction and catch problems, without personally touching every keystroke the mechanical execution produces.

What this means for the skills themselves

One detail I didn't expect: neither Brian nor the other guest on the call trust fully self-improving skills, the kind that automatically rewrite themselves based on session logs. In their experience, that approach tends to add rigid, deterministic behavior into places that were never meant to be rigid, and quality degrades within a few rounds. Skills, at the end of the day, are just prompts, in whatever markdown file you happen to be loading them from. The one genuine exception is hooks, since that's the one place actual deterministic code enters the loop instead of another prompt.

The takeaway

The technical skill that used to define a strong engineer, deep fluency in a language's syntax, is becoming less of a differentiator by the month. What's replacing it is something closer to taste: the ability to think in systems, spot bad patterns before they compound, and decide what's actually worth building in the first place. That's not a smaller job. If anything, it's a harder and more valuable one.