Forem: Fili

Traycer vs Antigravity: Fast Planning vs Structured Planning

Fili — Thu, 02 Apr 2026 16:40:15 +0000

Vibe coding without a plan is like gambling. It's sending prompt to a coding agent, and hoping the result will meet your desire.

But you never really know what you want. You probably won't fully explain your intent in one prompt.

The agent could misunderstand your intent, and execute the wrong thing, and reversing that and rebuilding takes more time than just planning upfront.

Both Traycer and Antigravity try to solve this. Instead of jumping straight to code, they make you plan first. They just do it very differently.

Antigravity: The Fast Food Cook

Antigravity is a standalone AI IDE built by Google.

When you send a prompt in Antigravity, it goes into plan mode first and immediately produces a single Markdown plan file. The plan has sections: proposed changes, example workflow, a verification checklist. It looks thorough, until you realise it assumed the wrong thing entirely.

But once you click proceed, it starts right away and builds. It has an action bias. It wants to move. It would rather start building and let you correct course than slow down to ask questions.

If you want more control, you have to explicitly state it in writing — just like telling a fast food cook exactly how you want your order. And to be clear: I'm not saying the code quality is as bad as fast food. But the process can end up far from the result you actually wanted.

The interesting part: Each line in the plan has a comment button… like Google docs. You can click on a line and leave a text comment to give feedback on that specific point. It’s a clever interaction model.

Traycer: The personal chef

Traycer is a VS Code extension that runs inside whatever editor you're already using: Cursor, VS Code, and even Antigravity — yes, you can layer Traycer on top of Antigravity. It's not a replacement for your tools, it's a layer on top.

When you send a vague prompt to Traycer, it doesn't plan immediately. It asks you questions. At least four in the first round, then more rounds as the picture gets clearer. The questions come as an interactive form: multiple choice, clickable options. You're not typing paragraphs, you're clicking answers.

This matters more than it sounds. When your idea isn't fully formed, writing a response is work. Clicking an option is easy. The clickable Q&A means you can participate in the clarification process without having already figured out what you want.

After the Q&A, Traycer builds out multiple plan files progressively:

A simple problem statement
A detailed plan with mermaid diagrams
A detailed plan with design and an HTML wireframe: a visual preview of what you're building before any code is written
Tickets: the execution units passed to your coding agent

That last step is the key architectural difference. Traycer doesn't execute code itself, instead it hands tickets to your agent (Cursor, Claude Code, etc.), which breaks them down further and runs them. After each ticket, Traycer runs a verification pass to check the implementation against the spec.

Side by Side:

	Traycer	Antigravity
Planning interaction	Interactive Q&A (clickable multiple choice)	Inline comments on plan (text only)
Plan output	Multiple files, built progressively	Single Markdown file
Visualizations	Mermaid diagrams + HTML wireframes	Text only
Verification	Automatic after each ticket	Manual review
Execution	Passes tickets to external agent	Builds internally
Architecture	VS Code extension	Standalone IDE
Speed	Slower, more checkpoints	Faster, fewer decisions

When Each One Makes Sense

Here's the framing I keep coming back to: it depends on whether you're starting from scratch or editing something that already exists.

When you're starting fresh, your idea is vague and that's okay. You can build fast, see what comes out, and iterate. The cost of a wrong assumption is low — nothing is broken yet.

When you're making changes to an existing codebase, wrong assumptions don't just produce imperfect output. They break things that already work. You want the AI to understand exactly what you mean before it touches anything. That's where Traycer's intent-extraction process earns its slower pace.

Use Antigravity if:

You're prototyping something new and want to move fast
Your idea is already fairly clear and you don't need to be questioned
You want everything in one environment — plan and build in the same place
You're comfortable correcting course after seeing an initial output

Use Traycer if:

You're working on an existing repo and need precision
Your idea isn't fully formed and you need help articulating it
You want visual output during planning — wireframes, diagrams
You want automatic verification at each execution step
You're already using Cursor or Claude Code and don't want to switch environments

I also compared Traycer with Kiro. read the full comparison here

Traycer vs Kiro (building an mcp app with both)

Fili — Wed, 01 Apr 2026 11:03:33 +0000

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

I Tested the Top Spec-Driven Dev Tools in 2026

Fili — Tue, 24 Mar 2026 15:02:53 +0000

Every major coding agent already has a plan mode. Claude Code, Cursor, Cline—they all ask you what you want, think through it, break it into steps, then execute. So why are there five different tools dedicated to spec-driven development?

I was curious, so I tested them. Here's what I found.

Kiro (by AWS)

Kiro is AWS's answer to spec-driven development. Launched mid-2025, it's a full VS Code fork, not just an extension bolted onto the side.

What it actually does: You've got two modes—vibe mode if you're just prototyping, and spec mode when you want structure. In spec mode, Kiro spits out user stories with acceptance criteria, a design doc, and a task list. You iterate on all three until they make sense, then Kiro analyzes your repo and builds an implementation plan with tasks sequenced by their dependencies. It even generates tests if you ask for them.

