Coder Legion - Recent posts tagged kiro

From Idea to Production: Building a Spider-Man Tic-Tac-Toe Game with Kiro

Thu, 30 Jul 2026 06:41:20 +0000

AI coding tools are changing how we build software, but I wanted to explore what it looks like to use AI as part of the software engineering process, not just for generating code.

In my latest article, I walk through building a Tic-Tac-Toe game with Kiro, covering:

Spec-Driven Development
Steering
Hooks
Model Context Protocol (MCP)
Building the application step by step
Lessons learned from using Kiro in a live student workshop

I also share some honest reflections on the experience and a few areas where I think Kiro can continue to improve.

Read the article here:
https://shakiran.hashnode.dev/building-tic-tac-toe-game-with-kiro

I'd love to hear your thoughts! Have you tried Kiro or another AI-powered IDE? What has your experience been like?

Full workshop here:
https://youtu.be/WR1aQBMB338

Live Demo: https://kiro-tic-tac-toe-workshop.vercel.app/

Kiro vs Cursor: Spec-Driven or Flow? Choosing Your Agentic IDE in 2026

Mon, 29 Jun 2026 15:11:16 +0000

If you're shopping for an AI coding environment in 2026, two names keep surfacing in very different conversations. Cursor shows up when developers talk about raw speed and staying in the flow. Kiro, AWS's agentic IDE, shows up when teams talk about shipping software that survives contact with maintenance. They're both "agentic IDEs," but that label hides the fact that they're built on opposite bets about how good software actually gets written.

I've spent real time in both — on multi-file features, not toy demos — and this is the comparison I wish I'd had before picking a side. I write and teach about agentic engineering at Cursuri-AI.ro, Eastern Europe's AI education platform, so I'll keep this grounded in how these tools behave in real projects rather than in launch-day hype.

One disclaimer up front: pricing and features in this category change almost monthly. Everything below is a mid-2026 snapshot — verify the current numbers on each tool's official page before you commit a team budget.

The core difference in one sentence

Cursor optimizes for speed-to-keystroke; Kiro optimizes for correctness-to-intent.

That's the whole article, really. Cursor wants to keep you in flow — type intent, get code, see the diff, keep moving. Kiro wants to slow you down at exactly one point — before implementation — so the agent builds the thing you actually meant. Everything else is a consequence of that one philosophical split. Let's unpack both, then put them head to head.

What is Cursor?

Cursor is an AI-native IDE built as a fork of VS Code, so the editor feels instantly familiar — extensions, keybindings, and themes mostly carry over. The difference is that the AI isn't a bolted-on plugin; the whole editing experience is designed around it.

Its signature capabilities:

Tab completion — a multi-line, context-aware autocomplete that predicts your next edit, not just the next token. It's the feature people miss most when they leave.
Composer — Cursor's agentic, multi-file editing mode. Describe a change in natural language and it edits across files, runs commands, and iterates. Cursor now ships Composer 2.5, its own model trained for agentic coding, alongside routing to frontier models from Anthropic, OpenAI, and Google.
Cloud Agents — introduced in the Cursor 3.5 release (May 20, 2026), these run in isolated cloud VMs with terminal and browser access, work across multiple repos in parallel, and report back to your IDE asynchronously.

Cursor's center of gravity is in-the-flow coding: you stay in the editor, see every diff, and the AI keeps pace with your thinking. It rewards developers who want speed without giving up granular control.

What is Kiro?

Kiro is an agentic IDE from AWS, also built on the Code OSS foundation (the open-source base behind VS Code), so the editor itself is familiar. What's radically different is the engine. Kiro launched broadly in May 2026 as a ground-up successor to Amazon's earlier AI coding effort, and its headline idea — in its own framing — is "moving beyond AI coding to agentic engineering."

Instead of treating each request as a one-off chat turn, Kiro turns a high-level prompt into a structured spec, then drives implementation from it. The pillars:

Spec-driven development — a feature request becomes three reviewable artifacts: requirements (written in EARS notation — Easy Approach to Requirements Syntax, a real, lightweight technique for testable requirements), design (architecture, components, data flow), and tasks (a sequenced, trackable list the agent implements in order). You review and correct at each stage, so ambiguity surfaces before code exists.
Agent hooks — event-driven automations that fire when something happens in your workspace (file save, file created, commit opened). Wire "run tests and a security scan on save" once and forget it.
Steering files — markdown files that give Kiro persistent context about your conventions, libraries, and architecture, so you stop re-explaining your stack every session.
Model routing and MCP — Kiro's auto-router selects across multiple models (Claude Sonnet, Qwen, DeepSeek, and others) running on Amazon Bedrock, and it supports the Model Context Protocol for connecting external tools and data sources.

Kiro's center of gravity is structure: front-load requirements and design, get an auditable trail of why the code is the way it is, and treat the spec as living documentation that doesn't rot.

