Je team reviewt elke pull request. Je hebt linting-regels, CI-checks en een cultuur van zorgvuldige code review. Goed zo. Die discipline is belangrijk.
Maar denk eens na over wat dat eigenlijk dekt. Elke PR-review bekijkt een diff: een handvol gewijzigde bestanden, beoordeeld tegen de omliggende context. De reviewer controleert of de nieuwe code logisch is, conventies volgt en geen voor de hand liggende problemen introduceert.
Denk nu eens na over wat het niet dekt. De 412.000 regels die er al waren toen je begon. De code die geschreven is door mensen die drie jaar geleden zijn vertrokken. De modules die werken maar die niemand volledig begrijpt. De authenticatie-flow die in 2019 uit een tutorial is gekopieerd. De foutafhandeling die in sommige bestanden exceptions slikt en in andere crasht.
Niemand heeft die code ooit gereviewd. Niet als geheel. Niet met frisse ogen. Niet met de vraag: is deze codebase logisch?
Dit is geen tooling-probleem. Het is een categorieprobleem.
De tools die je hebt zijn ontworpen voor specifieke scopes, en daar zijn ze goed in. Maar geen ervan is ontworpen om een volledige codebase te lezen en erover na te denken.
- PR-review-tools zien diffs. Ze vergelijken wat er veranderd is met wat er daarvoor was. Ze kunnen je niet vertellen dat wat er daarvoor was al kapot was.
- Statische analyzers controleren regels. Ze vinden ongebruikte variabelen, ongecontroleerde null-waarden en patroongebaseerde kwetsbaarheden. Ze kunnen je niet vertellen dat je codebase drie verschillende aanpakken voor configuratiebeheer heeft en dat geen ervan gedocumenteerd is.
- IDE-agents kijken vooruit, niet achteruit. Ze helpen je nieuwe code te schrijven. Ze kijken niet naar de 200 bestanden die je op dit moment niet bewerkt en vragen niet of die bestanden eigenlijk wel zouden moeten bestaan.
Er zit een kloof tussen het reviewen van elke wijziging en het reviewen van het geheel. Die kloof bestaat al sinds de uitvinding van versiebeheer, omdat de enige manier om hem te dichten was om iemand duur in te huren om de hele codebase door te lezen. En dat doet niemand.
Dus hebben we een tool gebouwd die het hele boek leest.
VibeRails is een desktopapplicatie die frontier AI-modellen orkestreert om full-codebase code review uit te voeren. Geen diff. Geen regelcontrole. Een review van elk bestand in je project, beoordeeld als samenhangend geheel.
De workflow bestaat uit vier stappen:
- Aanwijzen. Voeg je projectmap toe. VibeRails scant de bestandsstructuur lokaal en bereidt een review-scope voor.
- Reviewen. VibeRails orkestreert Claude Code of Codex CLI om elk bestand te lezen, context op te bouwen en issues te identificeren in 17 detectiecategorieën – van beveiligingslekken en performance-knelpunten tot dead code, complexiteits-hotspots en architecturale inconsistenties.
- Triageren. Findings worden één voor één gepresenteerd met volledige code-context. Accepteer, wijs af of stel uit met sneltoetsen. Jouw technisch oordeel vormt het herstelplan.
- Fixen. Voor geaccepteerde findings worden AI-fix-sessies gestart die wijzigingen direct in je lokale repository doorvoeren. Bekijk de diff, test, commit of revert. Jij houdt de controle.
Het resultaat is iets dat eerder niet bestond: een gestructureerde, geprioriteerde inventaris van alles wat er mis is met je codebase, gemaakt door een AI die daadwerkelijk alles heeft gelezen.
Twee dingen die anders zijn
De meeste AI-ontwikkeltools werken op dezelfde manier: je meldt je aan voor een gehost vendorplatform, koppelt een repo, stuurt je code erheen en betaalt een terugkerend bedrag. VibeRails pakt het anders aan: het draait als desktopapp en orkestreert de AI-tools die je al gebruikt.
Ten eerste: je brengt je eigen AI mee. VibeRails orkestreert je bestaande Claude Code- en Codex CLI-installaties. Je API keys blijven op je machine, en je bestaande AI-abonnementen betalen de rekenkracht. Wanneer je sessies start, wordt relevante code rechtstreeks vanaf je machine naar de AI-provider gestuurd die in die tools is geconfigureerd. VibeRails draait geen cloud backend en proxy't je requests niet, en we ontvangen of bewaren je broncode niet. Dit is het BYOK-model – Bring Your Own Key.
Ten tweede: de prijsstelling weerspiegelt dat. Omdat wij niet betalen voor jouw AI-gebruik, hoeven we geen AI-markup in de prijs te verwerken. Elke developer koopt een eigen licentie – $299 voor een lifetime-licentie, of $19/maand als je maandelijks wilt betalen. Eén licentie per machine. Er is ook een gratis versie: tot 5 issues per review-sessie, geen registratie, geen creditcard.
Lees het hele boek
Je hebt tot nu toe elk hoofdstuk gereviewd zodra het geschreven werd. Dat is noodzakelijk. Maar het vertelt je niet of het boek als geheel logisch is.
VibeRails leest het hele boek. Download het, richt het op je codebase en ontdek wat er al die tijd voor het oprapen lag.
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.