My long road to Kilo Code

Five tools. Five stages. A long road to an AI assistant I am willing to trust. On VS Code as an ambivalent foundation, on open source as a pragmatic conviction, and on the question of which daily tools an independent designer can still rely on.


I have been following this AI revolution longer than most people around me have known it exists. Not since November 30, 2022, when OpenAI released ChatGPT and gained one 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 is 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 is exactly why I want to make this foundation transparent 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. Those who want to avoid that can turn 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 the way, it is not cumbersome like other environments. And it works surprisingly well without GitHub, without a Microsoft account, and without the cloud. I make 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 — after the clearly noticeable price adjustment to Copilot in early June 2026 — was not an optional exercise but a necessity.

But fascination alone is not enough. When you watch this development, you eventually ask 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 are not sitting inside a corporation but are freelancers, indie developers, product engineers. In short: for everyone who cannot simply sign an enterprise SaaS contract. What is left for us once the dust of pricing changes 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 rises, contributions from small teams become more competitive against those of large organizations. That is a genuine democratization of software development. And it has only just begun.

At the same time, one has to keep one's eyes open. Open source costs money. Infrastructure, maintainer time, hosting. None of it is free. And the big players know that. They are on a veritable buying 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, a startup for agentic cloud infrastructure, followed, also for Codex. The message is unambiguous: 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 is not an accusation — that is capitalism. But it should be named as such before building one's daily workflow on such a foundation.

First contact

I still remember clearly 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 does not develop full-time, that was a genuine door-opener. And a first sense of what is possible when AI integration holds back and stays out of the way.

The mainstream route: 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 is not an accusation — that is a business model. It should just be named as such. And in the beginning, the pricing was fair.

So at some point I switched to the subscription. 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 there was 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 on paper at least it was exactly what I wanted.

The reality was rougher. Continue was buggy. Not in a way that can be ignored, 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 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 a lot 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 does not 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 requires an update to unlock new models. Formally, Cline is open source; in practice, it reliably steers users 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 as of May 15, 2026.

Three million installs and then simply lights 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 felt professional without trying to sell itself. Full model freedom, local LLMs treated as equals 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 was not the feature set alone. It was the question I now ask myself with every new tool: who is 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 covers CLI, cloud, and IDE.

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

What I took away

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

What do I take away? Anyone evaluating an open-source tool today should not stop at the GitHub repo. The questions that actually matter are: who started the project? How is it funded? What happens if users do not 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 do not 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 encountered along the way. And for me the rule is: as long as the license holds, local models are treated as equals, and nobody is trying to push me into API contracts with warning messages, I will give it a chance.