Spec-Driven Design with Kiro: Lessons from Seddle

Introduction

When we set out to build Seddle, our AI-powered feedback collection and decision-making platform, we knew we needed more than just great ideas and coding skills. After all, we are still a small software startup. We needed a systematic approach to transform our vision into production-ready infrastructure, and traditional development approaches felt too slow.

We decided to use Kiro, an AI-powered development environment that fundamentally changes how we build software. In just six weeks, we’ve gone from concept to a fully functional backend architecture that is 100% defined in Terraform, comprehensive authentication and authorization, multi-tenant data access patterns, and production-grade LLM integration with Amazon Bedrock.

This post shares our journey using Kiro to build Seddle, why spec-driven design beats pure “vibe-coding,” and the practical lessons we learned along the way. Whether you’re a solo founder, a small team, or an enterprise development shop, we hope these insights help you ship faster without sacrificing quality and security. Happy building!

What Is Kiro?

Kiro is an AI-powered IDE and development environment that combines the best of traditional coding tools with agentic AI capabilities. Think of it as having a senior software architect, DevOps engineer, and technical writer working alongside you 24/7. Yes, it’s that good.

Unlike traditional AI coding assistants that simply autocomplete code or suggest improvements, Kiro operates at a higher level of abstraction and helps you:

• Design before you build: Create comprehensive specifications with requirements, architecture decisions, and implementation plans
• Execute systematically: Break down complex features into manageable tasks with clear acceptance criteria
• Maintain context: Keep business logic, technical constraints, and architectural decisions in “steering documents” that guide development to ensure consistency and coherence
• Deploy with confidence: Generate infrastructure-as-code (IaC), write test procedures, and implement security best practices

Kiro uses the latest frontier models (e.g., Claude Opus 4.6, Anthropic’s newest SoTA model) and has “visibility” into the internet through built-in web tools and specialized Model Context Protocol (MCP) servers, allowing it to fetch documentation, research best practices, and stay current with rapidly evolving technologies.

Most importantly, Kiro integrates directly with your AWS account, enabling it to perform CRUD operations on your infrastructure, run tests, deploy resources, and validate configurations, all while maintaining strict security boundaries through IAM roles and least-privilege access.

In short, Kiro is pretty amazing!

Spec-Driven Design vs. Vibe-Coding

There are many people in the world right now using vibe coding platforms because they are not developers, and that’s okay. I believe these tools are great enablers for rapid prototyping, creating an MVP, or basic websites for things like landing pages, webinar registration pages, and more. In fact, we built the initial MVP for Seddle using Base44!

However, as I documented in detail in this blog post, there are some pretty important limitations of these platforms that exist today, which likely won’t be solved in the next 1–2 years (some of them maybe never, by design). Look no further than Reddit threads like this and you’ll quickly understand why hosting a production-grade application with paying customers on these type of platforms may be a bad idea.

At a certain point, you must take ownership of your architectural destiny and the underlying infrastructure responsibilities that come with it. A good litmus test for this should be the following:

“If I were your customer and asked you about your architecture and how you ensure the security of my data and maintain a reliable and scalable service offering, could you draw it on a white board and explain it to me in detail?”

You don’t need to understand every line of code, but someone on your team should be able to answer a resounding YES to the question above (and that someone should not be an AI agent). AI is rapidly evolving, and maybe one day large enterprises will be okay with an agent signing an attestation of PCI DSS compliance, SLA agreement, or owning the keys to the kingdom like your root account credentials. But that isn’t happening anytime soon.

As a quick recap of the blog post above, vibe coding often leads to:

• Scope creep: Features expand without clear boundaries
• Architectural debt: Early decisions become constraints later
• Inconsistent patterns: Different parts of the codebase solve similar problems differently and feel disconnected as complexity grows
• Documentation lag: Code changes faster than docs can keep up
• Context loss: Weeks after features are shipped, nobody remembers why certain decisions were made and minimal traceability
• Hidden limits: to save space, see blog post linked above!

