From Prompt Chaos to Production AI: Spec-driven Development for AI Engineers | Vishal Alhat

Editor's Note: This blog is adapted from a session by Vishal Alhat at thegeekconf mini 2026. As a Developer Advocate at Amazon Web Services with 13 years of experience spanning community building, cloud development, and agentic AI tools, Vishal brings a practitioner's lens to the way developers build with AI today. His talk cuts through the chaos of prompt-driven development, drawing a clear line between vibe coding and structured, spec-driven development, and makes the case for why requirements, design documents, and steering — not better prompts — will determine who ships production-ready systems at scale.

My name is Vishal Alhat. I am from Pune, and I work with Amazon Web Services in Bangalore as a developer advocate. I help developers build their own products and services, and understand new technologies and tools. Think of me as a peer — a developer who works alongside you on your problems and solutions. Feel free to ask any questions.

For today's session, we are going to look at something most developers face when they use AI to generate code — prompt chaos.

How many of you have tried to build a feature or an application using Vibe coding, just starting with a prompt? And how many of you tried one model, got a result, switched to another model, and got a different result? That happens to everyone.

Here is another familiar situation: code that works in a Jupyter notebook — the UI renders, the backend connects, everything looks right — but the moment you deploy to production, it breaks. The AI was not the problem. The implementation was.

Then there is prompt engineering tax — hours spent tweaking a prompt to get the intended result. And once you get somewhere, you enter endless iterations, going back and forth, revising prompts, checking code, starting over.

Most developers here know test-driven development — TDD. You write test cases first, define expected inputs and outputs, and then write code to satisfy those tests. Spec-driven development follows the same principle, but at the requirements level.

In spec-driven development, you write your requirements first in plain human language. No special format. Just describe what you want to build. The system generates a structured requirements document from that.

This maps to the requirements analysis phase of the software development life cycle — what the front end looks like, what technology to use, and what the back end handles. All of that goes into the requirements spec.

From there, a design document takes shape — the architecture, data models, API routes, infrastructure, and any integration or UI tests you want to include.

For this demo I am using Kiro — my preferred agentic IDE. You can use any agentic IDE you are comfortable with. Kiro has two features I find valuable: steering and agent hooks. The approach works in any similar tool.

I start with a prompt. In this first demo, I have an existing event management application, and I want to add a category feature. I enter one prompt describing that feature. Kiro reads it, checks the existing code, and lists all the changes required. It asks for confirmation before it proceeds.

Once confirmed, Kiro generates a requirements.md file — a full requirements document from my prompt. This is not a one-time document. You can come back, update it through vibe coding, and revise it as often as needed.

After you approve the requirements, Kiro generates the design document — class diagrams or data models, API routes, infrastructure specs, and test plans. Once you approve the design, Kiro generates the task list.

Now, let me show a full application built from scratch with this approach. The prompt: build a React task management application with AWS integration, CRUD operations, cards for each task, and tasks stored in a DynamoDB backend.

In the prompt, you can specify your UI components, technical constraints, partition key naming conventions, and any standards your team follows. If you have organisation-specific context, you add it to Kiro's steering.md file. Kiro can also auto-generate that steering file from your existing codebase.

I enter the prompt, and Kiro asks two questions. First: are you building a new feature or fixing something existing? I select a new feature. Second: Do you want to start with technical design or requirements? I start with requirements.

Kiro reads the prompt and generates a full requirements document — the back end, components, data models, APIs, and acceptance criteria. If anything looks wrong, I ask Kiro to revise it in the same chat. Once it looks right, I move to the design phase.

Here is the UI that came out of this process — a complete CRUD task management application. You can create tasks, update them, and delete them. It runs on AWS. And I did not open the AWS console once.

In the requirements and design documents, I specified which AWS services to use. Kiro generated infrastructure-as-code for those services, ran those files, created the infrastructure, deployed the application, and gave me the URL.

For teams in enterprise environments, two features in Kiro matter most: steering docs and hooks.

Steering docs tell the agentic IDE what context to apply before it accepts any prompt. Think of it like steering a car — you set the direction, and the agent follows it. If you have 10 developers on the same application, each with different prompts and different opinions on code style, the steering doc brings the output in line. Every prompt runs through the same context. A junior developer who just joined gets the same code standards as a senior engineer, because Kiro reads the steering doc before it writes any code.

Hooks handle automation. When I save a file, Kiro lints the code and checks for syntax errors. I can set a hook so that after every pull request, Kiro sends the generated code to a team lead on Slack for review. I can also hook into my API code so that any change to an endpoint updates the API documentation on its own. No manual documentation updates.

A question came up about how spec-driven development scales when five or ten developers each own different components of the same application.

The requirements document does not have to be a single file. You can split it into sections by component, or create separate requirement documents per team. The key is that each team gives Kiro the right scope. If you have a UI developer, a backend developer, and a DevOps engineer, you tell Kiro what each prompt is allowed to touch. A DevOps prompt should not modify UI code. You enforce that in the prompt or in the steering doc.

On integration testing: each component handles its own tests. For cross-component integration, you set Kiro hooks to run tests after each change and route results to the responsible team. There is a human in the loop for final verification.

On what happens when one team changes an API signature: Kiro rebuilds based on the updated requirements. The steering doc keeps changes within the correct boundary. If the backend team updates their requirement document, Kiro applies it to the backend scope only. It does not touch the UI unless the UI requirement document also changes.

So that is a quick recap of what we covered — what specs and prompts are, how to create consistent and reproducible code with agentic IDEs, and how to get production-ready code from day one. You can provide context through steering docs and automate through hooks so your code stays production-ready without constant revisions.

One thing I always say: start small. Create one component, get that working, and then integrate. You do not need to spend two or three days writing prompts. Start with one component for your spec-driven development and scale up from there.