Accueil / Gestes courants

Pièges d'écriture : fichiers, edits parallèles et livrables perdus

Un rapport de succès écrit par un sous-agent ne prouve rien sur l'état réel des fichiers, puisqu'il démarre dans un contexte isolé sans accès à ce que l'agent principal a déjà lu ou écrit, et la seule preuve fiable reste un diff vérifié après coup, pas le texte du rapport.

Un sous-agent démarre avec un contexte isolé et neuf à chaque appel, sauf pour un fork, qui hérite au contraire de toute la conversation en cours. Il ne voit ni l'historique de la conversation principale, ni les skills déjà invoquées, ni les fichiers que l'agent principal a déjà lus. Cette isolation ne l'empêche pas de consulter lui même le disque : il dispose des mêmes outils de lecture et d'exécution que la conversation principale, et peut très bien lancer un git diff ou relire un fichier pour vérifier son propre travail. Ce qui manque, c'est un regard extérieur : un rapport de succès reste un texte produit par le même agent qui vient d'agir, jamais une vérification indépendante, et rien ne garantit qu'il corresponde à une écriture réelle sur le disque tant que personne d'autre ne l'a contrôlé.

Le rapport de texte n'est pas la preuve

La bonne pratique documentée consiste à demander un diff vérifiable plutôt que de faire confiance au texte du rapport. Un diff montre les lignes réellement changées dans un fichier réel, un rapport de succès n'est qu'une phrase générée par le même agent qui affirme avoir réussi.

mkdir -p /tmp/demo-diff
echo "version initiale" > /tmp/demo-diff/avant.txt
echo "version modifiee" > /tmp/demo-diff/apres.txt
diff /tmp/demo-diff/avant.txt /tmp/demo-diff/apres.txt
# resultat : la ligne modifiee apparait, la preuve est dans le diff, pas dans une phrase

Un rapport en texte affirmant qu'apres.txt a été mis à jour n'apporte rien de plus que ce diff, et sans lui, rien ne distingue une écriture réelle d'une phrase inventée. Un script en une seule ligne qui contient des guillemets inversés se heurte à un piège voisin : le shell qui l'exécute peut les interpréter avant que la commande n'atteigne sa cible, et ce qui s'affiche ensuite ressemble à un succès alors que la commande réellement lancée était tronquée. Relire la commande telle qu'elle a été reçue par le shell, pas seulement telle qu'elle a été tapée, répond au même besoin de preuve que le diff.

Deux écritures sur le même fichier ne sont jamais indépendantes

Deux modifications envoyées ensemble sur le même fichier, que ce soit par deux sous-agents ou par deux appels de l'outil d'édition dans le même tour, s'appliquent l'une après l'autre sur le contenu que l'outil trouve au moment où il agit, jamais sur deux copies séparées fusionnées ensuite. La seconde modification peut donc échouer à trouver le texte qu'elle cherchait, parce que la première l'a déjà changé. Envoyer les deux modifications en séquence, en relisant le fichier entre les deux, réduit ce risque et rend chaque étape vérifiable pour elle même.

Le même principe de preuve vérifiable s'applique à un livrable long : un contenu de plusieurs paragraphes qui n'existe que dans la réponse affichée disparait avec elle dès que la conversation continue. L'écrire dans un fichier réel avant de l'afficher, comme pour une sortie structurée en mode headless, garantit qu'il reste consultable indépendamment du fil de conversation, exactement comme un diff reste lisible indépendamment du rapport qui l'accompagne.