From Vibe Coding to Spec-Driven Development with Kiro IDE from AWS
A recap of the AWS Egypt Meetup held online on Tuesday, June 30, 2026 (8:30–9:30 PM GMT+3, via Google Meet). The live session was delivered in Arabic for the AWS Egypt community; this write-up adapts it into English for swac.blog.
I recently hosted an online AWS Egypt Meetup titled “From Vibe Coding to Agentic Engineering with Kiro | SDD”. Like my earlier AWS meetup recap on building a serverless web app, this post turns the live session into something you can read at your own pace. In it, I explain what spec-driven development actually is, how AWS’s Kiro IDE implements it, and walk through the customer-service MCP server we sketched live, compared against a fuller build of the same idea done outside Kiro.
I. Why vibe coding was the wrong tool for this session
Most AI coding demos still follow the same loop: prompt, look at what came out, prompt again. That’s fine for a throwaway script. It falls apart the moment you need the AI to hold a whole system in its head: a data model, five API resources, and the contract between them.
The session’s premise, for a free one-hour online meetup hosted over Google Meet, was to show the alternative: spec-driven development (SDD). You write down what you’re building and how before asking an agent to write code, using AWS’s Kiro as the concrete example, and the open Model Context Protocol (MCP), created by Anthropic, as something worth building with that spec.
II. What is spec-driven development, in plain terms?
IBM’s definition of spec-driven development is a good anchor: it’s a methodology where a detailed specification of what to build is authored and agreed upon before development starts, so the spec becomes the single source of truth for both humans and AI agents working on the codebase.
IBM’s write-up frames it as a spectrum, not one fixed practice:
- Spec-first: write the spec once for initial clarity, then let it go stale as the code evolves. Good enough for small, short-lived features.
- Spec-anchored: the spec evolves with the code, usually enforced by tests in CI/CD. This is the sweet spot for most teams.
- Spec-as-source: the spec is the source of truth, and changes to it regenerate the code directly. High-trust, high-automation, not for the faint of heart.
There’s also a trap worth naming: over-engineering the spec itself. If you’re still debating a JSON field name three weeks in, the spec has stopped saving you time and started costing it. The rule of thumb from the session: the cost of refining a spec should always stay lower than the cost of fixing a misunderstanding downstream. The moment that flips, stop polishing and start building.
A tidy one-line summary that came up in the prep material: AI engineering ≈ spec coding + guardrails. The spec gives the agent unambiguous intent; the guardrails (tests, review gates, linting) keep it honest.
III. Kiro: AWS’s take on spec-driven development
Kiro is AWS’s agentic IDE, built on Code OSS, the same open-source base as VS Code, with the spec workflow baked into the product rather than bolted on as a prompting technique. When you start a feature, Kiro produces three documents in sequence, and (this is the structural part) it won’t generate implementation code until you’ve reviewed the first two:
requirements.md(think of it as a PRD): functional and non-functional requirements, written in structured, testable language (Kiro uses the EARS notation for acceptance criteria).design.md(a SPEC): the architecture, including layers, data model, API surface and error handling.tasks.md(a PLAN): the sequenced, trackable implementation steps the agent will actually execute.
Getting started: Kiro IDE and Kiro CLI
Installation is straightforward: grab the installer for your OS from kiro.dev/downloads, sign in (an AWS Builder ID works), and you can import your existing VS Code settings and extensions on first launch. A few things worth knowing if you’re evaluating it:
- Inside the IDE you explicitly toggle between “Vibe” and “Spec” modes. Kiro doesn’t force spec-driven development on every keystroke; it’s a mode you opt into for anything that deserves the structure.
- You can pick a specific model or leave it on Auto. Each model has its own credit multiplier, and the open-weight models cost noticeably less per request.
- Kiro CLI exists alongside the IDE, with slash commands in the same spirit as Claude Code, Codex CLI or GitHub Copilot CLI, so the spec workflow isn’t locked to one editor.
- Pricing has moved fast. At launch Kiro shipped with 3 pricing tiers; as of June 2026 that had grown to 5. Check kiro.dev/pricing directly, since this is exactly the kind of detail that goes stale quickly.
If you want more background than fits here, IBM’s article above and Birgitta Böckeler’s comparison of Kiro, spec-kit and Tessl on martinfowler.com were the two references the session leaned on most.
IV. The live build: a customer-service MCP server
Within that one-hour window, the demo picked a deliberately small, realistic target, split into two sprints:
- Sprint 1: a Node.js REST API over a SQLite customer-service database (~100 customers, their purchases, payments and support interaction history), fully documented with Swagger/OpenAPI and testable from Postman.
- Sprint 2: wrap that same service layer as an MCP server, so a client like Claude Desktop can ask natural-language questions such as “who’s the customer with the most support issues?” and get answers grounded in the real database instead of a guess.
(If you’re wondering why SQLite and not a managed database, it was purely to keep the demo self-contained. For production workloads on AWS, my post on choosing between DynamoDB and RDS covers that decision.)
The initial prompt handed to Kiro, almost verbatim from the prep notes, asked it to act as a senior software architect and follow a structured process: understand the PRD, produce an implementation plan, produce a technical spec, and stop before writing any code until that spec was reviewed. That last constraint is the whole point of spec-driven development: it’s a deliberate checkpoint, not an accident of how the tool happens to work.
V. The same idea, built two ways
The live Kiro session sketched the plan; it didn’t ship a finished server in the room. For comparison, here’s the architecture of a fuller implementation of the identical idea, built separately (with Cursor and a dual-LLM coder/reviewer workflow, not Kiro). It’s a useful reference for what “done” looks like for this exact spec:
The two entry points, the REST API and the MCP server, sit on top of the same service and repository layers, talking to one better-sqlite3 database. That’s the same principle Kiro’s design.md step is meant to force you to write down explicitly: one data/service layer, multiple thin transports on top. If layered design like this is new to you, my system design elements series is a good companion read.
The MCP server exposes five tools, all backed by that shared service layer:
| Tool | What it answers |
|---|---|
get_top_customers |
Highest spenders (or most active, or most support issues), ranked |
get_customer_summary |
Full profile for one customer: orders, payments, interaction history |
get_customer_issues |
Support tickets/issues tied to a customer |
search_interactions |
Free-text search across support interaction logs |
get_revenue_stats |
Aggregate revenue metrics across the dataset |
In practice, that’s enough for Claude Desktop to render a bar chart of top spenders or reason through “who had the highest number of orders and why” using the live SQLite data. It’s the same kind of question a support lead would ask a BI dashboard, except it’s a five-minute MCP server instead of a reporting project.
VI. Kiro vs. “assemble it yourself”: the honest comparison
Both approaches produce the same three-artifact shape (requirements → design → tasks), but where that shape lives differs:
- Kiro enforces the sequence structurally, inside one IDE, gated so code can’t get ahead of the spec.
- The dual-LLM workflow (Cursor as coder, a second model as reviewer) achieves a similar discipline through process and rules files, not IDE-level gating. It takes more setup, but it’s tool-agnostic and easier to bend to a house style.
Neither is “the” right answer. Kiro is the faster on-ramp if you want the discipline enforced for you. The manual workflow is the better fit if you already have review standards you don’t want to give up.
VII. Key takeaways on spec-driven development
- Spec-driven development isn’t a Kiro-specific idea. It’s a philosophical cousin of TDD and BDD, asking “have we defined what we’re building?” before “does the code pass a test?”
- The over-engineering trap is real: match your spec’s weight to the feature’s actual risk, not to how thorough a spec could theoretically be.
- MCP is a genuinely good fit for exactly this kind of internal-tool problem: wrap a service layer you already trust, expose a handful of well-named tools, and let a chat client do the querying. Pair it with a vector store (see my OpenSearch k-NN vs. Aurora pgvector comparison) when you need semantic search over unstructured data too.
Final thought: vibe coding is still great for exploring. But once an AI agent is writing code you’ll have to maintain, a short, reviewed spec is the cheapest insurance you can buy. Try Spec mode in Kiro on your next small feature and see how much rework it saves you.
