Ingénierie agentique : éviter les pièges des pull requests

Les comportements à éviter en ingénierie agentique

Dans le domaine de l'ingénierie agentique, certains comportements sont considérés comme des anti-patterns, c'est-à-dire des pratiques à éviter pour garantir une collaboration efficace et productive.

Soumission de code non révisé : un piège courant

Un des comportements les plus problématiques est la soumission de pull requests (PR) sans révision préalable. Ce phénomène est non seulement frustrant, mais il impose également une charge de travail inutile aux collaborateurs.

Lorsque vous soumettez une PR contenant des centaines, voire des milliers de lignes de code générées par un agent, sans vous assurer de leur bon fonctionnement, vous transférez la responsabilité de la révision à d'autres. Ces derniers auraient tout aussi bien pu utiliser un agent pour générer ce code eux-mêmes. Quelle valeur ajoutée apportez-vous alors ?

Responsabilité de la révision initiale

Avant de soumettre du code pour révision, il est crucial de s'assurer qu'il est prêt à être examiné par d'autres. La première révision est de votre responsabilité et ne doit pas être déléguée.

Une pull request bien préparée dans le contexte de l'ingénierie agentique doit répondre à plusieurs critères :

• Le code doit fonctionner correctement, et vous devez en être convaincu. Votre rôle est de livrer un code fonctionnel.

• Les changements doivent être suffisamment petits pour permettre une révision efficace sans surcharger le réviseur. Il est préférable de soumettre plusieurs petites PR plutôt qu'une seule volumineuse. Utiliser un agent de codage pour diviser le code en commits séparés peut faciliter la gestion des manipulations Git.

• La PR doit inclure un contexte supplémentaire pour expliquer le changement. Quel est l'objectif global de ce changement ? Lier la PR à des problèmes ou spécifications pertinents est ici très utile.

Importance de la révision des descriptions de PR

Les agents peuvent rédiger des descriptions de PR qui semblent convaincantes, mais il est essentiel de les réviser. Il est impoli de s'attendre à ce que quelqu'un d'autre lise un texte que vous n'avez pas vous-même validé.

Preuve de révision et de tests

Étant donné la facilité avec laquelle il est possible de transmettre du code non révisé, il est recommandé d'inclure une preuve que vous avez effectué ce travail supplémentaire. Cela peut prendre la forme de notes sur la façon dont vous avez testé le code manuellement, de commentaires sur des choix d'implémentation spécifiques, ou même de captures d'écran et de vidéos montrant la fonctionnalité en action. Ces éléments contribuent grandement à démontrer que le temps du réviseur ne sera pas gaspillé à explorer les détails.