Ihr Team prüft jeden Pull Request. Sie haben Linting-Regeln, CI-Checks und eine Kultur sorgfältiger Code-Reviews. Gut so. Diese Disziplin ist wichtig.
Aber denken Sie darüber nach, was das tatsächlich abdeckt. Jedes PR-Review betrachtet einen Diff: eine Handvoll geänderter Dateien, bewertet im Kontext des Umfelds. Der Reviewer prüft, ob der neue Code sinnvoll ist, Konventionen befolgt und keine offensichtlichen Probleme einführt.
Jetzt denken Sie darüber nach, was nicht abgedeckt ist. Die 412.000 Zeilen, die schon da waren, als Sie angefangen haben. Der Code, der von Leuten geschrieben wurde, die vor drei Jahren gegangen sind. Die Module, die funktionieren, aber niemand vollständig versteht. Der Authentifizierungsfluss, der 2019 aus einem Tutorial kopiert wurde. Die Fehlerbehandlung, die in manchen Dateien Exceptions verschluckt und in anderen zum Absturz führt.
Niemand hat diesen Code jemals geprüft. Nicht als Ganzes. Nicht mit frischem Blick. Nicht mit der Frage: Ergibt diese Codebasis Sinn?
Das ist kein Tooling-Problem. Es ist ein Kategorienproblem.
Die Werkzeuge, die Sie haben, sind für bestimmte Bereiche konzipiert, und darin sind sie gut. Aber keines davon ist darauf ausgelegt, eine gesamte Codebasis zu lesen und über sie als Ganzes zu urteilen.
- PR-Review-Tools sehen Diffs. Sie vergleichen, was sich geändert hat, mit dem, was vorher da war. Sie können Ihnen nicht sagen, dass das, was vorher da war, bereits fehlerhaft war.
- Statische Analyse-Tools prüfen Regeln. Sie finden ungenutzte Variablen, ungeprüfte Null-Werte und musterbasierte Schwachstellen. Sie können Ihnen nicht sagen, dass Ihre Codebasis drei verschiedene Ansätze für Konfigurationsmanagement hat und keiner davon dokumentiert ist.
- IDE-Agenten schauen nach vorn, nicht zurück. Sie helfen Ihnen, neuen Code zu schreiben. Sie betrachten nicht die 200 Dateien, die Sie gerade nicht bearbeiten, und fragen, ob diese Dateien überhaupt existieren sollten.
Es gibt eine Lücke zwischen dem Review jeder einzelnen Änderung und dem Review des Ganzen. Diese Lücke existiert seit der Erfindung der Versionskontrolle, denn die einzige Möglichkeit, sie zu schließen, war, jemanden Teuren zu beauftragen, die gesamte Codebasis zu lesen. Und das macht niemand.
Also haben wir ein Tool gebaut, das das ganze Buch liest.
VibeRails ist eine Desktop-Anwendung, die Frontier-KI-Modelle orchestriert, um Full-Codebase Code Review durchzuführen. Kein Diff. Kein Regel-Check. Ein Review jeder Datei in Ihrem Projekt, bewertet als kohärentes Ganzes.
Der Workflow besteht aus vier Schritten:
- Auswählen. Fügen Sie Ihr Projektverzeichnis hinzu. VibeRails scannt den Dateibaum lokal und bereitet den Review-Umfang vor.
- Reviewen. VibeRails orchestriert Claude Code oder Codex CLI, um jede Datei zu lesen, Kontext aufzubauen und Issues in 17 Erkennungskategorien zu identifizieren – von Sicherheitslücken und Performance-Engpässen über Dead Code, Komplexitäts-Hotspots bis hin zu architektonischen Inkonsistenzen.
- Triagieren. Findings werden einzeln mit vollständigem Code-Kontext präsentiert. Akzeptieren, ablehnen oder zurückstellen – per Tastaturkürzel. Ihr technisches Urteil formt den Behebungsplan.
- Fixen. Für akzeptierte Findings starten KI-Fix-Sessions, die Änderungen direkt in Ihrem lokalen Repository umsetzen. Diff prüfen, testen, committen oder verwerfen. Sie behalten die Kontrolle.
Das Ergebnis ist etwas, das es vorher nicht gab: ein strukturiertes, priorisiertes Inventar aller Probleme in Ihrer Codebasis, erstellt von einer KI, die tatsächlich alles gelesen hat.
Zwei Dinge, die anders sind
Die meisten KI-Entwicklertools funktionieren gleich: Sie melden sich bei einer gehosteten Anbieterplattform an, verbinden ein Repo, senden Ihren Code dorthin und zahlen eine wiederkehrende Gebühr. VibeRails geht einen anderen Weg: Es läuft als Desktop-App und orchestriert die KI-Tools, die Sie ohnehin verwenden.
Erstens: Sie bringen Ihre eigene KI mit. VibeRails orchestriert Ihre vorhandenen Claude Code und Codex CLI Installationen. Ihre API Keys bleiben auf Ihrem Rechner, und Ihre bestehenden KI-Abonnements bezahlen die Rechenleistung. Wenn Sie Sessions starten, wird relevanter Code direkt von Ihrem Rechner an den in diesen Tools konfigurierten KI-Anbieter gesendet. VibeRails betreibt kein Cloud-Backend und proxyt Ihre Requests nicht, und wir empfangen oder speichern Ihren Quellcode nicht. Das ist das BYOK-Modell – Bring Your Own Key.
Zweitens: Die Preisgestaltung spiegelt das wider. Da wir nicht für Ihre KI-Nutzung bezahlen, steckt kein KI-Aufschlag in der Lizenzgebühr. VibeRails kostet $299 pro Entwickler für eine Lifetime-Lizenz, oder $19/Monat pro Entwickler im Monatsabo. Eine Lizenz pro Rechner. Es gibt auch eine kostenlose Version: bis zu 5 Issues pro Review-Session, keine Registrierung, keine Kreditkarte.
Lesen Sie das ganze Buch
Sie haben bisher jedes Kapitel geprüft, sobald es geschrieben wurde. Das ist notwendig. Aber es sagt Ihnen nicht, ob das Buch als Ganzes Sinn ergibt.
VibeRails liest das ganze Buch. Laden Sie es herunter, richten Sie es auf Ihre Codebasis und finden Sie heraus, was die ganze Zeit offen sichtbar verborgen war.
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.