Sphinx : un hook Git pour vérifier votre compréhension du code avant de pousser
Sommaire
En bref
- Sphinx est un hook Git qui pause les poussées de code et pose une question tirée du diff pour forcer le développeur (ou l'agent IA) à justifier ses changements.
- Il s'appuie sur une idée simple : écrire du code avec une IA sans le comprendre crée un risque cognitif et un problème de maintenance.
- L'outil fonctionne minimal, s'intègre aux workflows existants (OpenRouter, endpoints OpenAI-compatibles) et log les skips en cas d'urgence.
Ce que dit la source
Sphinx répond à un problème réel observé par les utilisateurs d'agents de code : l'externalisation de la rédaction du code sans compréhension concomitante. Le postulat de l'outil est que forcer le développeur à expliquer ce que le code fait quand les choses tournent mal (scénarios d'erreur, edge cases) crée une friction constructive : elle révèle les trous dans la connaissance et renforce la responsabilité avant la mise en production. L'auteur ne prétend pas « résoudre » le problème culturel de la cession de l'intellect, mais créer un artefact qui le rend visible et inconfortable.
- Fonctionne comme un contrôle de compréhension distribué : le hook génère une question sur le diff, attend une réponse, puis poursuit ou refuse la poussée selon la qualité de la compréhension démontrée
- Les questions portent spécifiquement sur les scénarios d'erreur et les cas limites (« que se passe-t-il si la charge échoue ? ») plutôt que sur la mécanique du code
- Token-léger et agnostique : compatible avec Codex, Claude Code, Cursor ou tout endpoint OpenAI-compatible ; les réponses n'atteignent jamais l'agent et les fichiers .env ne sont jamais exposés
- Existe un mode `sphinx yolo` pour les urgences, mais chaque skip est enregistré pour traçabilité
- L'approche inverse une critique classique des hooks de révision : au lieu de laisser une IA relire du code, elle force le développeur à se relier à son propre changement
Dans les commentaires
Débat partagé mais sceptique. Plusieurs commentateurs reconnaissent le problème réel (perte de compréhension lors de la sous-traitance au code), mais divergent profondément sur le remède : pour certains, la vraie solution est d'exiger une bonne documentation de PR (ce qui force déjà la compréhension sans outil) ; pour d'autres, le questionnement est une friction de trop et disparaîtra dans une chaîne où les agents eux-mêmes apprendront à répondre aux quizz ; un utilisateur rapporte avoir abandonné l'outil par frustration avec le format ; enfin, quelques commentateurs suggèrent que c'est un pansement sur un problème structurel (la transformation fondamentale du rôle du développeur) plutôt qu'une vraie solution.
- Un commentateur rapporte avoir construit quelque chose de très similaire (PEAK) il y a six mois, puis l'avoir abandonné : selon lui, l'idée avait du sens au démarrage des agents de code, mais aujourd'hui la question est ailleurs, comment redéfinir la relation humain/agent plutôt que de gamifier la compréhension
- La suggestion récurrente : utiliser une bonne description de PR force déjà la compréhension sans outil supplémentaire, et c'est une pratique éprouvée
- Un développeur confesse ne pas lire du tout le code généré par Claude Code, ce qui contredit tacitement la prémisse selon laquelle un quiz motiverait la lecture
- Un autre cite la fatigue de confirmation : tôt ou tard, des agents seront construits pour répondre aux quizz à la place du développeur, créant une boucle infinie de délégation
- Objection sur la citation attribuée à Sun Tzu : un commentateur demande si elle est réelle ou inventée (elle n'est pas vérifiable)
- Un utilisateur note que le format quiz ne détecte pas les mauvaises décisions architecturales ou métier, seulement l'incompréhension mécanique
Alternatives citées : PEAK (Proof of Effort And Knowledge) cité par un commentateur comme alternative développée indépendamment ; skill de quiz manuel construit avec Claude par au moins deux utilisateurs ; automo.build mentionné comme approche alternative (tester et fiabiliser l'équipe d'abord, plutôt que de fiabiliser chaque push)
Notre lecture
Sphinx articule bien un vrai problème : la perte de compréhension quand on code avec des agents accélère l'accumulation de dette technique et transforme le rôle du développeur en vérificateur passif. Mais le fil HN suggère que le problème ne peut pas être résolu par un outil seul. Les commentateurs les plus réfléchis pointent que soit on revient à l'écriture et à la documentation manuelles (auquel cas l'outil est superflu), soit on accepte une nouvelle division du travail humain-machine (auquel cas forcer un questionnaire crée juste une friction qui sera contournée. La véritable question, comment une équipe s'approprie un code généré, dépasse l'outillage. À tester pour les équipes qui veulent formaliser la relecture, mais probablement pas une solution structurante face à la transformation plus profonde du métier de développeur.