My long road to Kilo Code

Five tools. Five stops. A long road to an AI assistant I actually want to trust. On VS Code as an ambivalent foundation, on open source as a pragmatic conviction, and on the question of who you can still trust with your daily tools as an independent designer.


I've been following this AI revolution longer than most people around me have known it exists. Not just since November 30, 2022, when OpenAI released ChatGPT and gained a million users within five days — an adoption rate faster than any consumer app in the history of the internet. I was there before that. I watched the development, read about it, discussed it. And I was fascinated from the start.

That's also why VS Code belongs at the beginning of this story. VS Code is the foundation I work in today. And it was the IDE that first gave me the idea of trying an AI assistant in my daily workflow. That's exactly why I want to be transparent about this foundation here. Especially since VS Code was marketed very aggressively as open source for years, though my experience with it has a few more facets than that.

VS Code remains a conscious compromise for me to this day. The source code is MIT-licensed and public. The binary Microsoft ships, however, contains telemetry and is distributed under a proprietary license. Anyone who wants to avoid that turns to VSCodium, a community build without Microsoft branding and with tracking disabled, compiled from the same sources. After the acquisition of GitHub in 2018, the strategic direction in the developer tooling space was actually easy to read. VS Code and GitHub are not philanthropic projects. They are platforms. Copilot was the logical consequence.

I still work in VS Code deliberately. The IDE is lightweight, it stays out of your way, it isn't cumbersome like other environments. And it works surprisingly well even without GitHub, without a Microsoft account, and without the cloud. I accept this compromise consciously. But it reminds me every day that independence in this space is never absolute.

Against this backdrop, my search for a genuine open-source assistant for local LLMs — following the clearly noticeable price adjustment to Copilot in early June 2026 — was not a luxury, but a necessity.

But fascination alone isn't enough. When you watch this development unfold, you eventually ask yourself a question that almost gets lost behind the feature releases and benchmark rounds: what does this revolution actually yield for us? For people who think independently, who build things themselves, who aren't sitting inside a corporation but are freelancers, indie developers, product engineers. In short: for everyone who can't simply sign an enterprise SaaS contract. What's left for us once the dust of the pricing shifts has settled?

The answer lies in open source

For me, the answer to that question is clear: open source. Not out of principle or ideology, but out of pragmatic conviction. AI is fundamentally changing open-source development. Commits get faster, code quality improves, contributions from small teams become more competitive against those of large organizations. That's a genuine democratization of software development. And it has only just begun.

At the same time, you have to keep your eyes open. Open source costs money. Infrastructure, maintainer time, hosting. None of it is free. And the big players know this. They are on a veritable acquisition spree, financed by valuations that often have little to do with actual performance. Anthropic acquired the JavaScript runtime Bun in late 2025 to integrate it into Claude Code. OpenAI acquired Astral in March 2026 — the makers of uv, ruff, and ty, three of the most widely used Python tools in the community — to embed them in Codex. In June 2026, the acquisition of Ona followed, a startup for agentic cloud infrastructure, also for Codex. The message is unmistakable: whoever controls the tools controls the workflow.

A pattern is clearly visible. An open-source project gains trust and a user base. Then it gets absorbed. Sometimes the code stays public, sometimes not. The incentives shift either way. That's not an accusation — that's capitalism. But it should be named as such before you build your daily workflow on a foundation like that.

First contact

I still remember the first time I really worked with AI. Not the way I do today, but more as a cautious experiment. The tool that gave me my entry point was Blackbox AI. It improved my first scripts, uncovered errors in source code and structure, and above all: it worked. No elaborate setup, no marketing promises of AGI. Just a tool that helped me with my everyday editor work. For someone who doesn't develop professionally, that was a real door-opener. And a first sense of what's possible when AI integration holds back and stays out of the way.

The mainstream path: Copilot and its logic

The next logical step was GitHub Copilot on the free plan. GitHub still conveys a certain open character, so I had few reservations at first. GitHub Copilot worked. The completions were more precise, the context depth better. But Copilot Free was, soberly considered, more of a sales argument. Almost every interaction carried the message: how far would you get with the Pro version? This idea was reinforced through banners, hints, and subtle UI restrictions. GitHub Copilot is not a bad product, but it was trying to pull me into a subscription. That's not an accusation — it's a business model. You should just call it what it is. And the pricing was fair at first.

