Building a Frankenstein App in 14 Days: How Kiro Changed My Development Workflow

The Challenge

During the Kiroween hackathon, I set out to build something ambitious: an API Schema Explorer that combines three typically separate developer tools into one unified platform. The app needed to:

1. Parse and explore OpenAPI specifications
2. Generate and serve mock API responses (Prism integration)
3. Generate production-ready client SDKs (OpenAPI Generator integration)

All of this in 14 days. Alone. Using an AI IDE.

It sounds impossible until you realize: each of these components already exists. The innovation isn't in building them; it's in seamlessly stitching them together. That's where Kiro became invaluable.

The Traditional Approach (What I Avoided)

Normally, this project would look like:

• Days 1-2: Scaffolding and boilerplate
• Days 3-4: Building upload/parsing logic
• Days 5-7: Integrating three separate tools
• Days 8-9: Fixing integration issues (when things break between components)
• Days 10-14: Praying nothing is broken

With that timeline, I'd probably end the hackathon barely functional.

My Kiro-Powered Approach

Instead, I implemented a three-phase strategy that leveraged Kiro's most powerful features: steering docs, spec-driven development, and context continuity.

Phase 1: Steering Docs Foundation (Day 1)

The breakthrough started before any code was written. I developed a detailed 14-day project plan with Claude, outlining:

• Architecture and tech stack decisions
• Feature breakdown and priorities
• Integration dependencies
• Development timeline

Then, I did something crucial: I configured Kiro to generate steering docs (product, tech and structure) from the plan and to automatically attach these docs to every new session.

In Kiro's settings, I enabled steering docs that covered:

• Product Overview: What the app does and why
• Tech Stack Rationale: Why Prism, OpenAPI Generator, HeroUI
• Architectural Decisions: Data flow, component relationships
• Development Constraints: "Maintain HeroUI components throughout," "Use Next.js API routes"

This meant every single session Kiro spawned would start with this constitutional document. It became the north star.

Why this mattered: I no longer had to re-explain architecture decisions or re-justify tech choices. Kiro automatically understood the context and constraints from Day 1 through Day 14.

Phase 2: Specification-Driven Architecture (Days 1-2)

With steering docs in place, I asked Kiro to generate comprehensive system design specifications for all the different features of the app in one spec session. This spec session included:

For each major component:

• Input/Output Contracts: What data flows in, what comes out
• Error Handling: How failures are managed
• Dependencies: What this component relies on
• Integration Points: Where it connects to other components
• Tech Specifics: Libraries, frameworks, patterns

The spec generation wasn't just documentation; it came with something powerful: design files, requirements files, and task files automatically generated for each feature.

The task files were particularly important. Each feature had a tasks.md file containing:

• Task 1: Build component A
• Task 2: Create API endpoint B
• Task 3: Integrate with component C
• (And so on...)

Why this mattered: Now I had not just a vague roadmap, but a precise specification that every piece of code would implement against. Implementation became predictable rather than exploratory.

Phase 3: Context-Driven Development with Task Files (Days 3-14)

Here's where my approach diverged from typical AI-assisted development:

Most developers treat each task as a fresh conversation. I didn't.

Here's my actual workflow:

1. I started Task 1 from the spec: "Build the upload form component using HeroUI"
2. When Task 1 was complete and working, instead of clicking Start Task for Task 2 (which would spin up a fresh session), I remained in the same conversation thread
3. Kiro automatically updated the spec with Task 1's completion status and I asked Kiro to continue with Task 2: "Create the API endpoint to parse the spec"
4. After Task 2 was done, I stayed in the same session again and moved to Task 3: "Build the explorer layout that displays parsed data"

All three tasks remained in the same conversation thread.

The benefit: Kiro remembered:

• That I'd already built the parser (no redundant implementations)
• That the explorer needed to receive data from the parser (automatic API integration)
• The exact error handling patterns I'd established
• My coding style and naming conventions
• More importantly, the issues that were faced in implementing the previous task, how it was fixed and makes sure not to repeat those mistakes.

