You’ve probably have heard of MCP servers by now.
They are basically plugins for AI agents.
MCP apps take it one step further because they come with a user interface. The agent does work in the background, and shows you something visual.
This short video shows how MCP apps look like:
In this case, I built the same MCP app twice: once with Traycer, once with Kiro. Let's see the process and compare the results.
First: What Is Spec-Driven Development?
You've probably also heard of vibe coding.. the thing where you just describe what you want to an AI, watch it write code, and fix things as they break. It feels fast and often works for small stuff. But on anything complex, it turns into chaos pretty quickly.
Spec-driven development is the opposite approach. Before you write a single line of code, you write specs — structured Markdown files that describe what you're building, how it should work, and what needs to happen. The AI then executes against that plan.
Both Traycer and Kiro do this. But they do it in very different ways.
The project
The app I was building was a mind-mapping MCP app.
It may sound simple but it's actually complex as MCP apps haven’t matured yet, and there’s a lot of inconsistent documentation out there.
Things break.. especially for very interactive usecase like mind mapping.
This is a good test for both tools.
Traycer
Traycer is a vs code extension that works in any editor you’re using. In my case, I use cursor so, I opened cursor.
Step one: brain dump. I typed out everything I was thinking in completely unstructured form and just sent it. no formatting whatsover. the organization is supposed to handle by traycer.
Traycer's response was an interactive Q&A. Think of it like a form, but conversational. It asked me about tech stack, edge cases, what I wanted the MCP UI to look like, and so on.
One thing Traycer flagged that I hadn't thought about was: should this use a database? I said sure, and it integrated Supabase (a database service for storage). That decision mattered: because if data lives in Supabase, the mind map is accessible from the web app and from any MCP client. Without that, it would've been ephemeral — only alive while the app was running.
After some back and forth it created the important spec files. What interested me most was that the specs can show HTML wireframes, showing what the end result would look like before I built it.
After specs were done, we broke them down into tickets and clicked execute. This sent those tickets one by one (some in parallel) to Cursor for execution. After each ticket, Traycer ran a verification layer that checked if the implementation matched the spec.
The output needed some tweaks but the design matched the plan.
Kiro
Kiro is a standalone agentic IDE, it’s not an extension. It’s its own editor, built by AWS, and both the planning and execution happen inside it. You download it, open it, and work entirely within Kiro.
When you open Kiro, you choose your mode. Vibe mode if you just want to build fast and loose. Spec mode if you want the structure. Both workflows exist in case you might want the other option depending on the day.
I opened spec mode and braindumped the same way I did with Traycer.
I noticed something different immediately: Kiro's questions came in text format. I had to type my answers. That's more friction than Traycer's clickable Q&A… and because it felt like more work to respond, I ended up explaining less than I would have otherwise.
Kiro's spec structure is clean and opinionated. Every project gets three files, always:
-
requirements.md: the what. What should this thing do? -
design.md: the how. What's the architecture? -
tasks.md: the todo list. What needs to be built, in what order?
These files live inside your project at .kiro/ — which means they're version controlled. You can push them to GitHub. You can reference themlater. That's a meaningful advantage if you care about documentation that survives the project.
Kiro also integrates directly with AWS services. Useful if your stack is already there.
What it didn't have: the HTML wireframes and almost no mermaid diagram visualizations. No visual preview of what you're building before you build it.
The output looked good, but was missing node adding, editing and delete functionality which is important to mind mapping. Probably because the Q&A wasn’t detailed and the mising verification layer.
MCP app built with traycer:
MCP app built with Kiro:
Conclusion
Building this app was a cool exercise in understanding what these tools actually are: they're both trying to solve the same problem — AI that drifts and forgets what it was supposed to build — but from opposite directions.
Traycer wraps around your existing workflow. The interactive planning, the wireframes, the verification layer — it all runs inside the tools you already use. The specs live on Traycer's platform, which means you can share them with teammates and assign tickets. The tradeoff: they're not in your repo.
Kiro replaces your workflow. The all-in-one IDE approach means planning and execution are integrated, specs live in your project as actual files, and integrates with AWS. The tradeoff: you're working inside a new environment, and the planning UX has more friction.
Which one you want depends on what you value more: flexibility and polish (Traycer) or integration and portability (Kiro).
Use Traycer if:
- You're already in Cursor, Claude Code, Antigravity and don't want to switch
- You want interactive planning over typing responses
- You want a verification layer per executed ticket
- Sharing specs with teammates matters to you
Use Kiro if:
- You want plan and execution in one environment
- You want your specs version controlled in the project
- You're in the AWS ecosystem
Top comments (0)