If you’ve been coding with AI seriously for the past six months, you’ve probably outgrown the “holy shit it wrote an entire file” phase. The novelty fades, and the real problems surface: AI-generated code that switches personality between sessions — today’s PR looks nothing like yesterday’s. Agents getting lost in their own context the moment requirements get slightly complex, undoing a bug fix you thought was settled two turns ago. And then there’s the classic hallucinated code — looks plausible, runs fine in isolation, detonates in production. The AI won’t tell you it doesn’t know. It’ll just confidently make something up.

Here’s the bottom line: the vibecoding era is over. That “just vibe it out with a few prompts” stage works for demos and side projects. The moment you’re dealing with a real, lived-in, multi-contributor codebase, vibes aren’t enough. You need discipline. And “discipline” is exactly what this wave of agentic coding frameworks is trying to solve.

Right now, five projects have emerged that qualify as frameworks rather than mere tools: Superpowers (Nous Research), BMAD Method, SpecKit (GitHub), OpenSpec, and GSD. Combined, they’ve pulled over 170,000 GitHub stars — but their approaches are so fundamentally different that picking the wrong one can waste weeks. Not because it’s hard to learn, but because it was never designed for your kind of project.

This article is my attempt to map the landscape as someone who actually uses these things day to day. Not a definitive review — more like notes from a fellow practitioner.

The Shared DNA: Agent, Workflow, Skill

Let’s get the common ground out of the way first. Despite looking nothing alike, all five frameworks rest on a three-part foundation: Agent (the doer), Workflow (the process controller), and Skill / Knowledge (the know-how).

The Agent is whatever actually touches files and runs commands — Claude Code, Codex, your own LLM pipeline. The Workflow governs when things happen: when to draft a spec, when to write code, when to run tests, when to pause for human review. These decisions aren’t made by the Agent; the framework enforces them. Skill, or Knowledge, is the “how” layer — project conventions, coding standards, tech stack constraints, lessons from past screw-ups. Without systematic management of this context, every new Agent session starts from zero, guessing.

Every framework has to tackle all three. The difference is which one dominates and how strictly each is enforced.

BMAD goes all-in on Workflow — absurdly so, simulating an entire dev team. SpecKit and OpenSpec focus on the “pre-work” phase of Workflow: writing specifications before code. GSD puts Knowledge and context management front and center, keeping Workflow relatively lightweight. Superpowers is, in my view, the most balanced across the three dimensions, but its killer feature is turning TDD into hard, non-negotiable discipline.

Let’s go through them one by one.

BMAD Method: The Heavyweight Team Simulator

BMAD is the heaviest of the bunch. Heavy to the point where it’s not just helping you write code — it’s trying to simulate an entire software development team.

The core idea is role-playing. Inside BMAD, you don’t talk to “an AI.” You talk to a Product Manager, an Architect, a Developer, and a QA engineer — each with distinct personalities, knowledge domains, and decision authority. The PM decomposes requirements. The Architect makes technical decisions. The Developer implements. QA validates. And critically, these roles challenge each other: the Architect can push back on unreasonable PM asks, QA can reject non-compliant code.

I get the motivation. Real software engineering isn’t a solo sport — quality emerges from friction between roles. BMAD tries to automate that friction so a single developer at their desk experiences the full ecosystem of “PM breathing down your neck, QA nitpicking your code.”

But the problems are obvious. First, it’s heavy. Configuring roles, defining permissions, setting interaction rules — the setup alone is a time commitment. For a small team or solo dev, that weight is a dealbreaker. Second, context transfer between roles is a massive pain point. The PM says something the Architect interprets differently. The Architect’s decisions don’t fully propagate to the Developer. QA tests something the PM never asked for. These are real problems in real teams, and BMAD hasn’t eliminated them — it’s just digitized them.

BMAD fits scenarios where you’re a large team with an already-mature development process and you want to codify that process into an AI workflow that runs on autopilot. If your goal is “I just want to ship something quickly by myself,” BMAD will mostly feel like it’s wasting your time.

SpecKit and OpenSpec: Institutionalizing “Write the Damn Docs First”

I’m grouping these two because they’re attacking the same problem: letting AI write code without a spec is like driving through a desert without a map.

SpecKit is GitHub’s official answer, and it’s very GitHub in its thinking — gate everything. You must write a spec first. The spec goes through review. Only then can you enter the implementation phase. Implementation must map one-to-one to spec items — no more, no less. The entire pipeline is gated: spec → review → plan → implement → verify, with explicit entry and exit criteria at every stage.

The upside is extreme determinism. You always know exactly where you are, and when something breaks, you can pinpoint which stage caused it. Because the spec exists as a stable artifact, even if you swap the AI model — or the developer — the output stays consistent as long as the spec doesn’t change.

But SpecKit’s weakness is also very GitHub: it’s built for greenfield. Starting from zero, spec-first-then-code is a smooth flow. But if you’re staring at a multi-year-old codebase with thousands of files and hundreds of thousands of lines, you can’t retroactively spec the entire thing. You can only spec the tiny piece you’re touching, but what about its coupling to everything else? SpecKit doesn’t have a great answer for that.

This is exactly where OpenSpec carves its niche. OpenSpec introduces the concept of delta specs — you don’t describe the whole system. You describe what’s changing this time. Specs are incremental, diff-bound, written against the existing codebase. This approach is dramatically friendlier to brownfield projects, which is to say, most real projects.

The SpecKit vs. OpenSpec debate is really an old question in a new coat: design-first vs. iterate-in-place. Neither is universally superior, but if you’re working on a real legacy codebase, OpenSpec is far more practical. Flip side: if you’re building something brand new, SpecKit’s rigor will save you from yourself.

GSD (Get Stuff Done): Context Management Is the Real Bottleneck

