La vibecoding : c'est trop bien

L'IA est rentrée brutalement dans notre quotidien de développeurs depuis maintenant quelques années, plus récemment, le vibecoding s'est imposé comme une solution envisageable pour construire des applications en un minimum de connaissances et d'écriture de code.

La vibecoding est indéniablement une révolution de nos métiers, mais attention à correctement le considérer dans ses forces et ses nombreuses faiblesses.

Ces nouvelles méthodes, bien que changeant profondément notre approche du développement, ne sont pas parfaites ou absolues : le métier de développeur change mais ne disparaît pas.

Nous pourrions identifier un ensemble de bonnes pratiques pour profiter à bon escient de ces nouvelles technologies.

À quoi sert le vibe coding ?

Passer l'excitation des premières générations, il est essentiel, en bon professionnel, de se poser la question suivante : à quoi peut servir le vibe coding ?

Le vibe coding excelle incontestablement pour le code à faible valeur technique et ne nécessitant pas de maintenabilité sur le long terme : Le code arrive vite, souvent juste, parfois bluffant.

Cette rapidité est séduisante mais ne doit pas masquer une réalité plus complexe : toutes les lignes de code de votre application ne se valent pas, le besoin en qualité d'un composant à l'autre n'est pas une chose uniforme et constante.

En partant de ce constat, nous pouvons établir la matrice suivante : plus un code est critique et exige un haut niveau de maintenabilité et de compréhension, plus il doit être écrit consciemment par un humain. À l’inverse, un code standard ou à faible enjeu se prête bien à une génération totale et automatisée.

De nos jours, entre 20 et 100% de mon code est généré automatiquement par une IA, l'intervalle est énorme, allant même jusqu'à l'absolue génération, mon expérience de développeur me permet justement de l'utiliser à bon escient : jusqu'à quel moment le vibe coding est pertinent ?

Il est vrai que le code généré par vibe coding est parfois objectivement mauvais, mais est-ce que ce code avait besoin d’être bon ?

La question pourrait paraître invraisemblable pour certains, mais force de constater que le mauvais code … fonctionne en production et génère de l'argent, la question de la pertinence se trouve donc ailleurs.

La qualité du code n’est pas un objectif sacré et absolu mais un compromis à faire au jour le jour : elle doit toujours être proportionnelle à la criticité fonctionnelle de vos développements.

De par sa nature, le code généré par l’IA peut manquer de maintenabilité, ce n’est pas uniquement une question de qualité technique : cela reflète essentiellement un manque de maîtrise.

Le code produit est souvent redondant, adopte un style qui lui est propre et ajoute beaucoup de bruit pouvant nuire à la lisibilité et à sa compréhension ... tout du moins par un humain.

L’IA nous mâche le travail, si bien que nous passons à côté d’un véritable effort de compréhension, effort qui pourrait devenir rédhibitoire pour maintenir la base de code : vous ne comprendrez pas ce code car il ne ressemble en rien à ce que vous avez l’habitude de lire et d'écrire.

Face à un bug retors, il devient parfois difficile de transmettre clairement à l’IA le contexte de l’anomalie : " dans cette situation A, faire ceci, après avoir fait cela … et là, il se passe ça, alors que ... ".

Si l’IA, elle même, n’arrive pas à reproduire le bug que vous essayez péniblement de lui décrire, vous vous retrouvez démuni face à un code que vous ne comprenez peut-être pas vous-même.

Il y a ici une limite fondamentale qui justifie de garder le contrôle sur les composants critiques : notre difficulté à communiquer efficacement ... que ce soit avec des machines ou des humains.

Peut-être qu'un jour ces IA seront également suffisamment perfectionnées pour détruire la notion même de qualité logicielle, maintenir un faible LCOM, une faible complexité cyclomatique revient surtout à palier aux faiblesses humaines qui possedent une capacité de charge mentale limité.

Il est possible que ces contraintes disparaissent un jour pour les machines, à mesure que leur capacité de raisonnement et la richesse de leur contexte s'amélioreront.

Mais pour l’instant, tant que le facteur humain reste prépondérant, il est essentiel de garder la main sur les composants essentiels et critiques de votre application et de ne jamais perdre de vue que vous restez, quoi qu’il arrive, le seul responsable du code source.