Spec-driven design flips this model. Before writing a single line of code, you create 1 or more structured specifications that answer:

1. What feature are we building? (Requirements)

2. How will it work? (Design)

3. What needs to be done? (Tasks)

This might sound like waterfall development, but it’s not. Specs are living documents that evolve as you learn. The key difference is that you’re making architectural decisions explicitly and documenting them as you go, rather than discovering them accidentally through code.

With Kiro, spec-driven design becomes practical and fast. Instead of spending days writing specifications manually, you collaborate with Kiro to generate comprehensive specs in hours. The AI helps you think through edge cases, suggests architectural patterns, and ensures consistency across your entire codebase while adhering to best practices.

For Seddle, this approach has been transformative. We’ve built complex features like multi-tenant authentication, DynamoDB single-table design with global secondary indexes for complex query patterns, cross-provider LLM failover, and Stripe payment integration, all with clear specifications that serve as both implementation guides and long-term documentation.

Getting Started with Kiro

If you’re building a serious application (not just a prototype), here’s the workflow we recommend based on our experience:

1/ Start with Steering Documents

Before writing any code, use Kiro to create foundational “steering documents” that will guide all future development. These live in `.kiro/steering/`, can (and should) evolve over time, and include:

Business Context (`business-context.md`):

• What problem are you solving?
• Who are your target users?
• What’s your business model and pricing strategy?
• What are your success metrics?
• What are your technical priorities (cost, scale, security)?

Technical Architecture (`tech.md`):

• What’s your technology stack?
• What are your core frameworks and libraries?
• What are your deployment targets (AWS, GCP, Azure)?
• How will you manage and deploy (Terraform, GitHub Actions)
• What are your performance requirements?

UI/UX Style Guide (`ui-ux-style-guide.md`):

• What’s your design system?
• What are your color palettes, typography, and spacing rules?
• What components are you using?
• What are your accessibility requirements?

… and more. Note, while steering documents help keep things “grounded” as you develop, we recommend not having too many, as it consumes context during Kiro session interactions in the development process. A few steering docs will be just fine as a starting point.

These documents become the “context” that Kiro uses for every decision. When you ask Kiro to build a new feature, it automatically considers your business priorities, technical constraints, and design standards. This eliminates the constant back-and-forth of “remember, we’re using DynamoDB” or “don’t forget our color scheme.”

For Seddle, we spent about ~6 hours creating these initial steering documents with Kiro. That upfront investment has saved us countless hours of rework and architectural debates in the future.

2/ Connect Kiro to Your AWS Account and GitHub remote repo

It goes without saying, but don’t store all of your code locally. Follow best practices and connect Kiro to a remote GitHub repository within your control, and sync your changes as you complete specs and tasks.

If you’re building on AWS (which we highly recommend for production applications), you’ll need to grant Kiro permissions to interact with your account. Without going into all of the AWS best practices around IAM authentication and account structure, we recommend you have at least a development and production account. This enables Kiro’s agentic mode to:

• Create and update infrastructure resources
• Deploy Terraform configurations
• Run integration tests against real AWS services
• Validate IAM policies and security configurations
• Monitor CloudWatch logs and metrics

Important: Kiro uses IAM roles with least-privilege access. You control exactly what Kiro can and cannot do. We recommend starting with a dedicated development AWS account (not production) and granting permissions incrementally as needed.

The setup process is straightforward:

1. Create an IAM role with appropriate permissions

2. Configure Kiro with your AWS credentials. We recommend using short-term access keys instead of long-term access keys, and you can use the new aws login capability detailed in this blog post to avoid storing credentials and API keys in code repositories

3. Specify which regions and services Kiro can access

4. Enable CloudTrail logging to audit all Kiro actions

Once connected, Kiro becomes dramatically more powerful. Instead of just generating Terraform code, it can apply configurations, verify resources were created correctly, run test procedures, and troubleshoot deployment issues autonomously.

3/ Establish Infrastructure-as-Code from Day One