Head-to-head: the dimensions that matter

Workflow philosophy

This is the real decision. Cursor assumes you'll steer continuously — you're in the loop on every diff, correcting as you go. Kiro assumes you'll steer up front — you invest in the spec, then let the agent execute against it. Cursor feels faster minute-to-minute; Kiro feels more accountable feature-to-feature. Neither is wrong; they fit different work.

Speed vs. maintainability

Cursor wins on time-to-first-result. For exploration, prototypes, bug fixes, and one-file changes, the flow model is simply quicker — there's no spec overhead to pay. Kiro wins when the work is durable and shared: the spec phase is overhead that pays off precisely when more than one person (or agent) will touch the code and conventions matter. Reach for Cursor's flow on a throwaway script; reach for Kiro's specs on a feature that has to live.

Automation and persistent context

Both fight the "re-explain your project every session" problem, but differently. Kiro makes it first-class with steering files and agent hooks — persistent rules plus event-driven automation baked into the IDE. Cursor has project rules too, but its automation story is lighter and more editor-centric. If you want the agent to behave like a teammate who's read your style guide, Kiro's approach is more explicit. This is really context engineering applied to a coding agent — and encoding the durable knowledge an agent needs is a discipline in its own right, one our course on context engineering and agent memory covers end to end.

Models

Both route across multiple models rather than locking you to one. Kiro's auto-router runs on Amazon Bedrock; Cursor blends its own Composer model with frontier models from the major labs. Practically, you're not betting on a single model with either — a healthy default in a year where model availability itself has proven volatile.

Extensibility (MCP)

Both support the Model Context Protocol, the open standard that lets an agent reach your database, ticketing system, or internal docs without bespoke glue for each one. MCP support matters more than it sounds, because it's what turns a code assistant into something wired into your actual stack. If MCP is new to you, building and integrating MCP servers is its own skill set — our MCP course walks through standing up real servers and wiring them into agentic workflows.

Pricing, side by side (mid-2026 snapshot)

	Free tier	Entry paid	Notes
Cursor	Hobby (free)	Pro — $20/user/mo	Teams at $40 and $120/user/mo; Pro includes a fixed pool of frontier-model usage
Kiro	50 agent interactions/mo	Pro — $19/user/mo	Higher tiers add more interactions; credit-based, no daily/weekly rate limits, pre-paid overages

A couple of honest notes on cost:

Cursor's $20 Pro includes a fixed amount of frontier-model usage; heavy users hit the ceiling and either upgrade or lean on its cheaper Auto/Composer routing.
Kiro meters by agent interactions rather than tokens, which some teams find easier to reason about; enterprise tiers add IAM/SSO, usage dashboards, cost controls, and IP indemnity.

Prices and tiers shift constantly here. Treat the table as a snapshot, not a quote, and confirm before budgeting.

So which should you choose?

The honest, task-based answer:

Choose Cursor if you want the best in-the-flow editing experience, you value fast inline generation and tight control over every diff, and most of your work is exploratory, iterative, or single-file. It's the natural pick for a developer who loves their editor and wants AI to keep pace.

Choose Kiro if you're building features meant to live and be maintained, more than one person touches the codebase, and you want an auditable trail of why the code looks the way it does. The spec phase is overhead that buys you correctness and maintainability — worth it exactly when the work is durable.

And the answer a lot of senior engineers actually land on? Both, by task. Vibe-code the prototype in Cursor; spec out the production feature in Kiro. The two philosophies aren't rivals so much as different modes for different moments — and knowing which mode fits which task is the real skill. That through-line, the spectrum from prompt-to-app speed to structured engineering, is exactly what our vibe coding course treats as complementary philosophies rather than a holy war.

The skill underneath the tools

Here's the part the demos hide: both tools amplify the engineer you already are. Point Cursor's flow at a vague intent and you get a fast wall of code you didn't design. Point Kiro's spec phase at sloppy thinking and you get a beautifully structured plan for the wrong thing. The developers getting real leverage from either aren't the ones who memorized the shortcuts — they're the ones who understand specs, agent architecture, context management, and the MCP ecosystem underneath.

That foundation is what we build at our Eastern European AI education platform — practical, project-based courses taught around real repositories with an interactive AI instructor, not slide decks. If you mainly want to master the AI-native editor workflow, our hands-on track on using Cursor as a pro is built around real multi-file, real-repo work rather than toy examples.

Frequently asked questions

Is Kiro better than Cursor?

Neither is universally "better" — they optimize for different things. Kiro is better for durable, maintained software where a spec and an audit trail pay off; Cursor is better for fast, in-the-flow coding, prototyping, and single-file changes. Match the tool to the task, not to a tribe.

Can I use Kiro and Cursor together?

Yes, and many engineers do. A common pattern is prototyping or exploring quickly in Cursor, then using Kiro's spec-driven flow for production features that need to be reviewed and maintained. They're complementary modes, not mutually exclusive products.