L'IA est faillible

C’est sans doute la critique la plus évidente mais également la plus éculée : l’IA fait (souvent) des erreurs.

Après tout, si écrire des bugs suffisait à disqualifier une pratique, le vibe coding ne serait pas le seul à devoir rendre des comptes ... nous autres, les développeurs, serions tous au chômage.

L’IA est loin d’être parfaite, elle ne comprend fondamentalement pas ce qu’elle fait (ce qui, soyons honnêtes, nous arrive souvent aussi), elle s'obstine parfois dans des impasses et n'a que trés peu de considérations pour le futur.

Si vous ne la contrôlez pas, votre base de code deviendra tres vite illisible et ingérable au fil des générations et des prompts.

L'IA est un outil puissant mais imprévisible, nous pourrions le comparer un chien à qui vous lancez une balle : il part à toute vitesse ... mais sans consigne claire et des rappels réguliers, il risque de ramener un baton, de poursuivre un chat ou de finir dans la rivière.

L’IA aura également tendance à modifier le code sans réel souci de l’existant, provoquant des régressions en cascade à chaque nouvelle instruction. Conserver une bonne couverture de tests devient alors primordiale … d’autant que l’écriture de ces tests est grandement facilitée par l’IA, vous n'avez plus d'excuse pour tester en profondeur votre code !

Il devient essentiel de configurer au mieux vos IA pour qu’elles travaillent comme vous le désirez en prenant en compte des normes, des critères de qualité spécifiques, des code styles ou tout simplement une architecture cible.

Un bon réflexe pour pallier ses faiblesses et son imprévisibilité sera de commit à chaque changement fonctionnel : une modification réussie de l’IA, un commit pour conserver un état sain du repo.

Confier naivement votre code à une IA sans lui expliquer ce que vous attendez d’elle sera le meilleur moyen d’obtenir un résultat peu fiable et peu qualitatif … vous laissant un arrière goût d’inachevé et la fausse idée que ces technologies ne sont pas abouties : l'IA n'est pas omnisciente, elle ne peut pas deviner ce que vous avez en tête.

Ce serait également oublier que l’IA est meilleure que nous pour écrire du code, c’est un fait : elle est plus rapide, plus fiable et infatigable. Plus tôt vous l’acceptez, plus vite vous apprendrez à l’utiliser correctement.

L'IA est excitante

L'IA, et notamment le vibe coding, change notre rapport aux codes et à la valeur du code source, ce qui pouvait autrefois être complexe et chronophage devient parfois expéditif ... et excitant !

Un gain de temps indéniable se fait ressentir sur toutes les prises de décision secondaires, celles qui sont parfois inconscientes mais brident notre vélocité : comment nommer cette variable, ou encapsuler ce code, où placer ce bouton ...

Toutes ces petites décisions n’avaient peut-être pas de valeur quelconque et son automatisation est salutaire, vous permettant de vous concentrer sur ce qui aura le plus de valeur dans vos développements : l’architecture, la cohérence des dépendances, la stabilité des composants, la clarté des intentions métier, etc.

Le contrecoup de cette tendance sera la fâcheuse manie de l’IA à générer des chose inutiles, lui déléguer trop de décisions conduit à un code inutilement "bloated" : un endpoint API ajouté au cas où, des champs en trop dans un formulaire.

Ces choses peuvent paraître anodines, et elles le seront souvent, mais pourraient constituer de véritables failles de sécurité si vous n'y prenez pas garde.

l’IA est stupide et cherchera toujours à vous faire plaisir en proposant la réponse la plus exhaustive possibles à ses yeux ... quand bien même cela dépasse de loin vos attentes. Elle peut alors facilement dériver, s’enliser dans des détails inutiles ou perdre le fil si vous ne la recadrez pas.

Dans cette situation, ne soyez pas trop attachés à vos discutions avec l'IA (ce ne sont que des robots, ils ne le prendront pas mal), n’hésitez pas à repartir de zéro si vous sentez que l’IA s’est embourbée dans son raisonnement : une fois le contexte pollué, la qualité des réponses peut se dégrader tres rapidement.

