The prevailing question in AI-assisted development—"Which methodology should I use?"—is fundamentally flawed.
Superpowers, BMAD, Compound Engineering, OpenSpec, SpecKit, GSD, Ralph. The ecosystem is flooded with systems claiming to run your AI agents. The thesis here is simple: There is no universal winner. Each framework orchestrates a distinct layer of agentic development.
Stop searching for a silver bullet. Build a stack.
1. Execution vs. Intent: Superpowers vs. BMAD
The most critical comparison dictates your starting vector.
- Superpowers (Pure Engineering): Operates as a demanding senior engineer. It enforces design, planning, strict test-driven development, and rigorous review. Default to this for daily coding, solo development, and pure implementation tasks.
- BMAD (Product Intent): Operates as a complete product organization—analysts, PMs, architects, and readiness gates. Deploy this when product intent remains uncertain or stakeholder complexity is high.
2. Context Retention: OpenSpec vs. SpecKit
Both frameworks combat context drift by anchoring requirements in versioned files.
- OpenSpec: Optimized for change and brownfield execution. It is the durable change contract for everyday work on real, existing production codebases.
- SpecKit: Optimized for governance. It dictates a constitution, traceability, and audit trails. Reserve for heavily regulated environments.
3. The Autonomy Layer: GSD vs. Ralph
Tread carefully here.
- GSD: Designed to safeguard structured projects across context windows via requirements, roadmaps, and verification. (Note: The original repository was archived in June 2026. Use only for long unattended runs once a stable fork emerges.)
- Ralph: A continuous loop (pick an item, implement a test, repeat). Warning: Without impenetrable tests, Ralph will happily burn tokens iterating on bad decisions.
4. The Meta-Layer: Compound Engineering
Compound Engineering shifts the focus from "How do we build this correctly?" to "How does this work make the next task frictionless?" Every feature delivery concludes by recording lessons for agents to reuse. If your role leans closer to founder than individual contributor, this is your core methodology.
The Winning Synthesis
Do not install everything. Orchestrate the right sequence based on the situation:
- BMAD to define requirements when product intent is ambiguous.
- OpenSpec to establish a durable change contract in the codebase.
- Superpowers to drive implementation and rigorous verification.
- Compound Engineering to extract and record lessons post-delivery.
I personally would start with BMAD as a higher level harness, and combine it with OpenSpec to drive quality of implementation to the desired level.
Top comments (1)
Layering distinct harnesses for intent, specification, and implementation solves the immediate failure mode of asking a single prompt to do architectural scoping and syntax generation simultaneously.
The fragile assumption across multi-agent pipelines is that downstream verification catches upstream drift without compounding the error budget. When an execution agent like Superpowers generates its own unit tests to validate code it wrote against an OpenSpec contract, both the test assertions and the implementation share the same model priors. If the agent misinterprets an edge case in the specification, it writes a green test that codifies the misinterpretation into the test suite.
The operational bottleneck is verification asymmetry. Generating a four-layer agent stack is cheap in tokens, but debugging a silent logic drift that passed three layers of automated green tests requires human engineers to reconstruct the agent's implicit assumptions. Unless the test harness uses invariants defined strictly outside the agent context, stacking more layers simply increases the speed at which unhedged assumptions get committed to the repository.