So at some point I switched to the paid plan. Honestly, the paid experience was good. Really good, as long as the credit model stayed stable. But then Microsoft changed it, and suddenly the value of the subscription was different from what it had been. That was my signal to look further.

The local dream: open-weight models with Continue

Between Copilot Free and the subscription came a detour that permanently changed my thinking: local open-weight models in VS Code, integrated with Continue. The idea was compelling. Local models directly in the editor, no cloud dependency, full control, no costs. Continue was positioned as an open-source alternative to Copilot, and at least on paper it was exactly what I wanted.

The reality was rougher. Continue was buggy. Not in a way you can ignore, but in a way that constantly disrupts the workflow. Connection drops, inconsistent behavior, configuration overhead that rarely paid off. I tried it multiple times over the past months as an alternative to Copilot and even had phases where it ran reasonably well. But in the end I always went back to Copilot. The Continue chapter has since resolved itself anyway: Cursor acquired the project. Cursor is an AI-powered IDE that operates exclusively on a subscription model. And Cursor itself now belongs to xAI. The pattern is familiar. Continue was better in theory, Copilot was more reliable in practice.

Cline: open source as a facade

I had also been using Cline for a while as a supplementary tool, for content revisions with Anthropic models. The configuration options and free prompting gave me plenty of room, and it worked. But when I tried to make it my primary coding assistant, I ran into a pattern that increasingly bothered me.

Cline is open source, but it doesn't treat local models as equals. Constant warning messages recommending a switch to Claude Sonnet or larger cloud models. Even modern open-weight models with a million-token context window were met with a warning. Since this is hard-coded in the assistant's code, it always takes an update to unlock new models. Formally, Cline is open source; in practice, it reliably steers you toward Anthropic's API models. The code may be public, but the intentions behind it are not. I still appreciate the tool, but after a sober reassessment I kept looking.

Roo Code: arrival and immediate departure

After further research I came across Roo Code, a fork of Cline that advertised a genuine focus on local models. Installation complete, editor restarted — and then, on first launch, a message that the project was being discontinued. Development was moving to a new product called Roomote. The VS Code extension Roo Code, the cloud service, and the router would be archived on May 15, 2026.

Three million installs and then the lights just go out. No dramatic failure. CEO Matt Rubens was even honest about it: the decision was based on the conviction that IDE-centric coding was not the future. Respect for the transparency. But I was back at square one.

Kilo Code: finally arrived

What I found next was Kilo Code. My first impression was unusual. Not because it made a particularly spectacular entrance, but because it came across as professional without trying to sell itself. Full model freedom, local LLMs on equal footing alongside cloud and API models, Apache 2 license, no subscription lock. The fork genealogy is transparent: Cline → Roo Code → Kilo Code. Kilo describes itself as a superset of both predecessors.

What kept me wasn't the feature set alone. It was the question I now ask myself with every new tool: who's behind it, and how is it funded?

The foundation matters more than the star count

Kilo Code was co-founded by GitLab co-founder Sid Sijbrandij and Scott Breitenother. The seed round of 8 million dollars, led by Cota Capital with participation from General Catalyst, had already closed in December 2025. When Roo Code left behind its community of three and a half million users, Kilo Code actively absorbed them while simultaneously building on its own OpenCode engine, which spans CLI, cloud, and IDE.

This is not a garage project that could disappear tomorrow. Nor is it a corporate tool with hidden paths into a subscription. It's a startup with clear funding, a founding team with genuine infrastructure DNA, and a licensing model that leaves real freedom. For now.

What I've taken away

This journey didn't discourage me — it made me smarter. And it reinforced my conviction: the AI revolution is real, it's powerful, and it can make open source stronger than ever before. But that's precisely why it's also a target. The big players are buying their way into exactly the infrastructure developers use every day. Sometimes the code stays open. The power over roadmap, priorities, and the future still lies elsewhere.

What do I take away? Anyone evaluating an open-source tool today should not stop at the GitHub repo. The truly relevant questions are: who started the project? How is it funded? What happens if users don't pay, and what happens when the money runs out? A well-maintained README and a high star count say little about whether a project will still exist in twelve months. Roo Code had both. And yet the first thing that greeted me after installation was a farewell message.

Where the journey with Kilo Code leads, I don't know. No startup is a promise of permanence, and the AI tooling landscape changes faster than any product roadmap can keep up with. But the foundation is more solid than anything else I've encountered along the way. And for me: as long as the license holds up, local models are treated as equals, and nobody is trying to push me into API contracts with warning messages, I'll give it a chance.