BMAD Is Overkill. I Kept the Brief.
Building AI Autopilot for code, research, and workflows.
I’m building HLTM — a personal automation layer that runs AI agents on my projects autonomously. To get there, I needed a methodology. A way to structure what the agents do and in what order.
So I looked at what existed.
I was not shopping for a philosophy. I was hunting for something I could run daily without drowning in process.
If it added ceremony, it had to earn it.
BMAD
BMAD stands for Business Model Agentic Development.
Full SDLC as prompts. Epics, sprints, retros, party mode, planning sessions. Dedicated roles — product owner, architect, developer, QA — each with their own prompt file and their own context window.
Serious work. Real adoption. People ship with it.
I ran it on a project.
It took three times as many rounds to get the same output I got with a direct prompt. Most of that time was process. Running the planner to write tasks. Running the estimator to size them. Running the product owner to approve the scope.
The agents were busy. The project wasn’t moving.
That’s not a bug in BMAD. That’s what BMAD is — structure for teams working on complex, long-running products. It mirrors how software teams actually operated: separate roles, handoffs, artifacts that survive context switches.
For a two-person startup or a solo dev with a bash loop, that structure doesn’t map. There are no handoffs. There’s no context switch between roles. The coordination costs BMAD was designed to manage don’t exist.
GSD
GSD is the opposite. One prompt. One agent. Just ship.
“Radical simplicity” was the pitch. No ceremony. No roles. No planning artifacts.
Works great for one-shot tasks. Write this function. Fix this bug.
Break it into anything stateful and it falls apart. The agent doesn’t know what it did three rounds ago. It doesn’t track partial progress. It has no concept of “we agreed earlier that the auth module was out of scope.”
One prompt gets you one task. A project is not one task.
What Both Were Solving
BMAD solves the complexity problem: big projects need structure or they drift.
GSD solves the overhead problem: too much structure kills momentum.
Both are right. They’re just aimed at different problems than mine.
My problem: one dev, small projects, repeatable loop. I needed just enough structure to keep agents on track across multiple rounds — without rebuilding an enterprise process on top of a 300-line bash script.
What I Actually Tested
Same project. Three runs.
BMAD: 23 rounds. Lots of planning artifacts. Clean output.
GSD: 7 rounds. Fast. Broke on the second feature because it forgot a constraint from round three.
Custom loop with develop and review phases: 8 rounds. Clean output. No orphaned artifacts.
What I Kept
From BMAD: the brief format. Writing a structured brief before any agent touches the project — that survived. The brief is the contract. Without it, agents make assumptions. With it, they have a reference they can check themselves against.
Also from BMAD: the retro idea. After a run, write down what the agent got wrong and why. Feed it back. Not as formal process — as a file.
From GSD: the energy. Don’t over-specify. Trust the model to fill in reasonable gaps. Give it direction, not instructions.
What I Dropped
Everything else.
No roles. No estimation phase. No sprint planning. No party mode.
The overhead BMAD carries is real overhead — and it’s worth it at the scale it was designed for. At my scale, it’s just friction.
What I Built
Two phases. That’s it.
Develop. Review. Repeat until done or until review passes.
One agent reads the brief, does the work, emits a signal. Another reads the result, checks it against the brief, emits a different signal. Bash routes between them.
Not a methodology. A loop.