L’autodérision est quelque chose d’important pour tout développeur qui se respecte. Être capable de plaisanter sur ses erreurs permet de prendre du recul et donc d’apprendre de ses fautes. Cela donne de nombreux mèmes, ces situations représentées souvent par des personnalités réelles ou fictives
Coder avec une intelligence artificielle (IA) permet de découvrir des concepts à défaut d’avancer sur le projet. Je vais caricaturer. Mais il y a du vrai dans les traits simples. Prenons deux plaisanteries récurrentes sur les réseaux sociaux.
Le vibe coding c’est aller plus vite pour corriger plus longtemps
Tout développeur qui s’intéresse aux usages des agents IA pour simplifier le code vous le dira. Développer un programme, pour un informaticien, c’est 3h à écrire du code et 8h à corriger les erreurs afin qu’il fasse ce qu’on attend. Pour un vibe coder, c’est 5 minutes à attendre la copie de l’IA et 5 jours pour le faire fonctionner.
Si vous me suivez, vous savez que l’informatique ne se résume pasc à aligner des instructions. Et comme dans tout domaine, les gens se spécialisent. Le développeur a parfois tendance à ne pas écouter l’analyste et à répéter ce qu’il sait faire. D’où les corrections à apporter par la suite.
Le vibe coder est un développeur qui préfère déléguer l’écriture du code à une IA. Le résultat renvoyé peut dépasser sa compréhension. Lire un programme si on ne comprend pas les schémas utilisés, les mots clés du langage, …, c’est lire le Dalloz avant de plaider à un procès sans connaître le Droit.
Si vous n’avez pas correctement cadré le travail de vos agents, si vous n’avez pas précisé vos exigences de cadre technique, d’organisation des composants, de lisibilité du code, … le travail de ce qu’on appelle aujourd’hui architecte logiciel, alors les corrections à apporter pour coller au métier deviennent très compliquées.
Un code informatique évolue avec les besoins des utilisateurs et les changements techniques. Plus on s’éloigne de ces réalités, en délégant, et plus les évolutions et les corrections sont chères. Cela amène d’ailleurs à la seconde plaisanterie …
La refactorisation, ce mal pour un bien
Je vous renvoie à ce mème. En référence à la scène du “Seigneur des anneaux” où Isildur refuse de suivre les conseils d’Elrond et de détruire l’anneau unique, le responsable informatique refuse que le développeur publie sa mise à jour technique qui n’apporte aucune fonctionnalité pour l’utilisateur.
Lorsqu’un informaticien écrit un programme, il le fait en fonction de ses connaissances. Avec le temps, il progresse et s’aperçoit qu’il aurait pu faire différemment et de manière plus efficace. C’est là qu’apparaît un dilemme. Doit-il réécrire les portions de code au risque de faire régresser des fonctionnalités de l’application ?
Un projet informatique est rarement l’œuvre d’une personne. Et modifier du code peut impacter le travail d’autres personnes et la responsabilité du chef de projet auprès des utilisateurs. Réécrire, refactoriser les parties de code qui semblent se répéter, c’est un risque et une charge à prendre en compte lors de la phase de recette.
En contrepartie, un code mal écrit, c’est une perte de temps à chaque évolution ou correction à apporter. Un développement qui coûte 1 jour pour un code lisible peut en coûter 10 pour un code mal organisé. Mais le chef de projet s’en moque. Son travail, c’est de plaire au client, pas à ses collègues développeurs.
…
Avec humour, je prends du recul sur mon travail afin de ne pas répéter mes erreurs. Je transmet ma compréhension aux autres. Ce qu’ils en font après ne me concerne plus.