Kyro IDE: I tried to build an AI-native editor and learned why scope kills prototypes
I want to be upfront about Kyro IDE: it's a prototype. It's not a shippable IDE. It's a sketch of what one could look like, and the most useful thing I got out of it was a lesson about scope.
The idea was simple to describe: an editor that uses local LLMs (via Ollama) for assistant features, with Monaco as the editor surface, Tauri as the desktop shell, and an "agent timeline" UI that shows what the assistant is doing. Local-first AI, no cloud dependency, no API keys.
The idea was very hard to actually build.
What's in the repo
- A Tauri shell with a Rust backend.
- A Next.js + React frontend.
- Monaco wired up as the editor.
- An Ollama integration sketch.
- An agent timeline component that shows plan → edit → test → review steps.
- Browser preview, terminal pane, and file explorer scaffolding.
- A bunch of accessibility and theming notes I wrote down so future-me wouldn't forget.
What's not in the repo: a working agent that actually edits code. The hard part. The part I underestimated.
What I underestimated
I thought "Monaco + local LLM" was 80% of the work and "make the agent useful" was 20%. It is the opposite. Monaco wires up in an afternoon. Getting a local model to reliably plan a code change, apply it, run a test, interpret the test output, and decide whether to retry — that's a multi-month problem. People at well-funded companies are still figuring it out.
I should have known this. AI assistants told me this. I ignored them because I was excited. That is the lesson.
What I did learn
Even though the project didn't reach "useful editor," I learned a lot:
- Tauri + Next.js integration is real work. SSR doesn't make sense in a desktop app, so I had to learn to use Next.js as a static export and reason about hydration in a context where there's no server.
- Monaco is amazing. It's the same editor that powers VS Code. Wiring it up was the most fun part of the project.
- Ollama is a great citizen. Running a local LLM is now almost as easy as running a database. Memory usage is the real constraint, not API integration.
- Agent UIs are an open problem. There's no settled vocabulary for what "an agent doing things" looks like in a UI. I tried four versions of the timeline and none of them felt right. The best AI tools I've used (Claude Code, Cursor) handle this with very different visual languages and both are still iterating. So I don't feel that bad.
Why I'm leaving it as a prototype (for now)
The honest thing to do is reduce scope. A real next version would be:
- Drop the agent timeline for v0.
- Drop the integrated browser for v0.
- Keep Monaco + Ollama + a single "ask about this file" command.
- Ship that. See if anyone wants more.
I think that's the right next step. I just haven't taken it yet because I'm working on other things, and I want to be honest that this project is parked, not actively shipping.
What AI specifically helped with
- Sanity-checking ambition. Claude told me, gently and clearly, that what I was describing was a 6+ month project. I built it anyway. Two months in I realized Claude was right. It would have saved me time to listen earlier — but I learned more by ignoring it. There's a lesson there about when to trust the warning and when to bash your head against the problem.
- Tauri config. The amount of TOML you write for a real Tauri app is wild. AI was great at "explain why this config key affects this build step."
- Monaco extension API. Monaco's API is huge. AI was a great search engine for "is there a built-in way to do X" before I went and wrote it from scratch.
What this project is good for
If you're a student looking at this repo: don't look at it as "an IDE." Look at it as "what does a Tauri + Next.js + Monaco + Ollama scaffold look like when someone actually wires the plumbing." That's the value. The agent layer on top is aspirational and clearly labeled as such.
The most useful skill I built here wasn't a feature. It was learning to write a README that admits where the work stops.