Je SonarQube-dashboard toont 0 kritieke issues. Overal groen. Uitrollen maar.
Ondertussen heeft je codebase drie incompatibele session management-aanpakken. Er is een zelfgebouwd ORM dat verbindingsfouten stilletjes slikt. De authenticatie-flow werkt technisch gezien, maar schendt elk beveiligingsprincipe uit de OWASP top 10 – niet vanwege een specifieke kwetsbaarheid die een scanner zou opmerken, maar omdat de algehele architectuur niet logisch is. De session tokens worden in de ene module opgeslagen in localStorage en in de andere in httpOnly cookies. De wachtwoord-reset-flow omzeilt de rate limiter omdat deze gebouwd werd voordat de rate limiter bestond.
Niets hiervan verschijnt op je dashboard. Elke regel wordt nageleefd. De codebase is groen.
Regels vinden regelovertredingen. Geen slechte architectuur.
Statische analyse-tools zijn uitstekend in wat ze doen. Ze matchen codepatronen tegen een database van bekende problemen. Ongebruikte variabele? Gevonden. Ongecontroleerde null-dereferentie? Gevonden. SQL-stringconcatenatie in plaats van geparametriseerde queries? Gevonden. Deze tools hebben duizenden echte bugs voorkomen die anders in productie waren beland, en ze verdienen elke adoptie die ze bereikt hebben.
Maar de moeilijkste problemen in legacy codebases zijn geen regelovertredingen. Het zijn architectuurbeslissingen die vijf jaar geleden logisch waren en dat nu niet meer zijn. Het zijn patronen die organisch zijn ontstaan toen verschillende teams hetzelfde probleem op verschillende manieren oplosten. Het is het soort problemen dat een ervaren developer zou opmerken tijdens een grondige code review, maar dat in geen enkele regeldatabase staat – omdat het geen overtredingen van een specifieke regel zijn, maar overtredingen van samenhang.
Bedenk wat een regelgebaseerde tool niet kan uitdrukken:
- Je project gebruikt drie verschillende logging-frameworks – Winston in de API-laag, Bunyan in de background workers en rauwe
console.login de utilities. Geen ervan is op zichzelf fout. Samen betekenen ze dat je observability versnipperd is, je logformaten inconsistent zijn en het debuggen van een request die modulegrenzen overschrijdt drie verschillende outputs vereist. - De helft van je asynchrone code gebruikt callbacks en de andere helft Promises. Iemand is twee jaar geleden begonnen met een migratie en is halverwege gestopt. Het resultaat is dat foutafhandeling zich anders gedraagt afhankelijk van in welke helft van de codebase je je bevindt – en de grens tussen de twee helften is waar de bugs leven.
- Er zijn 47 feature flags in de configuratie. Twaalf ervan besturen features die meer dan een jaar geleden voor alle gebruikers zijn uitgerold. Acht verwijzen naar beëindigde A/B-tests. Drie worden in de code gecontroleerd maar nergens gezet. Niemand durft ze te verwijderen omdat niemand weet wat ze allemaal doen.
Een statische analyzer zal niets hiervan markeren. Het zijn geen regelovertredingen. Het is het soort opgehoopte complexiteit dat codebases moeilijk bewerkbaar, traag veranderbaar en duur in onderhoud maakt.
Wat “review” werkelijk betekent
Wanneer een ervaren developer een codebase reviewt – geen diff, maar een daadwerkelijke codebase – controleert hij geen regels. Hij bouwt een mentaal model op. Hij leest bestand na bestand en accumuleert context. Hij begint patronen te herkennen: hoe fouten hier versus daar worden afgehandeld, welke conventies consistent worden gevolgd en welke niet, waar de grenzen tussen modules schoon zijn en waar ze verstrengeld zijn.
Hij merkt dingen op die er niet thuishoren. Een database-query in een view-template. Bedrijfslogica in een utility-functie. Een retry-mechanisme dat vier keer in vier verschillende bestanden opnieuw is geïmplementeerd. Configuratiewaarden die op sommige plekken hardcoded zijn en op andere uit omgevingsvariabelen worden gelezen.
Dit soort review levert iets op dat geen dashboard kan bieden: een narratief begrip van wat er mis is met de codebase en waarom. Geen lijst van issues op regelniveau, maar een beoordeling van het systeem als geheel.
Het probleem is dat deze review dagen of weken dure mensentijd kost. Dus vindt het bijna nooit plaats. De codebase groeit, de inconsistenties stapelen zich op en het dashboard blijft groen.
Dit is precies het soort redenering dat large language models nu op schaal kunnen uitvoeren. Een LLM kan bestanden sequentieel lezen, context opbouwen over honderden bestanden en redeneren over de relaties ertussen. Het controleert niet of een regel een regel schendt. Het vraagt of de code als geheel logisch is.
VibeRails vult de kloof
VibeRails is een desktopapplicatie die Claude Code en Codex CLI orkestreert om full-codebase code review uit te voeren. Het leest elk bestand in je project, redeneert over het geheel en brengt de issues aan het licht die tussen de regels leven – de issues waarvoor regelgebaseerde tools nooit ontworpen waren.
De analyse omvat 17 detectiecategorieën die verder gaan dan wat pattern matching kan uitdrukken: beveiligingslekken, performance-knelpunten, bug-risico's, dead code, complexiteits-hotspots, type-safety-lacunes, zwakheden in foutafhandeling, API-designproblemen, toegankelijkheidsproblemen, observability-lacunes, concurrency-risico's, data-integriteitsproblemen, internationalisatie-issues, afhankelijkheidsproblemen, documentatielacunes, testdeficiënties en onderhoudbaarheids-smells.
De triage-modus laat je findings efficiënt verwerken – accepteer, wijs af of stel uit met sneltoetsen. Fix-sessies sturen AI aan om de wijzigingen direct in je lokale repository door te voeren. Jij bekijkt de diff, test en commit.
VibeRails gebruikt het BYOK-model: het orkestreert je bestaande AI-abonnementen in plaats van requests te proxy'en via een VibeRails cloud service. Je API keys blijven lokaal, en je code wordt niet geüpload naar VibeRails servers. Je betaalt geen tussenpersoon om je toegang te verkopen tot AI die je al hebt.
Statische analyse is noodzakelijk. Alleen niet voldoende. Het groene dashboard vertelt je dat je code de regels volgt. Het vertelt je niet of de regels de juiste zijn, of dat de code die ze volgt als systeem logisch is.
Probeer VibeRails gratis – tot 5 issues per review-sessie, geen registratie vereist.
Limits and tradeoffs
- It can miss context. Treat findings as prompts for investigation, not verdicts.
- False positives happen. Plan a quick triage pass before you schedule work.
- Privacy depends on your model setup. If you use a cloud model, relevant code is sent to that provider; local models can keep inference on your own hardware.