# From Vibe Coding to Spec-Driven Development with Kiro IDE from AWS > Source: > Published: 2026-11-11 12:09:00+00:00 *A recap of the AWS Egypt Meetup held online on Tuesday, June 30, 2026 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. The session recording can be viewed [from here](https://youtu.be/bC12CpR-Hbk).* 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](https://swac.blog/power-up-your-website-a-serverless-frontend-and-backend-using-8-aws-services/), 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](https://kiro.dev/) 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. 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)](https://modelcontextprotocol.io/), [created by Anthropic](https://www.anthropic.com/news/model-context-protocol), as something worth building with that spec. [IBM's definition of spec-driven development](https://www.ibm.com/think/topics/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: 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. Kiro is AWS's agentic IDE, built on [Code OSS](https://github.com/microsoft/vscode), 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`` design.md``tasks.md` *Figure 1: The spec-driven development workflow in Kiro. Every artifact is reviewed before the next phase starts.* Installation is straightforward: grab the installer for your OS from [kiro.dev/downloads](https://kiro.dev/downloads/), sign in (an [AWS Builder ID](https://docs.aws.amazon.com/signin/latest/userguide/sign-in-aws_builder_id.html) 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: *Figure 2: Kiro's start screen. Spec mode plans first, then builds.* *Figure 3: The model picker and its credit multipliers (as of June 2026).* *Figure 4: Kiro CLI and its slash commands, including /plan, /model and /mcp.* 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](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) were the two references the session leaned on most. Within that one-hour window, the demo picked a deliberately small, realistic target, split into two sprints: (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](https://swac.blog/nosql-vs-sql-on-aws-choosing-between-dynamodb-and-rds-use-cases-pros-cons-2/) 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. *Figure 5: Kiro reads the PRD, then asks whether to start with requirements or technical design.* 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: *Figure 6: One service layer, two transports: a REST API for Postman/curl and an MCP server for Claude Desktop.* 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](https://github.com/WiseLibs/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](https://swac.blog/10-essential-system-design-elements-you-need-to-know-part-2/) 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. Both approaches produce the same three-artifact shape (requirements → design → tasks), but where that shape lives differs: 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. *Note that* All IP rights to this blog post are reserved. Since I have been facing several content piracy cases lately, this blog post has ONLY been published on [the Software, Architecture, and Cloud blog - SWAC.blog](https://swac.blog) ([original article](https://swac.blog/spec-driven-development-kiro-ide-from-aws-mcp-server/)) and canonically to [dev.to](https://dev.to/khalidelgazzar) only. If you are reading it elsewhere, then [please let us know](https://swac.blog/contact-us/) **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](https://kiro.dev/) on your next small feature and see how much rework it saves you.