Discussion :

[olsimare]

J'ai tenté l'expérience vibe coding sur un projet. Pour moi, ça reste possible que si on a quand même une bonne maître du langage, parce ce que je me suis souvent retrouve avec des proposition complètement pété, et même après 4 ou 5 demandes, c'était toujours pas fonctionnel. Alors que la correction était vraiment simple, j'ai fini par la faire moi même et passer à autre chose. Bref pour les finitions, c'est pas ouf, par contre pour dégrossir j'ai gagné un temps fou. Je pense que j'aurais même pas commencé ce projet sans ça. Au bout de 3 jours, le projet est devenu trop gros et il commence à me proposer des trucs totalement hors contexte. La refacto et les cas limites, je vais les faire sans IA.

Quand j'ai tenté le coup avec ChatGPT sur un truc de boostrap sur lequel je bloquais, le machin m'a sorti que la fonctionnalité pourtant décrite sur la page de doc de Bootstrap n'existait pas... Ial ne devait pas connaître ou avoir raté la page !
C'est fantastique, on va bien régresser !

Ceci dit, on voit qu'on a de l'ancien qui réagit donc je demande : "qui saura encore résoudre un 0C7 sur un mainframe en 2030 ? Ou pire un 0C4 ?"

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Accepter un code écrit par l'IA sans en comprendre le fonctionnement devient de plus en plus populaire

Bien avant l'IA, il y avait les forums internet où certains devs faisaient déjà du copier coller de bout de code sans chercher à le comprendre.
En tant que DBA, j'ai déjà vu du code SQL de mauvaise qualité et puis à un moment donné tu as un morceau avec des fonctionnalités vraiment avancées avec des noms de variables qui suivent un autre standard.
Ce qui est triste, c'est que le code aurait eu besoin d'un très léger ajustement pour répondre complètement au besoin...

[tgauchet]

ça fait longtemps (depuis google?) que je vois les développeurs demander au moteur de recherche, comment faire et recopier bêtement le code sans comprendre ce qu'il se passe derrière chaque langage, interpréteur, moteur... donc de ce point de vue, je vois l'IA comme un progrès. Le code à copier/coller est adapté au prompt grâce à l'intelligence.

[Pyramidev]

Aujourd'hui, Kush Brahmbhatt a publié une jolie diatribe contre le vibe coding : Why 'Vibe Coding' Makes Me Want to Throw Up.

Il insiste sur l'importance de comprendre le code pour faire un programme qui marche bien en production.

[kain_tn]

Aujourd'hui, Kush Brahmbhatt a publié une jolie diatribe contre le vibe coding : Why 'Vibe Coding' Makes Me Want to Throw Up.

Il insiste sur l'importance de comprendre le code pour faire un programme qui marche bien en production.

Merci pour le lien. J'ai trouvé l'article très bon.

[Zefling]

Quand j'ai tenté le coup avec ChatGPT sur un truc de boostrap sur lequel je bloquais, le machin m'a sorti que la fonctionnalité pourtant décrite sur la page de doc de Bootstrap n'existait pas... Ial ne devait pas connaître ou avoir raté la page !
C'est fantastique, on va bien régresser !

Ceci dit, on voit qu'on a de l'ancien qui réagit donc je demande : "qui saura encore résoudre un 0C7 sur un mainframe en 2030 ? Ou pire un 0C4 ?"

Je m'en suis servis pour faire des trucs chiants. J'ai fait principalement de la revue de code, de l'assemblage et corriger des trucs complètement pourri en terme de sécu. Mais grâce à ça, j'ai fais en temps cumulé 3 jours, ce que j'aurais mis en bien 3 semaines à faire. Je connais le langage, mais faire des formulaires pour faire de la gestion, c'est pas le truc le plus existant du monde et ça a déjà été fait des milliers de fois.

Sinon j'ai plein de projet ou je l'utilise jamais. Mais j'avoue, maintenant de temps en temps quand je ne veux pas faire une tache chiante (exemple, sortir tous les textes d'une page pour les mettre dans un json), j'ai tendance à l'utiliser.

[tatayo]

Le peu d'I.A. que j'utilise ce fait via des extensions de Visual Studio (Codeium, DocumentationAssistant...) , pour avoir de la complétion et des suggestions de code.
Suggestions qui sont pour la plupart correctes, mais pas toujours.
Ces suggestions ne concernent que quelques lignes de code à chaque fois, jamais une section complète.

Quoi qu'il en soit je relis systématiquement ce qui est proposé, histoire de savoir ce que fait le code, comment, et surtout si ça correspond bien à ce que je veux faire.

Tatayo.

[abgech]

Un retour de plus de 60 ans en arrière, au début des années 1960. L'époque ou l'on disait que le Cobol permettrait de se passer de main-d'œuvre humaine…

[destroyedlolo]

