Taming vibe coding: Our takeaways from spec-driven development

More code, same bottleneck

AI made generating code dramatically cheaper. It did not make reviewing, securing or maintaining that code any cheaper. Teams produce far more of it, and every line still passes the same human checkpoints. The research keeps showing the same result: More output, larger changes, slower reviews and timelines that barely move. Individual developers genuinely feel faster, yet the organization often is not. 

There are two ways of looking at this — and they lead to very different investments.

The first says code generation will be messy, so you have to build a better inspection line: AI reviewers that read every pull request before a human does, scanners built for the ways machine-written code breaks and a record of which lines an agent wrote. It is quality control at the end of the line: Fast to adopt, no change to how anyone works and solid evidence for the auditors and the board. But it only catches problems after the code exists, and does nothing to reduce how much code shows up for review. The more the AI writes, the bigger that inspection line has to get.

The second says the real problem lies earlier: AI produces confident, plausible yet wrong code because nobody tells it precisely what right looks like. Now, spec-driven development actually inverts the usual order of work. The spec is the artifact you write and maintain, and the code is generated from it. What really changes is where the argument happens: Teams settle what the system should do in writing before an agent starts producing, instead of discovering it in review.

The two views are not rivals; most teams actually run both. But only one really changes the calculus, which is why we started there.

What we tested, and why

Our job is to make development against commercetools both fast and good, and we had a platform-specific worry. A general-purpose agent knows a great deal about software, butvery little about commercetools. When it hits the edge of what it knows, it does not stop. It can produce an API call that looks exactly like a commercetools API call, follows all the right naming conventions — yet it does not exist. That code is expensive in a very specific way: it is confident, reads as correct in review and fails later.

So we built the commercetools spec-driven skill. It plugs our platform knowledge into whichever spec framework a team already uses: Any step touching commercetools loads the right expertise first, and every API call is verified against real documentation. It’s deliberately framework-agnostic, so anyone can choose which methodology to adopt.

We took three spec-driven frameworks, integrated our commercetools coding skills into each, and ran a real implementation through all of them: 

• Spec Kit, GitHub’s agent-agnostic toolkit.
• OpenSpec, with repo-resident living specs.
• BMAD, a fuller methodology built on AI personas. 

Then we compared cost, onboarding, code and how reliably our best practices reach the model. Here’s what we found. 

Finding #1: Running costs can vary widely 

OpenSpec is in a class of its own: It loads instructions only when they are needed, rather than carrying everything all the time. Both Spec Kit and BMAD carry higher — yet predictable — costs, while offering deep process customization. 

They also guide you through the entire workflow, transforming the user story into specifications, mapping those specs to design and ultimately breaking them down into actionable tasks. BMAD also depends on how much of its process you switch on, and but carries overhead either way. Token consumption is effectively a monthly cost per developer, so this is an important budget line to keep an eye on.

Finding #2: Onboarding is where BMAD loses badly 

Onboarding is where BMAD loses, and not narrowly. Spec Kit installs in one command and follows a single numbered sequence. BMAD adds dozens of tools, a cast of AI personas and a second toolchain, and it has reorganized itself twice in one version. 

When you are training a partner network, that matters. It is worth noting that OpenSpec has the leanest path, but with a small team, the difference in the onboarding effort is small. When the team scales and onboarding needs grow, then it starts to matter.  

Finding #3: The code itself remains roughly the same 

The code itself remains roughly the same: The same model writes it in every case, and the framework does not necessarily make it smarter. 

What differs is how reliably our best practices reach it:

• OpenSpec follows them automatically and cannot skip them. 
• BMAD carries them the furthest but relies on a single handoff step. 
• Spec Kit only asks the agent to consult them, the weakest of the three, and where specs quietly drift from what was built. 

So you are not evaluating code quality here, but whether your domain knowledge is guaranteed to arrive, is suggested to arrive, or is somewhere in between.

What to remember, and where to go from here

Two decisions come out of this. 

The first is which approach to bet on. Checking code after it’s written is easy to buy and it catches real problems, but you still have to review everything. Getting the requirements right first is harder to introduce, but it pays off because there is less to review.

The second is which framework to run it in. We would look to OpenSpec because it enforces domain usage on every call and keeps token consumption low. Additionally, we are monitoring how often Spec Kit ignores our guidance, and if it skips too much, OpenSpec automatically applies our best practices and costs less to run. BMAD only makes sense for teams that want its heavier and deeper review process.

Yet both decisions also come down to one other question: Does the AI actually know your platform before it writes code? And that’s exactly what our spec-driven skill addresses: It gives the agent verified platform knowledge up front, in whichever framework you use. 

Explore our other available skills, guides and tools in our commercetools for Builders library — and stay tuned for more!