ManiLens
Min egen kodereviewer. Den læser hver pull request i mine projekter, finder fejl og sikkerhedshuller og skriver på dansk direkte i koden, hvad der er galt, og hvordan det rettes. Den er under udvikling, og casen bliver opdateret undervejs. Billedet er taget med testdata.
Hvorfor
Jeg brugte CodeRabbit til at læse mine pull requests, før de blev merget. Jeg ville have det samme, men på dansk, med mine egne regler for hvert projekt og uden et ekstra abonnement. ManiLens kører på det Claude-abonnement, jeg allerede har.
Reglerne er det vigtigste. Hvert projekt har sine egne krav, fx at en CHANGELOG skal opdateres, eller at sider med persondata ikke må indekseres. En generel reviewer kender dem ikke. ManiLens læser dem fra projektet, før den læser koden.
Sådan læser den en PR
Når en pull request bliver åbnet eller får et nyt commit, kører ManiLens de samme trin hver gang:
Et review6 trin · fast rækkefølge
- Faste tjek projektets egne tests, lint og typecheck
- Scannere op til 14, fx opengrep, Ruff, Gitleaks og Trivy, kun hvor de passer til koden
- Fire reviewere én læser for fejl forfra og én bagfra, én for sikkerhed og én for projektets regler
- Efterprøver genlæser koden og dropper alt, den ikke selv kan bekræfte
- Dom blokér merge, kommentér eller godkend
- På PR’en kommentarer i koden med rettelse og en færdig prompt til en AI-agent
Et manglende eller fejlet tjek tæller aldrig som bestået, og en blokering bliver aldrig ændret til en godkendelse.
Efterprøveren er grunden til, at den er til at stole på. Reviewerne må gerne foreslå meget, men kun det, der bliver bekræftet i koden, når frem til PR’en.
En rigtig kommentar
Her er et ægte fund fra et demoprojekt, jeg bruger til at afprøve ManiLens. En søgefunktion satte brugerens søgeord direkte ind i SQL’en.
Alvorlig · Sikkerhed · noter/lager.py linje 41
- Søgeordet
don'tfår kommandoen til at gå ned x' OR '1'='1giver alle noter i stedet for de søgte- De to andre funktioner i samme fil gør det rigtigt med
?
LIKE ? ESCAPE
Man kan spørge ind til et fund direkte i PR’en, og ManiLens svarer i samme tråd:
@manilens hvorfor er dette et problem?
Læser noter/lager.py ·
Fordi søgeordet bliver til SQL-kode i stedet for data. En apostrof får kommandoen til at gå ned, og den rigtige tekst kan ændre, hvad forespørgslen finder. Det er alvorligt, men ikke kritisk, fordi den eneste kalder i dag er den lokale kommandolinje.
Svaret bygger på koden i PR’en.På GitHub og lokalt
ManiLens findes i to udgaver, som bruger de samme reviewere:
Det viste sig at være vigtigt. I starten af oktober var GitHubs gratis minutter brugt op, og reviews på GitHub stod stille. Den lokale udgave kørte videre, fordi den ikke bruger GitHub-minutter.
Målt mod CodeRabbit
Jeg har målt ManiLens på 10 rigtige pull requests fra mine projekter, som CodeRabbit allerede havde læst. En tredje model har afgjort, om hvert fund var en ægte fejl.
ManiLens fandt 21 af CodeRabbits 31 ægte fejl. Omkring 90 % af ManiLens’ egne fund var ægte, og 15 af dem havde CodeRabbit ikke fundet.
De fejl, den missede, var især i frontend og i meget store PR’er. Derfor får den nu de store PR’er i bidder og en tjekliste til frontend. Det blev målt på 9 nye PR’er, som ikke var brugt til at skrive tjeklisten:
CodeRabbit-fejl fundet (af 45)
12→12
Ægte fejl overset
11→11
Tallene er fra få kørsler, og modellen, der dømmer, er ikke altid enig med sig selv. De viser retningen, ikke en garanti.
Hvor langt den er
ManiLens læser i dag pull requests i mine egne projekter. Den har en server med login og en kontoside, hvor man kan se sine reviews, og en lille gruppe kolleger er ved at prøve den.
Hvor langt den er
- Reviewbygget og i brug
- Lokaltbygget og i brug
- Kollegerafprøvning i gang
- Retter selvbygget, men slået fra
Den kan også rette koden selv, skrive tests og løse mergekonflikter, men det er slået fra, indtil det er afprøvet ordentligt. Store PR’er er stadig det svageste sted. Casen bliver opdateret, efterhånden som den bliver bedre.