Pourquoi les applications développées avec l’IA continuent d’être écrites en JavaScript
Si de nombreuses applications créées avec l’IA se retrouvent en JavaScript, qu’en déduire au sujet des données d’entraînement et des boucles de rétroaction, ainsi que sur la question de savoir si le coding par ambiance restera lié à l’écosystème web.
Le coding par intention consiste à décrire ce que l’on souhaite obtenir à une aide IA et à la laisser générer la majeure partie du code. On guide le processus en utilisant un langage simple, on examine rapidement le résultat et on ajuste les instructions jusqu’à ce que tout fonctionne. Selon ceux à qui on le demande, il s’agit soit de l’avenir de la programmation, soit d’une mode passagère.
Une blague circule parmi les développeurs selon laquelle le coding par intention n’est en réalité que du JavaScript avec des étapes supplémentaires. C’est une blague, mais elle contient une part de vérité.
Regardez ce que les gens construisent réellement avec ces outils : des pages d’accueil, des tableaux de bord, de petits produits SaaS, des extensions de navigateur, des prototypes et des startups créées le week-end. La plupart de ces projets fonctionnent avec React, Next.js, Node.js et leurs dérivés, ce qui signifie que le résultat est presque toujours du JavaScript ou du TypeScript.
Il existe de bonnes raisons à cette superposition. Les modèles savent bien écrire en JavaScript parce qu’ils en ont vu beaucoup. Les dépôts publics, les tutoriels, les réponses sur les forums et la documentation concernant ce langage sont partout, et les données d’entraînement le reflètent. Les conventions de l’écosystème sont également assez uniformes, de sorte qu’un modèle ayant vu mille projets Next.js peut deviner à quoi ressemblerait le millième et unième.
Le web offre également le meilleur cycle de retours. Si vous demandez une page d’accueil, elle s’ouvre une minute plus tard dans une nouvelle fenêtre du navigateur. Si vous demandez un tableau de bord, une API ou une petite application, vous pouvez y accéder immédiatement. Si un bouton est mal placé, vous le signalez et la page se met à jour. Cette immédiateté explique en grande partie pourquoi le codage avec ces outils semble magique, et pourquoi les démonstrations impliquent généralement un site web.
Rien de tout cela ne limite cette pratique à une seule langue. Les gens utilisent déjà des assistants IA avec Python, Java, Go, Rust, C++ et bien d’autres langages. Les services backend, les scripts de données, les outils en ligne de commande ainsi que le code système peuvent tous être générés et modifiés de cette manière. Il est simplement plus difficile d’en faire la démonstration. Personne ne peut obtenir une capture d’écran satisfaisante d’une migration de base de données ou d’un script de compilation, c’est pourquoi ces exemples se répandent moins.
Ainsi, la question plus intéressante n’est pas de savoir si le « vibe coding » appartient au JavaScript. C’est plutôt de savoir si la programmation elle-même évolue vers une description du logiciel souhaité, avec un humain qui examine, corrige et décide de ce qui sera mis en production. Si c’est le cas, le langage utilisé deviendra progressivement moins important, et les compétences essentielles seront une spécification claire, un bon jugement quant au résultat produit par la machine et la capacité à détecter ses erreurs.
Nous sommes probablement encore au début de ce changement.