Hum, ceci tenderait à prouver que microsoft à "inventé" la machine à voyager dans le temps.
Sinon, comment expliqué qu'ils aient réussi à toujours produire un OS aussi instable depuis plus de 5 décénies ????

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Sinon, comment expliqué qu'ils aient réussi à toujours produire un OS aussi instable depuis plus de 5 décénies ????

Comment on peut écrire des choses pareilles sans passer pour un troll

[Kush Creates]

Pourquoi le « Vibe Coding » me donne envie de vomir, par Kush Creates

Un programmeur s'insurge contre le « Vibe Coding » et la tendance dangereuse qui consiste à accepter aveuglément le code généré par l'IA sans le comprendre. Découvrez pourquoi cette approche est en train de détruire le plaisir et l'art de la programmation.

Pour votre information, le Vibe Coding consiste à utiliser des LLM et des chatbots IA pour réaliser votre projet et à vibrer avec le code que le LLM vous donne.

Introduction

Vous souvenez-vous de l'époque où programmer signifiait comprendre son code ? Quand le débogage ne consistait pas simplement à coller des erreurs dans une IA ? Lorsque vous pouviez expliquer comment votre application fonctionnait réellement ?

Cette époque est apparemment révolue, si l'on en croit le récent X Post (Tweet) d'Andrej Karpathy sur le « Vibe Coding ». Il s'agit d'une approche troublante où les programmeurs abandonnent leur métier à des outils d'IA en espérant que tout se passe bien. En tant que personne ayant passé des années à perfectionner ses compétences en programmation, je trouve cette tendance non seulement préoccupante, mais carrément dangereuse.

Karpathy a donc lâché cette perle absolue sur le « Vibe Coding » et j'ai failli recracher mon troisième café de la matinée sur mon clavier. Si je comprends bien, nous sommes maintenant FIER de ne pas comprendre notre propre code ? Cool cool cool. Une approche totalement durable de l'ingénierie logicielle.

Ecoutez, je diffuse des solutions de code sur StackOverFlow depuis de nombreuses années. Vous vous souvenez de cette période sombre ? Lorsque vous deviez LIRE LA DOCUMENTATION ? Et maintenant, nous avons Mr. « J'ai cofondé OpenAI » qui se vante en toute décontraction de vibrer avec son code comme s'il s'agissait d'une sorte de trip technologique sous acide.

Laissez-moi vous expliquer pourquoi « vibrer » avec votre code donné par l'IA au lieu de le comprendre est le chemin le plus rapide vers la catastrophe technique et pourquoi les vrais développeurs devraient s'opposer à cette tendance bizarre.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

La montée du développeur qui "accepte tout"

J'"accepte toujours tout", je ne lis plus les diffs.

C'EST. QUOI. CE. BORDEL.

Oh cool, cool. Alors on se contente d'appuyer sur le bouton « Accepter tout » comme s'il s'agissait d'un jeu de morpion ? Je peux déjà sentir les conflits de fusion qui se préparent comme une mauvaise tasse de café que quelqu'un a laissée dans la salle de repos pendant trois jours.

Je veux dire, bien sûr Andrej, c'est très bien quand vous construisez un joli petit projet de week-end dont personne ne dépend. Mais certains d'entre nous travaillent sur des systèmes où « Accepter tout » est l'équivalent numérique de jouer à la roulette russe avec cinq balles chargées.

Laissez-moi vous dépeindre mon mardi de la semaine dernière :

1. Un développeur junior a « vibré » avec la base de code
2. Personne n'a revu les changements parce que YOLO, n'est-ce pas ?
3. Le serveur de production a pris feu à 2 heures du matin
4. Devinez qui a été bipé ? Pas les vibrations, c'est sûr.

L'écart de compréhension

Le code se développe au-delà de ma compréhension habituelle, il faudrait que je le lise vraiment pendant un certain temps.

Si ce n'est pas la phrase la plus terrifiante qu'un développeur puisse lire, je ne sais pas ce que c'est. Bien sûr, Andrej, construisons une maison dont nous n'avons aucune idée de l'emplacement des murs porteurs. Qu'est-ce qui pourrait bien aller de travers ?

Ce n'est pas un badge d'honneur, mais un drapeau rouge de la taille du Texas. Lorsque vous ne comprenez pas votre propre base de code, vous n'êtes plus un développeur. Vous êtes juste une personne extrêmement inefficace qui n'a jamais appris à coder et qui se contente d'utiliser l'IA.

Les étapes suivantes sont prévisibles :

1. Un code incompréhensible entraîne un comportement imprévisible.
2. Un comportement imprévisible conduit à un code non structuré, à des bidouillages et à des solutions de contournement.
3. Les bidouillages et les solutions de contournement conduisent à un code encore plus incompréhensible.
4. Répétez l'opération jusqu'à ce que votre dépôt GitHub soit légalement considéré comme une scène de crime.

C'est comme si "je laissais mon enfant concevoir mon portefeuille financier en sélectionnant au hasard les actions en fonction des logos d'entreprises qui ont les plus jolies couleurs." Sauf que le bambin est une IA qui a été entraînée sur StackOverFlow, y compris toutes les réponses désapprouvées.

