--- title: "Spec-Driven Development: Why Vibe Coding Doesn't Ship" slug: "spec-driven-development-ai-coding-agents" author: "ibl.ai Engineering" date: "2026-09-07 20:00:00" category: "Premium" topics: "AI coding agents, spec-driven development, GitHub Spec Kit, software engineering, agent orchestration" summary: "GitHub's Spec Kit makes the specification the shared source of truth an AI agent executes against — spec, then plan, then small testable tasks. The reason it matters is that ambiguity is where coding agents fail, and a spec is where ambiguity surfaces cheaply." banner: "" thumbnail: "" linkedin: | Vibe coding was genuinely fun. It also does not survive contact with a codebase anyone else has to maintain. GitHub's Spec Kit is the counter-proposal: an MIT-licensed toolkit that makes the specification the shared source of truth an AI coding agent executes against. The workflow is Spec → Plan → Tasks → Implement, with 30+ agent integrations (Copilot, Claude Code, Codex, Gemini CLI, Cursor, Windsurf). Worth correcting one thing that circulates about it: it is not days old. GitHub open-sourced it in September 2025 — it has had a year to mature, which is rather more interesting than a launch. The reason the approach works is not discipline for its own sake. It is that ambiguity is where coding agents fail, and a spec is the cheapest place to find ambiguity. Give an agent an underspecified request and it will not stop and ask. It will pick an interpretation — silently, plausibly, and often reasonably — then build hundreds of lines on top of that choice. You discover the assumption at review, after the code exists, when changing it is expensive. Force the spec first and the same ambiguity surfaces as a question in a document, before any code depends on it. Same ambiguity. Two orders of magnitude difference in what it costs to resolve. It also fixes the review problem. Reviewing 800 lines of agent-generated code means reconstructing intent from implementation. Reviewing a spec and a plan means checking intent directly, then checking that the code matches it. The general principle applies well beyond coding: an agent's output quality is bounded by the precision of its instructions, and structured intermediate artifacts — a spec, a plan, an explicit task list — are how you raise that ceiling and get an audit trail for free. With ibl.ai you own all the code and the data — self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from your own cloud to a fully air-gapped network. #iblai #AICoding #SpecDrivenDevelopment #AgenticAI #SoftwareEngineering #DeveloperTools --- ## The Short Answer **GitHub's Spec Kit makes a specification the shared source of truth an AI coding agent executes against — spec, then plan, then small testable tasks. It works because ambiguity is where coding agents fail, and a spec surfaces ambiguity before any code depends on it. The same principle governs enterprise agents generally: structured intermediate artifacts raise output quality and produce an audit trail. With ibl.ai you own all the code and the data.** An agent given an underspecified request does not stop and ask. It picks an interpretation and builds on it. ## What is GitHub Spec Kit, and how new is it? It is an MIT-licensed open-source toolkit that packages templates, a CLI and prompts to center development on a specification first — then a technical plan, then a set of small, testable tasks an AI agent implements. The core workflow is **Spec → Plan → Tasks → Implement**, and the `specify` CLI carries 30+ agent integrations including Copilot, Claude Code, Codex, Gemini CLI, Cursor and Windsurf. **It is not new, and the widely-circulated framing that it exploded "in days" is wrong.** GitHub [open-sourced Spec Kit in September 2025](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/). The repository passed 130K stars by September 2026, and figures quoted in write-ups range from 80K upward depending on when they were written — which is itself the reason to treat any single number with caution — but the project has had about a year to mature, which is a more interesting fact than a launch would be. ## Why do AI coding agents fail on ambiguity rather than on difficulty? Because an agent resolves ambiguity silently, and a human would ask. Give an experienced engineer an underspecified ticket and they will come back with a question. Give the same ticket to a coding agent and it will select a plausible interpretation and proceed — often a reasonable one, always an unstated one. The choice is invisible because the output looks finished. The cost is in when you discover it. The assumption surfaces at code review, after hundreds of lines already depend on it, when correcting it means unwinding work rather than answering a question. **The failure is not that the agent was wrong; it is that the agent was decisive about something nobody had decided.** A spec-first workflow moves that moment earlier. The same ambiguity appears as an open question in a document, before any implementation depends on it. Identical ambiguity, radically different cost of resolution. ## What does a spec change about reviewing agent-written code? It changes review from reconstructing intent to checking it. Reviewing 800 lines of agent-generated code without a spec means inferring what the author meant to do from what the code does, then judging whether that was right. That is the hardest form of review, and it is why review throughput — not generation throughput — is the real constraint on how much AI-written code an organization can absorb. This is also why the 2025 release date matters more than a star count. A workflow that has been exercised across 30-plus agent integrations for roughly a year has had time to find where spec-first breaks down, which a toolkit launched last week has not. With a spec and a plan, review splits into two tractable questions: is the intent correct, and does the implementation match it. The first is a short document. The second is mechanical enough to be partly automated by tests derived from the spec. This is why spec-driven development is a throughput argument rather than a bureaucratic one. The bottleneck was never how fast code could be produced. ## Does spec-first apply to enterprise agents beyond coding? Yes, and the enterprise case is stronger, because the artifacts double as an audit trail. The general principle is that **an agent's output quality is bounded by the precision of its instructions**, and structured intermediate artifacts are how that ceiling gets raised. A support agent that restates the request and its plan before acting, a research agent that produces an outline before drafting, a financial agent that states which records it will read before reading them — each of those is the same move as a spec. In a regulated setting the intermediate artifact is also the evidence. An agent that acts directly leaves you with an outcome and a log. An agent that produces a plan, gets it approved and then executes leaves you with a record of intent, an approval, and an execution trace against it. That is the difference between explaining what a system did and demonstrating that it did what was authorized. It connects directly to orchestration as a distinct architectural layer — the difference between an agent that plans and one that improvises is exactly the difference discussed in [the five-layer agent stack](/blog/five-layer-agent-architecture-what-ships-is-layer-one). ## How does ibl.ai support spec-driven agent work? By keeping the runtime, the artifacts and the audit trail inside your own perimeter. With ibl.ai you own all the code and the data. The platform is deployed on your own infrastructure with full source code access, so plans, intermediate artifacts and execution traces are stored in systems you control rather than in a vendor's. Agent orchestration supports multi-step execution with approval points, every tool call is audited, and permissions are RBAC-scoped and enforced server-side. It is model-agnostic across any LLM — which matters for coding specifically, since the best coding model changes often and a spec-driven workflow makes swapping one comparatively painless: the spec is the durable artifact, and the model that implements it is not. Pricing is usage-based with no per-seat licensing, and deployment reaches your own cloud, on-premise, GovCloud, or a fully air-gapped network where source code cannot leave the boundary at all. ibl.ai is family-owned and operated from New York, NY. *Related reading: [when agents exceed their scope](/blog/ai-agents-exceeding-scope-containment-architecture) — why intermediate artifacts and audit trails matter most when something goes wrong.* *Source: Spec Kit's workflow, licence, agent integrations and original release from [the GitHub Blog](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) and [the project repository](https://github.com/github/spec-kit).* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.