cubic

Sobald die GitHub-App installiert ist, führt cubic ohne Aufforderung ein GitHub-Pull-Request-Review bei jedem neuen PR durch. Es hinterlässt Inline-Kommentare zu Bugs und möglichen Verbesserungen, sodass Sie die Probleme direkt neben der Codezeile sehen, die sie verursacht hat. In einem stark genutzten Repo heißt das: Rückmeldung kommt in Sekunden statt erst, wenn ein Reviewer Zeit findet.

Sie beschreiben Ihre Standards in gewöhnlicher Sprache statt in komplexer Konfiguration, was vor allem in Teams zählt, in denen nur eine Person wirklich versteht, wie die aktuellen Linter-Regeln aufgebaut wurden. cubic macht aus diesen Regeln Review-Prüfungen und markiert Code, der sie verletzt. Der Gewinn: Konventionen liegen an einer lesbaren Stelle und nicht über ein Dutzend Linter-Dateien verstreut.

Einfache Probleme kommen mit einer Ein-Klick-Korrektur, die die Änderung für Sie übernimmt. Bei schwierigeren drücken Sie auf „Fix with cubic“ und lassen einen Coding-Agenten einen Patch entwerfen. Es löst nicht alles von allein, aber es räumt den Kleinkram weg, damit menschliche Review-Zeit den Ermessensentscheidungen zugutekommt.

cubic studiert, wie Ihre Senior-Engineers reviewen. Es liest deren frühere PR-Kommentare, um Ihren Hausstil aufzunehmen, und wendet dieses Muster dann auf neue Reviews an, was eine generische Checkliste schlicht nicht erreicht. Mit der Zeit klingt die Rückmeldung weniger generisch und mehr wie die Person, die Ihren Code normalerweise prüft.

Über einzelne PRs hinaus kann cubic nach Zeitplan Tausende KI-Agenten durch Ihr gesamtes Repository schicken, das heißt, das Review hört nicht auf, wenn Sie abends den Laptop zuklappen. Der Scan sucht nach ernsten Bugs und Sicherheitsproblemen, sortiert die Funde, benachrichtigt den richtigen Besitzer oder öffnet ein Ticket. Er plant sich selbst neu, sodass jeder Lauf die seit dem letzten hinzugekommenen Probleme erwischt.

Der Reviewer holt Hintergrund aus Linear, JIRA, Notion und ähnlichen Planungstools. Zusätzlicher Kontext hilft ihm zu verstehen, warum eine Änderung gemacht wurde, nicht nur, was der Code für sich tut. In der Praxis bekommen Sie weniger Kommentare, die am Kern eines Tickets vorbeigehen.

cubic läuft in Cursor, Claude Code, VS Code, Codex und anderen Coding-Agenten, dazu eine lokale CLI. Sie können Änderungen vor dem Push prüfen oder es per API-Schlüssel headless in der CI laufen lassen. Derselbe Kopf, andere Tür. Der Code bekommt im Editor und auf GitHub dieselbe Behandlung.