The Spec-First Workflow That's Replacing Vibe Coding

You asked the AI to fix a bug. It fixed it. Then three other things quietly stopped working — and nobody could explain why, because the "context" from that session was long gone.

That's not a glitch. That's the business model of vibe coding revealing itself.

In February 2026, Andrej Karpathy — the man who coined "vibe coding" — declared it passé on X. He said professionals had moved on to something he called agentic engineering: directing AI agents against detailed specifications, with a human in the oversight seat. Not vibing. Orchestrating.

That distinction has a name, a methodology, and already a 150% speed improvement on record at one of Japan's largest tech platforms.

It's called Specification-driven development. And the gap between teams using it and teams still prompting on instinct is getting harder to ignore.

What Spec-Driven Development Actually Is?

Most definitions say something like: "a methodology where specifications are written before code." True. Also useless without context.

Here's what that actually means in practice.

When you vibe code, the AI is working off your last message. That's its entire world. It doesn't know what you decided two sessions ago, what the other developer on your team built last week, or why you structured that auth flow the way you did. Every prompt is a fresh start in a conversation with no memory.

A specification changes this. It's a document — stored in your repo, versioned like code — that tells the agent: here's what we're building, here's how it connects to everything else, here are the constraints, here's what done looks like. The agent codes to the document, not to the vibe of your latest message.

The spec is the persistent memory AI doesn't have by default.

Think of it this way: vibe coding is like texting a contractor every morning with "just make it look nice." Spec driven development is handing them blueprints reviewed and signed off before they touch a single wall.

Why Vibe Coding Breaks (And Exactly When)

Vibe coding doesn't fail immediately. That's what makes it dangerous.

The first few weeks feel like a superpower. Features ship fast. The AI is helpful. Everyone's impressed. Then around month two or three, something shifts. Fixes start introducing new problems. Nobody can explain why a certain function was written the way it was. Two developers working on the same codebase have built completely different patterns for the same problem because they gave the AI completely different prompts.

Three things happen underneath the surface:

Context drift — the AI fixes what it can see. It can't see the rest of your system. A patch in one module silently breaks something two modules away, and no one catches it until it's in production.

Requirements drift — decisions made in one chat session evaporate when the session ends. There's no record, no reasoning, no anchor. The next agent you spin up starts from nothing.

Fragmentation — five developers + five AI tools + zero shared conventions = five different architectures living in the same codebase. The AI didn't cause this. The absence of a spec did.

GitClear's study of 211 million lines of code found that refactoring dropped from 25% of all changes in 2021 to under 10% by 2024 — while copy-pasted code rose 48% in the same period. For the first time, copy-pasting outpaced refactoring. That's what ungoverned AI velocity looks like, measured.

The Spectrum Nobody Explains Clearly

Spec driven development isn't one thing — it's a range. Most explanations skip this, which is why implementation feels harder than it should.

Spec-first — you write a spec before any code gets generated. Once the code exists, the spec might not be maintained. It was there to give initial clarity. Good for small, self-contained features.

Spec-anchored — the spec evolves alongside the code. Requirements change, the doc changes, and tests bridge the two. This is what most production teams actually need. It's the sweet spot between too loose and too rigid.

Spec-as-source — the spec is the source of truth. Code is a byproduct, entirely generated from the spec. Tools like Tessl operate at this level. Highest control, highest discipline required.

Most teams that try SDD and fail are trying to go straight to spec-as-source. Most teams that succeed start at spec-anchored and build the habit before raising the bar.

What a Spec Actually Contains

This is the part most articles skip entirely, and why teams stall when trying to implement.

A spec isn't a PRD. It's not a Notion doc with bullet points. In an SDD workflow, a spec file typically lives in your repo (often as structured markdown) and covers:

• What the feature does and what it explicitly doesn't do

• How it connects to existing systems and what it depends on

• Data models, API definitions, service boundaries

• Edge cases and how they're handled

• Acceptance criteria — how you'll know it's done

• Architectural constraints the AI must work within

The agent reads this. It codes to it. When something is unclear, the friction shows up in the spec review — not after three pull requests and a production incident.

When It Ran in Production: The Mercari Result

One of Asia's largest consumer marketplaces launched an internal initiative in mid-2025 with a single goal: double software development productivity by year-end.

By late 2025, 70% of their product code was already AI-generated. Delivery speed still wasn't moving. Different teams using different AI approaches were producing results nobody could replicate across the org. They named this internally: the divergence phase.

Their fix was ASDD (Agent Spec-Driven Development). Every AI coding agent received a structured spec covering API definitions, data models, test scenarios, and implementation steps. No freeform prompts. No open-ended chats.

Measured across 30+ internal backend projects:

• +150% speed gain over their traditional baseline

• +80% over teams using AI without a formal spec

That's not a productivity tool upgrade. That's what happens when you stop asking AI to guess and start giving it something to work from.

The Tools That Made This Real in 2026

The concept is solid. The tooling is now there to back it.

GitHub Spec Kit — open source, MIT licensed, 90,000+ GitHub stars as of May 2026. Supports 30+ AI agents including Claude Code, Cursor, Gemini CLI, and Codex CLI. Works across any IDE.

AWS Kiro — a full IDE built entirely around the SDD workflow. Strong for greenfield projects, especially teams on AWS infrastructure.

BMAD-METHOD — an open source framework that assigns AI agents different roles across requirements, design, and task phases. Good for teams that want a structured multi-agent orchestration layer.

When AWS builds a dedicated IDE around a methodology, the methodology has crossed from trend to infrastructure.

Vibe Coding vs. Spec Driven Development

The framing most senior engineers use now: vibe code to explore, spec before you ship. Not either/or — sequential.

The teams that win with AI in 2026 aren't the ones prompting the fastest. They're the ones who figured out that an AI agent given a map builds something completely different from an AI agent given a vibe.

If your team is generating code fast but starting to feel the architecture slipping — that's not an AI problem. That's a spec problem. Ambli AI specializes in product engineering and AI-enabled system architecture — helping teams build the structured foundations that make AI agents predictable, consistent, and production-ready. If you're done shipping on vibes and ready to build something that holds, let's talk.