Vos pull requests slop vibe-codées ne sont pas les bienvenues, car les outils de codage basés sur l'IA posent un nouveau problème aux responsables de projets open source, par Sam Saffron En tant que développeurs et responsables de grands projets open source, nous constatons que les outils de codage basés sur l’IA créent un nouveau problème pour les mainteneurs open source.
Les assistants IA tels que GitHub Copilot, Cursor, Codex et Claude peuvent désormais générer des centaines de lignes de code en quelques minutes. C’est certes très utile, mais cela a une conséquence inattendue : la révision du code généré par une machine est très coûteuse.
Le problème central : les outils d'IA ont rendu la génération de code peu coûteuse, mais ils n'ont pas rendu la révision de code peu coûteuse. Chaque PR incomplète accapare l'attention du responsable de maintenance, qui pourrait être consacrée à des contributions prêtes à être fusionnées.
Chez Discourse, nous constatons déjà que ce phénomène s'accélère au sein de notre communauté de contributeurs. L'année prochaine, tous les ingénieurs chargés de la maintenance de projets open source seront confrontés au même défi.
Nous avons besoin d’un cadre plus clair pour les contributions assistées par l’IA, qui tienne compte de la réalité du temps limité dont disposent les responsables de maintenance.
Un système binaire fonctionne extrêmement bien dans ce contexte. D’un côté, il y a les prototypes qui se contentent de démontrer une idée. De l’autre, il y a les PR prêtes à être révisées qui respectent les directives de contribution du projet et sont prêtes à être examinées par un humain.
L'absence d'étiquetage et de règles appropriés est néfaste pour l'écosystème logiciel.
Les nouveaux outils permettent de créer très facilement un ensemble de modifications et de le lancer par-dessus la barrière. Cela peut introduire un système pervers où les mainteneurs de projet consacrent des efforts disproportionnés à réviser du code généré par l'IA de qualité inégale, qui a pris quelques secondes aux contributeurs à créer et qui prendra désormais de nombreuses heures à réviser.
Cela peut être frustrant, chronophage et démotivant. D'un côté, il y a un contributeur qui a passé quelques minutes à jouer avec des invites d'IA ; de l'autre, un ingénieur qui doit passer de nombreuses heures, voire des jours, à déchiffrer une intelligence étrangère.
Cette situation n'est pas viable et est extrêmement néfaste.
Le prototype
Les agents de codage IA tels que Claude Code, Codex, Cursor CLI et bien d'autres ont ouvert la voie à la livraison d'un « nouveau type » de jeu de modifications : le prototype.
Le prototype est une démo en direct. Il ne respecte pas les normes de codage d’un projet. Ce n’est pas du code dont vous vous portez garant ou dont vous assurez la qualité. Il manque de tests, peut contenir des failles de sécurité et entraînerait très probablement une dette technique énorme s’il était fusionné tel quel.
Cela dit, c’est une démo vivante qui peut aider à rendre une idée plus concrète. C’est aussi extrêmement amusant.
Considérez-le comme un plateau de tournage enchanteur.
Considérez les PR de prototype comme des plateaux de tournage
Les prototypes, en particulier sur des projets tels que Discourse où des outils d’aide à la création existent, sont incroyablement faciles à explorer à l’aide d’outils comme dv.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 | % dv new my-experiment % dv branch my-amazing-prototype % dv ls total 1 * my-amazing-prototype Running 1 minute ago http://localhost:4200 # finally visit http://localhost:4200 to see in action |
Les prototypes sont d’excellents vecteurs pour explorer des idées. En fait, vous pouvez livrer plusieurs prototypes qui démontrent des solutions complètement différentes à un même problème, ce qui aide à choisir la meilleure approche.
Les prototypes, les démos vidéo et les maquettes visuelles simples sont d’excellents compagnons. Le prototype a l’avantage de vous permettre de jouer avec et d’explorer correctement le comportement d’un changement. La vidéo est plus rapide à consommer. Parfois, vous voudrez peut-être les utiliser tous.
Si vous pratiquez le « vibe coding » et le prototypage, il y a quelques règles claires que vous devriez suivre
1. N'envoyez pas de pull requests (pas même de brouillons), mais utilisez plutôt des branches pour partager votre code généré par la machine.
2. Partagez une courte vidéo ET/OU des liens vers une branche ET/OU des extraits de code particulièrement intéressants tirés du prototype dans des tickets ou des messages sur le forum.
3. Jouez cartes sur table, expliquez que vous exploriez une idée à l’aide d’outils d’IA, afin que les gens comprennent la nature du changement que vous partagez.
Peut-être aurez-vous de la chance et votre idée sera-t-elle adoptée ; peut-être que quelqu’un d’autre voudra investir du temps pour transformer un prototype en pull request de production.
Quand faut-il prototyper ?
Le prototypage est amusant et incroyablement accessible. Tout le monde peut s'y mettre en utilisant des environnements de développement locaux, ou même des environnements de développement sur le cloud tels que Jules, Codex Cloud, Cursor Cloud, Lovable, v0 et bien d'autres encore.
Cela abaisse considérablement le seuil d'accès au prototypage. Les chefs de produit peuvent prototyper, les PDG peuvent prototyper, les designers peuvent prototyper, etc.
Cependant, ce nouveau plaisir soulève une série de questions que vous devriez explorer avec votre équipe.
- Quand un prototype est-il approprié ?
- Que pensent les designers des prototypes ?
- Sont-ils source de distraction ? (les liens vers le code source sont-ils trop tentants) ?
- Nuisent-ils à la créativité humaine ?
- Comment devrions-nous nommer et partager les prototypes ?
- Un prototype permet-il à une idée de passer devant les autres ?
Lorsque vous introduisez le prototypage dans votre entreprise, vous devez aborder ces questions avec soin et parvenir à un consensus interne, sinon vous risquez de créer de profondes divisions et du ressentiment au sein de l’équipe.
L'intérêt du prototype
Les prototypes, à quoi servent-ils ? À beaucoup de choses, c'est certain.
Je trouve les prototypes incroyablement utiles dans mes pratiques de développement au quotidien.
- C'est comme un Grep sous stéroïdes. J'adore le fait que les prototypes servent souvent à parcourir notre vaste base de code pour isoler toutes les petites zones qui pourraient nécessiter une modification afin d'aboutir à un changement.
- J'adore communiquer par des paragraphes, mais je suis aussi quelqu'un qui communique de manière visuelle. J'adore la facilité avec laquelle un prototype bien construit peut communiquer une idée de conception que j'ai, même si je ne suis pas très doué avec Figma.
- J'adore le fait qu'il y ait quelque chose avec quoi jouer. Cela fait souvent ressortir de nombreuses préoccupations qui auraient pu passer inaperçues dans un cahier des charges. Le meilleur prototype est celui qui est testé ; pendant le test, on découvre de nombreux petits détails qu'il est tout simplement impossible de deviner à l'avance.
- Le code farfelu généré par les LLM m'intéresse souvent ; il peut parfois remettre en question certaines de mes idées.
Le prototype : guide de survie du mainteneur
Malheureusement, au fil de l’année, je m’attends à ce que de nombreux projets open source reçoivent beaucoup de PR au stade de prototype. Tout le monde n’aura pas lu cet article de blog, ni même ne sera d’accord avec lui.
En tant que mainteneur chargé de gérer les contributions externes :
- Protégez-vous et protégez votre temps. Limitez la durée des premières revues des ensembles de modifications volumineux ; concentrez-vous sur le fait de déterminer s’il s’agit d’un code « intuitif » plutôt que de laisser 100 commentaires sur du code généré par une machine qui n’a pris que quelques minutes à produire.
- Élaborez un code de conduite pour gérer les prototypes se faisant passer pour des PR. Renvoyez les contributeurs vers les directives de contribution, offrez-leur un autre moyen d’expression. « Je ferme cette PR, mais c’est intéressant, rendez-vous sur notre forum/nos tickets pour en discuter. »
- Ne vous sentez pas coupable de fermer une PR de prototype codée à l’instinct et non révisée !
La PR prête à être révisée
Une PR prête à être révisée correspond aux PR traditionnelles que nous soumettons.
Nous avons révisé tout le code généré par une machine et nous en garantissons l’intégralité. Nous avons exécuté les tests et, tout comme les tests, nous apprécions la structure du code ; nous avons lu attentivement chaque ligne de code et nous nous sommes également assurés que la PR respecte les directives du projet.
Les PR sont censées être des créations abouties, prêtes à être examinées par des humains
Tout le code farfelu généré par les agents en cours de route a été corrigé, et nous sommes heureux d’apposer notre propre marque sur le code.
Les projets ont généralement un ensemble de règles strictes concernant la qualité du code, son organisation, les tests et bien plus encore.
Nous avons peut-être utilisé l’aide de l’IA pour générer une PR prête à être révisée, mais fondamentalement, cela n’a pas d’importance : nous garantissons le code et nous nous portons garants de sa conformité à la fois avec notre marque et avec les directives du projet.
La distance entre un prototype et une PR prête à être révisée peut être trompeusement grande. Il peut falloir des jours de travail d'ingénierie pour prendre un prototype complexe et le rendre prêt pour la production.
Cette grande distance a également été évoquée par Andrej Karpathy dans le podcast Dwarkesh.
Pour certains types de tâches, de travaux, etc., il existe un écart très important entre la démo et le produit : la démo est très facile, mais le produit est très difficile.
…
Par exemple, en génie logiciel, je pense que cette caractéristique existe bel et bien. Pour beaucoup de codage « à l'instinct », ce n'est pas le cas. Mais si vous écrivez du code destiné à la production, cette caractéristique devrait exister, car toute erreur peut entraîner une faille de sécurité ou quelque chose de ce genre.
…
Par exemple, en génie logiciel, je pense que cette caractéristique existe bel et bien. Pour beaucoup de codage « à l'instinct », ce n'est pas le cas. Mais si vous écrivez du code destiné à la production, cette caractéristique devrait exister, car toute erreur peut entraîner une faille de sécurité ou quelque chose de ce genre.
Nos modèles s’améliorent de jour en jour, et tout dépend en réalité d’une quantité énorme de paramètres, mais le message central selon lequel les LLM peuvent générer et génèrent effectivement du code non sécurisé reste valable.
À propos de l’intelligence extraterrestre
La cause profonde de l’écart entre les directives du projet et un prototype est l’intelligence extraterrestre de l’IA.
Beaucoup d’ingénieurs que je connais se répartissent en deux camps : d’un côté, ceux qui trouvent cette nouvelle classe de LLM intelligente, révolutionnaire et incroyablement performante ; de l’autre, ceux qui considèrent tout le contenu généré par les LLM comme « les habits neufs de l’empereur », le code qu’ils produisent étant « nu », fondamentalement défectueux et toxique.
J’aime penser que ces nouveaux systèmes ne sont ni l’un ni l’autre. J'aime considérer cette nouvelle catégorie d'intelligence comme une « intelligence extraterrestre ». Elle est à la fois incroyablement bonne et incroyablement mauvaise, exactement au même moment.
Qualifier les LLM de « stagiaires super compétents » ou leur attribuer toute autre analogie humaine est erroné. Ces systèmes sont des extraterrestres, et plus tôt nous l'accepterons, plus tôt nous serons capables de naviguer dans la complexité qu'entraîne l'injection d'une intelligence extraterrestre dans notre processus d'ingénierie.
Tirer parti des atouts de l'intelligence artificielle : le prototype
Au cours des derniers mois, j'ai beaucoup expérimenté avec des agents IA. L'un des projets dont je suis particulièrement fier est dv. Il s'agit d'un orchestrateur de conteneurs pour Discourse, qui facilite l'utilisation de divers agents IA avec Discourse.
Je lance souvent plusieurs environnements Discourse complets et distincts, destinés à être jetés, sur mes machines afin d'explorer différentes fonctionnalités. Ce type d'outils est idéal pour créer des prototypes d'ingénierie d'ambiance.
Il est intéressant de noter que dv a été principalement construit à l’aide d’agents IA avec très peu d’intervention humaine ; une partie du code n’est pas tout à fait au niveau, mais contrairement à Discourse ou à bon nombre des autres joyaux open source que je maintiens, il s’agit d’un projet ludique.
Pour en revenir au sujet, dv s’est révélé être une excellente usine à prototypes sur Discourse. Cela a été formidable pour moi. J’ai pu explorer de nombreuses idées tout en rattrapant mon retard dans mes e-mails et mes discussions sur divers sites Discourse.
À propos de l'interdiction des contributions IA, des prototypes et autres
Tout d'abord, vous devez respecter les règles de tout projet auquel vous contribuez ; recherchez-les et lisez-les avant de contribuer. Par exemple : Cloud Hypervisor interdit le code généré par l'IA pour éviter les risques liés aux licences.
Cela dit, il existe une tendance chez de nombreux développeurs à bannir l'IA. Certains vont jusqu'à dire « L'IA n'est pas la bienvenue ici », trouvez un autre projet.
Cela me semble extrêmement contre-productif et fondamentalement inapplicable. De toute façon, une grande partie du code généré par l’IA est impossible à distinguer du code humain. On peut généralement repérer un prototype qui se fait passer pour une pull request humaine, mais une véritable pull request créée par un humain avec l’aide de l’IA peut être impossible à distinguer.
Les nouveaux outils LLM peuvent être utilisés de multiples façons, allant de simples revues de code et de simples renommages au sein d’un fichier, jusqu’à la mise en place d’une architecture de jeux de modifications.
Compte tenu de l’énorme désordre et de la grande diversité qui règnent ici, je pense que l’approche la plus saine consiste à définir des attentes claires. Si je soumets une PR, elle doit correspondre à mon image de marque et contenir du code dont je me porte garant.
En tant qu’ingénieurs, il est de notre devoir d’étiqueter correctement nos modifications. Notre modification est-elle prête pour une révision humaine ou s’agit-il simplement d’une exploration ludique de l’espace du problème ?
Pourquoi est-ce important ?
La révision humaine du code devient de plus en plus un goulot d'étranglement majeur dans l'ingénierie logicielle. Nous devons respecter le temps des autres et protéger nos propres marques d'ingénierie.
Les prototypes sont amusants, ils peuvent nous en apprendre beaucoup sur un domaine problématique. Mais lorsqu'il s'agit d'envoyer des contributions à un projet, traitez tout le code comme s'il s'agissait de votre propre code, apposez votre marque de propriété et d'approbation sur tout ce que vous construisez, et n'envoyez ensuite qu'une PR dont vous vous portez garant.
Source : Your vibe coded slop PR is not welcome
Et vous ?
Pensez-vous que cet avis est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
Au cœur du massacre des Pull Requests (PR) des logiciels open source (OSS) sur GitHub,Par Kush Creates
Le Vibe Coding crée des codeurs sans cervelle, par Namanyay Goe Le destin du « petit » open source : l'ère des petites bibliothèques à faible valeur ajoutée est révolue, les LLM en sont le coup de grâce, par Nolan Lawson
Vous avez lu gratuitement 480 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.