How I Use the BMAD Method with Antigravity for a Better Vibe Coding Experience

Image by StockSnap from Pixabay

I didn't want a framework. I tried BMAD because what I was doing wasn't working.

I don't know about you, but when I vibe code, I usually have different chats for different things and none of it connected. Brainstorm here, code there, debug somewhere else. It felt like I was moving. In reality I was just going in circles.

So I actually used BMAD while building Hive Roshambo, a rock paper scissors game on Hive, and Hive Curator Cockpit, a curation dashboard. Not just read about it. I used it.

BMAD is an agent framework, meaning you get 12+ specialized agents each with a different job instead of one AI trying to do everything. The ones I actually use are the Analyst, who digs into the problem before any code gets written, the PM who turns that into a proper PRD with scope and constraints, the Architect who designs the structure (this is the one you really don't want to rush), the Scrum Master who breaks everything into stories you can actually follow, the Developer who builds from those, and Quinn the QA agent who checks the output against what was planned. There's also a UX agent, a research agent, and a Party Mode where you pull multiple agents into one session, though I don't use those as much.

The workflow itself has two paths. Small stuff has a quick three-command flow. For anything real I go through the full planning path:

/product-brief : define the problem
/create-prd : full requirements
/create-architecture : technical decisions
/create-epics-and-stories : break it down

then per story:

/create-story → /dev-story → /code-review

The thing about BMAD that took me a while to get is that the order matters more than the agents themselves. When you vibe code you brainstorm and build and debug in the same session, which feels productive, but somewhere in there you made three decisions you didn't realize you made, and a week later you're quietly undoing them.

Doing one phase at a time is boring but it's also just less wrong.

BMAD works with any IDE you're already comfortable in, Cursor, VS Code, Claude Code, whatever. I run it inside Antigravity, Google's agent-first IDE.

What I like about it is the parallel agent view, where you can have multiple agents running on different parts of the project at once.

I rotate between Gemini Flash, Gemini Pro, Claude Sonnet, Claude Opus, and GPT-OSS. Sonnet, Opus, and GPT-OSS share premium quota. Gemini Flash doesn't. I use cheap models when things are still messy and save the premium ones for decisions that are harder to walk back.

Early on in the Analyst phase I use Gemini Flash. I'm not looking for accuracy yet, I just need to move. I throw half-formed ideas at it and see what sticks. When something starts to feel real I move to Gemini Pro and shape it into a PRD, and by the end I actually know what I'm building, not just what I think I'm building. Those are different things more often than I'd like.

Architecture I do with Claude Opus and I stop trying to move fast. I've rushed this step before and it doesn't show up as a problem right away. It shows up three weeks later when everything feels slightly broken and you can't figure out why. After that I go back to Gemini Flash for breaking things into tasks, which is repetitive work that doesn't need the expensive model. Before any code gets written I do a readiness check with Gemini Pro. I used to skip this when I felt good about the plan, and that confidence was usually wrong.

The coding loop runs on GPT-OSS because it handles iteration well. Fix this, that broke something else, okay try again, that's most of what this phase is. Last step is code review with Claude Sonnet, not the same model that wrote the code, because one model reviewing its own output just agrees with itself.

As good as the BMAD method is, I still make mistakes. For a while I threw Opus at everything early because I figured a smarter model meant better results, but it doesn't, it just costs more. I skipped the readiness check when I felt confident. Let one model do everything from start to finish. All of that cost me time I thought I was saving.

If you've been vibe coding and hitting the same walls, this is worth trying, especially if you already familiar with agile methodology in development cycle.