Le jour où un refactor est passé sur mon ordinateur portable et a échoué sur le vôtre

La plupart du code en cours d’écriture ne l’est pas. Il est généré, consulté, puis fusionné. Le critique est fatigué. La différence est grande. De plus en plus, le réviseur est lui-même un modèle de langage résumant le travail d'un autre modèle de langage. Quelque part dans cette boucle, il est censé y avoir un moment où quelqu'un confirme que le changement a fait ce qu'il prétendait. Souvent, ce n’est pas le cas.

Je voulais un petit outil ennuyeux pour combler cette lacune. Prenez une fonction avant et après un refactor. Exécutez les deux sur les mêmes entrées. Dites-moi clairement si le comportement a changé. Pas un avis. Pas un score de confiance. Un résultat que je pourrais réexécuter la semaine prochaine avec la même réponse, octet par octet. Si un coéquipier l'exécutait sur sa machine, il devrait obtenir mon résultat exact, pas quelque chose de proche.

Cette dernière phrase semble triviale. C'est tout le problème. C'est l'histoire de l'endroit où il s'est cassé et pourquoi le correctif s'est avéré être la décision de conception la plus importante de l'ensemble de l'outil.

Pourquoi le réexécuter est la seule affirmation qui vaille la peine d'être formulée

Les outils qui examinent votre demande de tirage ne manquent pas. Les plus récents sont des modèles de langage avec une interface agréable. Ils sont utiles. C'est aussi le même genre de chose qui a écrit le code : un système probabiliste vous donnant son impression. Demandez deux fois au même et vous obtiendrez deux avis différents. Dans un monde où un modèle a écrit le diff, un modèle révisant le diff est la même boucle fa...
[Courte citation de 8% de l'article original]