From Zero to Spec-Driven: How I Taught AWS Kiro to Beginners
Discover how to introduce beginners to software engineering discipline using AWS Kiro. This two-part series breaks down spec-driven development, steering files, and agent hooks using a hands-on Python Todo CLI.
Why I Started This Series
When AWS Kiro launched in July 2025, I was genuinely excited. As someone who teaches coding to beginners, I immediately saw what made it different. Not just another autocomplete tool. Not just a chat assistant that writes code on demand. Something more structured, more deliberate, and honestly more aligned with how real software is actually built.
But here is the thing I kept noticing. Most of the content about Kiro online was written for developers who were already experienced. Advanced tutorials. Enterprise use cases. Deep dives into agentic architectures. All valuable but none of it for the person who is just starting out. The person who opened Kiro for the first time and had no idea where to begin.
That is exactly who I make content for on Coding Hives. Beginners. People who are learning to code, figuring out their first tools, building their first real projects. And I was certain that if someone could show them Kiro in a simple, hands-on, beginner-friendly way it would change how they think about software development entirely.
So I built a series. This article walks through exactly what we covered, why each decision was made, and what I learned along the way. I am also sharing both video links so you can follow along or share with someone who needs it.
Part 1: Building a Todo CLI App with AWS Kiro from Scratch
📺 Video Link: https://youtu.be/LicOYks7l58?si=jM_DAtbHHmpHnwdu
Why a Todo CLI?
Every great tutorial starts with something small enough to understand completely, but real enough to actually teach something. A Todo CLI app is the perfect vehicle for showing Kiro's core workflow because it has clear requirements, a simple structure, and immediate, visible results. When the app runs in the terminal and accepts commands beginners feel it. They built something real.
More importantly, a CLI app has no frontend complexity to distract from what we were actually learning which was not Python, and not even the Todo app itself. It was Kiro's spec-driven development workflow.
What Spec-Driven Development Actually Means
Before showing a single line of code, I wanted viewers to understand the philosophy behind Kiro. Because once you get it really get it you start to see why every other AI coding tool feels slightly off by comparison.
Here is the problem those tools have. You type a prompt. The AI writes code immediately. It makes assumptions you did not ask it to make. It uses patterns that do not match your project. It misses edge cases you forgot to mention. And you spend the next hour iterating on something that could have been right the first time —if only there had been a plan.
Kiro's answer to this is spec-driven development. When you describe what you want to build, Kiro does not write code first. It writes a specification. Three documents are generated automatically:
requirements.md— A structured list of exactly what the feature must do, written in plain language with acceptance criteria. Think of it as a contract between you and the AI.design.md— The architectural plan. How files are organized, how data flows, which functions do what. The blueprint before construction.tasks.md— A step-by-step implementation checklist. Every task is numbered, sequenced, and scoped so nothing is missed.
You review these documents. You can edit them, add constraints, or remove things you do not want. Only when you approve the spec does Kiro start writing code.
"This is not vibe coding. This is engineering. And it changes how beginners think about building software from day one."
The Live Build
In the video, we opened a fresh empty folder in Kiro and described our app in one plain English sentence:
"Build a simple Todo CLI app in Python with add, delete, and list features"
Then we stopped talking for ten seconds and let viewers watch Kiro generate the spec. This was a deliberate choice. Silence on camera is uncomfortable but it forced every viewer to actually watch what was happening on screen. And what was happening was genuinely surprising to people who had only used tools like Cursor or GitHub Copilot. No code. Just planning.
After approving the spec, Kiro wrote the entire application. We ran it in the terminal live, added tasks, listed them, and deleted them. It worked on the first run because the code followed a plan that had already been reviewed and approved.
What the Beginner Takeaway Was
I ended Part 1 with a message I wanted every viewer to remember:
"Before Kiro, beginners would ask the AI to write code and then wonder why it did not do what they wanted. Now they understand that the problem was not the AI — it was skipping the planning step. Kiro makes that step unavoidable. And that is a feature, not a bug."
Part 2: Hooks and Steering Files Making Kiro Work for You Automatically
📺 Video Link: https://youtu.be/hv-8klJ7vLE?si=K35hD8wSnDePPLos
The Problem Part 1 Left Unsolved
At the end of Part 1, we had a working Todo CLI app. But there was a real problem lurking that I wanted to address directly in Part 2, because every beginner will eventually run into it.
You come back to your project three days later. You open Kiro. You start a new conversation and ask it to add a feature. And Kiro writes code that is slightly different from what you already have. Different naming conventions. A library you were not using. Comments in a style that does not match the rest of the file.
This is not Kiro being bad. This is Kiro having no memory. Every new conversation starts from zero. The AI does not know your standards, your preferences, or your previous decisions — unless you tell it again. And telling it again every single time is exhausting and error-prone.
This is the problem that Hooks and Steering Files solve completely. Once viewers understood this, the response in the comments was immediate. This was the "aha" moment of the whole series.
Steering Files: Permanent Memory for Kiro
Steering files are Markdown files that live in a specific folder inside your project workspace:
(Note: You can also place global steering files in your home directory at
~/.kiro/steering/ to apply standard rules across all your coding projects!)Every time you open Kiro and start interacting with it, Kiro reads these files first. Before your first message. Before anything. It already knows your project, your standards, and your tech stack — because you wrote it down once and Kiro never forgets it.
In the video, we used the built-in "Generate Steering Docs" button in the Kiro panel to create three foundation files automatically:
product.md— What this project is. What it does. Who uses it. What the goals are. Kiro understands the why.tech.md— Your technology stack. Language, libraries, frameworks. Kiro will always prefer these over alternatives.structure.md— Your folder structure, naming conventions, import patterns. Every new file Kiro creates matches your style.
Then we created a custom steering file for our Todo app:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
inclusion: always
# Todo App — Coding Standards
## Language
- Always use Python 3.10+
- Follow PEP 8 style guide
- Use type hints on all functions
## Naming Conventions
- Functions: snake_case (e.g. add_task, delete_task)
- Constants: UPPER_CASE (e.g. MAX_TASKS)
## Code Style
- Always add docstrings to functions
- Never use global variables
- Write comments in English
The result was immediate and visible. Every piece of code Kiro generated after this followed our standards without being asked. Type hints on every function. PEP 8 throughout. Docstrings on every method. Consistent naming across the entire codebase. Not because we reminded Kiro — because Kiro read the steering file and already knew.
Inclusion Modes: Controlling When Kiro Reads Each File
One of the more nuanced things we covered was inclusion modes — the front matter at the top of each steering file that controls when Kiro loads it. This is set in plain YAML at the very top of the file:
1
2
3
4
inclusion: always
There are four modes, each serving a specific purpose:
always— The file is loaded on every single interaction. Use this for core coding standards, language preferences, and project-wide rules that never change.fileMatch— The file loads only when you are working on files that match a specific pattern. For example, Python conventions load for.pyfiles only. React component standards load for.tsxfiles only. Efficient and targeted.manual— The file never loads automatically. You explicitly call it in chat using the hash symbol and the file name (e.g.,#standards.md). Useful for specialized documentation you only need occasionally.auto— Kiro reads the description in your front matter and decides by itself when this file is relevant. The most intelligent mode, requiring a clear description field so Kiro understands when to apply it.
For beginners, the practical advice is simple: start with
always for your core standards, and explore the other modes as your project grows.Hooks: Automation That Runs While You Code
If steering files give Kiro permanent memory, hooks give it the ability to take action automatically — without you asking, without you remembering, without you doing anything except continuing to code.
A hook is a simple rule: when THIS event happens, automatically DO THAT. The event could be a file being saved, a new file being created, a task in your spec completing, or even a message you submit to Kiro. The action could be running a shell command or sending a prompt to Kiro automatically.
Kiro stores these hooks in the
.kiro/hooks/ directory, meaning they can easily be committed to Git. We built three hooks live in the video, each demonstrating a different use case:Hook 1 — Auto-Run Tests on Every File Save
The most practical hook for any project. Every time Kiro saves a Python file, the test suite runs automatically. No manual command. No remembering to check. The terminal opens by itself and shows results.
We created this hook using plain English in the Kiro panel:
"After any Python file is saved by the agent, run the tests automatically and show the results"
Kiro generated the full hook configuration from that description. We tested it live — Kiro made a change to
todo.py, saved it, and the tests ran without a single manual command. For beginners who have never thought about continuous testing, this was a revelation.Hook 2 — Auto-Generate Docstrings After File Save
A code quality hook. Every time a Python file is saved by the agent, Kiro automatically checks all functions for docstrings and adds them if missing.
We demonstrated this by writing a function with no docstring:
1
2
def count_tasks(tasks):
return len(tasks)
After the agent saved the file, Kiro automatically detected the missing docstring and added a properly formatted one — without being asked. The standards were enforced by the environment, not by memory or discipline.
Hook 3 — A Safety Blocking Hook
This was the hook that generated the most discussion in the comments, and for good reason. This hook uses an exit code of
2 to block Kiro from proceeding with a dangerous operation entirely.In our Todo app, a bulk delete — clearing all tasks at once — is something we wanted to prevent from being generated accidentally. The hook checks for this pattern before any task executes, and if it detects it, stops Kiro and reports back.
The broader point this demonstrated was important: using Kiro with hooks is not just faster coding. It is safer coding. You are not hoping the AI does the right thing. You are enforcing it programmatically.
"Hooks beat promises. You do not ask Kiro to be careful. You build a system that makes carelessness impossible."
The Full Picture: How Everything Works Together
At the end of Part 2, we showed the complete workflow as a single diagram — because the power of Kiro is not in any one feature. It is in how these features form a cohesive system:
1
2
3
4
5
6
7
8
9
10
11
12
13
You describe a feature in plain English
↓
Steering files load → Kiro already knows your standards
↓
Kiro generates spec: requirements.md, design.md, tasks.md
↓
You review and approve
↓
Kiro writes code → following your steering rules exactly
↓
Hooks fire automatically → tests run, docs update, safety checks pass
↓
✅ Feature complete. Properly engineered. Every single time.
This is not a workflow for experts only. This is a workflow that makes anyone who uses it produce expert-quality output — because the quality is enforced by the system, not left to chance.
What I Learned Building This Series
1. Beginners Need to See the Problem Before the Solution
In both videos, I spent real time on the pain point before introducing the feature. The frustration of AI forgetting your conventions. The chaos of code written without a plan. The tedium of running tests manually after every change. When viewers feel that pain first, the solution lands differently. It does not feel like a feature. It feels like relief.
2. Start Simple, Then Add Depth
Part 1 touched nothing about hooks or steering files, even though both were available. This was intentional. Beginners need wins before complexity. By the time we introduced steering files in Part 2, viewers already had a working project to attach them to. The features felt necessary, not abstract.
3. The .kiro Folder Belongs in Version Control
One practical insight I emphasized in Part 2 that resonated strongly: commit your
.kiro folder to Git. Your hooks, your steering files, your spec documents — these are part of your project now. They describe how your project should be built, not just what it contains. Version them, back them up, and share them with your team.If you are building something with Kiro and want your project featured or discussed in a future video, drop a comment on either video. I read every single one!
Final Thought
"A junior developer using Kiro with proper steering files and hooks produces code that meets the same quality bar as a senior developer — because the standards are enforced by the environment, not by experience alone."
This is what excites me most about Kiro. Not the spec generation, impressive as it is. Not the hooks, powerful as they are. It is the democratization of engineering discipline. The idea that the practices that separate good code from bad code — planning, consistency, automated quality checks — can now be accessible to anyone on day one.
That is worth teaching. That is worth a series. And honestly, after one year of Kiro being in the world — we are only just getting started.
Happy Birthday, Kiro! 🎂
📺 Video Links
- Part 1 — Building a Todo CLI App with AWS Kiro: https://youtu.be/LicOYks7l58?si=jM_DAtbHHmpHnwdu
- Part 2 — Hooks and Steering Files Explained: https://youtu.be/hv-8klJ7vLE?si=K35hD8wSnDePPLos
🔗 Resources
- AWS Kiro —https://kiro.devÂ
- Kiro Steering Docs —https://kiro.dev/docs/steering/Â
- Kiro Hooks Docs —https://kiro.dev/docs/hooks/Â
- Coding Hives YouTube —https://www.youtube.com/@CodingHivesÂ
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article