- Un outil qui différencie en couleur chaque ligne et chaque token dans les changements de code (
diff) afin de visualiser le niveau d’examen nécessaire
- Conçu non pas pour une simple détection de bugs, mais pour mettre en avant « les parties qui méritent d’être revues »
- Utilisable immédiatement en remplaçant
github.com par 0github.com dans l’URL d’une Pull Request GitHub
- En interne, le système clone le dépôt dans une VM et exécute gpt-5-codex afin de produire un résultat d’analyse au format JSON
Aperçu
- Cet outil affiche sous forme de heatmap à quel point chaque partie du code modifié doit être examinée avec attention pendant la revue de code
- Les couleurs sont attribuées selon le niveau d’attention humaine requis, avec une approche différente d’une simple détection d’erreurs
Fonctionnement
- L’utilisateur accède au service en remplaçant le domaine de l’URL d’une Pull Request GitHub de
github.com par 0github.com
- Le système clone le dépôt concerné dans une machine virtuelle (VM) et exécute le modèle gpt-5-codex sur chaque diff
- La structure de données JSON générée par le modèle est analysée puis convertie en heatmap colorée
Critères d’analyse
- Il ne s’agit pas simplement de déterminer s’il y a un bug, mais de mettre en avant les éléments qui nécessitent une nouvelle vérification humaine, comme des secrets codés en dur, des modes de chiffrement inhabituels ou une logique complexe
1 commentaires
Avis Hacker News
Sur une base de code familière, je me dis : « merci LLM, mais je connais mieux le sujet, donc pas besoin ».
À l’inverse, si le code ne m’est pas familier, de toute façon je n’approuve pas la review ni le merge.
Cela dit, ce type d’usage créatif des LLM reste une tentative intéressante.
Le code supprimé n’était pas signalé du tout, et seules des lignes inchangées étaient surlignées.
L’intention était honnête, mais le résultat est décevant.
Je me demandais pourquoi GitHub demandait aussi l’autorisation d’agir à ma place.
cmux-agentdemandait un accès complet à mon compte GitHub.J’ai voulu ouvrir une issue, mais la fonctionnalité était désactivée sur le dépôt. Ça donnait une impression un peu suspecte.
J’ai testé en navigation privée les PR d’exemple, stack-auth, tinygrad, datasette, et ça fonctionnait bien.
Je ne savais pas pour les issues désactivées, et maintenant la page des issues fonctionne normalement.
Une GitHub App peut être installée uniquement sur certains dépôts, mais elle inclut quand même le droit « d’agir au nom de l’utilisateur ».
C’est pour cela que la fenêtre de permission a l’air inquiétante.
Mon application codeinput.com est une OAuth App et ne demande que l’email, mais cela crée un flux d’authentification complexe puisqu’il faut encore passer par une étape d’installation après la connexion.
L’orientation est intéressante, mais le rapport coût/utilité reste flou.
Pour l’instant, il est encore difficile pour un LLM de comprendre le contexte d’un projet à partir du seul diff d’une PR.
Une heatmap fondée sur les données, basée par exemple sur les bugs passés ou la fréquence des changements, semblerait peut-être plus fiable.
Ce serait encore mieux si on pouvait l’exécuter avec sa propre clé.
On pourrait peut-être réduire le coût par distillation, mais on est encore en phase d’expérimentation.
Je me demande aussi s’il y aurait un moyen de calculer la corrélation avec les bugs passés sans LLM.
Ce genre d’outil ne peut donc, au final, résoudre qu’une partie du problème.
Il est aussi possible que ce soient simplement des parties que les gens examinent de plus près.
Ce serait intéressant de le valider à partir de données open source.
J’étais content de voir ma PR apparaître sur HN.
Ce serait bien de pouvoir laisser le seuil à 0 % et ajuster plus finement le dégradé de couleurs.
Je me demande aussi si on pourrait utiliser cet outil pour pré-relire du code généré par l’IA avant même de créer la PR.
J’aimerais aussi avoir des retours sur l’idée d’une commande CLI ou HTML pour rendre le diff.
Le nom de domaine 0github.com me semble difficile à conserver sur la durée. Mieux vaudrait trouver rapidement un autre domaine.
Cela semble particulièrement utile pour les très grosses PR.
Au lieu d’un simple curseur, ce serait bien de pouvoir cliquer sur les couleurs pour voir directement leur signification.
Pour l’instant, ce n’est pas évident à lire d’un seul coup d’œil, mais avec l’habitude ça viendrait sans doute.
Je prévois aussi de l’améliorer pour qu’il soit visible sur mobile. Je me demande si une autre forme d’affichage serait préférable.
Je l’ai testé sur une petite PR Rust, et ça marchait plutôt bien.
Cela dit, ce serait bien de pouvoir ajuster plus finement l’emplacement des surlignages.
J’ai été impressionné qu’il ait repéré une faute de frappe presque invisible dans la PR d’un collègue.
Lien vers la PR testée
Une partie du code supprimé est signalée, mais beaucoup de choses sont ignorées.
Je me demandais si cela reposait sur un calcul de distance entre tokens.
Pour l’instant, c’est simplement basé sur un prompt LLM.
À terme, cela pourrait évoluer vers une approche de détection de tokens hallucinés. Je vais chercher des articles à ce sujet.
Avec la multiplication récente des grosses PR générées par l’IA, j’ai senti le besoin d’un outil comme celui-ci.
Ce serait bien s’il pouvait apprendre le style du reviewer pour fournir des reviews personnalisées.
Je vérifie si ce commit est bien le bon.
J’expérimente aussi avec un système DSPy pour une automatisation des reviews adaptée aux préférences du reviewer.
En réalité, le plus important reste sans doute de faire des PR de taille raisonnable, au point de ne plus avoir besoin d’un tel outil.
En ce moment, on relit des PR écrites par une IA, et parfois une IA répond même à mes commentaires.
On finira probablement dans un monde où les reviewers eux-mêmes seront remplacés par l’IA.
J’ai cliqué sur une PR d’exemple, mais elle restait en chargement permanent. On dirait qu’il faudrait du cache.