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.
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.
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.
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:
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, 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, 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:
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 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 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 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.
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 (original article) and canonically to dev.to only. If you are reading it elsewhere, then please let us know
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.