Kiro vs Potpie

Spec-driven development isn’t limited to writing requirements, it’s more about writing the right ones. While Potpie asks, probes, and grounds specs in the repo, Kiro assumes.

What is Potpie?

Potpie is an open source platform that uses ontology based knowledge graph to reason massive codebases spanning millions of lines of code. Potpie makes spec-driven development tractable at scale, producing file-accurate implementation plans directly from user requirements and specifications.

What is Kiro?

Kiro is a popular AI based IDE and CLI built by Amazon Web Services (AWS). Kiro provides a spec driven agentic coding environment for developing new software.

Quick Comparison

Kiro vs Potpie: Who wins in Spec-driven development?

For Spec-driven development to become the gold standard in building reliable features for modern codebases, instead of rushing into implementation, teams first define a detailed specification that captures requirements, dependencies, and edge cases. But not all spec-generation tools work the same way. We recently tested Potpie, Kiro by asking them to design a waitlist system for fully booked time slots in the Cal.com repo. The results unfolded striking differences in how each tool approaches clarity, accuracy, and developer intent.

We prompted each tool with the following Prompt.

“Add a waitlist system for fully booked time slots. When a time slot is full (for seated events) or already booked, users should be able to join a waitlist. When someone cancels their booking, automatically offer that slot to people on the waitlist in order.”

This scenario tested how well each tool could:

• Understand developer intent
• Expand requirements into a usable spec
• Handle edge cases and dependencies
• Ground its output in the actual Cal.com codebase

Potpie: Clarification First, Assumptions Later approach.

Potpie stood out by asking clarifying questions before writing anything down. For example, instead of assuming a default 24-hour acceptance window, it asked how long users should have to claim a cancelled spot. This probing approach ensured the spec reflected real developer intent rather than self-made assumptions.

Other Potpie strengths:

• Accurate file citations: Potpie mapped the exact files for each requirement. For example, Potpie identified the exact Typescript file for handling cancellations.

• Inference from existing codebase: Potpie identified the existence of a payment system and inferred from it to create a payment handling system. Potpie split each requirement into detailed states (e.g., PENDING, SENT, VIEWED, CLAIMED, EXPIRED) and handled edge cases.

• Unique Edge case identification : Potpie identified an edge case that if someone removes themselves from the waitlist, it doesn’t automatically release an offer since no slot has been freed.

• Concurrency solutions: Potpie proposed locks and async job queues to prevent double-booking.

• UI awareness: Instead of inventing new components, Potpie recognized existing inline replacements and recommended modifying them.

• Verification criteria: Each task came with clear success checks.

Potpie’s process was transparent, grounded in the repo, and mapped dependencies at the task level. It felt like working with a thoughtful teammate.

Kiro: Quick but Assumptive

Kiro started writing specs immediately, often relying on defaults. For example:

• Assumed a 24-hour timer without asking.

• Planned to add cancellation handling via an event listener, even though such a process doesn’t exist in Cal.com.

• Skipped payment lifecycle details entirely.

Verdict

While Kiro’s requirement doc used user stories, made the “why” behind each requirement clear. It missed phases of the user journey (like payment handling) and offered only one vague UI task for hosts. Overall, Kiro leaned heavily on general knowledge rather than repo-specific insights.

When it comes to spec-driven development, Potpie clearly outperformed Kiro, by Its ability to:

• Ask clarifying questions
• Ground specs in the actual codebase
• Handled unique edge cases
• Provide field level verification criteria

making it the most trusted thoughtful assistant for developers who want specs that translate seamlessly into code.

Spec-driven development isn’t just about writing requirements, it’s about writing the right requirements. Tools that clarify, probe, and ground their output in the repo save developers from expensive, high consequential rewrites and missed edge cases. Potpie proves that a thoughtful, repo-aware approach wins over speed and assumptions every time.