From Prompt to Spec: The Real Training Imperative Behind AWS’s Move to Kiro

Before Kiro, most AI-assisted development followed a recognizable pattern.

A developer opens a chat interface, types a prompt, reviews the output, adjusts, prompts again, and gradually assembles something that works. It is fast in the short term. It is also fragile, undocumented, and deeply personal.

This approach has been called "vibe coding" — a phrase that captures both its appeal and its problem.

The root issue is not that prompting is imprecise. The root issue is that the AI collaborator arrives for every session knowing absolutely nothing about you, your team, your standards, or your codebase. You have been treating it like a vending machine: input a prompt, receive code. But the machine has no memory, no context, and no understanding of what makes your organization’s work distinctive.

When the developer who held all that context in their head moves to another team, the vibe goes with them.

Enterprise software doesn’t scale on vibes. It scales on shared understanding, repeatable process, and artifacts that can survive a personnel change.

Kiro was built from a different premise.

Instead of treating AI as a sophisticated autocomplete or a chat assistant bolted onto an editor, Kiro treats the specification as the primary artifact of development. Code is what the specification produces.

Here is the framing I use when teaching this: think of your AI collaborator not as software you operate, but as an exceptionally capable intern you have just brought onto your team.

That intern is smart, fast, and tireless. But they arrive knowing nothing about your organization — nothing about how you name things, what architectural patterns you prefer, which security standards you hold firm on, or why you made the decisions two years ago that still shape the codebase today.

The intern is not the problem. The absence of onboarding is.

Kiro formalizes something experienced technical leads have always done intuitively: brief the collaborator before the work begins.

When a developer describes a feature in Kiro, the system generates three structured documents before writing a single line of code — a requirements file capturing user stories and acceptance criteria, a design document describing the technical approach and architecture, and a task list breaking implementation into discrete, verifiable steps.

Only then does Kiro generate code, working from those documents rather than around them.

This is not a minor workflow change. It reorganizes the entire relationship between intent and execution.

The spec is the brief. And a well-written brief produces better work than a well-worded prompt, every time.

This is the insight that separates Kiro’s approach from everything that came before it: specs are code.

They are not documentation created after the fact. They are not a form filled out for a project manager’s benefit. They are first-class artifacts of the development process — written before implementation, maintained alongside it, and committed to version control with everything else.

That means specs can be vetted. A senior engineer can review a requirements document before any code is written, catching ambiguity, scope creep, or architectural misalignment at the cheapest possible moment — before the intern has spent two days building the wrong thing.

It means specs can be versioned. When a requirement changes, the change history is preserved. You can see what the original brief was, when it changed, and why.

It means specs can be shared. A new team member can read the spec for a component and understand not just what it does, but what it was designed to do and what constraints shaped its design.

That is knowledge transfer that doesn’t require the original author to still be in the building.

Kiro extends this further with two constructs that operate at the team level rather than the feature level.

Steering files are the persistent documents you hand a new collaborator on day one: here is how we write code, here is what we value, here is what matters to us. They are automatically included in every Kiro session, so the intern doesn’t start fresh each morning.

Hooks are the standing reminders built into the workflow — event-driven automations that fire on file saves, pull request opens, or other repository events, running consistency checks and enforcing standards without anyone having to remember to do it. They teach through repetition rather than relying on the collaborator’s memory.

Both live in the repository and are shared by the entire team the moment they check out the code.

Here is where I want to speak directly to engineering leaders and L&D professionals — and shift the frame away from tool adoption entirely.

The real challenge AI-assisted development surfaces — and Kiro makes impossible to ignore — is a psychological one.

Most developers have spent their careers as individual contributors. Their relationship with code is direct and personal. They are the ones with the context, the judgment, and the taste. The tool does what they tell it to do.

Kiro asks them to become something closer to a technical lead: someone who communicates intent precisely, sets expectations explicitly, and reviews outputs critically.

The skill is not writing code faster. The skill is directing a capable collaborator who needs context to do good work — and building the team-level systems that give that collaborator the institutional memory it needs to stay aligned over time.

Writing a good spec is not the same skill as writing good code. It requires thinking clearly about what you are building before you build it, expressing requirements in language precise enough for an AI collaborator to act on reliably, and maintaining discipline about the separation between what a feature should do and how it should be implemented.

Most developers have never been trained to do this explicitly. They do it implicitly, in their heads, with varying degrees of rigor. Kiro makes that implicit process explicit. That is its greatest strength, and also the source of the steepest part of the learning curve.

Building good steering files requires teams to agree on shared principles and document them. That means the conversation finally has to happen — the one where senior engineers articulate the architectural assumptions they have been carrying silently for years.

A poorly onboarded intern develops bad habits. A poorly configured Kiro environment drifts from your standards in ways that compound quietly until they surface as technical debt.

That is a genuinely different cognitive posture than the industry has been practicing. And like any management skill, it does not develop by accident.

The business case for investing in structured Kiro training comes into sharp focus when you keep the intern frame in mind.

Consider two organizations.

The first deploys Kiro across its engineering teams, sends a migration announcement, and assumes developers will figure it out. The intern shows up, gets handed a laptop, and is pointed at the Jira board. Some thrive. Many default to the familiar pattern — prompting reactively, skipping specs, treating Kiro as faster autocomplete. The onboarding documents never get written. The intern produces inconsistent work, and nobody is sure why. The productivity gains are modest and uneven, and nobody can quite articulate what they expected to be different.

The second organization invests four to six weeks in structured adoption before broad rollout. Teams build their steering files together — articulating standards, documenting conventions, capturing the institutional knowledge that usually lives only in senior engineers' heads. Hooks are configured deliberately. Developers practice writing specs on real features with coaching, building the briefing discipline before it matters in production. The intern arrives to a proper first week: context, expectations, standing reminders, and a manager who knows how to give a good brief. The work that comes back reflects how the team actually operates.

The difference in outcomes is not primarily a function of the tool. It is a function of the onboarding investment.

Research on technology adoption consistently shows that structured training meaningfully accelerates time to competency. For a workflow as different from prior practice as spec-driven development, that compression matters enormously. Every week a team spends in the wrong habits is a week of technical debt building in the wrong direction — and the wrong habits here are particularly sticky, because they feel productive.

I have spent significant time with Kiro — building real things with it, teaching it to development teams, and working through what adoption actually looks like in practice.

That experience on both sides of the learning relationship has shaped how I guide clients through this transition.

Learn Flourish will no longer be developing new Amazon Q Developer courses. The platform has a sunset date, and our clients' time is better invested building capability around what comes next.

What we are building instead is structured Kiro enablement: programs that move teams from curiosity to competency, with particular attention to the management mindset that spec-driven development requires — not just the mechanics of a new tool.

We focus on teaching developers how to brief their AI collaborator well, how to build the onboarding documents that make that collaborator consistently useful, and how to review and refine AI output like a lead rather than a user.

The deadline is April 30, 2027. But the organizations that start structured adoption now will reach meaningful productivity well before the cutoff — and carry the habits forward long after the migration is complete.

Those that wait will spend 2027 catching up to the teams that onboarded their interns properly in 2026.

George Sawyer is a principal technical trainer and learning strategist at Learn Flourish LLC, specializing in cloud technologies and the organizational side of AI adoption. He has extensive hands-on experience building with Kiro and teaching it to development teams, and guides organizations in building structured adoption programs for agentic development tools.

Learn Flourish — Bringing High Tech Down to Earth
learnflourish.com