Why we use Kilo and not Claude

Why We Use Kilo and Not Claude

There are plenty of useful AI coding tools. We use Kilo Code not because every other assistant is useless, but because Kilo behaves more like a professional development tool and less like a general-purpose chat product.

That difference matters. In real engineering work the repository is live, the customer is paying, and every change has to be understood, reviewed and owned by a human developer.

Control Over the Workflow

Kilo gives us practical control over prompts, models, tools, modes, agents and workflow boundaries. We can use different behaviours for different jobs: design, implementation, debugging, documentation, review or refactoring.

That mirrors how software work actually happens. A migration, a production fault, a pull request review and a user interface tidy-up should not all be treated as the same task.

Architect mode helps turn loose requirements into a design before code is written. Ask mode answers questions without changing files. Orchestrator mode breaks larger work into sensible steps. Review mode approaches changes sceptically, as a reviewer should. Those distinctions are useful because they keep the assistant aligned with the job.

For us, the important question is not "which AI sounds cleverest?" It is "which AI lets a competent developer stay in control?"

Fast, Direct and Contained

Kilo is quick in the way developers mean quick: inspect what is needed, make the change, report the result and stop. It does not turn a small engineering task into a long conversation.

It also keeps scope under control. If a task belongs in one file, Kilo can stay in that file. If a wider search is needed, it can be deliberate. That makes the work easier to review and reduces the risk of an assistant wandering through unrelated parts of the repository looking for things to improve.

A coding assistant that cannot be constrained is not a tool. It is a liability with autocomplete.

Model Choice, Privacy and Resilience

Kilo can be configured to use local models and private cloud models as well as public ones. That matters because model choice is not just about capability, latency or cost. It is also about where the code goes, who may be able to see it and whether the team can keep working when one provider is unavailable.

Anthropic, OpenAI and Gemini all have outages. That is not a criticism of any one provider; it is a normal operational fact of depending on large cloud services. The problem with a proprietary single-vendor coding tool is that when the provider has a bad day, the tool can simply stop being useful. The editor integration, prompt history, agent behaviour and workflow may all be tied to the same unavailable service.

With Kilo the tooling is separate from the model. If one provider is down, rate limited or behaving badly, we can switch to another model and carry on with the same tooling, the same prompts, the same agents and the same development workflow. That is a practical continuity advantage, not a theoretical preference.

Repositories can contain credentials, customer data, internal identifiers, architecture details and commercially sensitive ideas. A professional AI coding environment must allow sensitive work to stay local or inside a controlled private deployment.

If the assistant can see the code, the model provider may be able to see the business.

Open Source Matters Here

Open source is not a slogan in this area. It is part of the control surface. When a coding assistant can read repositories, execute tools, inspect terminals, create diffs and send context to models, the difference between auditable behaviour and vendor promises matters.

The recent Claude Code leak showed extensive telemetry around coding-agent behaviour. We should not be surprised if similar proprietary products such as Codex and Antigravity collect comparable operational data. From a vendor perspective that data is valuable for debugging, safety analysis, product analytics and model improvement. From a customer perspective it may include a highly detailed map of how engineers work, what repositories they touch, which commands they run and where the tool struggles.

An open, inspectable toolchain gives teams a better chance of understanding what is collected, what is sent, what can be disabled and where policy enforcement actually happens. For regulated, security-conscious or simply commercially cautious organisations, that is not paranoia. It is due diligence.

AI coding tools are too close to the source code, the terminal and the developer workflow to be treated as ordinary SaaS widgets.

Visible Cost

Using Kilo with pay-as-you-go model providers makes cost visible. If a refactor, test improvement or documentation pass costs £5, that cost can be judged against the value produced.

That is preferable to opaque subscription limits that feel unlimited until capacity suddenly disappears. For business use, visible marginal cost is not a flaw; it is part of operational control.

Less Theatre, Better Reporting

We also prefer Kilo's tone. It does not pad every response with flattery, reassurance or social theatre. Developers do not need a machine to praise the prompt; they need it to follow instructions, flag problems and explain what changed.

The completion report matters too. Kilo can summarise the work in a way that connects back to files and lines, which makes review, diffing and rollback easier. A prose explanation is useful, but a reviewable change report is better.

Built for Developers

Kilo feels built for people who already know how to write software. It assumes the human will make decisions, review changes and understand trade-offs. It augments the developer rather than trying to replace the developer with a cheerful wizard.

Other assistants, including Claude Code, can be impressive and useful. In our experience, they often feel more optimised for conversation or demos than for the controlled professional engineering workflow we want. Serious teams need constraints, repeatable workflows, model choice, provider resilience, cost visibility and clear review trails.

The Real Reason

The reason we use Kilo is not simply that it can write code. Many systems can. We use it because it lets us use AI while preserving the habits that make software engineering safe: scope control, review, accountability, context discipline, operational resilience and cost awareness.

Claude Code is capable, but regularly seems to do its own thing instead of following instructions. Codex is good and faster but integrates less well, and Antigravity is.... Google. All three are also tied to vendor platforms whose availability, telemetry choices and product limits are outside our control.

For an experienced development team, a point-and-shoot tool with extensible MCP and agent support together with public, local and private models, open-source transparency and no artificial single-vendor limit is the better choice.