Ecoutez, je vais vous révéler un petit secret qui, apparemment, doit être dit en 2025 : LES BONS INGÉNIEURS COMPRENNENT LEUR CODE.

Cette connerie de « Vibe Coding » est l'équivalent en programmation de fermer les yeux en conduisant parce que votre Tesla est sur Autopilot. Ça marche très bien jusqu'à ce que vous vous retrouviez enroulé autour d'un arbre en vous demandant pourquoi l'IA ne l'a pas vu venir.


Ce n'est pas vraiment du codage

Écoutez les gars, je ne suis pas contre l'assistance de l'IA. J'utilise Copilot, ChatGPT, Claude depuis qu'ils ont été lancés, et ils sont vraiment utiles pour les modèles simples. Mais il y a une différence entre le « codage assisté par l'IA » et le spectacle d'horreur décrit par Andrej Karpathy.

Le vrai codage implique la compréhension. Le débogage. La résolution de problèmes. La satisfaction de comprendre enfin pourquoi cette fichue fonction ne cesse de retourner undefined et NaN à 2 heures du matin. L'effroi existentiel lorsque vous réalisez que c'est parce que vous avez mal orthographié quelque chose et que vous n'avez pas essayé de relire la fonction correctement. Ce sont ces expériences authentiques qui nous façonnent en tant que développeurs !


La philosophie du « contournement des bogues »

Parfois, les LLM ne peuvent pas corriger un bug, alors je le contourne ou je demande des changements au hasard jusqu'à ce qu'il disparaisse.

Oh mon dieu, c'est en train de me faire réagir. C'est comme réparer sa voiture en frappant différentes parties avec un marteau jusqu'à ce que le bruit bizarre s'arrête. Bien sûr, le bruit s'est arrêté ! Le problème sous-jacent ? On s'en fout ! VIBES !

Cette programmation équivaut à donner un coup de pied à votre fichue télévision jusqu'à ce que l'image revienne. Très professionnel. Très durable.

Je jure que je recevrai un appel d'un recruteur dans 6 mois :
« Nous recherchons un ingénieur Vibe senior avec plus de 10 ans d'expérience dans l'intégration exponentielle, et plus de 5 ans à oublier que le code existe. »

« Hey, pourquoi notre application se plante-t-elle en production ? »
« Aucune idée, mec. J'ai juste continué à lui donner des coups de bâton jusqu'à ce qu'elle arrête de faire ce truc sur ma machine ».


Ce n'est pas ce que je pensais que le « Vibe Coding » serait

Lorsque j'ai entendu parler de « Vibe Coding » dans les cercles de programmation, j'ai pensé qu'il s'agissait de vibrer avec des collègues et des amis programmeurs pour réaliser des projets ensemble, juste pour le plaisir. Vous savez, la vraie collaboration humaine, le partage d'idées, la programmation en binôme tout en partageant une pizza et des boissons énergisantes à minuit.

Mais non. La définition actuelle du « Vibe Coding » est apparemment la suivante : « Abandonner son pouvoir intellectuel à une IA et espérer que tout se passe bien ». C'est la porte d'entrée vers l'enfer de la programmation. La prochaine chose que vous saurez, c'est que vous serez dans une réunion à essayer d'expliquer aux utilisateurs de X, pourquoi l'application continue d'envoyer les informations de la carte de crédit des utilisateurs à un canal Telegram aléatoire.

« Ce n'est pas un bug », direz-vous, la sueur coulant sur votre front, « c'est une vibration ».


Le tsunami de dette technique

Parlons de la dette technique. Le codage normal en crée déjà suffisamment et nous avons tous écrit ce hack de code « temporaire » qui est toujours en production cinq ans plus tard. Mais le « Vibe Coding », c'est comme si vous preniez une hypothèque à haut risque sur votre base de code et que vous mettiez immédiatement le feu à vos comptes.

Lorsque vous ne comprenez pas votre propre code, vous créez non seulement des dettes, mais aussi des dettes dont vous ne soupçonnez même pas l'existence jusqu'à ce qu'elles vous tombent dessus. C'est comme jouer au Jenga les yeux bandés, en état d'ébriété et avec de la vodka dans une main.

Titre : Une application supprime aléatoirement les données de l'utilisateur lorsque Mercury est en rétrograde
Description : Aucune idée de la raison pour laquelle cela se produit. Les ondes doivent être éteintes.
Priorité : Peut-être élevée ? Qui sait ?

La mort des compétences de débogage

Il y a une satisfaction particulière à déboguer correctement un problème complexe. Suivre la piste des miettes de pain, mettre en place le cas de reproduction parfait, réduire le problème étape par étape. C'est un peu comme si vous étiez un détective du code.