Soyez également tres attentif au déroulement de la discussion, motivés par la succession de prompts et le code qui s'affiche progressivement à l’écran, nous avons vite tendance à valider passivement ce que l’IA propose ... quand bien même elle nous demande des précisions supplémentaires !

Ne vous effacez pas totalement : l'IA est un binôme, non un exécutant, elle doit penser avec vous et non à votre place.

L'IA existe, elle est là pour durer

Je développe des applications web depuis maintenant plus de 15 ans, j’ai toujours cultivé une certaine curiosité au fil des années … mais rien de comparable à ce que l’arrivée de l’IA a pu déclencher.

Ces derniers temps, j’ai sans doute exploré plus de frameworks, d’IDE, de technologies et de langages que durant tout le reste de ma carrière !

L’IA n’est pas une menace pour les développeurs mais un formidable tremplin : elle permet d’expérimenter, de repousser les barrières techniques et d’aborder des technologies qui, autrefois, pouvaient nous sembler intimidantes.

L’arrivée de l’IA et du vibe coding n’a rien d’exotique : elle incarne l’évolution naturelle de notre métier, qui depuis toujours ne cesse de concevoir des langages toujours plus abstraits, toujours plus éloignés des contraintes de la machine.

Le passage de l’assembleur au C nous a libérés des registres et des interruptions, celui du C à des langages de plus haut niveau comme Java ou Python nous a épargné la gestion manuelle de la mémoire. PHP, de son côté, nous a permis de produire des applications web sans réinventer le fonctionnement d’un serveur HTTP à chaque projet.

Chaque fois, nous avons accepté de confier à la machine une part de la complexité pour mieux nous concentrer sur ce qui a de la valeur : la logique métier, l’expérience utilisateur, l’intention derrière le code.

L’IA n’est que la prochaine marche, une couche d’abstraction de plus, qui nous aide à formuler ce que nous voulons faire plutôt qu’à détailler comment le faire.

Le vibe coding se distingue cependant sur un point, et non des moindres, en faisant rentrer le développement dans l’ère de l’indéterminisme : demandez lui de coder deux fois de suite la même fonctionnalité et vous aurez deux résultats différents.

Cette situation va radicalement à l’encontre de ce que nous avons appris à faire en tant que développeurs : décrire avec précision le comportement attendu d’une machine dans un contexte donné.

Ce changement de paradigme peut être déstabilisant et exigera sans doute de notre part une véritable prise de recul dans la décennie à venir.

Il est difficile de se projeter sur l'impact profond que pourrait avoir cette nouvelle mouvance, mais des auteurs commencent à se pencher sur la question.

Conclusion

Nous avons vu à travers cet article que l'IA était un outil aussi puissant qu'imparfait qu’il serait incensé d’ignorer.

L’IA est désormais présente dans le paysage technique, que vous le vouliez ou non, et son adoption dans vos pratiques de développement n’est plus un choix personnel mais une nécessité incontournable.

Cette tendance peut sembler inquiétante, comme tout changement majeur, d’autant que beaucoup profitent de ces bouleversements pour choquer, provoquer … et vendre.

La peur reste un levier commercial redoutablement efficace, sur ce point également, rien de nouveau sous le soleil.

Restez lucides face aux démonstrations spectaculaires de vibe coding censées générer des applications complètes de A à Z. Derrière les effets "wahou", ces projets sont souvent truffés de bugs fonctionnels : c’est impressionnant, parfois élégant en surface … mais rarement robuste dans les faits.

Créer une nouvelle chose à partir de rien est facile, la maintenir et la faire grandir est infiniment plus complexe et continuera de demander toute votre expertise.

Le code n’est qu’une facette du travail du développeur, souvent vue comme dominante au détriment des autres compétences.

Votre véritable responsabilité a toujours été de concevoir des solutions technologiques aux problématiques de l’entreprise, des solutions qui, il est vrai, prennent souvent la forme de code.

Le métier de développeur n'est pas disparu, il se transforme, la valeur du code source peut diminuer dans certaines circonstances, mais votre métier ne s’est jamais limité à ca.

Mathieu De Gracia

Des fois, mon chat code à ma place 🐱