La question de savoir si des LLM modernes bien configurés et correctement supervisés peuvent proposer des patchs utiles me semble totalement dépassée: c'est évident que oui. À moins de partir sur un créneau d'authenticité (de style "poulets fermiers élevés à l'ancienne"), les logiciels libres ont tout intérêt à utiliser ces outils pour automatiser des tâches ingrates, y compris trier les PR, les patcher pour correspondre aux conventions de la communauté, trier les rapports de bugs, vérifier les bugs, vérifier les non-régressions, écrire des tests unitaires, etc.
À mon avis, le problème vient plutôt de la source de ces PR. Il me semblerait tout à fait pertinent qu'un mainteneur habituel du logiciel utilise des outils pour détecter des vulnérabilités potentielles, des fuites de mémoire, des bouts de code qui ne respectent pas les conventions, des bouts de code mort, des dépendances non-nécessaires, etc. Les LLM peuvent faire l'équivalent de ces analyses statiques, et bien plus encore : ils peuvent proposer des patches, et le faire d'une manière interactive.
Par contre, ce qui est malvenu, c'est des contributions externes. Un PR basé sur "j'ai fait tourner valgrind et il m'a dit que votre code était tout pourri" n'est probablement pas plus bienvenu qu'un truc rédigé par Claude".
Je ne pense pas qu'il faille avoir peur des LLM dans le LL, mais par contre il faut approvoiser ces outils, et faire comprendre à tout le monde que si les devs utilisent déja ces outils, proposer des PR n'apporte rien au LL, ça n'est pas une contribution.
# Problème de méthode, pas de fond
Posté par arnaudus . En réponse au journal Recrudescence de contributions générées par IA. Évalué à 3.
La question de savoir si des LLM modernes bien configurés et correctement supervisés peuvent proposer des patchs utiles me semble totalement dépassée: c'est évident que oui. À moins de partir sur un créneau d'authenticité (de style "poulets fermiers élevés à l'ancienne"), les logiciels libres ont tout intérêt à utiliser ces outils pour automatiser des tâches ingrates, y compris trier les PR, les patcher pour correspondre aux conventions de la communauté, trier les rapports de bugs, vérifier les bugs, vérifier les non-régressions, écrire des tests unitaires, etc.
À mon avis, le problème vient plutôt de la source de ces PR. Il me semblerait tout à fait pertinent qu'un mainteneur habituel du logiciel utilise des outils pour détecter des vulnérabilités potentielles, des fuites de mémoire, des bouts de code qui ne respectent pas les conventions, des bouts de code mort, des dépendances non-nécessaires, etc. Les LLM peuvent faire l'équivalent de ces analyses statiques, et bien plus encore : ils peuvent proposer des patches, et le faire d'une manière interactive.
Par contre, ce qui est malvenu, c'est des contributions externes. Un PR basé sur "j'ai fait tourner valgrind et il m'a dit que votre code était tout pourri" n'est probablement pas plus bienvenu qu'un truc rédigé par Claude".
Je ne pense pas qu'il faille avoir peur des LLM dans le LL, mais par contre il faut approvoiser ces outils, et faire comprendre à tout le monde que si les devs utilisent déja ces outils, proposer des PR n'apporte rien au LL, ça n'est pas une contribution.