ManiLens
My own code reviewer. It reads every pull request in my projects, finds bugs and security holes and writes directly in the code what is wrong and how to fix it, in Danish. It is in development, and this case will be updated along the way. The screenshot uses test data, and the interface is in Danish.
Why
I used CodeRabbit to read my pull requests before merging. I wanted the same, but in Danish, with my own rules for each project and without another subscription. ManiLens runs on the Claude subscription I already have.
The rules matter most. Each project has its own requirements, for example that the CHANGELOG must be updated, or that pages with personal data must not be indexed. A general reviewer does not know them. ManiLens reads them from the project before it reads the code.
How it reads a PR
When a pull request is opened or gets a new commit, ManiLens runs the same steps every time:
One review6 steps · fixed order
- Fixed checks the project’s own tests, lint and type check
- Scanners up to 14, such as opengrep, Ruff, Gitleaks and Trivy, only where they fit the code
- Four reviewers one reads for bugs from the top and one from the bottom, one for security and one for the project’s rules
- Verifier rereads the code and drops anything it cannot confirm itself
- Verdict block the merge, comment or approve
- On the PR comments in the code with a fix and a ready prompt for an AI agent
A missing or failed check never counts as passed, and a block is never turned into an approval.
The verifier is why it can be trusted. The reviewers may suggest a lot, but only what is confirmed in the code reaches the PR.
A real comment
Here is a real finding from a demo project I use to test ManiLens. A search function put the user’s search term straight into the SQL.
Serious · Security · noter/lager.py line 41
- The search term
don'tcrashes the command x' OR '1'='1returns every note instead of the ones searched for- The two other functions in the same file do it right with
?
LIKE ? ESCAPE
You can ask about a finding right in the PR, and ManiLens answers in the same thread (in Danish, translated here):
@manilens why is this a problem?
Reading noter/lager.py ·
Because the search term becomes SQL code instead of data. An apostrophe crashes the command, and the right text can change what the query finds. It is serious but not critical, because the only caller today is the local command line.
The answer is based on the code in the PR.On GitHub and locally
ManiLens comes in two versions that use the same reviewers:
That turned out to matter. In early October, GitHub’s free minutes ran out and reviews on GitHub stopped. The local version kept running, because it does not use GitHub minutes.
Measured against CodeRabbit
I measured ManiLens on 10 real pull requests from my projects that CodeRabbit had already read. A third model decided whether each finding was a real bug.
ManiLens found 21 of CodeRabbit’s 31 real bugs. About 90% of ManiLens’ own findings were real, and CodeRabbit had missed 15 of them.
The bugs it missed were mostly in frontend code and in very large PRs. So it now gets large PRs in slices and a frontend checklist. That was measured on 9 new PRs that were not used to write the checklist:
CodeRabbit bugs found (of 45)
12→12
Real bugs missed
11→11
The numbers come from few runs, and the judging model does not always agree with itself. They show the direction, not a guarantee.
How far it is
Today ManiLens reads pull requests in my own projects. It has a server with login and an account page where you can see your reviews, and a small group of colleagues is trying it out.
How far it is
- Reviewbuilt and in use
- Localbuilt and in use
- Colleaguestrial under way
- Fixes codebuilt, but switched off
It can also fix code itself, write tests and resolve merge conflicts, but that is switched off until it has been tested properly. Large PRs are still its weakest spot. This case will be updated as it gets better.