This is perhaps the most important thing to do from day 1 before you starting creating resources in your cloud account(s) — never use ClickOps for production infrastructure, you will cause many future headaches.

ClickOps (clicking through the AWS Console to create resources) is tempting because it feels fast. But it creates massive problems:

• No version control: You can’t track what changed, when, or why
• No reproducibility: Rebuilding your infrastructure requires remembering every click, which is impossible for real apps
• No collaboration: Team members can’t review or approve changes
• No disaster recovery: If something breaks, you’re manually recreating everything. If you have real customers, that’s a big problem.
• No multi-environment support: Dev, staging, and production drift apart

Instead, use Terraform (or CloudFormation) from the very first resource. With Kiro, this is actually easier than ClickOps because Kiro generates the Terraform code for you.

Our recommended structure:

```
/infra
/bootstrap # Initial setup (S3 backend, IAM roles)
/auth # Cognito, user management
/compute # Lambda functions, API Gateway
/data # DynamoDB, RDS, S3 buckets
/networking # VPC, subnets, security groups (if needed)
/monitoring # CloudWatch, alarms, dashboards
```

Each directory contains modular Terraform configurations with clear inputs, outputs, and dependencies. Kiro helps you:

• Generate Terraform modules following AWS best practices
• Implement proper state management (remote S3 backend with locking)
• Create reusable modules for common patterns
• Add comprehensive outputs for resource references
• Document every resource’s purpose and dependencies
• Tag every AWS resource with necessary metadata

For Seddle, we have 100% of our infrastructure defined in Terraform. We can tear down and rebuild our entire stack in under 20 minutes. Before we launch in production, we’ll have DynamoDB Global Tables and Backups enabled to ensure we have the ability to restore customer data, even if (in the rare event) our AWS account were completely deleted or we lost access. We can review every infrastructure change in pull requests, and we can confidently deploy to multiple environments knowing they’re all using identical infrastructure configurations.

This architectural decision will prove to be valuable later when we offer Enterprise capabilities like dedicated infrastructure deployments in preferred regions, for example. Rather than create everything from scratch, we have a starting blueprint that can be easily adapted saving time and money. Most importantly, we can ensure architectural consistency.

Key Features That Make Kiro Exceptional

Below are some key features that stand out to us:

Spec-Driven Workflow with Property-Based Testing

Kiro’s spec workflow isn’t just about documentation, it’s about correctness. When you create a spec, Kiro helps you define:

• Requirements: User stories and acceptance criteria
• Design: Architecture decisions and data models
• Correctness Properties: Formal specifications that your code must satisfy before proceeding
• Property-Based Tests: Automated tests that verify properties hold across all inputs (prevents human bias and manual testing)

This approach caught bugs we would have never found with traditional unit tests. For example, our DynamoDB repository layer has property-based tests that verify:

• Tenant isolation (users can never access another tenant’s data)
• Query optimization (GSI queries return correct results)
• API authentication (invalid tokens are always rejected)

These tests run thousands of randomized inputs through our code, finding edge cases that would take months to discover manually. They also cleanup any resources that were created in the process. For example, we might create 100 Cognito users in our User Pool to test the user registration, verification, password reset, MFA, and account deletion flows. After tests complete, we destroy those resources that were created to avoid paying for unneccessary resources or causing confusion later.

Internet Connectivity via MCP Servers

One of Kiro’s most powerful features is its ability to access the internet through built-in web tools and Model Context Protocol (MCP) servers. This means Kiro can:

• Fetch the latest AWS documentation when writing Terraform
• Research best practices for DynamoDB single-table design
• Look up current pricing for Bedrock models
• Find examples of implementing OAuth 2.0 flows
• Check compatibility between library versions

This “live research” capability is transformative. Instead of constantly switching between your IDE, browser, and documentation sites, Kiro brings that context directly into your development workflow.