Are Kiro and Cursor based on VS Code?

Both build on the Code OSS foundation behind VS Code, so the editor surface feels familiar in either. The difference is the engine, not the shell: Cursor centers on in-editor flow, while Kiro centers on turning prompts into specs before code.

Do Kiro and Cursor support MCP?

Both support the Model Context Protocol, the open standard for connecting external tools and data sources to the agent. That means you can wire either into your database, ticketing system, or internal docs without bespoke integration code for each one.

Which is cheaper, Kiro or Cursor?

As of mid-2026 their entry paid tiers are close — Cursor Pro at around $20 per user per month and Kiro Pro at around $19 — but they meter usage differently: Cursor includes a fixed pool of frontier-model usage, while Kiro counts agent interactions. Your real cost depends on how heavily you use the agent, so check both pricing pages against your actual workload before deciding.

Conclusion

Kiro and Cursor aren't really competing for the same slot — they're two answers to two different questions. Cursor asks "how do I keep a developer in flow and fast?" Kiro asks "how do I make the agent build what was actually meant, in a way we can maintain?" Both answer their own question extremely well, and both are compromised at the other one.

So don't ask "which is better." Ask "better for which task, on which kind of code." Build the judgment to use the spec when the work is durable and the flow when it's disposable — and you'll get more out of either tool than someone who picked a tribe. Try each on a real feature, not a demo, and the difference becomes obvious fast.

Written by the team at Cursuri-AI.ro — practical, hands-on AI engineering courses for developers and professionals across Eastern Europe, from agentic coding and MCP to context engineering and the modern AI-native IDE workflow.

Sources: kiro.dev · Kiro Specs docs · Kiro pricing & docs · Cursor Models & Pricing

KiroGraph: from a personal side project to community-AI-driven tool

Wed, 27 May 2026 08:24:08 +0000

This is the second part of my "Build in Public with Kiro" series. I'm an AWS Community Builder, and this is the story of what happens when you share something early, people actually care, and the project grows faster than you expected.

TL;DR

Since the first article, KiroGraph went from a CLI agent prototype (v0.5.0) to a multi-client, 30+ language, architecture-aware code knowledge graph (v0.13.1). It's now published on npm, has a full documentation site, an interactive graph dashboard, and supports Claude Code and Codex alongside Kiro. Most of this happened because people showed up, contributed, and pushed the project in directions I hadn't planned.

{% github davide-desio-eleva/kirograph %}

Where we left off

The first post covered the core idea: pre-index your codebase into a semantic graph so the AI agent queries structure instead of re-reading files. At that point KiroGraph had structural indexing, seven semantic engines, an interactive installer, and a CLI agent for kiro-cli.

That was v0.5.0. Here's what happened next.

Kiro acceleration effect

I want to be honest about something: this pace of development wouldn't have been possible without Kiro.

KiroGraph went from v0.5.0 to v0.13.1 in about five weeks, adding architecture analysis, 14 new languages, 17 framework resolvers, an interactive graph dashboard, multi-client support, npm publication, a documentation site, and dozens of bug fixes. As a side project. With a day job.

Kiro's spec-driven development is the reason. When I need to add a new framework resolver, I don't start from a blank file. I write a spec, Kiro breaks it into tasks, and the implementation flows from there. The agent understands the existing patterns (especially with KiroGraph indexing itself), so new code fits the architecture without me hand-holding every decision.

But here's where it gets interesting for open source specifically.

Simpler to contribute

When contributors work in a TypeScript codebase that isn't their primary stack, it's Kiro that makes that possible. The spec-driven approach gives structure to the work, the agent handles the TypeScript idioms, and the contributor focuses on what they actually know: the domain expertise. Someone who knows Elixir deeply can contribute a full Phoenix framework resolver without being a TypeScript expert. Someone who understands how Claude Code's MCP configuration works can wire up a multi-client integration without knowing the internals of the indexing pipeline.

I received PRs for features I wouldn't have imagined building myself, in domains where I lack expertise, and they were solid. My role shifted from "implement everything" to "review and guide". That's a fundamentally different way to run an open source project.

It works the other way around as well

Community members bring ideas from their domain. Architecture analysis, coupling metrics, layer detection patterns. These came from people who understood the problem space deeply. I had the codebase context and the TypeScript implementation skills. Kiro bridged the gap: their ideas became specs, specs became tasks, tasks became working code. Fast.

This is the pattern I didn't anticipate: community members bring domain knowledge and ideas, Kiro accelerates the implementation regardless of who writes the code, and the project ships features that no single person would have built alone.

People as global reviewer

When you build in public with an AI-accelerated workflow, the community acts as a global reviewer. People try KiroGraph on codebases I've never seen, in languages I don't write daily, with frameworks I've never used. They find the bugs that only surface in production-like conditions.

