- Traiter des tickets Django avec des LLM n’est pas utile, et il est plus bénéfique de consacrer ces ressources directement à un don à la Django Software Foundation
- Django est un projet aux exigences de qualité très élevées, centré sur la stabilité à long terme, qui demande une compréhension approfondie au-delà de la simple génération de code
- Si un LLM produit le code à la place de l’auteur, puis gère jusqu’à la description de la PR et les réponses aux revues, cela crée un problème : il devient difficile de savoir si le contributeur comprend réellement ce qu’il fait
- Dans la contribution open source, la communication humaine et la coopération communautaire sont essentielles ; si un LLM les masque, la confiance avec les reviewers s’affaiblit
- Pour contribuer à Django, le processus consistant à construire sa compréhension par l’apprentissage et l’expérimentation directs est indispensable, et mène à une progression en tant que développeur
Les limites des contributions à Django via les LLM
- Utiliser des LLM pour résoudre des tickets Django n’aide pas concrètement la communauté
- Lorsqu’une PR est soumise avec du code généré par un LLM et que le feedback est ensuite traité de la même manière, il devient difficile d’évaluer le niveau de compréhension de l’auteur
- Du point de vue du reviewer, cela donne l’impression de dialoguer non pas avec une personne, mais avec une “fausse apparence de compréhension”
- Django a une base d’utilisateurs massive, un cycle de changement lent, ainsi que des exigences de qualité propres à un projet destiné à durer plus de 20 ans
- À cause de ces caractéristiques, une compréhension approfondie et une contribution responsable sont plus importantes qu’une simple génération de code automatisée
La bonne manière d’utiliser les LLM
- Les LLM doivent être utilisés comme outils d’assistance à la compréhension
- Il est préférable de rédiger d’abord une explication avec ses propres mots, puis d’utiliser un LLM pour en améliorer la formulation
- Lorsqu’il est difficile de communiquer, on peut utiliser activement un LLM, mais il faut indiquer explicitement qu’il a été utilisé
- Lors d’une contribution à Django, le contributeur doit comprendre lui-même le problème, la solution et le feedback de review
- Du code généré sans compréhension peut nuire à la qualité de l’ensemble du projet
Une collaboration open source centrée sur l’humain
- Contribuer à Django est une expérience communautaire, qui inclut transparence humaine et vulnérabilité
- Si un LLM masque cette humanité, la collaboration devient plus difficile
- Les reviewers trouvent leur motivation lorsqu’ils communiquent sur la base d’une “véritable compréhension humaine”
- Les LLM ne devraient être utilisés que comme moyens d’assistance, et ne doivent pas remplacer le rôle essentiel du contributeur
La nature et la valeur d’une contribution à Django
- Django est un projet avec 20 ans d’histoire et une vision de long terme, et tout code ajouté doit être compris en profondeur
- Cette compréhension exige du temps, de l’expérimentation et de l’apprentissage
- Contribuer à Django est une expérience qui apporte une progression en tant que développeur, bien plus qu’une simple mention de son nom
- L’apprentissage acquis pendant le processus de contribution a bien plus de valeur que le fait d’apparaître dans une liste
Proposition à la communauté
- Il ne faut pas utiliser les LLM de manière excessive pour se dissimuler soi-même et masquer sa compréhension
- La communauté Django veut collaborer avec de vraies personnes
- Si vous souhaitez soutenir Django, le plus efficace est d’y investir du temps et de l’argent, ou de faire un don à la Django Software Foundation
1 commentaires
Réactions sur Hacker News
Je pense que les LLM peuvent causer des problèmes dans n’importe quelle base de code avec des relecteurs humains
Utiliser un LLM sans comprendre le ticket, la solution ou les retours sur la PR nuit à l’ensemble du projet
Contribuer à l’open source est un acte communautaire, mais les LLM masquent la transparence et la vulnérabilité humaines
Du point de vue du relecteur, on a l’impression de dialoguer avec le « masque » d’un humain, ce qui est une expérience démotivante
Donc les LLM doivent être utilisés comme outils d’appoint, pas comme moyen de remplacement
Ces derniers temps, même dans les équipes, les PR rédigées par l’IA explosent, et on voit Claude ou Codex répondre aussi aux retours de review
Si cette culture s’installe, j’ai l’impression qu’elle mènera à un effondrement de la confiance dans tout le secteur et à une baisse du moral
Plutôt qu’un gain de productivité, il ne reste qu’une « impression de vitesse »
En pratique, comme les organisations mesurent mal la productivité, personne ne connaît l’effet net de ce genre de fonctionnalités
L’usage généralisé de l’IA est en train d’éroder la confiance
L’apparence est meilleure, mais l’authenticité disparaît
Au final, le code passe, donc je me demande si cela dérange vraiment les gens
Les meilleurs collègues avec qui j’ai travaillé faisaient toujours en sorte qu’il soit facile pour le relecteur de critiquer
Ils notaient clairement leurs hypothèses, ce qu’ils ne savaient pas, leurs tâtonnements, et expliquaient les choses de manière à ce qu’on puisse facilement les contredire
Si une PR montre cette humilité et cette introspection, la présence d’un LLM ne m’inquiète pas
Le problème, c’est que des gens qui soumettaient déjà du code ne compilant même pas à la base produisent maintenant encore plus de PR médiocres avec les LLM
C’est pour ça que je ne suis pas d’accord avec l’idée que « tant que le code fonctionne, peu importe qui l’a écrit »
La situation est actuellement hors de contrôle
En particulier depuis que l’activité GitHub est devenue un critère d’évaluation dans les recrutements, les gens essaient de fabriquer un historique de contributions avec des LLM
En pratique, il suffit qu’une PR passe sans qu’ils comprennent réellement le projet
Qu’un bon développeur utilise un LLM n’est pas un problème
Le vrai problème, c’est que des gens déjà peu compétents peuvent maintenant soumettre davantage de code de mauvaise qualité grâce aux LLM
Il y avait déjà auparavant des gens qui soumettaient du code copié-collé depuis StackOverflow sans rien comprendre
L’IA n’a fait qu’amplifier cela
Si quelqu’un bombarde plusieurs dépôts avec des PR similaires et que la plupart sont refusées, c’est un signal très clair
Au final, il faut revenir à une culture de contribution centrée sur la qualité plutôt que sur la quantité
Il est facile d’identifier le problème, mais il est difficile de construire un consensus et des solutions concrètes, et les techniciens ne sont pas très bons sur ce terrain
J’aime bien l’idée de donner de l’argent
Les contributeurs centraux de Django sauraient probablement mieux utiliser un financement que des tokens
D’autres projets prennent des mesures comme la divulgation de l’usage de l’IA, la suspension temporaire des contributions externes, ou des restrictions sur l’ouverture d’issues
Les PR de mauvaise qualité sont devenues trop faciles à générer, ce qui grignote le temps et l’attention de la communauté
Il faudra peut-être donc évoluer vers des modèles de collaboration plus fermés
J’ai aussi trouvé impressionnante la décision de Debian d’aborder ce problème avec prudence
À mon avis, au lieu d’acheter des tokens, il vaut mieux simplement donner de l’argent aux contributeurs principaux et les laisser décider comment l’utiliser
Je me reconnais profondément dans l’idée que « parler à un masque humain est mentalement épuisant pour le relecteur »
L’une des récompenses de l’open source, c’est l’échange humain ; si cela disparaît, tout ressemble à du simple travail
Au final, la patience de tout le monde diminue et le plaisir de collaborer s’évapore
Comme chez un boucher de quartier avec qui on discute, ils veulent créer une relation
La rédaction d’articles est devenue plus facile avec les LLM, mais la vérification et la relecture restent difficiles et chronophages
Il faudrait donc peut-être indiquer explicitement l’usage de l’IA, ou marquer les PR avec des algorithmes de détection d’IA
Au fond, cela reviendrait à pousser les gens à traduire les réponses du LLM dans leur propre langage
Mais en pratique, il y aura toujours des gens qui ignorent les règles
Aujourd’hui, toute l’innovation semble aller dans le sens de récompenses à court terme
La structure des incitations ne soutient pas les personnes qui ont une vision de long terme
Dès qu’on regarde un peu la théorie des jeux, il devient difficile de nier que le monde est conçu ainsi
Elle a donc ses limites pour évaluer les stratégies de long terme
C’est un bon message, mais les gens qui font tout avec des LLM ne liront probablement même pas ce genre de texte
En tant que mainteneur open source, moi aussi j’ai du mal à distinguer si du code a été écrit par une IA
En réalité, il y a très peu de développeurs professionnels de ce type
Je me dis qu’on pourrait plutôt créer des projets open source dédiés aux LLM
En rassemblant uniquement du code produit par des LLM et en définissant clairement un protocole de contribution
Mais une grande partie des contributions LLM sert probablement simplement de portfolio
Il compte des milliers de contributeurs et des dizaines de milliers de commits
L’IA n’augmente souvent pas la productivité ; elle se contente de refiler le coût de la vérification à quelqu’un d’autre
Au final, les mainteneurs se retrouvent avec plus de travail, tandis que les contributeurs récupèrent le mérite
Moi aussi, j’ai déjà utilisé un LLM pour produire des patchs sur un projet comme Django
Sans LLM, je n’aurais probablement même pas essayé
Mais j’ai relu le résultat moi-même et j’ai aussi écrit des tests
Aujourd’hui, le code, la description de la PR et même les réponses aux retours de review sont parfois entièrement prises en charge par un LLM
Du point de vue du relecteur, on finit presque par se dire : « autant que je fasse simplement la review avec un LLM moi aussi, non ? »
C’est pourquoi le LLM doit rester un outil d’assistance, et non un moyen de remplacement