A 10-minute primer for your trainees. What Kiro is, how it differs from a general chat assistant, and the one signature workflow — spec → tasks → code — that makes it useful for real engineering work.
Kiro is an agentic AI development environment — an IDE built on VS Code where an AI collaborator actually writes the code, runs the tests, and iterates on the diff, while you focus on design decisions.
If ChatGPT gives you a code snippet, Kiro ships the whole change. It reads your codebase, drafts a plan, edits files, runs the build, and asks for review — all in the same tool where you already work. Think of it less as an assistant and more as a junior engineer who can execute on a well-defined task without hand-holding.
The "spec" in "spec-first" is Kiro's key move: instead of vibing over messages, Kiro can operate from a written specification (requirements → design → tasks) so the work is reviewable, not just conversational.
Kiro's superpower is making complex features tractable by writing them down first. Three artefacts, one clear direction of travel.
For a two-line bug fix, specs are overkill — Vibe mode handles it. But for a real feature ("add pagination", "migrate this table", "wire up SSO"), the spec forces you to answer the big questions before the AI generates 400 lines of code you have to unread. It's the difference between "the AI wrote something plausible" and "the AI shipped what I asked for".
You review the tasks, adjust anything wrong, then let Kiro work through them one at a time. Each task becomes real edits + a real test run — not a suggestion.
Show your trainees a spec file, then click "start". Watching Kiro tick through tasks in real time is the moment "AI IDE" clicks — that this is fundamentally different from copy-pasting from ChatGPT.
Two features you should be able to describe in one sentence each. Both make Kiro your team's Kiro, not just an AI with defaults.
Steering files live at .kiro/steering/*.md and get pulled into every Kiro session. They're where you write project conventions: "we use kebab-case for filenames", "prefer functional components over classes", "never touch anything in /legacy without approval". Once written, Kiro respects them automatically — no more pasting the same "here's how we work" preamble into every prompt.
Steering can be always-on (default), or triggered when a specific file pattern is opened, or invoked manually with # in chat.
Hooks fire on IDE events — you save a file, Kiro completes a turn, a task finishes. Each hook can run a shell command or inject a prompt. Common uses: run the linter after every save, add a "did you update the docs?" reminder when a config file changes, kick off tests when a task finishes.
Hooks live at .kiro/hooks/*.json and are the way teams turn "here's the rule" into "the rule is enforced automatically".
| Part | What it is | Lives at |
|---|---|---|
| Specs | Reviewable "requirements → design → tasks" documents Kiro executes against | .kiro/specs/<name>/*.md |
| Steering | Persistent project rules injected into every session | .kiro/steering/*.md |
| Hooks | Event-triggered actions (commands or prompts) | .kiro/hooks/*.json |
| Skills / Sub-agents | Reusable specialised capabilities (e.g. "review this diff", "gather codebase context") | .kiro/skills/<name>/ |
Quick and Kiro sit at opposite ends of the same idea. Quick is for anyone — no code, business teams, prototyping. Kiro is for builders — real repos, real commits, real deploys.
If a trainee asks "can Quick actually build a production app?", the honest answer is: for internal tools yes, for a customer product you'll want a real IDE — and if you like the AI-assist feel of Quick, you'll love what Kiro does for engineering work.
This is a Quick session, not a Kiro session. Keep it to 10 minutes — one screenshot of a spec, one screenshot of a hook, and a "if you're an engineer, come talk to us after" hand-off. Trainees who care will follow up.