he multi-language call edge bug in v0.12.0 had actually existed since v0.1.0. Nobody noticed because nobody was using KiroGraph on a Java project until someone did.

Speed matters here and when a bug report comes in, I can fix it very quickly. Kiro understands the codebase, the fix is scoped, the PR is merged, and the reporter sees their issue resolved in hours, not weeks. That responsiveness builds trust, and trust brings more contributors.

⚡ Acceleration is real

I'm not being hyperbolic: combination of Kiro's spec-driven development, KiroGraph's self-indexing feedback loop, and a community that both contributes code and stress-tests the result creates a development velocity that feels disproportionate to the effort. One person maintaining a 30+ language code analysis tool with 18 MCP tools, seven semantic engines, and an interactive dashboard shouldn't be sustainable. But it is, because the tooling makes it sustainable.

If you're hesitant to contribute to a project because the stack isn't your primary one, Kiro removes that barrier: the domain expertise is yours while the implementation details are handled.

Kiro Community

As mentioned earlier, the project's trajectory changed because people from *Kiro Community engaged with it. Two main examples:

Maurizio Argoneto commented on the first post about "hierarchical summarization" and the "big picture" problem. That conversation directly influenced the architecture analysis feature, one of the most useful additions for understanding large codebases at a high level.
Alessandro Franceschi contributed Elixir/Phoenix language support and the multi-client integration (Claude Code and Codex), expanding KiroGraph well beyond its original Kiro-only scope.

I was initially reluctant to open this project to other AI clients, agents, or IDEs, but Alessandro explained the situation to me very clearly: people are using Kiro in a wide range of ways and within a multi-tool AI development process that fits their needs. Restricting this project to Kiro alone would, in my view, mean closing the door to those who actually want to use it in this scenario. So I’m not opening it to competing AIs, but rather to complementary ones.

The stargazers, the folks who opened issues, the people who tried it on their own codebases and reported what broke. All of that feedback shaped what got built and in what order. That's the kind of feedback loop that makes building in public worthwhile.

Kiro Community is really outstanding in this.

The project has been recognized by AWS Community Builders team

And also enthusiastically endorsed by Kiro Ambassadors

Noted by Vice President at Amazon Web Services

Loved by far more people than I might imagine (those are just sample, I may be missing some screenshots, apologies for that!)

New features by numbers

As a result, from v0.5.0 to v0.13.1, I've added several features:

30+ languages supported (up from 17)
17 framework resolvers added
18 MCP tools (up from 12)
Interactive graph dashboard with search, path finding, clustering, heat maps
Architecture analysis with coupling metrics
Multi-client support (Kiro, Claude Code, Codex)
Full documentation site
Published on npm

️ What got built

Now let's walk through the features themselves.

️ Architecture analysis (v0.6.0)

An architecture layer that detects packages (via manifest files like package.json, go.mod, Cargo.toml, pom.xml, etc.) and assigns files to architectural layers: api, service, data, ui, shared. Each layer uses language-specific glob patterns, so a Python Flask project and a TypeScript Express project both get correctly classified.

On top of that, KiroGraph now computes coupling metrics between packages: afferent coupling (Ca), efferent coupling (Ce), and instability (Ce / (Ca + Ce)). Three new MCP tools expose this to the agent: kirograph_architecture, kirograph_coupling, kirograph_package.

The practical effect: when Kiro needs to understand where a new feature should live, or whether a refactor will create circular dependencies between packages, it can query the architecture graph instead of guessing from file paths.

Embedding model selection (v0.7.0)

The installer now presents an arrow-key menu with four curated models plus a custom option. The embeddingDim config field means all vector engines adapt automatically. Migrated from @xenova/transformers (v2) to @huggingface/transformers (v3), enabling support for modern ONNX models.

The esbuild migration (v0.8.0)

The old tsc build took 5-10 seconds. After migrating to esbuild + tsx, builds dropped to ~400ms with incremental watch mode. Type checking is now decoupled (npm run typecheck), so you get fast feedback during development and correctness checks when you need them.

Small change, big quality-of-life improvement. Especially when you're iterating on the tool using the tool itself.

Caveman mode (v0.9.0)

Inspired by caveman by JuliusBrussee. The insight: KiroGraph's graph tools already return compact, structured data. The bottleneck in long sessions isn't the tool calls, it's the verbose prose the agent wraps around them.

Caveman mode compresses the agent's communication style. Four levels: off, lite, full, ultra. At ultra, you get abbreviations, arrows for causality, maximum compression. The rules are injected via the steering file and CLI agent prompt, so they're always in context with zero extra tool calls.

It never touches code blocks, file paths, or technical terms. Only prose. And it auto-reverts to normal for security warnings or irreversible actions.

kirograph caveman ultra   # maximum compression
kirograph caveman off     # back to normal

Hotspots, snapshots & dead code (v0.10.0)

Three new MCP tools that give the agent analytical capabilities:

kirograph_hotspots finds the most-connected symbols by edge degree. Before you touch a function, you want to know if it's called from 3 places or 300.
kirograph_surprising finds non-obvious cross-file connections. Scores edges by path distance × kind weight. The highest-scoring pairs are the ones that represent unexpected coupling worth investigating.
kirograph_diff compares the current graph against a saved snapshot. Save before a refactor, diff after. See exactly what changed structurally.

Plus CLI commands for all of them, and a snapshot system (kirograph snapshot save|list|diff) that stores lightweight graph states in .kirograph/snapshots/.

Interactive graph dashboard (v0.11.0)

kirograph export now renders a full interactive graph visualization. No server required, works offline, three static files.

This is the kind of thing that's hard to describe in text. You open it in a browser and suddenly the structure of your codebase is visible. Where the hotspots are, which modules are tightly coupled, where the dead ends live.

Elixir, Phoenix, Java/C# edge cases (v0.12.0)

Full Elixir language support: modules, functions, macros, protocols, implementations, structs. Plus Phoenix framework detection with route extraction from router.ex.

The bigger fix in this release was improving multi-language call edge extraction. It turned out that walkForCalls only recognized call_expression (JS/TS/Go/Rust), which meant C#, Java, Python, Ruby, and PHP produced zero call edges. The kirograph_callers and kirograph_callees tools were silently returning nothing for those languages. Fixed now, with per-language name extraction using tree-sitter field lookups.

Same story for inheritance edges in C# and Java, and namespace/package import resolution. These were the kind of bugs that only surface when real people try the tool on real codebases in languages other than TypeScript.

Sync progress & stability (v0.12.1)

Large codebase support got serious attention here. Paginated embedding (pages of 2,000 instead of loading everything into memory), WASM parser poisoning detection (skip a language if its parser aborts instead of retrying every file), sync progress output, and a staleness warning in kirograph_status when the index is behind.

The MCP sync awareness is particularly nice: when pending unindexed files exceed a threshold, the agent gets a warning and can choose to wait rather than working with stale data.

Documentation site & npm (v0.12.2)

KiroGraph is now published on npm (npm install -g kirograph) and has a full documentation site with dark theme, responsive layout, scroll-spy navigation, and pages for docs, MCP tools, CLI reference, and changelog.

This was overdue. A tool that saves tokens shouldn't require reading source code to understand how to use it.

And also how it evolves

The big language expansion (v0.13.0)

14 new languages in one release: Scala, Lua, Zig, Bash, OCaml, Elm, Solidity, Vue, Objective-C, YAML, HCL/Terraform, CSS, SCSS, HTML.

So many languages that I had to add a search feature to the docs.

17 new framework resolvers: Play (Scala), Nuxt/Vue, Solidity (Hardhat/Foundry/Truffle), SST, AWS CDK, Serverless Framework, AWS SAM, Terraform/OpenTofu, Pulumi, CloudFormation, Kubernetes/Helm, Docker Compose, Ansible, Angular, and AWS Amplify Gen 2.

My best pick: since I regularly work on IaC projects, why shouldn’t I use KiroGraph for them?

This is where the project's scope expanded significantly. KiroGraph started as a TypeScript-focused tool. Now it indexes infrastructure-as-code (Terraform resources, CloudFormation stacks, Kubernetes manifests), smart contracts (Solidity with Hardhat/Foundry detection), and serverless configurations (SAM, CDK, SST handler resolution).

The framework resolvers are particularly useful: they understand that a handler string like "src/handlers/auth.handler" in a SAM template points to an actual function symbol, and they create the edge in the graph. The agent can then trace from an API route all the way to the implementation without reading YAML files.

Multi-client support (v0.13.1)

KiroGraph can now be installed for Claude Code and Codex in addition to Kiro.

kirograph install --target claude  # .mcp.json + .kirograph/claude.md + CLAUDE.md import
kirograph install --target codex   # .kirograph/codex.md + AGENTS.md block

All targets share the same .kirograph/ data. Installing another target only writes that tool's integration files. The graph is the graph, regardless of which agent queries it.

Kiro remains the primary supported target. Claude Code and Codex are marked experimental, but they work. The community asked for it, and it made sense: the value of a pre-indexed code graph isn't tied to a specific IDE.

What's next

The roadmap from the first post is mostly done.

What's left and what's new:

Smarter sync: content hash per embedding to skip unchanged symbols even when the file was modified. The paginated embedding in v0.12.1 was a step, but there's more to gain.
Cross-project search: for monorepos and workspaces with shared libraries. The graph is per-project right now.
Richer graph traversal: "explain this path" semantically, not just the nodes but why each edge exists.
Plugin system for engines and languages: the abstractions are clean enough that external contributions could be self-contained packages.
Kiro Power packaging: embedding KiroGraph into a configurable Kiro Power to reduce friction for folks who just want to install and go.