Avec le « Vibe Coding », cette compétence est remplacée par « coller l'erreur dans l'IA et prier ». Lorsque cela ne fonctionne pas, la solution consiste apparemment à « demander des changements aléatoires jusqu'à ce que le problème disparaisse ».

Il ne s'agit pas de débogage, mais d'exorcisme numérique. « LE POUVOIR DE L'IA VOUS ATTIRE ! » asperge le clavier d'eau bénite.


Le copier-coller des messages d'erreur

Lorsque je reçois des messages d'erreur, je les copie-colle sans commentaire, ce qui règle généralement le problème.

Oh là là. C'est comme si tu disais que tu allais donner toutes les erreurs et tous les bugs de ton application et que tu attendais en te disant « Cette fois-ci, ce sera réparé sans drame ». Parfois, ça marche ! Jusqu'à ce que ce ne soit pas le cas, et que vous ayez à faire face à un mal de tête pour résoudre ce problème à 3 heures du matin parce que vous n'avez jamais compris pourquoi cette erreur/bogue particulière s'est produite en premier lieu.

Laissez-moi vous dépeindre cette approche :

Le développeur : *collage d'un message d'erreur*
LLM : J'ai corrigé le problème en ajoutant un délai d'attente.
Développeur : *3 semaines plus tard* Pourquoi ma base de données se bloque-t-elle ?
LLM : Ajoutons un autre délai d'attente !
Développeur : *2 mois plus tard* Pourquoi ma base de données se bloque-t-elle ? *2 mois plus tard* Pourquoi tout mon système est-il un château de cartes construit sur des délais arbitraires ?
LLM : Avez-vous envisagé une carrière dans le management ?

L'illusion de la productivité

Bien sûr, vous pouvez construire quelque chose plus rapidement avec cette approche au début. Vous vous émerveillerez de la rapidité avec laquelle votre application prend forme, de la facilité avec laquelle les fonctionnalités semblent se matérialiser. Vous vous direz : « C'est génial, je suis 10 fois plus productif ! ».

Puis la réalité frappe. Le château de cartes s'effondre. Votre base de données est corrompue. Votre gestion des états est un cauchemar de dépendances circulaires. Votre CSS est plus une guerre des spécificités qu'un véritable stylisme. Et le pire, c'est que vous n'avez aucune idée de la façon de réparer tout cela parce que vous ne l'avez jamais compris.

C'est comme si vous prétendiez être un peintre productif parce que vous pouvez rapidement jeter des seaux de peinture au hasard sur une toile. Certes, vous avez couvert la toile rapidement, mais qu'avez-vous créé exactement ?


La fin de la propriété du code

Il y a quelque chose de profondément satisfaisant à regarder un morceau de code et à savoir que c'est vous qui l'avez écrit. Ce qui est encore mieux, c'est de revisiter un code que vous avez écrit il y a plusieurs mois et de vous dire : « Bon sang, le passé était comme ça bla bla bla ». (Ou, de manière plus réaliste : « À quoi le moi du passé pensait ? C'est terrible ! »).

Avec le « Vibe Coding », ce sentiment de propriété disparaît. Le code ne vous appartient pas, mais il s'agit d'un effort de collaboration entre vous (20 %) et une IA (80 %) qui n'a aucun intérêt dans la réussite du projet. Lorsque les choses tournent mal, il n'y a pas de fierté qui vous pousse à les réparer, juste de la confusion et de la frustration.

C'est comme si vous revendiquiez la paternité d'un livre alors que vous n'avez fait que donner de vagues instructions à une IA. « Dire que le chapitre 3 devrait comporter plus de dragons, je suppose », n'est pas la même chose que d'écrire le chapitre 3 à partir de rien, avec votre imagination et votre créativité.


La pente glissante

Ce n'est pas trop mal pour les projets de week-end jetables.

Mais les habitudes prises le week-end ne disparaissent pas comme par magie le lundi matin. Cette mentalité est contagieuse, et avant que vous ne vous en rendiez compte, votre code de production a l'air d'avoir été écrit par un LLM souffrant de TDAH.

Lorsque nous abandonnons la compréhension au profit de la commodité, nous ne sommes plus des ingénieurs, mais des ingénieurs prompts, ce qui est au codage ce que la lecture d'instructions au four à micro-ondes est à l'art culinaire.


La véritable alternative à l'ingénierie

Au lieu du « Vibe Coding », essayez ces concepts radicaux :

• Comprenez ce que votre code fait réellement
• Écrire des tests qui valident vos hypothèses
• Retravailler régulièrement votre code pour maintenir la complexité à un niveau raisonnable
• Documentez votre raisonnement, pas seulement votre code
• Utilisez l'IA pour amplifier vos tâches ennuyeuses (tâches répétitives), et non pour remplacer vos compétences réelles.

Ces principes ennuyeux ont permis de construire tous les logiciels fiables dont vous dépendez. Pas les vibrations. Pas d'exponentielles. Juste de l'ingénierie solide.

Conclusion

