[🤖] Codex m’a effacé de mon propre blog technique

✨ Résumé de GPT-5.6 Sol

J’ai demandé à Codex d’écrire un billet technique, mais au lieu de raconter comment j’avais repéré le problème et dirigé le travail, il a rédigé son propre rapport. Voici comment j’en ai recherché la cause et replacé l’utilisateur au centre narratif de la Skill d’écriture.

J’ai disparu du billet technique que j’avais écrit

Après avoir découvert l’expression Graph Engineering, j’ai continué à demander si cette méthode permettait vraiment d’éviter les échecs que j’avais connus lors de longs travaux avec Codex. Je n’avais jamais voulu d’un framework grandiose. Mon idée était la structure la plus réduite possible : lorsqu’une session terminait une unité de travail, elle transmettait le résultat à une session d’audit indépendante et ne pouvait pas poursuivre avant le retour de cet audit.

Au lieu de commencer par critiquer ma proposition, Codex l’a approuvée de façon convaincante, puis a changé de position chaque fois que je lui apportais une objection. J’ai donc demandé des revues critiques à répétition et continué à retirer tout ce qui aurait rendu la structure inutilement complexe ou simplement gourmande en tokens. Au fond, je ne voulais pas d’un article expliquant le mot à la mode Graph Engineering. Je voulais un journal racontant ce que j’avais découvert dans un échec réel et les instructions avec lesquelles j’avais changé la manière de travailler de Codex.

Mais je n’étais pas au centre du texte que Codex m’avait rendu. Le problème que j’avais repéré, la raison pour laquelle j’avais rejeté la première réponse et les objections par lesquelles j’avais réduit la structure étaient relégués à l’arrière-plan. À la place, Codex était devenu le personnage principal : la structure qu’il avait mise dans une Skill, la procédure d’audit qu’il avait exécutée et les vérifications qu’il avait réussies. Un rapport de travail de Codex avait failli être publié sur mon blog technique.

C’est seulement à ce moment-là que j’ai formulé précisément le problème.

Le centre doit toujours être le problème que j’ai identifié et la manière dont je t’ai demandé de le résoudre. La façon dont tu as travaillé n’est absolument pas le sujet central et ne mérite qu’une très brève mention.

Le processus d’implémentation de l’IA peut être expliqué un peu plus lorsqu’il apporte un conseil utile au lecteur. Peu importe sa complexité technique ou la qualité de ses vérifications : rien ne l’autorise à prendre la narration de mon texte.

La Skill que je croyais avoir corrigée contenait la cause

Le plus absurde était que je me souvenais avoir déjà réglé ce problème. Fin juillet, en écrivant J’ai relié le flux et la sensation du travail avec une Codex Skill, j’avais fait en sorte que la Skill d’écriture cesse de transporter une copie des règles de cdb et lise directement, à chaque fois, les règles actuelles du projet, la conversation et l’historique Git.

À l’époque, cela avait bien résolu un problème important. Lorsque des règles anciennes sont copiées dans une Skill, l’écriture se décale chaque fois que le projet évolue. J’avais donc corrigé la source des règles et demandé à la Skill de relire le contexte actuel. Je pensais l’avoir correctement réparée.

Mais cette fois, j’ai constaté que j’avais corrigé l’endroit où les règles étaient lues, pas l’expérience que le texte devait raconter.

L’ancienne Skill commençait par chercher, dans les preuves du travail, une valeur technique à offrir au lecteur. Elle séparait le journal personnel du billet technique réutilisable puis, quand la matière technique était abondante, penchait naturellement vers une structure de rapport généralisé. Elle comportait même une autoévaluation destinée à vérifier si la valeur technique restait claire après suppression de la chronologie personnelle. Ce que j’avais vécu, jugé et ordonné n’était pas considéré comme un texte source à préserver, mais comme un bruit qu’on pouvait retirer pour rendre l’explication technique plus propre.

