Un mainteneur de logiciel maintient une position claire concernant les demandes d'exécution (PR) : il n'en accepte plus de nouveaux contributeurs. Bien qu'il apprécie l'enthousiasme de la communauté et son désir d'aider, il estime que la collaboration actuelle est une perte de temps pour les deux parties. Les raisons de ce changement résident dans la nature même de la révision de code. Sans connaître personnellement les contributeurs, le mainteneur doit systématiquement supposer un risque de sécurité potentiel, rendant l'analyse plus risquée et plus lente que s'il appliquait les modifications lui-même. De plus, le code est empreint de préférences subjectives liées au formatage, à la structure et aux dépendances. Les allers-retours incessants entre le contributeur et le mainteneur, les conflits de fusion et les vérifications d'automatisation ralentissent considérablement le processus. L'avènement des modèles de langage génératifs a modifié cet équilibre. Auparavant, le temps consacré à l'écriture du code justifiait parfois le risque de fusionner le travail d'un tiers. Aujourd'hui, les IA génèrent du code fonctionnel rapidement. Le mainteneur peut coderifier ses propres standards et itérer à son rythme sans la contrainte de synchronisation humaine ou de fuseaux horaires différents. Le code généré par une IA ne présente pas les mêmes risques de malveillance que celui d'un inconnu. Par conséquent, il est plus efficace que le mainteneur réalise lui-même les modifications en s'aidant de ces outils. La nature du développement logiciel a évolué. Le code est devenu une couche intermédiaire plus visible entre une idée humaine et l'exécution machine, facilitée par la génération automatique. Le mainteneur se place dans une position intermédiaire face aux agents de codage : il conçoit l'architecture et laisse l'agent rédiger la majorité du code, puis il procède à la révision et au raffinement. Cependant, le véritable goulot d'étranglement ne réside plus dans la production de lignes de code, mais dans la conception, la révision et la prise de décision stratégique. Puisque l'écriture de code directe est moins valorisée, les autres formes d'aide au mainteneur gagnent en importance. Les utilisateurs sont invités à fournir des retours d'expérience sur le fonctionnement réel du logiciel et sur les pistes d'amélioration possibles. Discuter des idées et des perspectives différentes permet d'affiner la vision de ce qui doit être construit. La signalement des bugs demeure cruciale. Une bonne description, incluant les étapes de reproduction et une analyse de débogage préliminaire, constitue l'essentiel de la résolution d'un problème. En outre, les contributeurs peuvent envoyer des exemples de code ou les invites de commande (prompts) utilisés pour les générer. Ces éléments servent à illustrer des concepts ou à fournir des bases de travail réutilisables et révisables, sans pour autant être intégrés directement dans la base de code. Enfin, la révision par les pairs et le fork du code sont encouragés. Si le mainteneur est saturé par la tâche de révision, l'œil d'un tiers extérieur est précieux. Le mainteneur recommande également aux développeurs de forkuer le projet pour créer leurs propres versions adaptées à leurs besoins spécifiques. Cela évite les longs processus de consensus sur les compromis et les designs. Chaque développeur peut ainsi implémenter ses fonctionnalités rapidement et les maintenir à son propre rythme, permettant à tous d'apprendre mutuellement sans alourdir la charge du mainteneur principal.