GSD — short for Get “Stuff” Done — has a deliberately casual name, but the problem it tackles is anything but. It focuses on something severely underestimated in AI-assisted coding: context rot.

What’s context rot? You ask the AI to change a feature. It starts strong — understands the requirements, finds the right files, even matches the code style. But as the conversation continues and you ask for a second change, then a third, performance degrades. The AI’s internal context has been polluted by earlier turns: stale assumptions linger, new information contradicts old, the file state in its mental model diverges from reality.

GSD solves this with something called wave parallelism. It decomposes a large task into independent waves, each with its own isolated context window. Wave A touches the user module. Wave B touches payments. They run in parallel, never contaminating each other’s context. Once all waves complete, results merge.

The elegance here is that GSD doesn’t try to make the AI smarter — it changes how we use the AI. Context rot isn’t a bug in the model; it’s an inherent property of long-conversation LLMs. GSD accepts that constraint and architects around it.

GSD also deserves credit for its multi-agent orchestration. Unlike BMAD’s role-playing dynamic, GSD’s agents operate more like a task distribution system — a Controller Agent splits the work, Worker Agents execute, results aggregate back. It’s closer to MapReduce, and it’s extremely effective for batch modifications across large codebases.

The downsides: a real learning curve and an immature ecosystem. Concepts like waves, context isolation, and orchestration take time to internalize. It also lacks the official backing SpecKit enjoys from GitHub — the community and documentation are still early-stage. If you’re willing to invest the time, the payoff is real. If you want something that “just works” out of the box, GSD might frustrate you.

Superpowers: Anchoring on TDD, Baking Discipline into the Pipeline

Full disclosure: I know Superpowers better than the others because I use it daily.

Its central insight is simple and deep: AI’s biggest problem isn’t intelligence — it’s reliability. And the most battle-tested weapon against unreliability in software engineering is Test-Driven Development.

Superpowers elevates TDD from “recommended practice” to mandatory workflow. Its pipeline runs brainstorming → design → plan → implement, and at the implement stage, every single step must follow RED (write a failing test) → GREEN (make it pass) → REFACTOR. This cycle isn’t a suggestion — it’s a framework-level hard constraint.

What does this get you? The AI’s hallucinations can’t fool you. You don’t judge whether generated code works by squinting at it — you judge by whether the tests pass. A red test means the job isn’t done. In a long-running project, this determinism is a massive psychological relief: no matter how much the AI flails around, as long as the test suite stays green, the system isn’t broken.

Beyond the TDD killer feature, Superpowers has other smart design choices. Its Skills system is a reusable knowledge base — project conventions, tech constraints, lessons learned get packaged as skills that auto-load into every new session. Its Memory system persists cross-session context, solving the “every new conversation, re-explain the entire project” pain. And its four-stage brainstorming → design → plan → implement flow strikes a solid balance between “think before you act” and “stop overthinking and ship.”

The trade-off is clear: Superpowers asks you to accept a relatively fixed workflow. If your style is “fire off prompts, iterate on the fly, figure it out as you go,” Superpowers will feel restrictive. It’s built for developers who already buy into TDD and are willing to invest in writing tests. If you think tests are a waste of time, the entire value proposition doesn’t hold.

Also worth noting: Superpowers currently lives in its CLI and session management — IDE integration isn’t deep yet. If you’re used to doing everything inside VS Code, the terminal-switching overhead is non-trivial.

Head-to-Head: A Decision Matrix

Putting them side by side, the positioning is actually pretty clear:

Solo dev, want reliable output: Superpowers’ TDD pipeline is the most direct guarantee. You don’t need a simulated team — you need code that doesn’t blow up.

Large team with mature processes: BMAD can automate your existing workflows, provided you can stomach the weight.

Brand-new project, documentation matters: SpecKit’s gated spec process ensures requirements-to-implementation traceability and makes onboarding easy.

Legacy project, incremental changes: OpenSpec’s delta specs are infinitely more practical than full-spec approaches.

Context management is your bottleneck, project is large and complex: GSD’s wave parallelism is the most elegant context isolation strategy I’ve seen.

And critically: these frameworks are not mutually exclusive.

The Case for Mixing and Matching

Honestly, going all-in on a single framework is probably not optimal. In my own workflow, Superpowers’ brainstorming → design → plan flow is excellent for front-loading clarity, but when it comes to spec writing, I lean toward OpenSpec’s delta style — not because full specs are bad, but because in a real project, the changes you make are always local, and the ROI on a full spec just isn’t there.

If you’re using GSD for context management, there’s nothing stopping you from running Superpowers’ TDD cycle inside each wave for quality control. BMAD’s role-playing can be injected into Superpowers’ design phase — let the AI critique a design from multiple role perspectives before a single line of code gets written.

This isn’t an either-or choice. It’s more like building with LEGO — each framework addresses a specific layer of the problem. You compose them to fit your context.

Closing Thoughts

This wave of AI coding frameworks is, at its core, a collective reckoning with vibecoding. Everyone has come to the same realization: getting AI to write working code is easy. Getting AI to write code that is consistently, reliably, predictably working — that’s hard. And “consistent, reliable, predictable” are the three words software engineering as a discipline has spent decades trying to achieve.

Each framework answers from a different angle: BMAD says you need team process. SpecKit says you need specification documents. GSD says you need to manage context. Superpowers says you need tests.

None of these answers is perfect, but every single one is a massive step forward from “vibe it out with prompts.”

For me personally, the current setup is Superpowers + OpenSpec-style specs + selective adoption of GSD’s context isolation thinking. It’s still a work in progress, but broadly speaking, it’s the first time I’ve felt like I’m no longer wrestling an unreliable AI — there’s a system helping me manage it.

And that’s enough.