Skip to content
Tool Review

Kilo Code — hands-on review 2 months (team, daily usage)

Sébastien Giband · Team migration from Kilo Code v1 to v2. Full-stack Symfony/TypeScript project in production. Head-to-head comparison with OpenCode on the same refactoring tasks. · · Updated on
PHP/Symfony 7 TypeScript/React VS Code (team) GKE
8/10 Recommended for VS Code-first teams

The richest out-of-the-box tool for IDE workflows. The mode marketplace and native VS Code integration make it the natural choice for teams that aren't terminal-first. Quality is on par with OpenCode, the initial experience is better.

Strengths

  • + Native VS Code integration: reads LSP diagnostics in real time, understands editor context without configuration
  • + Ready-to-use mode marketplace (Architect, Coder, Debugger, Reviewer) — operational with no initial investment
  • + MCP servers supported natively with graphical configuration interface — no need to touch JSON
  • + Full multi-provider: same freedom as OpenCode to route by task and cost
  • + Open-source Apache 2.0 — auditable code, no tool lock-in
  • + Team configuration sharing via Git (.kilocode/ in the repo)
  • + Visual diff interface before applying changes — clear feedback on what will change

Limitations

  • Strict VS Code dependency: no pure terminal usage, no remote/SSH setup without VS Code Server
  • Marketplace modes aren't all equal quality — some are poorly maintained, you need to curate
  • Slower to start than OpenCode on less powerful machines due to VS Code overhead
  • The graphical interface can be counterproductive for profiles who prefer full CLI control

Test context

Version tested: Kilo Code 2.x (December 2025 → February 2026). Deployed across the team (4 devs) after comparison with OpenCode. Stack: PHP/Symfony 7 + TypeScript/React, VS Code as the shared team editor. My personal tool has changed since (OpenCode back then, Claude Code today), but Kilo Code VS Code is still the team’s tool as of mid-2026 — this review reflects both perspectives, and the rollout held.

What Kilo Code actually does

Kilo Code is a VS Code extension that transforms the editor into an interface for a coding agent. Its architecture is similar to OpenCode (LLM client with access to environment tools), but the integration is designed to leverage the VS Code API rather than being IDE-independent.

What this concretely changes: the agent sees what you see. It knows the active file, reads errors in the Problems panel, understands the workspace structure. It doesn’t need to be told where the problems are — it sees them.

Modes are the distinctive feature. Each mode is a profile with system instructions, action permissions, and preconfigured available tools. The Architect mode can’t modify files by default — it’s limited to analysis and proposals. The Coder mode has full access. It’s a clean way to structure delegation.

What works

LSP integration is the real differentiator. When there’s a TypeScript error in the code, Kilo Code sees it directly in context without you having to copy-paste. In practice, the “modify → see error → fix” cycle is shorter than on OpenCode where you have to run tests or communicate the error manually.

The marketplace reduces initial investment. With OpenCode, it takes 2-3 hours to build custom commands covering recurring workflows. With Kilo Code, the Architect and Coder modes do the job to get started. On the team, onboarding took 30 minutes versus an estimated 3 hours for OpenCode.

The visual diff reassures less confident profiles. Before each modification is applied, Kilo Code displays a diff. For devs discovering agents, seeing exactly what will change reduces delegation anxiety. Experienced profiles quickly disable it, but it’s a good initial safeguard.

What doesn’t work

The VS Code dependency is structural. Our primary dev workflow is Mac → SSH → Ubuntu remote. VS Code Server works but it’s heavier than running opencode directly server-side. For quick SSH sessions, we switch back to OpenCode.

The marketplace is uneven. Of the ~50 available modes, 10-15 are well-made and maintained. The rest are generic variations without real added value. You need to invest time curating, which diminishes the “ready-to-use” advantage.

Who is it for?

The Kilo Code profile is the team or dev whose central working environment is VS Code. LSP integration, the mode marketplace, and the graphical MCP configuration interface make it the most accessible tool for teams wanting to adopt agents without significant initial configuration investment.

For terminal-first workflows or intensive SSH setups, OpenCode remains better suited.

Recommended for

  • Teams using VS Code as their primary editor
  • Quick onboarding — preconfigured modes, no need to build workflows from scratch
  • Projects requiring rich MCP integration (databases, external APIs)
  • Developers coming from Cursor who want to keep the IDE experience but with multi-provider freedom

Not recommended for

  • Terminal-first or remote/SSH workflows without VS Code Server
  • Profiles who want full CLI control without a graphical interface
  • Machines with limited resources where VS Code overhead is problematic

Frequently Asked Questions

Kilo Code vs OpenCode: how to choose?
Short answer: VS Code daily → Kilo Code. Terminal/Neovim/SSH → OpenCode. Both are multi-provider, open-source, and comparable in quality. Kilo Code wins on IDE integration and ready-to-use workflows. OpenCode wins on lightness, remote, and full CLI control. It's not necessarily an exclusive choice — some use Kilo Code during the day in VS Code and OpenCode for SSH sessions outside.
Is the mode marketplace actually useful?
For getting started, yes. The Architect and Coder modes cover 80% of use cases without configuration. After a few weeks, you typically end up customizing or creating your own modes tailored to the project. The marketplace is a good starting point, not an end in itself.
How do you share Kilo Code configurations across a team?
The .kilocode/ folder at the project root is versioned in Git. It contains custom modes, project instructions (equivalent of CLAUDE.md for OpenCode), and MCP configurations. A new dev who clones the repo automatically inherits the team's workflows.
Does Kilo Code work with Ollama for local models?
Yes. Ollama is natively supported as a provider. Configuration is done directly in the VS Code interface — local Ollama server URL, model selection. Useful for tasks on sensitive code you don't want to send to the cloud.