The workflow: Three markdown files—what you're building, how you're building it, the todo list. It's rigid, but in a way that's meant to keep things aligned.

The cost: It's free while they're in public preview, but now Kiro has pricing: Pro at $20/month, Pro+ at $40/month, and Power at $200/month. Different pricing from what was announced during preview, and honestly, if your team loves fast iteration and doesn't care about docs, the overhead might just annoy you.

Who it's for: Teams already on AWS, or people who like the idea of paying for a managed tool so they don't have to deal with API keys.

Kilo Code

Here's a fun one. Kilo Code is a fork of a fork of a fork. The original was Cline. Then Roo Code forked Cline. Then Kilo Code forked Roo Code. And then they all kept stealing ideas from each other. It raised $8 million and has 1.5M+ users, so it's doing something right.

What makes it different: Kilo has this Orchestrator mode that breaks your task into smaller subtasks and routes them to the right specialist—architect mode for planning, coder mode for actually writing, debugger mode for fixing. It also does inline autocomplete, which the other open-source tools didn't have for a while.

The real thing: Where Cline feels minimal and Roo Code feels like it's trying to be everything, Kilo lands in the middle. You get power without drowning in options. The one thing it doesn't have: web search built in, which you might miss if you're building something that needs to reference external APIs or documentation mid-task.

The problem: It's newer, so things are still moving fast. Some features like cloud agents and one-click deploy are half-baked. But honestly, since all three of these tools keep borrowing from each other, the gap is getting smaller every month.

Money: It's free to use (open-source extension). You bring your own API key. Realistically, you'll spend $20–200/month depending on how much you build and which model you're using. No markup, which is nice.

Who it's for: People who want the most features in an open-source package and don't mind tinkering with modes and settings.

Augment Code

Augment Code's whole thing is understanding your entire codebase at once. Most agents see your code one file at a time. Augment indexes up to 500,000 files and remembers how they all fit together—your microservices, shared libraries, the config files nobody looks at. It's genuinely different.

What this means: Instead of asking "how do I use this function" and getting a generic answer, Augment knows exactly where it's used across your whole repo. It can find bugs that span multiple services without you having to point them out.

The spec connection: Augment has been moving toward spec-like workflows through something called "Intent" features, but it's not as explicit about specs as Kiro or Traycer. The real value is the context depth—the AI understands your system before it plans.

The catch: There's no free tier. You're paying for that deep indexing and enterprise-grade context. If you have a small side project, this isn't for you.

Who it's for: Big teams with massive codebases (100k+ lines of code) where understanding the system is the biggest bottleneck.

Traycer

Traycer is built specifically for spec-driven development. It's a VS Code extension that sits on top of your existing agents (Cursor, Claude Code, whatever you're using) and acts like a senior engineer managing the process.

How it actually works: Instead of writing one giant spec that becomes outdated the moment something changes, Traycer uses "mini-specs"—a PRD, a tech plan, some wireframes, edge case notes. Each one small enough that you can actually maintain it. When you need to change course, you just update the relevant spec instead of rewriting everything.

Epic Mode is Traycer's main feature. You describe what you want, and it interviews you. It asks about the problem, your tech stack, edge cases, constraints. Then it generates PRDs, specs, tech flows, wireframes, sequence diagrams. Finally, it breaks everything into tickets small enough to hand to an AI agent (or a teammate) without them having to guess.

The thing that stuck with me: Verification is built in, not added later. As the agent works, Traycer scans your repo and makes sure the code actually matches the spec. If something drifts, it catches it.

Latest feature: Epic Mode collaboration. You can share Epic boards with your team in real time, edit specs and tickets simultaneously, assign work, and track ownership. Different roles (Editor/Viewer) control access.

Money: Free ($5 credits), Lite $20/month ($20 credits), Pro $40/month ($50 credits), Ultra $100/month ($150 credits).

Who it's for: People already using Cursor or Claude Code who want to add planning and verification without switching tools.

GitHub Spec Kit

This one's different from everything above. GitHub Spec Kit isn't a full tool. It's more like... a folder structure and a set of prompts that you use with whatever AI agent you already like.

How it works: You run specify init and it scaffolds your project with templates for your chosen agent (Claude, Copilot, Gemini, whatever). Then you use slash commands inside that agent—/specify, /plan, /tasks. That's it. You're steering the agent through prompts, not through a UI.

The interesting part: Spec Kit introduces constitution.md, which is where you write the non-negotiable rules for your project. "Always write tests." "We use this framework." "Security is handled this way." When the agent generates a plan, it enforces these rules.

The catch: It's terminal-based and has a steeper learning curve than the other tools here. You're not getting a visual interface or fancy orchestration. You're setting up a folder structure, running commands, editing markdown files, understanding how agents integrate with CLI. If you love the terminal and want maximum flexibility, this is perfect. If you want something that just works out of the box, you'll spend time reading docs.

