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. 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.
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 — 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 and the project repository.