But in reality, the community is shaping the roadmap: this tool is designed to save tokens and improve the AI’s understanding of the provided code, so it is the users who ultimately determine what matters most.

This is happening daily:

What’s really on my mind: I’m particularly curious about what it would mean to integrate features from RTK into KiroGraph. I’m not aiming for a “one tool for everything” approach, but if I had to prioritize, this is probably what I’d focus on first (spoiler here).

Try it

npm install -g kirograph
cd your-project
kirograph install

The installer walks you through everything. Start with cosine if you're not sure which engine to pick. Switch later if you need to.

{% github davide-desio-eleva/kirograph %}

The repo is public. PRs are welcome, I'd love to hear from you.
A very special thanks to the Stargazers, your support means a lot and truly makes a difference.

Who am I

I'm D. De Sio and I work as a Head of Software Engineering in Eleva.
As of Feb 2026, I’m an AWS Certified Solution Architect Professional and AWS Certified DevOps Engineer Professional, but also a User Group Leader (in Pavia), an AWS Community Builder and, last but not least, a #serverless enthusiast.

Building KiroGraph: a 100% local semantic code knowledge graph for Kiro

Wed, 27 May 2026 08:23:42 +0000

This is part of my "Build in Public" with Kiro series. I'm an AWS Community Builder, and this is the story of building a tool by using the tool itself, which is either very meta or very efficient, depending on how you look at it.

TL;DR

KiroGraph is a local code indexing system for Kiro AI IDE. It turns your codebase into a queryable structural using a semantic graph, dramatically reducing AI tool calls and token usage (up to 90%).

Instead of re-reading files with grep/glob, the AI queries a pre-built AST-based graph (plus optional embeddings), making code navigation faster, cheaper, and more scalable.

It supports multiple vector engines (e.g. SQlite, PGlite, Orama Qdrant, Typesense) and is fully local, with an interactive installer and automatic syncing.

{% github davide-desio-eleva/kirograph %}

How it started

A few weeks ago I came across CodeGraph by Colby McHenry, a semantic code knowledge graph for Claude Code. The idea was brilliant: instead of letting the AI wander through your codebase with grep and file reads, you give it a pre-indexed 100% local graph it can query instantly.

Fewer tool calls, less context burned, faster responses.

I use Kiro, AWS's spec-driven AI IDE, and there was nothing equivalent for it. So I did what any reasonable developer does when they see a good idea: I ported it.

That's how KiroGraph started but the community’s genuine interest motivated me to essentially rebuild CodeGraph from the ground up and significantly expand its functionality.

Why this should matters to us (the token problem)

When you ask an AI agent to work on a complex task, "fix the auth bug", "add rate limiting to the API", "refactor the payment service", the agent needs to understand your codebase before it can do anything useful. The way it typically does that is by reading files, running grep, globbing directories. Every one of those is a tool call.

Tool calls cost tokens. Lots of them. And they're slow.
Aside from cost, we’re currently in a period where reasonable plans for using AI are either being rate-limited or subject to increasingly restrictive limits. The community is actively exploring solutions to optimize requests and responses, reduce token usage, and improve overall efficiency.

The insight behind KiroGraph (and CodeGraph before it) is simple: your codebase doesn't change that often. Between agent runs, you might touch a handful of files.

Why should the agent re-discover the structure from scratch every single time?

KiroGraph pre-indexes everything, functions, methods, classes, interfaces, types, call relationships, import graphs, type hierarchies, into a 100% local SQLite database. When Kiro needs context, it doesn't read files. It queries the graph. One MCP tool call instead of twenty file reads and multiple tool calls.

The impact is real: tasks that once consumed entire context windows simply don’t anymore: saving tokens, improving efficiency, and delivering greater speed.

⚖️ Benchmark

An image is worth a thousand words

Up to a 90%+ reduction in token usage for common read patterns in the KiroGraph codebase. I can confirm similar results across different and larger codebases as well.

These numbers represent the average outcome of identical requests executed with and without KiroGraph, across different semantic engines for comparison.

What this practically means for me is that I used up all my tokens with Kiro on the $20 plan in just 10 days. Now, I’ve gone a full month without even reaching the full allowance.

️ KiroGraph architecture

The tool has two indexing layers.

Structural indexing is always on. tree-sitter parses every source file into an AST and extracts nodes (functions, classes, routes, components, 24 kinds total) and edges (calls, imports, extends, implements, references, and more). Everything lands in kirograph.db. This powers all the graph traversal tools: find callers, trace impact, detect circular deps, find dead code.

Semantic indexing is opt-in. When you enable it, KiroGraph generates 768-dimensional vector embeddings for every embeddable symbol using nomic-ai/nomic-embed-text-v1.5 (~130MB, downloaded once to ~/.kirograph/models/). This powers natural-language search, ask for "auth middleware" and get the relevant functions even if they're named validateJwt or checkPermissions.