For Seddle, this was particularly valuable when integrating Amazon Bedrock. The service is relatively new, documentation is evolving rapidly, and there are 100s of models available, each with different quotas and region support. Sifting through the documentation can be a real pain. Kiro was able to research current patterns, find relevant GitHub issues, lookup the right limits we needed to raise for model access, and suggest solutions based on the latest information, all without me leaving the IDE.

Security and Compliance Built-In

Kiro takes security seriously, which is critical when building production applications. Note: It’s worth reiterating that the below features are not a replacement for humans in-the-loop, and we recommend having at least one person who deeply understands your application’s architecture and how to manage the below facets like security, compliance, and more. In general, we think a winning combination (and when Kiro performs best) is when there is a technical operator overseeing and orchestrating.

Key security features include:

• Least-Privilege IAM Policies: Kiro generates IAM policies that grant only the minimum permissions needed for each resource you create like Lambda functions, API Gateway routes, or service integrations.
• Secrets Management: Kiro integrates with AWS Secrets Manager and Systems Manager Parameter Store, ensuring sensitive values (API keys, database credentials, etc.) are never hardcoded.
• Audit Logging: All Kiro actions associated with the respective IAM role used are logged via CloudTrail, providing a complete audit trail for compliance and debugging.
• Security Scanning: You can use Hooks in Kiro to run security scans on your code, identifying common vulnerabilities like SQL injection, XSS, and insecure dependencies.
• Compliance Frameworks: Kiro understands compliance requirements (SOC 2, GDPR, HIPAA) and can help you implement necessary controls.

For Seddle, security is non-negotiable. We handle sensitive user data, facilitate confidential conversations, and need to meet enterprise security standards. Kiro’s security-first approach helps provide confidence that we’re building on a solid foundation and will assist with evidence collection during future audit cycles, removing traditionally time-consuming tasks.

Change Management and Version Control

Kiro’s change management capabilities are exceptional. Every change Kiro makes is:

• Tracked in Git: All code and infrastructure changes are committed with clear messages for audit purposes
• Reviewable: You can review diffs before accepting changes
• Reversible: Easy rollback if something goes wrong
• Iterative: You can run sub-tasks and procedures iteratively, allowing you to supervise and thoroughly understand the development process (we strongly recommend this)
• Documented: Changes are linked to specs and tasks for full traceability with summary documents and checkpoints along the way

This is particularly valuable when working with infrastructure-as-code. Terraform changes can be complex and risky. Kiro’s ability to generate plans, explain impacts, and validate changes before applying them helps prevent production incidents where resources might inadvertently be deleted or modified.

Latest Models and Continuous Improvement

Kiro uses the latest frontier models from Anthropic. As these models improve, Kiro’s capabilities improve automatically. You’re not locked into a specific model version or provider, and by default you can use Auto, which is Kiro’s default intelligent model router that combines multiple frontier models with advanced optimization techniques.

What We’ve Achieved with Kiro So Far

In six weeks of development with Kiro, we’ve built:

Authentication & Authorization:

• AWS Cognito user pools with custom attributes
• Multi-tenant isolation
• JWT-based API authentication
• Role-based access control (RBAC)
• Lambda triggers for user lifecycle events

Data Access Layer:

• DynamoDB single-table design with multiple GSIs for complex queries
• Repository pattern for all entities (User, Session, Conversation, etc.)
• Tenant-scoped queries with automatic filtering
• Property-based tests for data integrity
• Integration tests against DynamoDB

LLM Integration:

• Amazon Bedrock client with multi-model support
• Cross-provider failover to prevent throttling (Claude → Nova)
• Exponential backoff and retry logic
• Structured logging for cost and performance monitoring
• Real-time AI facilitation with sub-5-second latency

API Layer:

• API Gateway with JWT authorizer
• RESTful endpoints for all core operations
• Request validation and error handling
• CORS configuration for frontend integration
• Rate limiting and throttling

Infrastructure:

• 100% Terraform-managed resources
• Modular infrastructure with clear dependencies
• Remote state management with S3 + DynamoDB locking
• Multi-environment support (dev, staging, prod)
• CloudWatch monitoring and alarms

