Anti-patterns : choses à éviter

Anti-patterns : choses à éviter

Il existe certains comportements qui sont des anti-patterns dans notre étrange nouveau monde de l'ingénierie agentique.

Infliction de code non révisé sur les collaborateurs

Cet anti-pattern est courant et profondément frustrant.

• Ne soumettez pas de pull requests (PR) avec du code que vous n'avez pas vous-même révisé.

Si vous ouvrez une PR contenant des centaines (ou des milliers) de lignes de code générées par un agent pour vous, et que vous n'avez pas pris le temps de vous assurer que ce code fonctionne, vous déléguez le travail réel à d'autres personnes.

• Ils auraient pu solliciter un agent eux-mêmes. Quelle valeur apportez-vous réellement ?

Lorsque vous soumettez du code pour révision, vous devez être sûr qu'il est prêt pour que d'autres personnes y consacrent leur temps. Le premier passage de révision est votre responsabilité, et ne doit pas être confié à d'autres.

Une bonne pull request en ingénierie agentique possède les caractéristiques suivantes :

• Le code fonctionne, et vous êtes convaincu qu'il fonctionne. Votre tâche est de livrer un code qui fonctionne.

• Le changement est suffisamment petit pour être révisé efficacement sans imposer une charge cognitive trop importante au réviseur. Plusieurs petites PR sont préférables à une grande, et il est facile de diviser le code en commits séparés avec un agent de codage pour gérer les manipulations Git.

• La PR inclut un contexte supplémentaire pour aider à expliquer le changement. Quel est l'objectif global que ce changement sert ? Lier à des problèmes ou spécifications pertinents est utile ici.

• Les agents rédigent des descriptions de PR qui semblent convaincantes. Vous devez également les réviser ! Il est impoli de s'attendre à ce que quelqu'un d'autre lise un texte que vous n'avez pas lu et validé vous-même.

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