ManiLens
Mein eigener Code-Reviewer. Er liest jeden Pull Request in meinen Projekten, findet Fehler und Sicherheitslücken und schreibt direkt in den Code, was falsch ist und wie man es behebt, auf Dänisch. Er ist in Entwicklung, und diese Referenz wird laufend aktualisiert. Das Bild zeigt Testdaten, die Oberfläche ist auf Dänisch.
Warum
Ich habe CodeRabbit genutzt, um meine Pull Requests vor dem Merge lesen zu lassen. Ich wollte dasselbe, aber auf Dänisch, mit meinen eigenen Regeln für jedes Projekt und ohne ein weiteres Abo. ManiLens läuft über das Claude-Abo, das ich ohnehin habe.
Die Regeln sind das Wichtigste. Jedes Projekt hat eigene Anforderungen, etwa dass das CHANGELOG aktualisiert werden muss oder dass Seiten mit personenbezogenen Daten nicht indexiert werden dürfen. Ein allgemeiner Reviewer kennt sie nicht. ManiLens liest sie aus dem Projekt, bevor er den Code liest.
So liest er einen PR
Wenn ein Pull Request geöffnet wird oder einen neuen Commit bekommt, führt ManiLens jedes Mal dieselben Schritte aus:
Ein Review6 Schritte · feste Reihenfolge
- Feste Prüfungen die eigenen Tests, Lint und Typprüfung des Projekts
- Scanner bis zu 14, etwa opengrep, Ruff, Gitleaks und Trivy, nur wo sie zum Code passen
- Vier Reviewer einer liest auf Fehler von vorn und einer von hinten, einer auf Sicherheit und einer auf die Regeln des Projekts
- Prüfer liest den Code erneut und verwirft alles, was er nicht selbst bestätigen kann
- Urteil Merge blockieren, kommentieren oder freigeben
- Im PR Kommentare im Code mit Korrektur und einem fertigen Prompt für einen KI-Agenten
Eine fehlende oder fehlgeschlagene Prüfung zählt nie als bestanden, und eine Blockade wird nie in eine Freigabe verwandelt.
Der Prüfer ist der Grund, warum man ihm vertrauen kann. Die Reviewer dürfen viel vorschlagen, aber nur was im Code bestätigt wird, landet im PR.
Ein echter Kommentar
Hier ist ein echter Fund aus einem Demoprojekt, mit dem ich ManiLens teste. Eine Suchfunktion hat den Suchbegriff des Nutzers direkt in das SQL gesetzt.
Schwerwiegend · Sicherheit · noter/lager.py Zeile 41
- Der Suchbegriff
don'tlässt den Befehl abstürzen x' OR '1'='1liefert alle Notizen statt der gesuchten- Die beiden anderen Funktionen in derselben Datei machen es richtig mit
?
LIKE ? ESCAPE
Man kann direkt im PR zu einem Fund nachfragen, und ManiLens antwortet im selben Thread (auf Dänisch, hier übersetzt):
@manilens warum ist das ein Problem?
Liest noter/lager.py ·
Weil der Suchbegriff zu SQL-Code wird statt zu Daten. Ein Apostroph lässt den Befehl abstürzen, und der richtige Text kann ändern, was die Abfrage findet. Das ist schwerwiegend, aber nicht kritisch, weil der einzige Aufrufer heute die lokale Kommandozeile ist.
Die Antwort stützt sich auf den Code im PR.Auf GitHub und lokal
ManiLens gibt es in zwei Varianten mit denselben Reviewern:
Das hat sich als wichtig erwiesen. Anfang Oktober waren die kostenlosen GitHub-Minuten aufgebraucht, und die Reviews auf GitHub standen still. Die lokale Variante lief weiter, weil sie keine GitHub-Minuten verbraucht.
Gemessen an CodeRabbit
Ich habe ManiLens an 10 echten Pull Requests aus meinen Projekten gemessen, die CodeRabbit bereits gelesen hatte. Ein drittes Modell hat entschieden, ob jeder Fund ein echter Fehler war.
ManiLens fand 21 von 31 echten Fehlern, die CodeRabbit gefunden hatte. Etwa 90 % der eigenen Funde von ManiLens waren echt, und 15 davon hatte CodeRabbit übersehen.
Die übersehenen Fehler lagen vor allem im Frontend und in sehr großen PRs. Deshalb bekommt er große PRs jetzt in Stücken und eine Checkliste fürs Frontend. Gemessen wurde das an 9 neuen PRs, die nicht für die Checkliste verwendet wurden:
CodeRabbit-Fehler gefunden (von 45)
12→12
Echte Fehler übersehen
11→11
Die Zahlen stammen aus wenigen Durchläufen, und das urteilende Modell ist sich nicht immer selbst einig. Sie zeigen die Richtung, keine Garantie.
Wie weit er ist
Heute liest ManiLens Pull Requests in meinen eigenen Projekten. Er hat einen Server mit Login und einer Kontoseite, auf der man seine Reviews sieht, und eine kleine Gruppe von Kollegen probiert ihn aus.
Wie weit er ist
- Reviewgebaut und im Einsatz
- Lokalgebaut und im Einsatz
- KollegenTest läuft
- Korrigiert selbstgebaut, aber abgeschaltet
Er kann Code auch selbst korrigieren, Tests schreiben und Merge-Konflikte lösen, aber das ist abgeschaltet, bis es gründlich getestet ist. Große PRs sind noch seine schwächste Stelle. Diese Referenz wird aktualisiert, je besser er wird.