The index stays fresh automatically via Kiro hooks.
File saved, mark dirty. Agent stops, sync if dirty.
Batched, efficient, zero overhead during active editing.

The agent knows what to do through a Kiro steering file, which the final KiroGraph adopter can easily adapt to suit their specific needs.

Is KiroGraph a RAG/GraphRAG?

It’s useful to compare KiroGraph to both a classic RAG system and a GraphRAG approach, because it sits somewhere in between, but also slightly outside both categories.

1) A local RAG works on unstructured text, splitting documents into chunks and retrieving the most relevant pieces via embeddings.
KiroGraph instead indexes code structure, where functions, classes, and relationships come directly from the AST.
This removes chunking entirely and replaces text retrieval with symbol-level navigation over a code graph.

2) GraphRAG builds graphs by extracting entities and relationships from documents, then uses them to improve retrieval quality.
KiroGraph doesn’t infer the graph from text, it derives it deterministically from the codebase structure itself.
As a result, its graph is not an approximation of knowledge, but a direct representation of the system architecture.

The key difference: RAG retrieves text, GraphRAG organizes text, KiroGraph represents code structure.
And embeddings in KiroGraph are optional, not foundational.
The core idea is not better retrieval, but queryable program structure with semantic enrichment on top.

A lot of semantic engine possibility

Here's where it got interesting.
Once you have embeddings, you need somewhere to put them, and how you store and search them has real consequences at scale.

The original approach is cosine similarity over all vectors in SQLite. That's fine for small to medium projects, but for a large codebase with thousands of indexed symbols, you want approximate nearest-neighbour (ANN) search with a proper index structure.

So I built support for seven engines, each solving a slightly different problem:

cosine (default): the original linear scan over the vectors table in kirograph.db. No extra deps. Works great up to a few thousand symbols. If you just want to try semantic search without any setup, this is it.
Alex Garcia's sqlite-vec brings ANN search to SQLite via a native extension. Sub-linear query time, stays in the SQLite ecosystem. Best for large codebases that don't want to run a separate process.
Orama does something clever: hybrid search. One query combines full-text relevance and vector similarity, which produces better results than running them separately and merging. Pure JS, no native compilation. If you want the best result quality and no native dependencies, Orama is the choice.
PGlite is PostgreSQL compiled to WASM with the pgvector extension. You get exact (not approximate) nearest-neighbour search, ON CONFLICT upserts, HNSW indexing, all the PostgreSQL semantics, in-process, no server. Pure WASM means no native binaries and no compilation. And because it's exact, results are deterministic and reproducible. I particularly like this one.
LanceDB stores embeddings in Apache Lance columnar format. Columnar storage is efficient for batch reads and writes, which matters a lot during indexing. Pure JS, no native deps, sub-linear ANN search.
Qdrant is a dedicated vector database, HNSW index, cosine distance, the full feature set. KiroGraph spawns the Qdrant binary as a managed child process via qdrant-local. The server runs as a persistent background daemon, state tracked in .kirograph/qdrant-server.json. This is the heavy option. You get Qdrant's full query capabilities and a proper production-grade vector store. The trade-off is you're now running a binary.
Typesense is a search engine that added HNSW vector search. KiroGraph auto-downloads the binary (~37MB, cached at ~/.kirograph/bin/) and manages it as a background daemon. State tracked in .kirograph/typesense-server.json. Similar to Qdrant in concept, persistent binary daemon, but with Typesense's search-engine heritage. Very excellent for hybrid queries.

️ Adding installer because DevEx always matters

A lot of CLI tools treat configuration as an afterthought. You edit a config file, restart, wonder why nothing worked, read the docs, try again. It's friction. You don't want friction when working within an AI powered IDE like Kiro.

I wanted KiroGraph's setup to be genuinely good and simple.

So the installer is interactive, not just yes/no prompts but arrow-key menus with descriptions for each option. Run it once and you walk away with a fully working setup, no post-install surprises.

kirograph install

Here's every decision the installer walks you through, and why each one matters.

Enable semantic embeddings

The first question is whether to turn on semantic search at all. Structural indexing is always on and costs nothing extra. Semantic indexing is opt-in because it requires a local embedding model (~130MB, downloaded once) and adds time to every index run.

If your team mostly does exact symbol lookups, "go to definition" style queries, structural-only is fast and lightweight. If you want to ask things like "where is rate limiting handled?" or "which functions deal with user authentication?", you need embeddings.

The installer is upfront about this: it tells you what you're signing up for before you say yes.

Embedding model

Once you enable embeddings, the installer asks which HuggingFace model to use. The default is nomic-ai/nomic-embed-text-v1.5, a solid general-purpose model that produces 768-dimensional embeddings and runs well locally via Ollama.

You can enter any HuggingFace model identifier in org/model-name format. If you enter something non-standard, the installer rejects it and explains the expected format. If you enter a non-default model, it reminds you to run ollama pull <model> before indexing.

