- Récemment, il devient facile de repérer à l’intérieur d’une équipe le code généré par un LLM
- Ces codes, bien que clairs et bien testés, ne respectent pas les conventions du projet
- Ils ignorent plusieurs patterns ou bibliothèques existants pour implémenter quelque chose de neuf
- L’inquiétude grandit face à la tendance à ne chercher que la vitesse dans le développement logiciel
- En fin de compte, l’essentiel reste la qualité et la cohérence, ainsi que la maintenabilité
Les traces du vibe coding
- Certaines parties de code écrites récemment par un membre de l’équipe paraissent claires et fonctionnellement parfaites, mais peuvent être immédiatement identifiées comme générées par un LLM parce qu’elles ne respectent pas les conventions propres au projet
- Par exemple, malgré la présence d’une bibliothèque de récupération de données dans le projet, l’équipe écrit directement une implémentation de requêtes HTTP qui couvre tous les cas d’exception
- Les fonctions utilitaires des modules existants sont recréées à répétition, et malgré l’existence d’un mécanisme de modification de configuration au niveau du module, les réglages globaux sont changés
- Malgré une culture bien implantée de codage fonctionnel, du code basé sur des classes est écrit à nouveau
- Il s’agit d’un style de code qu’un développeur n’aurait, il y a quelques années, jamais écrit
L’importance de la maintenabilité et des principes logiciels
- En développement logiciel, on a toujours investi des efforts pour établir des patterns et standards durables
- En pratique, n’importe qui peut écrire du code qui fonctionne, mais le vrai défi est d’avoir un code facile à maintenir et à modifier sur le long terme
- L’enjeu n’est pas la mise en œuvre de la fonctionnalité elle-même, mais une base de code qui puisse être conservée au fil du temps
- Le « vibe coding » peut faire s’effondrer ce type de philosophie et ces standards
Faire de la vitesse la ligne directrice absolue ?
- Il utilise l’exemple d’un nouveau barista dans un café qui, en se dépêchant, renverse son café, pour souligner que l’obsession de la vitesse n’apporte pas toujours de bons résultats
- Les équipes de développement d’aujourd’hui en sont au même stade, allant trop vite pour construire de nouveaux logiciels et provoquant ainsi une baisse de la qualité
- Ce que les gens attendent au fond, c’est un résultat correct, même s’il faut attendre un peu plus longtemps
- Je pensais que la recherche effrénée de la vitesse était un problème de métiers non techniques, mais j’ai été déçu de voir des collègues développeurs eux aussi abandonner les principes pour ne poursuivre que la vitesse
Ce que nous voulons vraiment
- On ne se soucie pas de la manière dont le code a été injecté dans l’IDE
- L’important est l’attitude d’un développeur qui veille à la qualité
- On reconnaît que les LLM sont une avancée technique remarquable, mais on rappelle que la responsabilité de fabriquer un vrai logiciel repose toujours sur le développeur
- Il préconise d’appliquer des principes existants en sachant rédiger de meilleurs prompts, en spécifiant les bonnes bibliothèques, en fournissant des exemples, en travaillant fichier par petit fichier
- Ne laissez pas la qualité du code et la maintenabilité à la charge des seuls « poids » du modèle
Aucun commentaire pour le moment.