An AWS team completed an 18-month rearchitecture project in 76 days. Six engineers, where 30 had originally been scoped. The tool: Kiro IDE, built around a methodology called spec-driven development. That number isn’t a fluke — it’s showing up across EY, Amazon’s product lines, and the Kiro team itself. The question worth asking is why, and whether the approach scales.
What spec-driven development actually is
The premise is simple: before an AI agent writes a single line of code, the team produces a structured specification the agent can execute against. Not a prompt. Not a ticket. A spec.
Kiro’s workflow structures this as three documents: requirements.md written in EARS notation (Easy Approach to Requirements Syntax, originally from Rolls-Royce aerospace engineering), design.md with architecture decisions and diagrams, and tasks.md with discrete, trackable implementation steps. The agent only touches code after a human approves the spec. The result is that errors surface at the specification stage — when they cost minutes to fix — rather than during code review or production, where they cost days.
The numbers behind the discipline
The AWS 76-day case is the headline, but the supporting data is more interesting. EY’s implementation started with 15–60% efficiency gains in the early adoption phase and scaled to 4x–5x for fully deployed teams. The differentiator wasn’t the model — it was what EY called the “context universe”: agents connected to internal code repositories, engineering standards, and compliance frameworks. Without that structured context, agents produced syntactically valid code that failed against internal requirements.
This aligns with the risk data. A CloudBees survey of 200+ enterprise technology leaders found that 81% reported production failures tied to AI-generated code. Unstructured agentic coding at scale has a reliability problem — and spec-driven development is the direct response to it.
The delegation gap — why most AI coding pilots underperform
Anthropic’s 2026 Agentic Coding Trends Report names this clearly: developers now use AI in roughly 60% of their work, but only 0–20% of tasks are fully delegatable. The report calls this the “delegation gap.” The spec-driven approach closes part of that gap by converting vague intent into agent-executable instructions — turning delegation from a gamble into a repeatable process.
The same report notes that 27% of AI-assisted work today consists of tasks that wouldn’t have been attempted at all without AI — previously uneconomical projects like internal dashboards, exploratory bug fixes, and one-off integrations. Specs make these tractable: the agent knows what “done” looks like before it starts.
The contrarian view — and why it’s only half right
A prominent Hacker News thread titled “Spec-Driven Development: The Waterfall Strikes Back” makes the obvious objection: this is Big Design Up Front repackaged. The criticism has teeth. Waterfall failed for exactly the reason critics identify — misspecified requirements are expensive to correct when code is already written.
The counter-argument is structural, not rhetorical. The feedback loop has collapsed. An agent can regenerate code from an updated spec in 5–15 minutes. Iterative spec correction is viable in ways that 1980s Waterfall never was. The failure mode shifts from “we wrote the wrong code for three months” to “we wrote the wrong spec for three days” — a meaningful improvement, though not a solved problem.
Where the industry is going
AWS, OpenAI, Apple, and GitHub are all shipping tooling that treats structured specifications as a first-class artifact. Kiro IDE is the clearest expression of the approach, but OpenAI’s Codex agent, Apple’s Xcode 26.3 integration, and GitHub’s enterprise offerings all operate on the same premise: agents need structured context to produce reliable output at scale.
VentureBeat’s framing is blunt: “Vibe coding is dead.” A Claude Code multi-agent swarm recently built 50+ React components, a mock API for three enterprise integrations, and a full admin interface in 6 hours — work estimated at 18 developer-days manually. That’s not a demo. That’s a new baseline.
Conclusion
The 76-day AWS project is memorable, but the more durable takeaway is structural: the teams producing those results aren’t using better models than everyone else — they’re investing in the specification layer that gives agents the context to work reliably. Spec-driven development is the discipline that separates AI coding as a productivity experiment from AI coding as engineering infrastructure. If your organization is still treating specs as optional overhead, it’s worth revisiting that assumption before the next project kicks off.