Ce n’était donc pas un hasard si Codex répétait la même erreur. J’avais beau expliquer clairement mon intention dans la conversation, la Skill qui produisait réellement le texte extrayait d’abord les faits techniques et le processus d’implémentation. L’historique Git et les traces des outils auraient dû servir à vérifier les faits, mais ils sont devenus le sommaire. Le travail de Codex aurait dû rester une explication secondaire, mais il est devenu le protagoniste. Une Skill sert à répéter un travail de manière fiable ; elle répétait donc aussi une mauvaise prémisse avec une remarquable fiabilité.

Je lui ai d’abord fait inverser le sujet de la narration

Au début, je me suis demandé si seules quelques formulations étaient fautives. Mais lorsque Codex a de nouveau tenté de se rabattre sur l’idée que la Skill était « globalement correcte et avait juste besoin d’être un peu renforcée », je lui ai ordonné de l’améliorer véritablement. Ajouter quelques phrases ne suffirait pas. Il fallait inverser l’ordre même dans lequel le texte était produit.

La première ligne du nouveau critère n’était plus un sujet technique, mais l’utilisateur. La Skill devait d’abord reconstituer pourquoi j’avais commencé ce travail, ce que j’avais jugé incorrect, ce que j’avais demandé à l’IA, pourquoi j’avais rejeté le premier résultat, comment j’avais de nouveau resserré les conditions et comment le résultat avait finalement changé.

L’historique Git, les sorties des outils, les modifications du code et les résultats des vérifications ne pouvaient servir qu’à confirmer les faits, jamais à remplacer ce récit. Les fichiers modifiés par l’IA et les contrôles réussis ne seraient conservés que s’ils expliquaient le résultat de mon jugement ou apportaient un véritable conseil à quelqu’un d’autre. J’ai aussi resserré l’exception : l’implémentation elle-même ne pouvait devenir centrale que lorsque l’utilisateur demandait explicitement un tutoriel ou une référence technique.

J’ai également inversé l’autoévaluation. Désormais, même après avoir retiré les détails d’implémentation de l’IA, le problème que j’ai trouvé, mes instructions, mes critiques, mes corrections et ce que j’en ai appris doivent rester clairs. Si ce n’est pas le cas, peu importe la fluidité de la prose ou la quantité d’informations techniques : ce n’est pas mon journal. La Skill révisée a même réussi sa validation syntaxique, mais ce qui comptait cette fois n’était pas la réussite d’un contrôle. C’était l’inversion du critère de jugement.

Dans le prochain texte, je vérifierai si je suis encore là, pas la tournure des phrases

Ma plus grande erreur dans cette histoire a été de me souvenir que je l’avais « déjà corrigée ». J’avais fait relire les règles actuelles à la Skill et j’avais donc cru que le problème d’écriture était lui aussi résolu. En réalité, je n’avais corrigé que la source des règles, pas la finalité du texte. Même si elle lit parfaitement les règles les plus récentes, le résultat restera faux si ces règles traitent mon expérience comme un matériau destiné à un rapport technique.

Plus je confie de travail répétitif à l’IA, plus les Skills et les règles partagées deviennent puissantes. Mais elles reproduisent aussi avec plus d’obstination une perspective erronée. Si une réponse isolée est mauvaise, je peux la contester et la corriger sur-le-champ. Mais si un mauvais modèle narratif entre dans une Skill, la session suivante m’efface de la même façon.

Désormais, la première chose que je vérifierai dans le brouillon d’un blog technique ne sera pas à quel point les phrases paraissent convaincantes ni le degré de détail de l’explication technique. Je regarderai d’abord si le problème que j’ai identifié, ainsi que les instructions et les objections par lesquelles j’ai changé le résultat, sont encore présents. L’IA peut accomplir une quantité immense de travail à ma place, mais je ne peux pas la laisser transformer en sa propre histoire jusqu’à la raison pour laquelle je lui ai confié ce travail.