Highlights
This blog outlines all the methodologies that an ISV can leverage to build products leveraging the AI curve. As a CTO, what choices do you have: is it vibe-coding, SDD, BMAD, or GSD? How important are these choices? Let’s answer some of these questions here.
Over the last few months, at least five separate teams, working independently, with no shared roadmap and no coordinating body – each built the same fundamental fix for AI development and gave it a different name.
I anticipate the pushback. AIDLC, BMAD, GSD, Superpowers, and GSTACK are not identical. Each addresses a distinct set of problems, makes different architectural choices, and draws from different influences. That distinction is real and worth respecting.
But strip away the branding, and they are all responding to the same underlying observation: AI agents are impressive for the first thirty minutes, and then quality degrades, consistently and predictably, unless something imposes discipline on the process.
Five teams. Different codebases. Different organizations. The same conclusion.
That is not a coincidence. It is a signal. And if you are a CTO or building toward that role, it is a signal worth paying close attention to.
What ‘Vibe coding’ is and why it works till it doesn’t
Vibe coding (ugh, that term) – it is real and a practical term.
Vibe coding means: Prompt; AI assisted code generation; output review, run, evaluate; modify the prompt; Repeat. – There are no written specifications.
Success is “looks right and runs okay on my computer.” AI here is freelancing on vibes, and so are you.
There is no question that ad hoc prompting is fast. For prototypes, internal tools, and throwaway scripts, it is often entirely sufficient.
The problem surfaces the moment the context window fills up; the output requires formal validation, or more than one person needs to collaborate on building the system. What felt like velocity in the first session becomes a liability by the third. The absence of structure, which made it feel agile at the start, is precisely what makes it fragile on a scale. Some terms you need to consider before you start out:
- Context rot: It refers to the severe degradation of an AI’s accuracy, instruction-following ability, and recall as its context window fills up. Behaves like a standard “U shaped” curve.
- Output Validation: The nondeterministic nature of LLM can return unexpected output, thus impacting reliability, security, and safety.
- Multi persona: It refers to the various stakeholders including Product Owner, Architect, Engineering Manager, Developers, Testers. Each of these roles needs to be captured in the dev life cycle.
There is a widely cited benchmark 2026 study that found that the same underlying model, wrapped in different orchestration approaches produced a 21% performance spread on SWE bench Verified (a standard coding benchmark). Same brain, different scaffolding, wildly different reliability. This single data point should reframe how any technical leader thinks about ‘which AI coding tool is the best’. The model matters less than you think. The structure around it matters more.
Maturity Spectrum: What are the levels of AI-native development maturity?
Every team using AI to build software tends to move through three recognizable stages, regardless of whether they are working with Claude Code, GitHub Copilot, or a custom-built agent.
Stage 0: Ad hoc Prompting: This is where every team starts, which is why I call it Stage 0 rather than Stage 1. There are no written specifications. Success exists entirely in the developer’s head. No one has stopped to ask the most important question in software development, what do you want here?
The output feels fast, until a second person touches it. Or a second session. The moment the context shifts, a new developer, a new conversation, a new sprint, the whole thing starts to unravel. It is the natural starting point, but it is not a place to stay.
Stage 1: Spec-driven development: Write the requirements down before AI starts building it. In my experience, through a significant number of client engagements, this single change fixes a surprising number of problems. The AI now has a blueprint. It has something concrete to build toward, and critically there is a document to reference when the output diverges from the intention – Output Validation.
But there is a limitation I have come to recognize in this stage. In its early form, the spec is a one-way handoff. Humans write, AI executes, and any gap between what was meant and what was written only surfaces at review time. It is substantially better than ad hoc prompting, but it remains fragile.
Governance helps. We have built a code-to-production framework specifically to address the pattern where a proof of concept performs as expected, and production tells a very different story. I will write about that separately.
We know you wish to see cut defects, accelerated time-to-market, and maintenance of enterprise governance, while rework costs drop by 20–40%. We’ve captured these dynamics and the technology required for it, in our factsheet.
Stage 2: Verifiable specs: I use the term ‘verifiable specifications’ because no single established name yet captures what this stage represents. What is interesting is how several open-source and enterprise methodologies converged on the same idea from different directions, viz. AIDLC, BMAD, and GSD, and more recently frameworks like Superpowers, Musabi, and GSTACK, all arriving at similar conclusions through different paths.
At this stage, the specification is built collaboratively with AI and refined until ambiguity is genuinely eliminated. Requirements are broken down into criteria a machine can check. Vague instructions (“make it fast”) become “P95 latency under 200ms”. “Handle errors gracefully” become a specific, testable list of failure modes and expected system behavior for each one.
The specification stops being a handoff document and becomes a contract, one that both the human and the AI can be held to.
Fig: AI Delivery Maturity
The common thread across all of them is specialized roles instead of one agent doing everything, achieving a state that survives a session ending instead of just living in the chat history, and quality gates that block progress categorically instead of relying on AI to remember to test its own work.
Some of these methodologies come with a significant token cost and by extension, a significant budget conversation. That is a reality worth acknowledging upfront. However, higher consumption does not automatically mean poor return. When applied to the right use case, the quality of output and the reduction in rework can more than justify the investment. The ROI case is real. It simply requires the right framing and the right measurement framework to make it visible.
The Field Guide: What are AIDLC, BMAD, GSD, and How are they different?
- AIDLC or AI-driven Development Lifecycle acts as a structured gated approach with adaptive workflows to steer AI coding agents.
- BMAD or Breakthrough Method for Agile Development is an open-source AI native framework that orchestrates a series of tasks for agents, each with a committed role to perform.
- GSD or “Get sh–t done” (on a lighter note) is a structured approach to software development and breaks complex tasks into plan, execute, and review modes. It replaces complex apps with simple daily workflows.
Here is what happens under the hood of each one.
| Stage | Name | Full name / origin | Core mechanic | How it survives a long session |
|---|---|---|---|---|
| Baseline | Vibe Coding | No formal framework, an informal industry term | Prompt, glance, run; reprompt if it’s wrong. No written spec, no defined roles, no gate | It doesn’t. Quality degrades silently as the context window fills, and nothing in the process is built to notice |
| Principle | SDD | Spec-Driven Development, a general practice, formalized in tools like GitHub’s Spec Kit | Write the specification before implementation starts; the spec becomes the source of truth the AI builds against | Depends entirely on the implementation. SDD is a principle, not a runtime. This is the gap AI-DLC, BMAD, and GSD each built their own answer to. |
| Implementation | AI-DLC | AI-Driven Development Lifecycle — The Bushido Collective | “Hats”, fresh specialist agents (Planner, Builder, Reviewer, Red Team, Blue Team, and others) spawned per unit of work, each restricted by a markdown file to one role | A “bolt”: each session saves state to disk before the context window runs out; the next session reloads it and resumes exactly where it stopped |
| Implementation | BMAD-METHOD | Breakthrough Method for Agile AI-Driven Development, BMAD Code, LLC | Maps the workflow onto agile roles most orgs already know: Analyst, PM, Architect, PO, Scrum Master, Developer, QA; each a separate persona file | Large specs get “sharded” into small, self-contained story files with context baked in, so no single agent holds more than one story’s worth |
| Implementation | GSD | Get Shit Done, or Get Stuff Done, created by Lex Christopherson (“TÂCHES”) | A thin orchestrator per phase (discuss, plan, execute, verify) that dispatches to specialized subagents instead of doing the work itself | Each subagent gets a fresh ~200K-token window built from saved project files; the main orchestrator reportedly stays around 10-15% context usage for hours |
Some specifications to consider before we move on:
1. AIDLC enforces three hard checkpoints:
- A plan gate: No building without a blueprint
- A quality gate: Tests, build, and lint run automatically on every stop
- A criteria gate: Nothing ships without evidence against the original spec.
- There is also a rachet rule where you could add gates mind-build but can never remove.
2. BMAD has grown well since mid-2026. A recent addition, it has over 12 specialized personas available across its module system.
3. GSD, which started out in December 2025, has also seen a steady rise because of its single claim to fame; the finding that a single orchestrator holding an entire project context in one window is the root cause of quality drift, not a symptom.
What is already past GSD?
There are two frameworks today that have outgrown GSD and have taken the idea in different directions.
- One is Superpowers, built by Jesse Vincent and accepted into Anthropic’s official Claude Code plugin marketplace in Jan 2026. It enforces a mandatory seven-phase test-driven pipeline: brainstorm, spec, plan, TDD (test-driven development), subagent development, review, ship, and delete code written before a test exists rather than let the agent skip ahead.
- Second is GSTACK, built by Garry Tan, takes the opposite bet. Instead of enforcing how work gets done, it simulates an entire organization (CEO, engineer, QA lead, etc., so an agent has a clear role-based sign off before code ships not just the test suite.
All these three are increasingly at a complementary level with GSTACK deciding what should get built, GSD keeping the build from drifting, and Superpowers enforcing how it gets built.
Word of caution: Before you pilot any community framework, check who currently maintains it and how the package is distributed. GSD’s original maintainer went dark in April 2026, and the community had to fork and republish a clean version under separate governance.
The GATE Test: How To Evaluate an AI Coding Framework?
Here is a quick way to check when you want to evaluate an AI-native development methodology.
1. G: Grounded criteria:
- Pull up a spec from a real project and count how many success criteria have actual numbers attached. ‘Handle errors gracefully’ is a mission statement. “429s retry three times with exponential backoff, then dead-letter” is a criterion an AI or a human can verify without asking anyone what it meant.
- Red Flag: If most of the specs read like the first one then no amount of orchestration is going to fix that one
2. A: Agent Isolation:
- Ask directly. When a reviewer checks the work of a builder, is it genuinely a different agent with a different context window or is it the same session grading it three messages later?
- Red Flag: Your ‘hats’ don’t exist then. A reviewer who remembers writing the code it is reviewing isn’t a reviewer then.
3. T: Tollbooth enforcement:
- Does the agent get blocked from stopping until ‘npm test’, go vet’, or your equivalent gate commands pass? Or do you have a line in your prompt that says, “please remember to check this.”
- Red Flag: If it is the latter, then you know which one survives a bad day.
4. E: Evidence Trail:
- Can someone point to an artifact; could be an atomic commit or a signed-off gate log to prove specific requirements were met? Or was it a sheepish line like, “AI said it is done.”
- Red Flag: If your only record for the audit or incident review is going to be a chat transcript, then you don’t have an evidence trail, you have what I call a diary entry.
Score it honestly, whether you have a bar graph or a pie like this one; make the move. If your scores are low, then you just have vibe coding with a better logo, that’s all.
Fig: Trust Score Breakdown
What are the most common mistakes when adopting AI Development Methodologies?
Methodology failures are rarely caused by choosing the wrong tool. The cause is almost always simpler than that.
- The elaboration phase gets skipped under deadline pressure. A team adopts spec-driven development, then under time pressure writes a specification that is good enough to start but never rigorous enough to validate against. Discipline gets abandoned precisely when it matters most.
- Specifications are treated as a one-time artefact rather than a living document. Requirements shift mid-build, they always do. A specification that is not updated alongside them becomes a historical record that nobody trusts, and teams quietly revert to ad hoc prompting without ever formally deciding to do so.
- There is no clearly designated owner for the human review step. “Someone will catch it in review” is not a process. If the reviewer changes every sprint, there is no single person holding a consistent quality bar. Accountability that belongs to everyone effectively belongs to no one.
- More agents get confused with more rigor. Adding specialized agent roles only produces value when each agent operates with a genuinely distinct context and a genuinely distinct remit. Specialization only pays when each role knows something the others do not. A generalist agent wearing a specialist label is still a generalist.
- Model selection is driven by popularity rather than fit. A framework trending on social media tells you it is being adopted frequently, not that it is appropriate for your stack, your team size, or your delivery model. A methodology designed for a solo developer working on independent projects is solving a fundamentally different problem than one designed for a twelve-person team building a production-grade product, even if both are generating attention at the same moment.
The teams that navigate this well are rarely the ones with the most sophisticated agent architecture. They are the ones who ran their own process through a rigorous internal review, did not like what they found, and fixed it before the customer did.
You can write to me with your thoughts about the ideas in this blog.
Contact us at Nitor Infotech to learn more about what we achieve in the Agentic world.