All of this was built with comprehensive specifications, property-based tests, and production-grade security. We estimate this would have taken 3–4 months with traditional development approaches. With Kiro, we did it in 6 weeks. We have mostly been focused on the backend technology stack for Seddle, and soon we’ll be shifting our priorities to the frontend to ensure the UI/UX is something people will enjoy looking now that the “internal plumbing” phase is nearing completion. :)

Pricing and Recommendations

Kiro offers several pricing tiers, but for serious application development, we strongly recommend starting with Pro+ or higher. Here’s why:

For Seddle, we’re on Pro+ and it’s been worth every penny. The time savings alone justify the cost; we estimate Kiro has saved us ~200+ hours of development. That’s equivalent to hiring a senior engineer for a month.

The pricing is also incredibly affordable compared to hiring additional developers or consultants. A Pro+ subscription costs less than a single day of consulting from a senior developer, yet provides 24/7 access to AI-powered development assistance.

To reiterate an earlier point, this does not mean you don’t need a human technologist or developer in the loop. Kiro is fantastic at what it does, but even the best AI systems perform best when they are orchestrated or conducted by a human who understands what is happening. There have been numerous instances using Kiro where things could have gotten off-track, used the wrong service, or consumed credits unnecessarily if a human was not overseeing the development process. To maximize your success, have someone who knows what they are doing. :) This applies to any AI coding assistants that exist and is not unique to Kiro.

Tips for Success with Kiro

Based on our experience, here are our top recommendations:

1. Invest in steering documents upfront: Spend 4–8 hours creating comprehensive business, technical, and design documents. This pays dividends later throughout the development process.
2. Use specs for all non-trivial features: Don’t skip the spec process for “quick” features. Specs bring structure to the development process and as noted earlier are a great reference for documentation purposes later.
3. Review Kiro’s changes carefully: Kiro is powerful, but not infallible. Always review generated code, especially infrastructure changes.
4. Start with infrastructure-as-code: Never use ClickOps. Define everything in Terraform from day one.
5. Enable property-based testing: The upfront cost of writing properties is worth it. These tests find bugs traditional tests miss.
6. Connect to AWS early: Don’t wait until you’re ready to deploy. Connect Kiro to a dev AWS account from the start and deploy resources iteratively rather than all-at-once. This iterative process will help deconflict deployment issues later.
7. Use MCP servers liberally: Let Kiro research documentation and best practices. It’s faster and more accurate than manual research.
8. Commit frequently: Kiro’s change management works best with frequent, small commits. Don’t let changes pile up.
9. Upgrade to Pro+ for serious projects: The free and basic tiers are great for learning, but production applications need Pro+ features to get to the finish line of any complex project.
10. Embrace the learning curve: Kiro’s spec-driven approach feels different at first. Give it time, the benefits compound quickly.

Conclusion

Building Seddle with Kiro has been transformative. We’ve shipped more code, with higher quality, in less time than we would have been able to do just a few years ago. The spec-driven approach forced us to think through architectural decisions upfront, preventing costly rework later. The infrastructure-as-code discipline gave us confidence to iterate rapidly without fear of breaking production, and the property-based testing caught bugs we would have never found manually.

Most importantly, Kiro allowed us to focus on what matters: building a product that solves real problems for our users. Instead of wrestling with boilerplate code, debugging infrastructure issues, or searching documentation, we spent our time on product features, user experience, and business logic.

If you’re building a serious application, especially on AWS, we can’t recommend Kiro enough. The combination of AI-powered development, spec-driven design, and infrastructure-as-code is the future of software development. We’re excited to continue building Seddle with Kiro and can’t wait to see what we accomplish in the next six weeks.

Happy building!

Dustin Ellis

CEO & Cofounder at Lap 1 Labs, building Seddle to transform how teams make decisions. If you made it this far, thank you for reading! I would love to hear your thoughts and feedback. You can reach me at dustin@lap1labs.com, connect on LinkedIn, or book a meeting.