- Ein Tool, das jede Zeile und jedes Token in Code-Änderungen (Diffs) farblich unterscheidet, um zu visualisieren, wie stark eine Prüfung nötig ist
- Es ist nicht für einfache Bug-Erkennung gedacht, sondern darauf ausgelegt, „Bereiche, die einen zweiten Blick wert sind“ hervorzuheben
- Direkt nutzbar, indem in einer GitHub-Pull-Request-URL
github.com durch 0github.com ersetzt wird
- Intern wird das Repository in eine VM geklont und gpt-5-codex ausgeführt, um Analyseergebnisse in einer JSON-Struktur zu erzeugen
Überblick
- Dieses Tool markiert im Code-Review-Prozess jeden Teil des geänderten Codes als Heatmap danach, wie aufmerksam er geprüft werden sollte
- Die Farben werden nach dem Maß der erforderlichen menschlichen Aufmerksamkeit vergeben und verfolgen damit einen anderen Ansatz als reine Fehlererkennung
Funktionsweise
- Nutzer greifen darauf zu, indem sie in der GitHub-Pull-Request-URL die Domain von
github.com auf 0github.com ändern
- Das System klont das betreffende Repository in eine virtuelle Maschine (VM) und führt für jeden Diff das Modell gpt-5-codex aus
- Die vom Modell erzeugte JSON-Datenstruktur wird geparst und in eine farbige Heatmap umgewandelt
Analysekriterien
- Nicht nur „ob ein Bug vorliegt“, sondern auch hartcodierte Geheimnisse, ungewöhnliche Verschlüsselungsmodi, komplexe Logik usw.
hebt Bereiche hervor, die Menschen noch einmal prüfen sollten
1 Kommentare
Hacker-News-Kommentare
Bei einer vertrauten Codebasis denke ich: „Danke, LLM, aber ich kenne mich besser aus und brauche das nicht.“
Bei unbekanntem Code würde ich den Review ohnehin gar nicht erst freigeben oder mergen.
Trotzdem ist so ein kreativer Einsatz von LLMs ein interessanter Versuch.
Gelöschter Code wurde überhaupt nicht angezeigt, und stattdessen wurden nur unveränderte Zeilen hervorgehoben.
Ein ehrlicher Versuch, aber das Ergebnis ist enttäuschend.
Ich habe mich gefragt, warum GitHub dafür sogar die Berechtigung verlangt, in meinem Namen zu handeln.
cmux-agentfordert Vollzugriff auf das gesamte GitHub-Konto an.Ich wollte ein Issue anlegen, aber im Repository war die Issue-Funktion deaktiviert. Das wirkte etwas verdächtig.
Ich habe im Inkognito-Modus die Beispiel-PRs, stack-auth, tinygrad und datasette getestet, und es funktionierte gut.
Dass Issues deaktiviert waren, wusste ich nicht; inzwischen ist die Issue-Seite wieder normal erreichbar.
Eine GitHub App kann zwar nur für bestimmte Repositories installiert werden, enthält aber weiterhin die Berechtigung, „im Namen des Nutzers zu handeln“.
Deshalb erscheint dieses beängstigende Popup.
Meine App codeinput.com ist eine OAuth App und fragt nur nach der E-Mail, aber dafür entsteht nach dem Login ein komplizierter Authentifizierungsfluss, weil anschließend noch eine Installation nötig ist.
Die Richtung ist interessant, aber Nutzen im Verhältnis zu den Kosten ist fraglich.
Für ein LLM ist es noch schwer, nur anhand eines einzelnen PR-Diffs den Projektkontext zu verstehen.
Eine datenbasierte Heatmap auf Grundlage früherer Bugs oder der Änderungshäufigkeit wäre womöglich verlässlicher.
Noch besser wäre es, wenn man es mit einem eigenen Key ausführen könnte.
Mit Distillation ließen sich die Kosten vielleicht senken, aber wir testen noch.
Ich überlege auch, ob sich die Korrelation mit früheren Bugs ohne LLM berechnen lässt.
Solche Tools können letztlich nur einen Teil des Problems lösen.
Es kann auch sein, dass Menschen dort einfach aufmerksamer hinschauen.
Es wäre interessant, das anhand von Open-Source-Daten zu überprüfen.
Ich habe mich gefreut, dass mein PR auf HN gelandet ist.
Es wäre gut, wenn man den Schwellenwert auf 0 % setzen und den Farbverlauf vielfältiger anpassen könnte.
Ich frage mich auch, ob man mit diesem Tool von einer AI erzeugten Code schon vor dem Erstellen des PR vorab reviewen könnte.
Ich würde gern Meinungen dazu hören, ob ein Befehl zum Rendern des Diffs per CLI oder HTML sinnvoll wäre.
Der Domainname 0github.com dürfte sich langfristig schwer halten lassen. Es wäre besser, schnell eine andere Domain zu finden.
Besonders bei großen PRs scheint das nützlich zu sein.
Statt eines Sliders wäre es gut, wenn man pro Farbe klicken und die Bedeutung direkt sehen könnte.
Im Moment ist es nicht leicht, alles auf einen Blick zu erfassen, aber bei häufiger Nutzung gewöhnt man sich vermutlich daran.
Das soll künftig auch auf Mobilgeräten sichtbar werden. Ich würde gern wissen, ob eine andere Darstellungsform besser wäre.
Ich habe es auf einen einfachen Rust-PR angewendet, und es funktionierte ziemlich gut.
Es wäre allerdings gut, wenn man die Position der Hervorhebungen noch feiner justieren könnte.
Beeindruckend war, dass in einem PR eines Kollegen ein kaum sichtbarer Tippfehler gefunden wurde.
Link zum getesteten PR
Ein Teil des gelöschten Codes wird angezeigt, aber vieles wird ignoriert.
Ich habe mich gefragt, ob dabei die Distanz zwischen Tokens berechnet wird.
Im Moment basiert es auf einem einfachen LLM-Prompt.
Künftig könnte es sich zu einer Methode zur Erkennung halluzinierter Tokens weiterentwickeln. Ich will dazu passende Papers suchen.
In letzter Zeit gibt es viele große PRs, die von AI erzeugt wurden, und dadurch habe ich den Bedarf für so ein Tool gespürt.
Es wäre gut, wenn es den Stil des Reviewers lernen und darauf abgestimmte Reviews liefern könnte.
Ich prüfe gerade, ob dieser Commit der richtige ist.
Mit dem DSPy-System experimentieren wir gerade mit automatisierten Reviews, die auf die Vorlieben des Reviewers zugeschnitten sind.
Eigentlich ist es wichtiger, PRs in einer vernünftigen Größe zu erstellen, sodass man solche Tools gar nicht erst braucht.
Inzwischen reviewe ich PRs, die von AI geschrieben wurden, und sogar auf meine Kommentare antwortet AI.
Am Ende kommt wohl eine Zeit, in der auch Reviewer durch AI ersetzt werden.
Ich habe auf einen Beispiel-PR geklickt, aber es lädt nur endlos. Caching scheint nötig zu sein.