Alors oui, Andrej Karpathy, je vais m'en tenir à mes bonnes vieilles méthodes pour comprendre réellement ce que fait mon code, merci beaucoup. Je continuerai à utiliser les outils d'IA comme des assistants plutôt que comme des remplaçants de mon cerveau. Je continuerai à lire mes diffs comme s'il s'agissait d'une approche traditionnelle.

Parce que lorsque le code généré par l'IA se cassera inévitablement de manière spectaculaire (et il le fera), je préférerais être le développeur qui peut le réparer plutôt que celui qui dit « Je ne sais pas, mec, les vibrations me disaient d'utiliser 17 promesses imbriquées pour ce gestionnaire de clic de bouton ».

La véritable excellence en ingénierie vient de la compréhension et non de l'externalisation de votre compréhension pour des raisons de rapidité. Lorsque vous donnez la priorité aux « vibrations » plutôt qu'à la compréhension, vous n'êtes pas un développeur 10x mais vous êtes juste quelqu'un qui va créer 10x plus de problèmes pour la pauvre âme qui héritera de votre base de code.

Et oui, j'ai peut-être l'air d'un développeur vieux de la vieille qui crie sur les nuages. « À l'époque, nous avions l'habitude de coder des applications par nous-mêmes et NOUS AIMIONS ÇA ! » Mais certains principes ne changent pas simplement parce que la technologie évolue. Comprendre son code n'est pas facultatif, mais c'est la différence fondamentale entre un ingénieur et quelqu'un qui se contente de jouer les programmeurs déguisés.

Les vrais pros le savent : Utilisez l'IA comme un outil. Pas pour remplacer votre cerveau.

P.S. - Si votre réaction a ce discours n'est pas « C'EST VRAI, BIEN REÇU », c'est que vous êtes probablement vous-même un « vibe codeur ». Désolé, vous avez encore le temps de vous changer et d'APPRENDRE À CODER, ce n'est pas trop difficile.


Source : Why 'Vibe Coding' Makes Me Want to Throw Up

Why 'Vibe Coding' Makes Me Want to Throw Up by Kush Creates is licensed under Creative Commons Attribution 4.0 International

Et vous ?

Pensez-vous que ces déclarations sont crédibles ou pertinentes ?
Quel est votre avis sur le sujet ?

Voir aussi :

« L'IA Cursor m'a dit que je devais apprendre à coder au lieu de lui demander de générer du code », rapporte un programmeur. Quand l'IA remet elle-même en question la culture du « vibe coding »

Être développeur à l'ère de l'IA qui raisonne, par Mani Doraisamy

Les nouveaux développeurs juniors ne savent pas coder, par Namanyay

L'utilisation de code généré par l'IA fera de vous un mauvais programmeur, par Rudis Muiznieks

[RenarddeFeu]

Le déclin présent et à venir du métier de programmeur a des causes structurelles qui vont bien au-delà de l'avènement de l'IA.

[Cendyne]

"Vibe Coding" vs Réalité, par Cendyne

Il existe une tendance sur les médias sociaux où beaucoup répètent les mots d'Andrej Karpathy : « se laisser porter par les vibrations, embrasser les exponentielles, et oublier que le code existe. » Cette croyance - comme beaucoup de prises de position erronées de l'humanité - provient de la paresse, de l'inexpérience et d'une imagination illusoire. C'est ce qu'on appelle le « Vibe Coding ».

« Embrasser les exponentielles » semble provenir d'un drogué de la NFT.

Comme les adeptes de la NFT, il existe une bulle d'irréalité à laquelle ils s'accrochent pour justifier leur perception du monde.

La production de logiciels est désormais plus accessible, car de nouveaux outils permettent aux gens de décrire ce qu'ils veulent dans un langage naturel à un modèle de langage étendu (LLM). Cette idée fait son chemin car les agents LLM sont désormais accessibles à toute personne souhaitant s'abonner à des éditeurs tels que Cursor, GitHub, Windsurf et d'autres. Ces éditeurs disposent d'une option « agent » qui permet aux utilisateurs de demander quelque chose et, en réponse, des modifications sont apportées aux fichiers appropriés, plutôt qu'au seul fichier en cours d'examen. Au fil du temps, l'agent demandera d'exécuter des commandes pour effectuer des tests ou même d'exécuter des scripts qu'il a précédemment écrits dans le système de fichiers, comme vous le feriez si vous étiez en train de résoudre le problème.

En 2022, les gens ont pu copier du code dans ChatGPT et poser des questions ou demander des réécritures.

En 2023, les utilisateurs ont pu lui demander de réviser et d'éditer un fichier unique grâce à l'intégration d'un EDI tel que Copilot.

En 2024 et 2025, les utilisateurs ont pu lui demander de résoudre un problème spécifique dans le projet et lui demander de trouver les fichiers à éditer, de les éditer, puis de vérifier son propre travail et de corriger les erreurs qu'il a commises grâce au retour d'information sur les erreurs de linting et les tests unitaires.

Les agents LLM ayant autant de capacités, les gens peuvent déléguer l'idée d'affiner leurs idées imprécises à une implémentation précise élaborée par un LLM par le biais du « Vibe Coding ».

First - what is vibe coding?

A concise definition from @stuffyokodraws, and then an exploration of how technical vs. non-technical users approach these tools. pic.twitter.com/PDEqsjEhHN

— Justine Moore (@venturetwins) March 13, 2025

Si vous ouvrez un dossier vierge et lui demandez de mettre en place un projet initial, il peut faire beaucoup de choses à la fois. Sans règles, sans modèles à imiter et sans contraintes, il peut produire quelque chose qui vous semble plus adapté en quelques minutes que npx create-react-app ne pourrait jamais le faire.

Avec une simple instruction comme « Je veux créer un site web pour ma station de ski » et une dizaine de minutes à lui faire masser les erreurs qu'il a lui-même commises, c'est exactement ce que je peux obtenir.

Ce sont ces bonds en avant qui alimentent l'idée du « Vibe Coding ». Passer de rien à quelque chose de partageable et de personnel semble incroyable.

Ce moment m'a procuré une excitation que je n'avais pas ressentie depuis longtemps lorsque je codais. Cependant, cette excitation s'est rapidement dissipée à mesure que je m'éloignais de la toile blanche.

Les agents, en tant que concept, ne sont pas nouveaux. Google IO a inventé des mots à la mode comme « ère agentique » pour décrire ce concept. Il a été concrétisé par des technologies ouvertes comme AutoGPT, XAgent et, plus récemment, par Anthropic avec le Model Context Protocol (MCP).

Lorsque le modèle peut interagir avec autre chose qu'une simple personne qui transmet ses résultats dans différents domaines, il est autonome. S'il peut effectuer des recherches sur le web ou dans une base de code, il peut enrichir son propre contexte avec les informations dont il a besoin pour répondre à la demande actuelle. En outre, lorsqu'il peut produire des résultats et obtenir un retour d'information immédiat et automatique sur ces résultats, il peut affiner sa solution sans qu'une personne n'intervienne.

Certaines actions, comme l'exécution de commandes dans la console ou la suppression de fichiers, demandent le consentement de l'utilisateur avant d'être exécutées. Ce consentement peut être approuvé à l'avance grâce à un mode appelé « YOLO ».

Un mode « On ne vit qu'une seule fois » ? Vraiment ?

Vous pouvez constater cette autonomie par vous-même aujourd'hui dans Cursor.

Le concept d'agent a du mérite et peut aujourd'hui fournir des preuves de concept dans lesquelles des sociétés de capital-risque comme Y-Combinator investiront - des preuves de concept qui sont trash par des fondateurs non qualifiés espérant gagner la loterie tout en menant une vie de loisir.

I’ve cracked vibe coding, TrendFeed has almost hit its first 10k month, and Ai built the entire thing

Im just sitting here sipping coffee, coding with Ai + MCP

Also more time to shitpost on X haha pic.twitter.com/oaOFJZsuDl

— Sebastian Volkis (@sebastianvolkis) March 13, 2025

Le fondateur technique optimal pour un investisseur en capital-risque n'est pas l'ingénieur 10x. C'est quelqu'un qui fournira suffisamment de produits pour tester leur pertinence sur le marché et qui réussira ensuite à lever des fonds supplémentaires. L'exécution de sa vision et ses prouesses en matière de recrutement sont plus importantes que ses compétences techniques.

L'exécution des agents aujourd'hui est surestimée et ne répond pas aux besoins d'entreprises opérationnelles qui ont besoin d'experts pour développer et maintenir leurs capacités techniques au lieu de points d'échec uniques sur l'internet.

babe, come to bed

i can't, i'm vibe coding pic.twitter.com/AnszFVzRYL

— Ian Nuttall (@iannuttall) March 13, 2025

Ces modèles sont formés à partir d'un code moyen peu soigné, de mauvaises réponses sur Stack Overflow et de déchets qui aboutissent sur Quora. Malgré la puissance et la capacité de Claude 3.7 Sonnet dans des contextes restreints, lorsqu'il est confronté à une base de code, même petite, il commet constamment des erreurs stupides qu'aucun développeur normal ne répéterait et qu'il continue de répéter à chaque heure de son fonctionnement.

Détails spécifiques sur les erreurs (vous pouvez ignorer cette partie)

• Clone régulièrement des interfaces TypeScript au lieu d'exporter l'original et de l'importer.
  
• Réinvente sans cesse des composants avec la même structure sans chercher dans la base de code une copie existante de ce composant.
  
• Ecrit une logique serveur de confiance du côté client, en utilisant des appels RPC pour mettre à jour la base de données.
  
• Au fur et à mesure qu'une fonctionnalité se développe, elle donne la priorité au maintien des erreurs précédentes plutôt qu'à la réévaluation de sa conception, même lorsqu'on lui demande de le faire. Il faut dire que l'implémentation précédente est carrément inutilisable pour qu'elle remplace sa conception.
  
• Cursor dispose d'une sorte de « mode concis » qu'il active en cas de forte charge, où le modèle sera toujours évalué au prix normal mais se comportera de manière inutile. Ce mode omettra des détails, laissera tomber des conclusions importantes et corrompra le résultat produit.
  
• On ne peut pas lui faire confiance pour produire des tests unitaires avec une couverture décente.
  
• Il casse souvent le code du projet pour l'adapter à un test unitaire plutôt que de corriger le test unitaire lorsqu'on lui demande de le faire.
  
• Lorsqu'on lui demande de corriger des styles avec des détails précis, il modifiera entièrement le mauvais composant.
  
• Lorsqu'on lui indique précisément où se trouvent de nombreux composants dupliqués et qu'on lui demande de les remanier, il ne remanie que la première instance de ce composant dans le fichier au lieu de toutes les instances dans tous les fichiers.
  
• Lorsqu'on lui demande de remanier son code, il ne cherche pas les ruptures qu'il a causées, même lorsqu'on lui demande de le faire.
  
• Produit allègrement des fichiers de plus de 1000 lignes qui dépassent sa fenêtre contextuelle au fil du temps, même lorsqu'on lui demande de remanier son code dès le début.
  
• Efface régulièrement des gestionnaires de route entiers s'ils ne sont pas liés à la hiérarchie des fichiers.

Tels qu'ils sont conçus actuellement, ces modèles ne peuvent pas apprendre de nouvelles informations. Ils ne peuvent pas faire mieux que l'ensemble de données avec lequel ils ont été créés. Au lieu de cela, leur capacité est réalisée par l'efficacité avec laquelle ils peuvent traiter les jetons entrant dans leur fenêtre contextuelle.

Si vous demandez à Claude 3.7 Sonnet de développer un schéma d'exécution pour valider un langage spécifique à un domaine et que vous lui demandez ensuite de remanier le fichier - parce qu'il est trop volumineux pour que sa fenêtre de contexte puisse continuer - il se dégradera et produira un non-sens incohérent avant d'avoir terminé son travail.

Il n'a pas tapé « I've » correctement et a réuni les mots « schema » et « refactored » en un seul.

my saas was built with Cursor, zero hand written code

AI is no longer just an assistant, it’s also the builder

Now, you can continue to whine about it or start building.

P.S. Yes, people pay for it

— leo (@leojr94_) March 15, 2025

Vous ne pouvez pas demander à ces outils aujourd'hui de développer une application React performante. Vous ne pouvez pas demander à ces outils de mettre en œuvre un flux d'enregistrement d'utilisateur sécurisé. Ils choisiront d'exécuter des fonctions telles que l'enregistrement de l'utilisateur sur le client plutôt que sur le serveur.

D'autres l'apprennent d'une manière plus dure.

guys, i'm under attack

ever since I started to share how I built my SaaS using Cursor

random thing are happening, maxed out usage on api keys, people bypassing the subscription, creating random shit on db

as you know, I'm not technical so this is taking me longer that usual to…

— leo (@leojr94_) March 17, 2025

Sans l'intervention d'un expert, le mieux que ces outils puissent faire aujourd'hui est de produire une maquette quelque peu fonctionnelle, où chaque changement futur au-delà risque de détruire la fonctionnalité existante.

Je ne peux pas - et je ne ferais pas - confiance à un membre de l'équipe qui code par vibration dans une application de production. La négligence constante que j'observe lors du « Vibe Coding » est atroce et inacceptable pour une clientèle de toute taille.

Aucun modèle disponible ne fait preuve d'une attention constante et nécessaire aux détails dans un environnement de production. Ils ne sont pas encore équipés ou conçus pour transformer des informations impliquant de multiples contextes inhérents à la production d'un produit numérique.

Ces outils sont optimisés pour produire des solutions qui tiennent dans un seul écran de démarquage et on leur demande maintenant de faire bien plus que ce pour quoi ils ont été formés. Au fur et à mesure que la fenêtre de contexte déborde et que le modèle se dégrade, il ne parvient même pas à formater correctement les appels MCP et, lorsqu'il atteint ce point de non-retour, il produit un journal qui donne l'impression d'avoir été torturé. Comme un robot qui perd un membre, il essaiera encore et encore de marcher pour tomber jusqu'à ce que l'éditeur mette la conversation en pause pour économiser des ressources.

Contourner le problème

Un "Twitch plays Pokémon" moderne se déroule en ce moment même : Claude joue à Pokémon. Il atténue le problème de la fenêtre contextuelle en commençant un nouveau contexte avec des informations fournies par son incarnation précédente sous la forme de nombreux fichiers Markdown, qu'il peut ensuite lire comme s'ils étaient nouveaux et rechercher via MCP au cours de sa lecture.

So, what makes this possible? Claude was given a knowledge base to store notes, vision to see the screen, and function calls which allow it to simulate button presses and navigate the game.

Together, they allow Claude to sustain gameplay with tens of thousands of interactions. pic.twitter.com/uGXp63EcYY

— Anthropic (@AnthropicAI) February 25, 2025

Malgré cela, il peut faire de mauvaises suppositions et passer 43 heures à s'évanouir intentionnellement, encore et encore, au Mont Moon (un itinéraire dans le jeu entre les lieux de l'histoire), sans faire de progrès réels pour atteindre son prochain objectif parce que, le temps de se remettre en question, sa fenêtre de contexte n'est plus en état de continuer.

Il s'est échappé et a progressé, mais seulement après que l'instance critique du modèle a suggéré que son hypothèse était incorrecte.

Après un nettoyage du contexte, qui prend environ cinq minutes, le modèle commet les mêmes erreurs que son incarnation précédente. Les notes qu'il a écrites ne sont pas interprétées de manière pertinente dans le contexte, et je constate que la même chose se produit avec les règles de Cursor que j'écris.

L'augmentation de la longueur de la fenêtre contextuelle améliorera certaines expériences immédiates, mais il s'agit d'un problème d'échelle qui nécessite une solution différente pour que les agents soient plus efficaces et, peut-être, pour que le « Vibe Coding » se rapproche de la réalité.

Un bullet journal formalisé sur MCP aiderait-il un modèle à être plus complet et à fournir des résultats plus fiables ?

Tant que le modèle le vérifie correctement avant de conclure que son travail est terminé !

Un bullet journal peut être l'un des nombreux outils qui améliorent la fiabilité des modèles dont nous disposons aujourd'hui.

Le problème suivant est que ces modèles ne peuvent pas ingérer des informations provenant de plusieurs sources simultanées en temps réel. Dans un terminal, nous pouvons exécuter le serveur et dans un autre des tests de bout en bout. Ces deux terminaux ont été créés à la demande de l'agent. Il ignore ou n'est pas alimenté par la trace de pile enregistrée par le serveur dans le premier terminal alors qu'il observe la sortie des tests de bout en bout qui échouent et réessayent, échouent et réessayent.

Pour que les agents aient l'impact promis par le battage médiatique, les LLM ont besoin d'un mécanisme robuste pour imiter le développement de la mémoire à court et à long terme sans intégrer finement les mémoires dans le modèle.

En outre, pour que les agents puissent contribuer à une équipe, il doit y avoir un moyen de développer des mémoires à long terme liées à l'organisation et à ses produits qui fusionnent et se réconcilient avec les mémoires personnelles de chaque membre de l'équipe.

Enfin, ces mémoires doivent être portables. Au fur et à mesure que les modèles s'améliorent et sont intégrés dans nos outils, les mémoires spécifiques à un domaine doivent pouvoir être utilisées par la prochaine génération de grands modèles de langage.

Conclusion

Le "Vibe Coding" peut vous permettre d'obtenir un concept fonctionnel à 80 %. Mais pour produire quelque chose de fiable, de sûr et qui vaille la peine de dépenser de l'argent, vous aurez besoin d'humains expérimentés pour faire le travail difficile qui n'est pas possible avec les modèles d'aujourd'hui.

Les agents démontrent suffisamment de capacités pour que les PDG influents de LinkedIn répandent avec confiance l'irréalité selon laquelle nous pouvons remplacer les emplois par l'« IA agentique ».

Les agents permettent effectivement à des personnes qualifiées de créer plus indépendamment qu'elles ne l'ont jamais fait. Pour l'instant, ils ne remplaceront pas ceux qui peuvent résoudre les problèmes difficiles que seules l'expérience et l'intuition peuvent identifier. Comme d'autres solutions « no-code », les agents donnent aux personnes moins qualifiées plus de capacités qu'elles n'en avaient la veille. Tant qu'ils n'auront pas développé leurs propres compétences, les « Vibe Coders » ne seront pas en mesure de produire des logiciels de qualité dans ce monde, quelle que soit l'exponentialité de l'agent par rapport à leurs propres compétences inférieures.

Gardez un œil sur la façon dont les agents LLM se développent et s'améliorent. Pour l'instant, ils méritent d'être évalués et discutés, mais ils ne sont pas prêts à ce que nous leur déléguions la tâche précise de créer des logiciels fiables, sécurisés et évolutifs qui alimentent notre société. Le « Vibe Coding » ne créera pas le "next big thing" en 2025.


Source : "Vibe Coding" vs Reality

Et vous ?

Pensez-vous que cette analyse est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Pourquoi le « Vibe Coding » me donne envie de vomir, par Kush Creates

Être développeur à l'ère de l'IA qui raisonne par Mani Doraisamy

L'utilisation de code généré par l'IA fera de vous un mauvais programmeur par Rudis Muiznieks

Au-delà du battage médiatique : Mes réflexions honnêtes sur l'IA générative, par Mensur Durakovic