Si vous allez faire du vibe coding, pourquoi ne pas le faire en C ?
(stephenramsay.net)- Le vibe coding fonctionne effectivement très bien, mais il réduit aussi le plaisir essentiel de programmer, car il produit du code que l’auteur ne comprend pas lui-même
- Tous les langages de programmation sont des outils conçus pour la commodité humaine, et non pour la machine ; leurs atouts comme la sûreté, l’abstraction ou la lisibilité ne sont au fond que des structures au service de la pensée humaine
- Dès lors, un langage convivial pour les humains est-il vraiment nécessaire pour du code écrit par l’IA ? L’auteur propose VOPL (Vibe-Oriented Programming Language), un nouveau langage centré sur l’IA et plus proche de la machine
- Ce langage pourrait prendre diverses formes : pseudocode exécutable, extension de la programmation lettrée, ou encore syntaxe fondée sur le langage naturel avec des tournures spécifiques
- Comme aux débuts des ordinateurs à programme enregistré, la résistance aux nouveaux paradigmes de calcul est une constante de l’histoire ; le vibe coding pourrait bien en être l’étape suivante
La tension entre programmation et vibe coding
- Pour l’auteur, programmer est un plaisir plus qu’un travail, une passion qui dure depuis la fin des années 1990
- Il enseigne la programmation depuis 25 ans et dit être particulièrement fier de transformer des non-spécialistes en programmeurs
- Lorsqu’il programme, il accorde une grande importance au plaisir de comprendre par soi-même en résolvant un problème
- À l’inverse, le vibe coding est un processus dans lequel l’IA écrit le code à la place de l’humain, ce qui conduit à une situation où l’auteur ne comprend pas totalement le résultat
- Cela donne parfois l’impression de « tricher » (même si ce n’est pas exactement cela), avec un malaise difficile à formuler
- Cela semble enlever une grande partie du plaisir de coder
- Malgré cela, le vibe coding fonctionne suffisamment bien pour produire de vrais systèmes de haute qualité
- Cela va bien au-delà d’un simple remplacement de la recherche, et résout aussi précisément des problèmes qu’on n’a pas envie de traiter soi-même
- L’IA est plus habile que l’humain pour traquer les erreurs et gérer la mémoire, et l’auteur est régulièrement surpris par les résultats obtenus lorsqu’il lui soumet une idée de programme
Les langages sont à l’origine des outils pour les humains
- Comme dans Structure and Interpretation of Computer Programs d’Abelson & Sussman, un langage de programmation est un moyen d’expression pour les humains
- Le code est « destiné à être lu par des humains », et la machine, elle, n’a pas besoin de lisibilité
- Tous les langages de programmation sont conçus comme des médias destinés à soutenir la pensée et l’expression humaines
- La sûreté de Rust, l’abstraction de C++, la concurrence de Go, etc. sont des fonctionnalités pensées pour les humains, pas pour la machine
- La gestion mémoire, la concurrence, la sûreté des types, etc. ne sont que des abstractions destinées à aider la structure de la pensée humaine
- Par conséquent, à l’ère où l’IA écrit le code, une conception des langages centrée sur l’humain pourrait devenir superflue
Alors, l’IA a-t-elle besoin d’un tel langage ? : le sens de la proposition « faire du vibe coding en C »
- En vibe coding, l’humain écrit déjà des programmes sans comprendre pleinement l’ensemble du code
- Dans ce contexte, la raison de conserver une syntaxe conviviale pour l’humain s’affaiblit
- Au lieu d’un langage centré sur l’humain, il pourrait être plus rationnel d’écrire directement dans un langage centré sur la machine (comme C ou l’assembleur)
- L’IA peut gérer avec plus de finesse que l’humain les undefined behavior, libérations mémoire, erreurs de type off-by-one, etc. en C
- Un peu comme un compilateur qui optimise mieux, elle montre une capacité plus précise à maîtriser l’exécution du code
- D’où la question : ne faudrait-il pas un langage mieux adapté à l’usage de l’IA ?
- Pourquoi faire du vibe coding à tout prix en Python, Rust ou C++, ces langages « centrés sur l’humain » ?
Proposition de VOPL (Vibe-Oriented Programming Language)
- Si l’on imagine un langage conçu à partir du vibe coding, on peut envisager plusieurs possibilités
- Un langage de très haut niveau proche d’un pseudocode exécutable
- Une forme achevée de programmation lettrée, où l’humain se contente de décrire et l’IA génère le code machine
- Une structure ressemblant au langage naturel, mais avec certaines « expressions idiomatiques » spécifiques
- Un concept proche d’une expression de la concurrence en vocabulaire courant (slang), au lieu d’un terme comme
goroutine
- L’idée serait de concevoir un système d’expression centré sur la machine permettant à l’IA de comprendre précisément un problème et de générer rapidement du code exécutable
- Il existe certes la question de l’apprentissage d’un nouveau langage par l’IA, mais comme de nombreux développeurs échangent déjà avec l’IA en lui fournissant du pseudocode pour produire du code,
il est possible qu’une certaine forme de VOPL soit déjà en cours d’apprentissage
L’évolution de l’acte de programmer
- Le « codage à la main » pourrait à l’avenir être considéré, dans la formation des vibe coders, comme une base de type Montessori
- De la même manière que l’apprentissage du dessin à la main avant Photoshop, ou la résolution d’équations sur papier, restent présents dans l’enseignement à l’ère des calculateurs électroniques
- La résistance face à l’arrivée d’un nouveau paradigme s’est répétée tout au long de l’histoire
- Les réactions hostiles au début de l’introduction des ordinateurs à programme enregistré (ENIAC → EDVAC)
- Même Grace Hopper a dû lutter contre l’idée qu’« une machine ne peut pas écrire les instructions d’une machine »
Message final
- Le vibe coding est déjà une réalité, et le développement logiciel de demain pourrait exiger une refonte du langage lui-même
- Après l’ère des langages centrés sur l’humain, il est peut-être temps de discuter sérieusement d’un basculement vers des langages centrés sur l’IA
« Same vibe, as the kids say. » — Comme disent les jeunes, c’est la même vibe
4 commentaires
Croire qu’en codant avec un modèle de langage, la machine va comme par magie produire toute seule des expressions proches du matériel, c’est franchement abusé.
Plus il y a de contraintes, mieux on travaille à l’intérieur de ces contraintes.
Même si l’IA écrit le code, la responsabilité du service incombe malgré tout au développeur. Je me demande s’il peut vraiment assumer la responsabilité d’un code qu’il ne comprend pas lui-même.
« Même si l’on fait du vibe coding, il faut le faire dans un langage que l’on maîtrise bien pour pouvoir relire le résultat. »
Il y a une phrase vraiment très importante dans les commentaires.
Avis sur Hacker News
Cela m’a rappelé à quel point les métiers du développement logiciel sont variés.
Je fais du backend, surtout du développement d’API, et le principal goulot d’étranglement de la productivité vient du fait que la plupart des gens ne savent pas définir correctement les exigences.
Quand on demande au PM, il esquive, et les développeurs frontend attendent que le backend fournisse l’API.
Au final, le plus difficile n’est pas le code, mais le processus de réflexion qui consiste à découvrir et interpréter les exigences.
La vraie programmation, c’est implémenter le système qu’on a conçu et lui donner vie.
Si on confond ça avec le simple fait d’écrire du code en entreprise et qu’on appelle ça « Programming », on crée un malentendu.
En revanche, il n’a probablement pas beaucoup d’expérience du développement de grands logiciels commerciaux.
Sa vision du « futur de la programmation » est séduisante, mais elle peut avoir certaines limites dans un contexte industriel.
(Référence : présentation de Stephen Ramsay)
Au fond, l’essentiel, c’est le mindset et le niveau d’exposition à la technologie.
Les LLM ont énormément augmenté ma productivité — surtout parce que j’ai une façon de penser orientée architecture.
Ce qui me prenait autrefois des mois se fait maintenant en quelques heures.
En ce moment, j’utilise des LLM pour traduire de vieux bouts de code Shockwave Lingo vers des langages modernes afin de restaurer des jeux legacy.
Si le vibe coding représente l’avenir, cela suppose donc en même temps que l’IA n’est pas complète.
Dès qu’on fixe arbitrairement les capacités et les limites d’une IA imaginaire, la discussion devient floue.
Il faut souvent quatre ou cinq réunions avec les parties prenantes avant que ce soit clair.
J’ai essayé le vibe coding en C, et je déteste toujours autant le C.
L’IA oublie de libérer la mémoire comme un humain, puis corrige plus tard.
Avec Rust, c’était bien plus agréable, et la vraie compétence consiste à comprendre l’écosystème de dépendances du langage.
L’IA aide à explorer rapidement ce type de « savoir livresque ».
En C, il fallait vérifier à la main si la mémoire était bien libérée, alors qu’en Rust cette inquiétude disparaît presque totalement.
Même en vibe coding, je pense que Rust est bien meilleur grâce aux garde-fous du langage.
Les fonctionnalités pensées pour les humains en Python aident aussi l’IA.
Grâce à l’IA, il est désormais plus facile de créer soi-même une UI ou un utilitaire,
et d’implémenter uniquement les parties critiques en C++.
Si j’avais dû tout déboguer moi-même avec GDB, cela aurait pris bien plus longtemps.
Je suis satisfait qu’elle prenne en charge les parties pénibles comme le traitement des chaînes ou la gestion des pointeurs.
Le code généré par le compilateur est toujours plus efficace, mais je transforme les erreurs de l’IA en opportunités d’apprentissage.
Même avec un LLM local, on peut automatiser des vérifications comme la libération de mémoire.
Il y a récemment eu une discussion intitulée « Why AI Needs Hard Rules, Not Vibe Checks ».
(lien)
Si Rust convient bien au vibe coding, c’est grâce à des validations gratuites comme les garanties de types et de durées de vie.
Sans ce type de vérification, un LLM produit facilement du code non sûr.
L’abstraction est nécessaire non seulement pour les humains, mais aussi pour les LLM.
Un langage où chaque fonction, variable, type et exception devrait être strictement spécifié.
Ce serait pénible à écrire, mais facile à lire et à vérifier.
Il traite de la difficulté à produire une traduction qui préserve non pas le chemin d’exécution du code, mais son intention.
Des outils comme Shellcheck peuvent déjà faire passer un débutant pour un expert.
Pour progresser avec le RL, il faut pouvoir juger automatiquement la cohérence du code.
Des langages logiques comme Prolog mériteraient peut-être d’être remis à l’honneur.
Si un LLM produit du code plein de bugs, le résultat restera similaire quel que soit le langage.
Au début, le vibe coding était impressionnant, mais la boucle de corrections permanente finit vite par faire fondre le cerveau.
C’est comme faire défiler un fil algorithmique qui vide la concentration.
Maintenant, je code moi-même et je laisse seulement les parties ennuyeuses à ChatGPT.
Et en plus, on n’apprend rien.
Cela permet de clarifier les exigences et de passer plus facilement à une autre IA.
Je doute qu’un LLM puisse produire du code C sans fuite mémoire.
Même les développeurs humains se trompent sur ce terrain, donc un LLM entraîné sur des données de qualité inégale est encore plus risqué.
Si on fait du vibe coding pour obtenir un programme qui segfault, c’est une perte de temps.
Ça casse rarement et ça compile presque toujours.
Les humains se fatiguent, pas les LLM.
En les réentraînant sur du bon code C, il y a une marge d’amélioration.
L’IA qui éviterait l’undefined behavior en C ? J’ai du mal à y croire.
Si le modèle est entraîné à faire des erreurs comme un humain, il a de fortes chances de produire les mêmes bugs.
Comme ils prédisent les tokens les plus probables, ils font moins souvent les erreurs courantes.
Il a aussi bien identifié la cause d’un crash.
Des langages modernes comme Zig ou Rust sont bien meilleurs.
Si le vibe coding me met mal à l’aise, ce n’est pas simplement parce que ça ressemble à de la triche.
Programmer est un art habité par une âme.
Chacun résout les problèmes à sa manière, et c’est cela, la créativité.
Le vibe coding donne l’impression que cette créativité est absorbée par la machine.
Au final, les idées, les décisions et même les erreurs sont toutes déléguées à la machine.
Il y a eu une proposition de créer un « vibe-oriented programming language (VOP) ».
Mais si c’est un langage pour les LLM, il devrait au contraire être strict et verbeux.
Il ne devrait pas compiler tant que toutes les conditions et exceptions ne sont pas explicitement décrites.
C’est inconfortable pour les humains, mais pour un LLM cela a l’avantage de réduire l’ambiguïté.
Il faut une structure où l’humain explique le concept, puis l’IA le transforme en code.
Une fois compilé, il fonctionnait presque toujours correctement.
Même en vibe coding, il vaut mieux utiliser un langage qu’on maîtrise bien pour pouvoir relire le résultat.
Sinon, autant faire l’expérience directement en brainfuck.
À la question « Et en assembleur x86, alors ? »,
la réponse a été non, parce que « je dois pouvoir le relire moi-même et l’étendre ».
Le vibe coding pur n’est qu’une expérience de pensée, pas un objectif réaliste.
Un jour, l’IA pourra peut-être gérer aussi la QA, mais pour l’instant, des langages sûrs et une vérification humaine restent indispensables.
Je suis désormais un développeur trop ancien pour ce genre de débat.