Travailler avec l'IA : retour d'expérience du créateur de htmx

Carson Gross, créateur de la bibliothèque htmx et du langage de scripting hyperscript, publie un retour d'expérience détaillé sur l'utilisation de Claude dans le cadre d'une session de débogage concrète. L'exercice dépasse le simple témoignage : il documente avec précision à quelles étapes l'IA s'est montrée utile, et à quelles étapes elle a proposé des solutions insuffisantes ou incorrectes.

Le point de départ est un bug de régression signalé par un utilisateur après la mise à jour vers la version 0.9.91 d'hyperscript. Une expression de type `fetch ... as JSON` ne se parsait plus correctement : le mot-clé `as`, qui sert à la fois de modificateur de la commande `fetch` et d'opérateur de conversion dans les expressions générales, était capturé au mauvais niveau de l'arbre syntaxique. Le problème est classique en théorie des parsers : un conflit de liaison dû à une ambiguïté grammaticale introduite lors d'un refactoring.

Sur la phase de diagnostic, Claude s'est montré efficace. En quelques minutes, le LLM a identifié la cause racine — une méthode `parseURLOrExpression()` extraite lors du refactoring, qui élargissait involontairement la grammaire après la commande `fetch`. Gross reconnaît que sans l'IA, cette investigation lui aurait pris sensiblement plus de temps.

La phase de correction est plus révélatrice. Face à la demande d'un fix, Claude a d'abord proposé une solution ciblée uniquement sur le cas signalé, ignorant le cas général où une variable serait utilisée comme URL. Gross a rejeté cette approche comme trop hacky. Le LLM a ensuite proposé un mécanisme de flag contextuel `noConversions` sur le parser, plus général mais introduisant une complexité inutile. C'est Gross lui-même qui a identifié qu'une infrastructure existante du parser hyperscript — le système de "follows", permettant à une commande de réclamer un token comme le sien pour empêcher les expressions de le consommer — suffisait à résoudre le problème proprement. Informé de cette piste, Claude a correctement implémenté la solution, mais de façon trop large : la modification s'appliquait aussi à la commande `go`, qui partage la méthode `parseURLOrExpression()` sans utiliser `as` comme modificateur. Gross a finalement écrit lui-même la version finale, en restreignant le push/pop du follow au seul périmètre de `FetchCommand#parse()`.

La génération de tests constitue en revanche un cas d'usage où l'IA a rendu un service net : Claude a produit une suite de tests unitaires ciblés, couvrant les différents cas de figure, plus exhaustive que ce que Gross dit avoir eu l'énergie de rédiger seul.

Ce compte-rendu illustre ce que Gross nomme le "Sorcerer's Apprentice problem" : le risque pour un développeur de devenir exécutant passif des suggestions d'un agent IA, en acceptant des solutions qui accumulent de la dette technique sans comprendre les implications architecturales. Dans ce cas précis, un développeur moins familier avec les internals du parser hyperscript aurait probablement retenu le deuxième ou troisième fix proposé, introduisant soit une limitation non documentée, soit un état supplémentaire dans le parser.

L'auteur aborde également une dimension moins souvent discutée : l'effet de l'IA sur les développeurs seniors. À cinquante ans, Gross observe que deux fragilités naturelles liées à l'âge — la mémoire et la capacité à soutenir de longues sessions de travail — sont directement compensées par l'assistance des LLMs. L'IA permet de retrouver rapidement le contexte d'un projet après une interruption, et de déléguer les tâches répétitives à forte charge cognitive comme la génération de tests. En contrepartie, il exprime une inquiétude explicite : la délégation excessive pourrait accélérer un déclin cognitif déjà amorcé par l'âge, en réduisant les occasions d'exercer un raisonnement autonome profond.

La conclusion opérationnelle qui se dégage de cet essai est que la valeur d'un LLM en contexte de développement est fortement conditionnée par le niveau de compétence de l'humain qui l'accompagne. L'IA excelle à l'exploration et à la génération mécanique, mais produit régulièrement des solutions localement correctes et globalement inadaptées à l'architecture existante. La supervision experte reste le facteur déterminant de la qualité du résultat final. Ce constat nuance les discours sur l'autonomie croissante des agents de coding, et pointe vers une question ouverte : que se passe-t-il lorsque le développeur en boucle ne dispose pas de cette expertise préalable ?