- Les récentes déclarations d’Andrej Karpathy ont fait le buzz : « Laissez-vous porter par la vibe, acceptez la croissance exponentielle, et oubliez même que le code existe. »
- Le « Vibe Coding » désigne la tendance à déléguer la résolution de problèmes à des outils d’IA, sans plan clair ni écriture directe de code
- Grâce à des agents LLM (grands modèles de langage), il devient possible de donner des instructions en langage naturel pour générer et modifier du code
- 2022 : possibilité de copier et modifier du code dans ChatGPT
- 2023 : possibilité de relire et modifier du code dans Copilot intégré à l’IDE
- 2024~2025 : possibilité de modifier plusieurs fichiers d’un projet, ainsi que d’exécuter ses propres tests et correctifs
Fonctionnement du « Vibe Coding »
- Les utilisateurs techniques comme non techniques peuvent configurer un projet via des agents basés sur des LLM
- Il est possible de créer un site web ou une application avec une simple instruction (ex. : « créer un site web pour une station de ski »)
- Après la configuration initiale, l’agent peut corriger et tester automatiquement
-
Exemples :
- Cursor, GitHub Copilot Agent Mode, etc. peuvent modifier des fichiers et exécuter des commandes
- Exécution de corrections et de tests automatiques → des erreurs peuvent survenir faute de cohérence
Le problème de l’autonomie des agents
- Les agents peuvent exécuter automatiquement certaines tâches, mais ils ne sont pas totalement autonomes
- Une exécution sans validation de l’utilisateur peut être risquée (ex. : lancer des commandes en mode YOLO)
- Des problèmes de qualité et de précision du code peuvent apparaître
-
Principaux problèmes :
- Échec de réutilisation du code existant → recréation répétée des mêmes composants
- Tentative d’exécuter une logique côté serveur sur le client
- Introduction d’erreurs après une correction de code erronée → échec des correctifs
- Échec d’écriture de tests unitaires ou destruction du code
Limites réalistes
- Des modèles comme Claude 3.7 Sonnet ne peuvent pas dépasser les limites de leurs données d’entraînement
- Lorsqu’ils perdent le contexte dans une base de code, ils ne peuvent plus produire de modifications cohérentes
- Quand la taille du code augmente, les performances se dégradent et le maintien du contexte devient impossible
- Lorsque la fenêtre de contexte d’un LLM est dépassée, des problèmes de cohérence apparaissent
-
Exemples concrets de problèmes :
- Duplication d’interfaces TypeScript
- Exécution de logique serveur côté client
- Échec de correction de composants dupliqués
- Échec d’écriture de tests unitaires
- Échec à corriger des erreurs après refactorisation du code
Tentatives de résolution
- Claude Plays Pokémon : un agent interagit en temps réel en jouant au jeu
- Échec à conserver la mémoire et à corriger des erreurs répétitives
- Échec à construire une mémoire à long terme → erreurs persistantes
-
Pistes d’amélioration :
- Nécessité d’améliorer le MCP (Model Context Protocol) et la gestion de la mémoire
- Lors des modifications de code, le LLM doit refléter avec précision les corrections précédentes
- Nécessité de conserver une mémoire par domaine et l’historique des tâches
Conclusion
- Le « Vibe Coding » peut permettre d’atteindre jusqu’à 80 % de l’implémentation d’un concept fonctionnel, mais créer un produit fiable et sûr exige toujours l’effort d’un humain expérimenté
- Les agents IA permettent à des personnes qualifiées de créer davantage de manière indépendante, mais ils ne peuvent pas remplacer ceux qui savent résoudre des problèmes difficiles nécessitant expérience et intuition
- Au niveau actuel, il est difficile que le « Vibe Coding » débouche réellement sur des produits utiles, et l’aide de développeurs expérimentés reste indispensable
- Le « Vibe Coding » n’est qu’un outil d’assistance à l’écriture du code, pas un substitut complet
9 commentaires
La partie « niveau actuel » me saute aux yeux. N’est-ce pas regarder les LLM à travers la conception humaine du temps ?
Ce que je ressens en codant avec l’IA, c’est que même si on ne lui donne qu’une partie du code, si on découpe en unités dans l’esprit du principe de responsabilité unique et du TDD pour qu’elle puisse comprendre le contexte, il faut finalement structurer les choses de sorte qu’elle n’ait pas besoin de lire le contexte global et qu’un contexte local suffise à bien cadrer le travail.
J’utilise surtout l’IA pour un hobby, la création de jeux web, donc je suis d’accord. Quand le projet dépasse une certaine taille, il arrive qu’à un moment l’IA perde nettement en concentration, si on peut dire ça comme ça. Moi, je l’utilise de la façon suivante : je fusionne toute l’arborescence du jeu et le code source en un seul fichier, TOC comprise, puis j’ouvre un nouveau thread, j’envoie ce fichier et je continue le travail à partir de là. Et quand je pose une question, je demande toujours une réponse en indiquant explicitement le nom du projet en cours. Malgré cela, il y a encore des points qui me laissent insatisfait… mais je suis très satisfait de pouvoir mener à bien, en relativement peu de temps, des loisirs que je n’aurais même pas osé envisager par le passé, trop pris par la vie quotidienne.
J’aime beaucoup ce modèle qui consiste à faire quelque chose à la va-vite, puis à peaufiner le reste des détails.
On peut faire diverses tentatives, mais les limites de la mémoire sont évidentes. C’est bien au niveau PoC. C’est utile pour évaluer rapidement le potentiel et l’utilisabilité.
Le problème, c’est qu’il faut d’autant plus de personnes expérimentées.
Si l’on considère que l’on passe la majeure partie de son temps en programmation à déboguer et à lire du code, je trouve que c’est très exagéré. Les gens qui créent de l’IA tiennent tous ce discours, mais au moins au vu de la situation actuelle, cela ne semble pas être le cas. Si l’on arrive à une situation où l’intervention humaine n’est plus nécessaire, aura-t-on encore vraiment besoin de coder ? Il vaudrait mieux simplement fournir la description de l’API et utiliser le LLM comme backend.
En pratique, on configure le schéma pour recevoir les données, donc c’est souvent utilisé comme ça.
Je suis d’accord. Au début, on a l’impression d’une vitesse de développement presque magique, mais à mesure que l’ampleur augmente et que le nombre de fichiers se multiplie, si la personne responsable de la gestion (ici, l’humain) n’arrive pas à maîtriser efficacement l’ensemble, on finit par n’obtenir qu’un résultat gonflé et truffé d’erreurs. Une fois qu’on a dépassé le point de non-retour, on ne fait plus que gaspiller des crédits (Windsurf) ou des requêtes (Cursor). Ça va sûrement s’améliorer progressivement, mais pour l’instant, il ne faut pas faire confiance à 100 % au code généré par l’IA.
Avis Hacker News
La grande différence entre le « battage autour de l’IA vs la réalité » se situe dans les chiffres de productivité souvent avancés. Par exemple, des partenaires de YC citent une entreprise affirmant une « amélioration de vitesse de 100x » en matière de performance de codage. De telles affirmations seraient manifestes pour des observateurs externes, donc elles ne devraient pas nécessiter d’auto-déclaration.
En ce moment, on suit une vague comparable à celle de l’externalisation. Malgré toutes les affirmations exagérées, la réalité est différente. Il est difficile de faire la part des choses dans les discussions sur les agents de codage LLM.
C’est comme quand la communauté Go disait qu’un ordinateur ne pourrait pas battre des joueurs humains de Go. On a déjà des exemples de modèles qui trouvent de meilleurs algorithmes de tri. Avec les bons incitatifs et suffisamment de temps, les ordinateurs finiront par nous battre.
Partage d’un nouveau problème avec les LLM de codage. Des développeurs offshore sont pleinement intégrés à l’équipe. Mais l’usage des LLM est désordonné et sporadique, si bien que les pull requests soumises deviennent un cauchemar.
Le « Vibe Coding » peut implémenter 80 % d’un concept. Mais pour construire quelque chose de fiable, sûr et utile, il faut des humains expérimentés.
Récemment, quelqu’un a essayé d’utiliser Claude et OpenAI o3-mini pour convertir du code Matlab en Python, mais les performances étaient très mauvaises. Presque chaque ligne importante contenait des erreurs. C’est le genre de tâche qui devrait être automatisable, mais cela a échoué.
Faire du « Vibe-TDDing » vaut mieux que de ne pas avoir de tests du tout. Si l’on comprend le code et les tests, on peut utiliser les LLM pour réduire les effets externes négatifs.
Depuis avoir partagé comment construire un SaaS, des choses étranges se produisent. L’utilisation des clés API atteint son maximum, des contournements d’abonnement apparaissent, et des éléments aléatoires sont créés dans la base de données. C’est probablement une farce.
Voir beaucoup d’ingénieurs sous-estimer les capacités et la productivité des outils de codage IA donne un sentiment de sécurité vis-à-vis de son emploi. Je ne lâcherai pas Cursor.