Bon, les enfants, approchez. On va parler des bases de l’ingénierie, du merge et des contributions automatisées pour vos projets open source, parce que presque tout le monde est en train de tout foirer.
Le truc à comprendre avec les agents de code, c’est que ce sont des machines à contraintes. Donnez-leur les bonnes contraintes pour bosser sur un projet, et ils sortiront du code qui tourne. Donnez-leur les mauvaises, et tout s’embrase pendant que vous regrettez amèrement le jour où vous avez commencé à les utiliser.
Et il n’y a rien de mal là-dedans, faut juste comprendre comment ça marche. Les contraintes vont dans vos guides de contribution, votre readme, et elles doivent être claires. Vous devriez déjà le faire pour les contributeurs humains, parce que rien de tout ça n’existe dans le vide.
Si vous ne voulez pas autoriser les agents à soumettre du code généré, ça doit être clairement stipulé dans vos documents de gouvernance, comme le fichier CONTRIBUTING au minimum. Se contenter de dire « Haha, soupe d’IA » n’est pas la manière de gérer ces contributions. Utilisez vos mots.
Quand une soumission automatisée ne respecte pas les standards de code, ou qu’elle est trop massive pour être révisée par un humain, il faut le dire. Si la PR tente des changements radicaux dans votre architecture sans qu’il y ait un ticket ou une discussion sur un forum, c’est un échec de communication.
Le mode de défaillance dans ces situations, et la raison du rejet, sont en fait plus importants que le rejet lui-même.
Pensez au code, pas à la source.
Si on parlait d’ingénieurs humains, on ne réfléchirait pas à deux fois à cette idée pourtant évidente.
Ou alors, dites simplement à l’agent : « Hé, on a une politique qui interdit les soumissions automatisées sur ce projet. Désolé mon pote. » Ça, c’est du signal, parce que les agents lisent ces trucs-là.