Most “AI code reviewer” launches in 2025 and 2026 have been marketing demos. The product posts a comment on a pull request, the comment is sometimes useful, and the vendor moves on. Kilo Code Reviewer is one of the few I have kept installed in my own workflow for more than a couple of weeks, and I want to be specific about what it does well, what it doesn’t, and where I think it fits.
What Kilo actually is
Kilo Code Reviewer is a self-hosted (or vendor-hosted) agent that watches a Git repository for new pull requests, diffs them against the base branch, runs an analysis pass, and posts structured review comments back to the PR. The “agent” framing is the part I was skeptical of, because in this market that word gets stretched. Here it means a model is given tools: file reads, grep, the ability to run your test suite in a sandbox, and access to your project conventions if you provide them. It then plans a review pass and executes it, rather than just generating a one-shot summary.
What surprised me was how unromantic the actual value is. It is not a “let me redesign your architecture” tool. It is a “let me catch the thing you missed because you wrote the code at 1 AM” tool. I have been writing code for a long time, and I still ship dumb mistakes. Kilo catches a non-trivial number of them, which is the actual bar for me to keep using something.
The setup story
Setup is the first thing I look at with any tool like this, because if the setup is bad, nothing else matters. Kilo’s setup is reasonable. The minimum is: a GitHub or GitLab token with repo access, a model API key, and a config file. The config file is where you tell it what to review for, what to skip, and what conventions to enforce. If you have a CONTRIBUTING.md, Kilo will read it.
There are a few different deployment shapes:
- A GitHub App that runs the review in the vendor’s cloud. Easiest, no infra to manage, but your code leaves your environment.
- A Docker container that you run in your own infrastructure. You provide the model, you keep the data, and you can point it at internal repos.
- A CLI for local review, which I find useful for catching the same class of issues before I push.
The self-hosted path is the one most enterprise teams I have talked to end up on, and it is the path I run. It is not a 30-second setup, but it is not a week-long project either. The README walks through the standard GitHub Actions integration, which is what most teams will start with.
What it actually catches
I have been running Kilo against my own repos for about six weeks, and the catch rate is high enough that I notice when it is off. The categories I see most often:
- Off-by-one errors in loops, especially in list comprehensions and stream processing code.
- Missing error handling on file I/O. I have a bad habit of writing happy-path code first and not coming back. Kilo flags the empty catch block more reliably than I do.
- Race conditions in async code. These are subtle enough that a static analysis tool can sometimes see what I missed, and Kilo does.
- Tests that don’t actually test the thing they claim to test. I have had Kilo point out a test that passed for the wrong reason at least four times in the last month.
- Style violations against the conventions in the project’s CONTRIBUTING.md, which is the underrated feature.
What it doesn’t catch, in my experience:
- Architectural problems. Kilo will not tell you that your module boundary is wrong or that you should split the service in two. That is still a human job.
- Performance issues that require benchmarking. It can suggest that something is O(n²), but it cannot run the load test for you.
- Domain-specific logic. If the bug is in the business rule, Kilo will not find it unless you write a test that encodes the rule.
The agent framing is real, mostly
The reason Kilo can catch the things it catches is that it is given tools, not just a prompt. In practice, this means it will often open the file in question, read the related test file, run the test suite, and post a comment that includes the actual failing test. That is meaningfully more useful than a comment that says “consider adding a test for this case.”
It also means the review is slow. A typical PR takes two to five minutes to be reviewed by Kilo, depending on size. For a small PR that is fine. For a large refactor PR, that is annoying. I usually tag large PRs with a “skip-review” label and run Kilo on the smaller follow-up PRs, which is a reasonable workflow.
The other thing about the agent framing is that Kilo is configurable. You can give it a list of “review focus areas” that map to your project’s risks. On a payments project I worked on recently, the focus list included currency rounding, idempotency keys, and timezone handling. Kilo did catch a bug in a timezone conversion that I had not noticed, which I would have caught in QA but which was nice to catch in review.
Trade-offs
- The model cost is not nothing. A self-hosted model is cheaper, but the vendor-hosted path can run a few dollars per PR on a large repo. The math is fine for a paid team and questionable for a hobby project.
- The review latency is real. If your team has a culture of “merge as soon as CI is green,” a two-minute review pass changes the rhythm. The fix is to set expectations, but it is a real cost.
- The comments are not always right. I have had Kilo post a comment that was confidently wrong twice in the last month, both times on async code. You still have to read the comments.
- The vendor-hosted path sends your code to a third party. For some teams that is a non-starter, which is why the self-hosted path exists.
- It is not a replacement for human review. It is a filter that runs before human review, and the value depends on how your team uses it.
When to use this
Kilo Code Reviewer is a fit if your team has more than three engineers, ships code through pull requests, and wants a first pass that catches the obvious stuff before a human spends their afternoon doing it. It is a worse fit for solo projects, for repos where the code is mostly generated by another AI, and for teams that are already paying for an expensive human review process that does not need help.
I would not put Kilo in front of every PR I open. I would put it in front of every PR on a team repo where other people will be reading my code, because the cost is small and the catch rate is real. That is the bar I have been looking for, and it is the bar Kilo meets.