Un conte de deux questions sur Claude Code

Deux questions sur le même outil ont croisé ma route récemment sur Stack Overflow, et elles n'auraient pas pu connaître de fins plus différentes. "How do you index a codebase in Claude Code?" (comment indexe-t-on une base de code dans Claude Code ?) stagnait à moins huit, fermée, tout en bas, en compagnie de devoirs déversés tels quels et d'une demande d'aide pour craquer un mot de passe. Pendant ce temps, une réponse à "Is reviewing only by sight a good use of Claude Code to write code?" (relire seulement à l'œil est-il un bon usage de Claude Code pour écrire du code ?) affichait 13 points, ce qui sur le Stack Overflow d'aujourd'hui relève de l'air raréfié, la ligue d'une magnifique explication de l'arithmétique des CRC et d'une pile de prose normative du C++.

Même outil. Même site. Même communauté qui vote. Verdicts opposés. J'ai lu les deux questions plus de fois qu'elles ne le méritent, parce que je pense que l'écart entre elles n'est pas du bruit, et pas non plus de l'hostilité envers l'IA. La communauté trie, et une fois que vous voyez la règle du tri, vous pouvez vous en servir.

Celle qui est morte

Commençons par le cadavre. "How do you index a codebase in Claude Code?" est une phrase qui sonne raisonnablement. C'est aussi, et je le dis avec sympathie, trois erreurs distinctes sous un seul point d'interrogation.

D'abord, elle repose sur une prémisse que l'outil n'a pas. Claude Code ne construit pas d'index de votre base de code. Il cherche à la demande, comme vous le feriez avec grep, et tout le design parie que la recherche rapide bat un index périmé. Demander comment configurer l'index, c'est demander comment seller une voiture. Il n'y a pas de réponse à la question telle qu'elle est posée, seulement une correction de celle-ci, et les questions auxquelles on ne peut répondre qu'en démontant leur prémisse s'en sortent mal partout, pas seulement sur Stack Overflow.

Ensuite, c'est une question de support. Pas une question moindre, mais un genre différent : sa vraie réponse vit dans la documentation de l'éditeur et change avec ses notes de version. Stack Overflow ferme les questions de support d'outils depuis bien avant que cet outil existe, parce que le format du site suppose une réponse qui mérite d'être archivée pendant une décennie, et les réponses de support pourrissent en un trimestre. Quand la durée de vie d'une question est plus courte que sa file de relecture, la fermer n'est pas du gatekeeping. C'est de la gestion de stock.

Enfin, et c'est l'erreur qui m'importe vraiment, elle interroge l'outil et non le travail. Ce qui est exactement le piège dont j'ai parlé dans le billet sur la course aux outils : l'outil est la partie que vous pouvez remplacer en un jour, et la partie en dessous, celle qui a pris des années, est celle où vivent les questions durables.

Celle qui a survécu

Maintenant la survivante. "Is reviewing only by sight a good use of Claude Code to write code?" n'a pas de prémisse à démonter, parce qu'elle n'affirme rien sur le fonctionnement de l'outil. Elle n'a pas de problème de péremption, parce qu'elle sera encore une question vivante dans trois outils et cinq versions ; remplacez le nom du produit, et c'était déjà une question vivante à l'ère de l'externalisation, et de la revue de code en général. Et ce n'est pas une question de support, parce qu'aucune documentation d'éditeur ne peut la trancher. C'est une question de jugement. La seule réponse honnête est l'expérience : quelqu'un qui a relu à l'œil, livré le résultat, et découvert ce que cela coûte.

La réponse qui a obtenu 13 points vaut quelque chose précisément parce qu'elle ne peut pas être générée à la demande. Un modèle produira volontiers une dissertation sur les pratiques de revue, et elle sera fluide et générique. Ce que les votants ont récompensé était autre chose : une personne qui prend position depuis ses propres cicatrices, sur une question où les positions sont tout ce qu'il y a.

Transparence totale : celle-ci a aussi trouvé en moi une cible facile. J'ai publié un billet sur exactement cette question environ une semaine avant que les votants du site ne hissent cette réponse dans cet air raréfié, en défendant l'idée que lire un diff est une vraie revue pour un type de changement et une histoire rassurante pour un autre. Je ne sais pas qui a posé la question ni qui y a répondu, et je ne prétends pas que le billet ait causé quoi que ce soit. Ce que j'affirme est plus petit et plus intéressant : la question est dans l'air. Quand le même sujet fait surface indépendamment sur un blog personnel et sur Stack Overflow au cours des mêmes quelques semaines, voilà à quoi ressemble une question vivante vue de deux points d'observation.

La règle du tri

Mettez les deux questions côte à côte et la règle s'énonce presque d'elle-même.

Demandez-vous si la prochaine version pourrait vider votre question de son sens. Si l'éditeur livre une fonctionnalité demain, ou en renomme une, et que votre question s'évapore, c'est une question de support, et la foule d'inconnus d'un site de questions-réponses est le mauvais public pour elle. Le bon public, c'est la documentation, le changelog, les canaux de l'éditeur lui-même, ou dix minutes avec l'outil, qui démontrera son comportement réel plus vite qu'un forum ne peut le décrire. Rien de honteux dans cette catégorie. Elle est simplement périssable, et les archives sont faites pour ce qui dure.

Mais si votre question survivait à la disparition de l'outil, si vous pouviez rayer le nom du produit, écrire celui d'un concurrent à la place et avoir toujours besoin de la réponse, alors vous ne posez pas du tout une question sur l'outil. Vous posez une question sur le travail : quoi déléguer, quoi vérifier, ce que coûte une pratique, là où le jugement doit rester humain. Ces questions n'ont pas de date de péremption, pas de documentation vers laquelle les renvoyer, pas de prémisse à faire s'effondrer. Ce sont aussi, et ce n'est pas une coïncidence, les questions auxquelles l'IA répond le plus mal, parce que la réponse n'est pas de la récupération. C'est du témoignage.

Le vote de la communauté a été dur d'un côté de cette ligne et généreux de l'autre, et je pense que la dureté et la générosité sont le même signal lu deux fois. Un site qui archive des réponses pendant des décennies a toutes les raisons de rejeter ce qui pourrit et de thésauriser ce qui se conserve. L'IA n'a pas créé cette logique. Elle a seulement déplacé la ligne, en faisant pourrir plus vite tout ce qui est récupérable.

Demander au grand jour

S'il y a un conseil là-dedans, ce n'est pas « évitez de poser des questions sur les outils d'IA en public ». C'est : avant de demander, découvrez laquelle des deux questions vous tenez entre les mains. La question de support mérite dix minutes avec la documentation, et honnêtement, le modèle lui-même y répondra mieux qu'un forum, puisque décrire son propre comportement est le seul sujet sur lequel il est la source primaire. La question de jugement mérite le traitement inverse. Portez-la à des gens, et habillez-la correctement : nommez les enjeux, dites ce que vous avez essayé, avancez votre propre position provisoire pour que le témoignage ait quelque chose contre quoi s'appuyer.

Les deux questions ont été posées par deux inconnus qui ne sauront jamais qu'ils formaient une paire assortie. À elles deux, elles ont cartographié tout le territoire : ce qu'il ne faut pas apporter aux autres, et ce à quoi les autres servent encore, irremplaçablement. Moins huit et plus treize n'est pas une contradiction dans l'humeur de la communauté à l'égard de l'IA. C'est la formulation la plus précise que j'en aie vue de toute l'année.