The reason this is configurable: embedding quality varies by domain. Code-specific models like jinaai/jina-embeddings-v2-base-code may outperform general models on certain queries.
Giving you control here means you're not locked in.

Semantic engine

This is the arrow-key menu. Each option shows a one-line description so you can make an informed choice without reading docs:

? Choose the semantic search engine:
  ❯ cosine      In-process cosine similarity. No extra deps. Best for small/medium projects.
    sqlite-vec  ANN index. Sub-linear search. Best for large codebases. Needs: better-sqlite3, sqlite-vec (native).
    orama       Hybrid search (full-text + vector). Pure JS. Needs: @orama/orama, ...
    pglite      Hybrid search via PostgreSQL + pgvector. Exact results. Pure WASM. Needs: @electric-sql/pglite.
    lancedb     ANN search via LanceDB (Apache Lance columnar format). Pure JS. Needs: @lancedb/lancedb.
    qdrant      ANN search via Qdrant embedded binary (HNSW index, Cosine). Needs: qdrant-local.
    typesense   ANN search via Typesense (auto-downloaded binary, HNSW, Cosine). Needs: typesense.

After you pick one, the installer immediately runs npm install for the required dependencies. No separate step, no forgotten follow-up. If the install fails, it tells you exactly what to run manually.

For engines that spawn a binary (qdrant, typesense), it also asks whether you want a dashboard (a web UI to navigate the vectors).

Extract docstrings

This controls whether KiroGraph reads JSDoc, Python docstrings, and inline comments from your source files and stores them as symbol metadata. Enabled by default.

Docstrings significantly improve semantic search quality. When a function has a good docstring, the embedding captures its intent, not just its name. A function called proc with a docstring "processes incoming webhook payloads and dispatches to handlers" will surface correctly when someone searches for "webhook processing". Without the docstring, the name alone gives the model almost nothing to work with.

The trade-off is slightly longer indexing time. For most projects it's negligible. The installer lets you disable it if you're indexing a very large codebase and want the fastest possible first run.

Track call sites

This controls whether KiroGraph records the exact line and column of every function call when building call graph edges. Enabled by default.

With call sites tracked, you get precise "go to call site" information in addition to "which functions call this symbol". The kirograph_callers and kirograph_callees MCP tools return not just the caller's name and file, but the exact location of the call. This is what makes the call graph actually useful for debugging and impact analysis.

The trade-off is index size: call site data adds rows to the edges table. On codebases with millions of call expressions this can get large. If you only care about the structural shape of the call graph and not the precise locations, you can disable this to keep the database lean.

Indexing

The final prompt asks whether to run the first full index immediately. If you say yes, the installer runs kirograph index, shows you a live progress output (files scanned, symbols extracted, embeddings generated), and reports the final counts.

This is the "zero to working" moment: by the time the installer exits, your graph is built and Kiro can start using it. No deferred setup, no "remember to run this before you start".

Each phase is surfaced in the output so it's always clear what's happening: scanning files, parsing, resolving references, detecting languages and frameworks, generating embeddings. If something is slow, you know exactly where.

The philosophy across all of this is the same: the installer should leave you in a working state and make every choice transparent. If something requires a separate binary or native compilation, you know before you commit to it. If a step can be done for you automatically, it is.

The feedback loop that accelerated everything

Here's the part I didn't fully anticipate: because I've used KiroGraph to indexes itself, so I could use it in Kiro while building it.

Every time I added a new engine, the Kiro agent could immediately use kirograph_context and kirograph_callers to understand the existing codebase structure. It knew which interfaces to implement, where the integration points were, what the existing patterns looked like, without me having to explain any of it.

This is augmenting spec-driven development with actual graph-powered context. The agent writes specs and code that fits the existing architecture because it can see the architecture. Not by reading files, by querying the graph.

The speed difference and saving in tokens is hard to overstate. Tasks that would have required multiple rounds of "read this file, now read that file, now understand how they connect" collapsed into a single kirograph_context call followed by implementation.

Supported languages and frameworks

As per CodeGraph by Colby McHenry, KiroGraph supports different languages and framework (and it easy to add new ones).

Just try it

Go to KiroGraph repository, fork it, try it. PR's are welcome.
It’s not yet published on npm, so it should be considered an alpha version. Expect significant changes in the future so do not consider it stable.

{% github davide-desio-eleva/kirograph %}

The installer will walk you through everything. If you're not sure which engine to pick, start with cosine, it works out of the box with no dependencies and you can always switch later. If you're using it on large codebases, pick pglite.

The repo is public. If you build on it, find a bug, or have thoughts on the engine choices, I'd love to hear from you.

A very special thanks to the Stargazers, your support means a lot and truly makes a difference.

Who am I

It’s always amusing how AI is convinced developers are basically 80% coffee, 20% code, and somehow still functional.