- Lors d’une implémentation en Go de ML-DSA, un algorithme de signature post-quantique standardisé par le NIST, un problème a fait échouer la vérification des signatures
- Claude Code v2.0.28 a rapidement trouvé un bug complexe de bas niveau à partir du seul code de test et des chemins du code source
- La cause a été identifiée comme une erreur de fusion de fonctions qui recalculait les bits de poids fort de
w1 en double à l’étape Verify
- Lors de deux expériences suivantes, Claude a également trouvé une erreur de calcul de constante Montgomery et un bug de longueur de signature incohérente
- Les trois essais ont permis d’identifier les bugs avec succès, montrant le potentiel de l’IA pour le débogage bas niveau
Implémentation de ML-DSA et problème initial
- L’auteur a réimplémenté en Go ML-DSA (Post-Quantum Signature Algorithm), standardisé par le NIST
- Après 4 jours de live coding, les tests ont révélé un problème où la fonction
Verify rejetait toutes les signatures
- Le journal de test affichait à répétition l’erreur
invalid signature
- À cause de la fatigue, l’auteur a interrompu le débogage et a demandé à Claude Code d’analyser le problème
Premier débogage par Claude Code
- Claude Code v2.0.28 (modèle Opus 4.1, sans system prompt) a reçu les informations suivantes
- la commande d’exécution des tests (
bin/go test crypto/internal/fips140/mldsa)
- l’emplacement du code (
src/crypto/internal/fips140/mldsa)
- l’explication selon laquelle « les signatures sont toujours rejetées » et l’indice «
w1 est différent »
- En quelques minutes, Claude a renvoyé une proposition de correction complète
- La cause était qu’après avoir fusionné
HighBits et w1Encode, l’étape Verify reprenait les bits de poids fort du résultat de UseHint, alors que celui-ci les avait déjà produits
- Autrement dit, il s’agissait d’une erreur structurelle calculant deux fois les bits de poids fort de
w1
- Claude a compris la cause juste après avoir chargé le code, puis a écrit ses propres tests pour valider son hypothèse
- La correction proposée n’était pas parfaite, mais l’identification de la cause centrale a réduit le temps de débogage
- L’auteur a ensuite refactoré
w1Encode pour lui faire recevoir les bits de poids fort en entrée, tout en raccourcissant la conversion en représentation Montgomery
Deuxième expérience : bugs dans l’étape de génération des signatures
- L’implémentation de la génération des signatures faisait elle aussi échouer les tests
- Premier bug : erreur de calcul des constantes (1, -1) dans le domaine Montgomery
- Problème difficile à trouver, ayant nécessité de nombreux
printf et plusieurs hypothèses, pour environ 1 à 2 heures de travail
- Deuxième bug : erreur de longueur d’une valeur incluse dans la signature (32 bits au lieu de 32 octets)
- Plus facile à repérer en raison de la différence de taille de signature
- L’auteur a jugé que ces deux bugs étaient adaptés pour évaluer les performances de Claude, puis a relancé Claude Code sur une version antérieure du code
Résultats du deuxième débogage par Claude Code
- Dans le premier prompt, Claude a effectué du débogage avec
printf et du traçage de valeurs, puis a trouvé et corrigé la constante erronée
- Le temps de traitement a été inférieur à celui d’un humain, et la cause de l’échec des tests a été identifiée avec précision
- Dans le second prompt, il a trouvé le problème d’incohérence de longueur de signature
- Après avoir exploré plusieurs pistes, Claude a proposé une correction ne modifiant que la longueur allouée
- La correction proposée n’était pas complète, mais l’emplacement de l’erreur principale était correctement pointé
- Dans les trois essais indépendants, Claude a trouvé seul la cause exacte des bugs
Efficacité du débogage par IA et implications
- L’approche de Claude s’est montrée efficace comme assistant automatisé spécialisé dans la recherche de causes d’échec de tests
- L’utilisateur n’a pas appliqué directement les correctifs de Claude, et s’est contenté de repérer l’emplacement du bug avant de corriger lui-même
- L’auteur évoque le besoin d’un outil où un LLM analyse automatiquement la cause lorsqu’un test échoue
- Il estime qu’un agent de débogage piloté par les tests serait plus idéal qu’un simple chat ou qu’une génération automatique de PR
Soutien et autres informations
- La maintenance open source de l’auteur est soutenue via Geomys, avec le soutien de
Smallstep, Ava Labs, Teleport, Tailscale et Sentry
- Ava Labs souligne l’importance d’un développement open source durable pour les protocoles cryptographiques
- Teleport présente la plateforme Teleport Identity pour empêcher la compromission de comptes utilisateurs et renforcer le contrôle d’accès
Annexe : image et mention personnelle
- L’article montre Clippy, le trombone de Microsoft Office, dans une bulle disant qu’il a « pris deux fois les bits de poids fort de
w1 »
- À la fin, une photo de chat est incluse, présentée comme une touche d’humour pour apaiser les débats émotionnels autour de l’IA
2 commentaires
Dernièrement, je fais un peu de développement de kernels GPU avec triton ou cuda, et alors qu’avec la 3.5 je ne voyais même pas de code qui s’exécutait correctement, avec la 4.5 on voit qu’il produit dans une certaine mesure du code correct et des optimisations.
Avis Hacker News
Utiliser un agent de codage pour remonter jusqu’à la cause racine d’un bug fonctionne plutôt bien.
Les trois sessions de débogage en one-shot ont réussi. L’essentiel est que le LLM ne modifie pas directement le code, mais joue le rôle d’un assistant qui indique seulement l’emplacement du bug afin que je puisse juger et corriger moi-même.
Cette approche peut aussi être un bon point de départ pour les sceptiques des LLM. Il ne s’agit pas de leur faire écrire le code à votre place, seulement de leur confier la recherche de bugs pénibles.
La proposition du type « il faut corriger ça » n’est pas forcément fausse, mais elle est souvent hors sujet par rapport au problème central. Au final, les suggestions de modifications inutiles s’accumulent, et si un développeur junior les applique telles quelles, cela ne fait qu’augmenter le travail superflu.
J’utilise aussi ce genre d’outils, mais j’ai souvent l’impression que « ça me prend encore plus de temps de l’expliquer à un junior ».
La génération de tests fonctionne bien pour l’algorithmique, mais atteint vite ses limites dans les situations de concurrence. Malgré cela, pour des usages comme la « génération de tests » ou le « débogage », cela reste largement utile.
En revanche, pour le refactoring du code ou la maintenance à long terme, c’est encore insuffisant.
En revanche, en les utilisant comme chasseurs de bugs comme le recommande le billet, j’ai été surpris par leur efficacité. En quelques semaines, ils ont permis de repérer plusieurs bugs en production.
Leur faire rédiger longuement la documentation pertinente avant de creuser vraiment le code présente peu de risques même s’ils se trompent, et c’est aussi une bonne porte d’entrée pour les plus sceptiques.
Je trouverais dommage de déléguer cela à une machine. La chasse aux bugs pousse à comprendre en profondeur l’architecture d’un système et aide, sur le long terme, à devenir un meilleur programmeur.
Sans ce type d’expérience, on risque de finir par dépendre du LLM jusque dans son propre jugement sur le code.
Mon conseil tient en un mot : AI First.
En soumettant d’abord le problème à l’IA, on apprend à la fois les limites du modèle et on développe sa capacité à structurer les prompts.
Les modèles récents sont assez puissants pour être traités comme des collègues sur la plupart des problèmes. Mais il est essentiel de comprendre leurs modes d’échec et de se forger une intuition.
À chaque nouvelle génération de modèles, je recommande d’abandonner les anciens processus et d’expérimenter avec les plus récents, comme GPT-5-Codex ou Sonnet 4.5.
Un expert métier saura distinguer les hallucinations et erreurs d’un LLM, mais sans cette expertise, on risque surtout de perdre du temps.
Au final, ces outils sont surtout utiles aux experts, tandis que pour les débutants, la qualité reste très irrégulière.
J’ai moi aussi utilisé Sonnet 4.5, et je l’ai trouvé seulement un peu meilleur que la version précédente. Cela reste encore souvent une perte de temps.
Anthropic m’a offert Claude Max gratuitement pendant quelques mois.
Dernièrement, il y a aussi énormément de contenus liés à Claude dans les publicités Instagram. Vu le nombre d’annonces du type « installer Claude Code » qui s’affichent, on dirait que l’équipe marketing travaille vraiment d’arrache-pied.
Les développeurs trouvent Claude Code très utile, et les abonnements à 200 dollars par mois semblent nombreux. S’il y a de la rentabilité, il est logique d’investir massivement dans le marketing.
Les LLM aident à trouver des bugs, mais ils peuvent aussi fournir des explications à côté de la plaque qui font perdre du temps.
Au final, l’important est de conserver son esprit critique.
Le LLM est un excellent outil, mais il tire facilement des conclusions hâtives. Dès que l’humain cesse de réfléchir, le modèle part dans une direction absurde.
Je partage l’avis selon lequel « utiliser les LLM uniquement sous forme de chat ou d’autocomplétion, ce n’est pas terrible ».
Moi aussi, c’est en utilisant Claude Code/Codex que j’ai commencé à en percevoir le potentiel. Un mode d’exécution continue serait encore plus intéressant.
Il pourrait supprimer des fichiers par erreur ou abîmer un dépôt Git. C’est pourquoi je n’expérimente que dans des environnements sandboxés.
Je veux un outil collaboratif de type socratique, où le modèle me pose des questions et où j’interviens moi-même tout en apprenant.
L’approche actuelle, centrée sur l’automatisation, risque de rendre les développeurs illettrés en code. À l’inverse, si l’outil est bien conçu, il peut amplifier la compréhension et l’intuition.
Le terminal CLI reste une interface très puissante.
Gemini CLI ou Qwen Code sont gratuits, et il est facile d’y brancher une API compatible OpenAI.
On peut automatiser les tâches simples et traiter les parties difficiles en one-shot avec Grok. Rien qu’avec un CLI + un serveur MCP + des fichiers MD, on peut déjà créer des programmes intelligents.
L’idée de faire analyser automatiquement la cause par un LLM à chaque échec de test est intéressante.
C’est possible en lançant Claude CLI via un Git hook.
On peut voir des exemples et une antisèche dans ce guide.
On verra sans doute bientôt des cas d’attaques adversariales contre les données d’entraînement des LLM visant à provoquer des erreurs cryptographiques.
Le fait qu’une « correction inclue l’ajout d’une fonction entièrement nouvelle » me semble dangereux dans le cadre d’une implémentation cryptographique.
J’ai l’impression que le billet donne un mauvais conseil.
Le code de correction a été jeté, puis réécrit par un humain. Au contraire, cela ressemble plutôt à un usage prudent et responsable.
Le LLM ne doit pas être utilisé comme un « réparateur », mais comme un détecteur de fuite de gaz qui indique où se trouve le problème.
Les LLM ont permis de reconnaître des patterns ambigus dans le code et d’éliminer beaucoup de problèmes ennuyeux.
Mais cela a aussi un effet secondaire. Ma codebase ressemble à du Node.js, alors qu’en réalité ce n’en est pas, et le modèle continue donc à la prendre à tort pour un projet Node.