The upside: You can use it with any agent, on any stack. It's open-source, so you can version your entire SDD workflow like code.

Who it's for: GitHub-native teams. People who want maximum flexibility and don't mind the CLI. Shops that want to version their SDD process alongside their codebase.

Quick Comparison

Tool	Format	Strengths	Best For	Friction Points
Kiro	Managed IDE fork	Structured specs, built-in workflow, no keys to manage	AWS teams, paying for simplicity	$20–$40/mo, opinionated
Kilo Code	VS Code extension	Multi-mode orchestration, inline autocomplete, free tier	Developers who want BYOK control, flexible model selection	No web search built-in, newer tool
Augment Code	VS Code extension	Deep codebase indexing, 500k file support	Enterprise-scale repos	Paid-only, focused on context not workflow
Traycer	VS Code extension	Mini-specs, verification built-in, Smart YOLO, integrates with existing agents	Teams with Cursor/Claude Code	Steeper learning curve for Epic Mode
GitHub Spec Kit	CLI + templates	Open-source, agent-agnostic, versionable workflows	GitHub-native shops, terminal users	Steeper learning curve, CLI-based complexity, requires agent integration knowledge

So... Why Even Use These?

Real talk: Claude Code has plan mode. Cursor has plan mode. Cline has plan mode. All of them will break down your task and show you the thinking before they code.

The difference is that spec-driven tools treat the plan as a persistent artifact. With Claude Code, you approve the plan and it codes. The plan is gone. With Traycer, that plan becomes a ticket system. With Kiro, it becomes a document you can reference later. With GitHub Spec Kit, it's version-controlled markdown in your repo.

So the question isn't "do I need a plan?" You already have that. The question is "do I want to keep and version the plan as part of my project?"

If you're building solo or shipping fast, probably not. If you're building something that needs handoff, needs to be maintained, or your team needs to understand the reasoning later—then maybe.

These tools exist because plan modes in existing agents are ephemeral. Spec-driven tools make them permanent.

Two Ways of Building with AI — With and Without Traycer

Fili — Wed, 11 Mar 2026 10:51:13 +0000

After a year of building with Cursor, I started noticing a pattern. There are basically two modes of AI-assisted development. One I did for a long time. The other is what happens when you add Traycer.

How the AI understands what you actually want

When you use Cursor alone, the AI makes assumptions. You describe a feature, it makes its best guess at the intent, and starts coding. Sometimes the guess is right. Often it's mostly right — but "mostly right" in a codebase compounds fast.

Traycer's Epic Mode doesn't jump straight to code. It asks. Not just one clarifying question — it keeps going until the intent is actually clear. Things like: "Should this live in the same repo, or a separate project?" "How should errors be handled?" "What about backward compatibility?"

Without Traycer: Describe the feature → AI makes assumptions → code gets written → you discover a missed edge case in review (or worse, in production).

With Traycer: Describe the feature → Traycer asks about repo structure, error handling, edge cases → intent is documented → then code gets written. The refactor that would've happened later doesn't happen at all.

What you're left with after the session ends

Here's something that doesn't show up in demos: what happens when you close your laptop and come back the next day.

Without Traycer, your context lives in chat history. The to-do list Cursor generated makes sense in the moment, but by tomorrow you've forgotten why you wrote step 3 the way you did, what you were worried about, what you decided not to do and why. You end up re-reading the whole chat to reconstruct your own reasoning.

With Traycer, the intent is in the artifact. Each ticket has its own spec, acceptance criteria, and dependency chain. You can pick up exactly where you left off — days later — without re-reading anything.

Without Traycer: A linear to-do list tied to chat context. Come back tomorrow and it's just a list of tasks with no memory of the decisions behind them.

With Traycer: Structured tickets with specs, acceptance criteria, dependencies. Self-contained. Readable without the chat. The intent survives the session.

Linear building vs. looped building

The more I've used both, the more I think this isn't really about tools — it's about two different mental models for AI-assisted development.

Linear: prompt → code immediately. Fast. Works great when you know exactly what you want. Still the right call for prototypes and quick features.

Looped: clarify → plan → code → verify. Slower upfront. But you close the loop intentionally instead of accidentally — in review, or when something breaks.

Here's the thing: we were always doing the loop manually. Every time you verify output, debug a regression, or refactor something the AI got wrong — that's the loop. Traycer just makes it explicit, structured, and earlier. It moves the cost from the back end (debugging) to the front end (clarifying), where it's much cheaper.

For bounded tasks where the shape is clear: go fast, go linear.

For complex builds, multi-session work, or anything where you're figuring it out as you go: the loop is worth it.

TL;DR

Linear building (Cursor alone): fast, works great for small tasks, but assumptions compound and context doesn't survive the session.
Looped building (with Traycer): slower upfront, but intent is documented, tickets are self-contained, and the refactor that would've happened later doesn't happen at all.

If you work on anything multi-session or multi-ticket, it's worth trying. Traycer has a free tier and you can get 10 credits on first payment with this link.