Compare this to starting fresh: Three separate conversations means possible different code styles, different approaches to error handling, and three separate integration nightmares when things didn't line up.

Concrete example: When building the SDK generator UI, Kiro automatically ensured it used:

• The same HeroUI component library (without me saying "use HeroUI like before")
• Matching styling conventions and color schemes
• Dark mode support consistent with the rest of the app
• Error states matching the upload form's patterns

I never had to re-explain these decisions because the context was unbroken.

How Steering Docs and Specs Work Together

Here's the magic: Steering docs + specs + task continuity created a compounding intelligence.

In essence, every session Kiro spawned had:

1. Steering docs at the top (the constitutional layer)
2. The spec file (the architectural contract)
3. The current task context (what we're building right now)
4. The conversation history (what we've already built)

This four-layer context meant Kiro could make intelligent decisions without asking clarifying questions. It wasn't just following commands; it was architecting.

Key Learnings: What Actually Worked

1. Steering Docs Are Your Secret Weapon

The steering docs, configured to auto-attach to every session, became a constitutional document that prevented drift. Kiro referenced it constantly without me asking. This single feature probably saved 20-30 hours of explanation and re-clarification.

2. Specification-First, Code-Second

Having Kiro generate specs before code felt slow at first (extra time!), but it paid dividends:

• Implementation became predictable
• Integration issues appeared on paper, not at runtime
• Code generation was 3x faster because Kiro had a precise target, not loose requirements
• Debugging became easier (the spec defined what should happen, so deviations were obvious)

3. Context Continuity Beats Freshness

Starting a new AI conversation for every task feels clean and organized, but it wastes enormous cognitive effort reestablishing context and preventing same errors. Keeping the same session for related tasks lets the AI understand your system holistically. This is counterintuitive but powerful.

4. Task Files Bridge Specs and Implementation

The auto-generated task files were more than a checklist. They were a communication channel between me and Kiro. Kiro automatically updating them as it completed tasks kept it oriented without long explanations.

5. Working Integration Over Perfect Components

I didn't wait for polished UX. I got Prism running by Day 6, even with basic controls. Working integration > perfect design. Kiro helped me ship fast, then iterate on quality.

The Numbers

• Days to completion: 14 (vs. 25-30 estimated for manual development)
• Context switches: ~25 (vs. 80+ with fresh conversations per task)
• Integration issues found post-deployment: Yet to find one (vs. typical 12-15)
• Code quality: Production-ready without major refactoring
• My favorite metric: I spent 65% of my time thinking about architecture/integration and only 35% hunting bugs

What I'd Do Differently

1. Invest even more time in steering docs. They're the foundation. The better your constitutional document, the smarter Kiro becomes across all future sessions.

2. Version your steering docs and specs. As architecture evolved, I should have updated the spec file so every new session referenced the latest decisions.

3. Use task files as a two-way communication channel. Don't just use them to trigger Kiro, update them with notes of issues faced, and how they were resolved, in completing each task so Kiro knows what happened and what to avoid should you spawn a new task in a new session.

4. Lock your tech stack on Day 1. Every framework switch resets context. Steering docs prevent this, but minimize changes anyway.

5. Ask Kiro to explain the spec. Instead of assuming it understood, I should have asked: "Based on the spec, what's the contract between component A and B?" This catches architectural misunderstandings early.

The Bottom Line

Kiro didn't just write code for me. It became a system architect who understood my design decisions, remembered what I'd already built, and anticipated what I'd need next.

The real innovation wasn't in the tech stack (Prism, OpenAPI Generator are all existing tools). It was in having an AI that understood how to stitch them together consistently, and the steering docs and specs gave it that understanding.

Three specific Kiro features made this possible:

1. Steering docs auto-attached to every session (providing constitutional context)
2. Spec-driven generation (creating an architectural contract)
3. Task continuity within sessions (maintaining unbroken context across related work)

That combination changed my development workflow from "guess and fix" to "architect and build."

---

Have you used Kiro's steering docs or spec-driven approach in your projects? What surprised you most? Drop your experience in the comments. I'd love to hear how others are leveraging these features for rapid, cohesive development.