Relire un diff
Lire dans le bon ordre, et chercher d'abord ce que vous n'avez pas demandé.
Relire ce que produit la machine
Un diff d'agent se relit mal, et pour une raison précise : il est trop bien écrit. Le code d'un collègue pressé contient des indices — un nom bâclé, une indentation qui saute, un commentaire « TODO fix later ». Ces irrégularités sont des signaux qui appellent l'attention à l'endroit du risque. Un agent produit un texte uniformément soigné : le contournement douteux et la correction juste ont la même typographie, les mêmes commentaires bien tournés, la même assurance. Votre détecteur d'anomalies habituel ne s'allume plus, et vous approuvez un diff de 300 lignes en quatre minutes en vous disant que c'est propre.
Le second piège est l'ordre de lecture. Face à un diff, l'instinct est de commencer en haut du premier fichier et de dérouler. Sur du code humain, cela fonctionne à peu près, parce que l'auteur a fait ce que vous lui avez demandé, ni plus ni moins. Sur du code d'agent, cela vous fait lire longuement le changement attendu — la partie la moins risquée, celle que vous avez spécifiée — et arriver fatigué sur le fichier numéro sept, celui que vous n'aviez jamais mentionné et où se trouve le vrai problème. La relecture efficace inverse la logique : on cherche d'abord ce qui n'a pas été demandé, ensuite seulement on vérifie ce qui l'a été.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion