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

[Michka1111]

RdEX : Retour d'EXpérienceS
"Coder AVEC" : Ce n'est ni l'IA qui écrit mon code, ni moi qui recopie son code. J'ai essayé, ça n'a pas marché.
Au début, J'ai prompté la description de l'appli que je voulais faire, il n'en est pas ressorti grand chose, si ce n'est qu'il me fallait apprendre à lui parler et à lire entre les lignes de ses réponses, prose ou code. Une chose est sure : c'est plaisant.
J'ai vite compris qu'il fallait lui préciser le contexte, en particulier évaluer sa connaissance des mots-clés des concepts.
Cela me rafraichissait la mémoire, et alimentait la conversation.
J'ai compris ensuite que "poser le contexte" est synonyme de "présenter les conversants", Je lui précise donc à qui je veux m'adresser, avec l'expert de quel domaine j'engage la conversation.
Ensuite, j'explore ses connaissances du domaine.
C'est plus récemment que j'ai compris qu'il faut lui préciser ce que j'attends des réponses : certains LLM commentent systématiquement, à d'autres il faut le leur demander.
Ceci évolue d'ailleurs rapidement, au fil des apprentissages mutuels "automatiques" (les siens) et "manuels" (les miens), des versions, d'avec ou sans Internet, au fil des algorithmes de réponses, de mise en forme, de conversation.
Ollama.exe, par exemple, est mis à jour régulièrement, et je vois les différences en surveillant la consommation mémoire du gestionnaire de tâches toujours au premier plan.
Comme la conversation est plaisante, c'est productif, toutes les réponses m'apportent quelque chose.
J'ai été surpris des réponses en français, J'ai vite compris qu'il traduisait ma question et sa réponse grâce à quelques "coquilles" qui m'ont fait mélanger des mots anglais à mes phrases en français pour être sûr qu'il comprenne certains mots-clés. C'est toujours d'actualité.
Bref, le mot d'ordre est "vivre avec son temps" mais avec mes acquis.
C'est donc TRÈS productif.
Notamment si c'est un langage que je ne connais pas ou pas bien.
Je suis resté baba en lisant son code de génération d'un fichier "play-list" de vidéos pour VLC à partir du résultat d'une requête SQL en LibreOffice Basic sur la base LibreOffice Base que je venais de créer.
Mais je travaille AVEC lui. Ni moi pour lui, ni lui pour moi : il m'assiste.
C'est bien du "codage assisté". Ni plus, ni moins.
La syntaxe est TOUJOURS correcte, LibreOffice Basic, bash, Python, ffmpeg pour ce que je lui ai demandé, et il y a ajouté java spontanément avec l'API objet OpenOffice / LibreOffice.
L’algorithmique, par contre, est presque toujours incorrecte.
Parce qu'il fait du "bachotage", si vous voyez ce que je veux dire…
Et comme chez moi c'est l'inverse, je trouve en lui mon complément de production idéal.
Les résultats ?
- Appli LOBase qui requête un schéma étoile des matches de la NFL et qui produit des playlists pour VLC des vidéos sélectionnées.

- script bash / ffmpeg.exe qui convertit mes films en hevc 600p, me faisant gagner ~2.5x en volume stocké (239 vidéos passés de 307Go à 135Go). Soit de 1,2Go / film à 0.56Go / film en moyenne.
Et il a lui-même paramétré ffmpeg pour faire ça !
$FFMPEG_PATH -i "$(wslpath -w "$file")" -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2,scale=trunc((iw*${TARGET_HEIGTH}/ih)/2)*2:${TARGET_HEIGTH}" -c:v libx265 -crf ${FFMPEG_CRF} -preset ${FFMPEG_PRESET} -c:a copy "$(wslpath -w "$output_file")"
À part certaines variables, je n'ai rien changé, et j'ai gardé les valeurs des variables FFMPEG.
Reste un bug dans bash pour boucler sur une liste regex/ls de fichiers en entrée qui ne traite qu'un film lorsque le script appelle cmd.exe /C ffmpeg.exe. Mais ça me va bien comme ça pour l'instant.

- extension personnalisée pour Sphinx/ReStructuredText en Python (en cours) avec Workspace VSCode et TDD.

Et j'utilise Bing Copilot, VSCode + Chat( Github Copilot) + Continue( Ollama(Llama3.2, DeepSeek-coder-v2(16B) en local)). Si j'ai Internet, c'est VSCode+Chat( Github Copilot), si j'ai pas Internet, c'est VSCode+Continue( Deepseek-coder-v2) en Chat ou en Edit sur Ollama en local, donc avec un LLM jusqu'à 16B avec 20Go RAM Ryzen 5 2500U Lenovo Ideapad 330.

Il est clair que le retour arrière est impensable.
;-*

[Michka1111]

RdEX : Retour d'EXpérienceS
Et il a lui-même paramétré ffmpeg pour faire ça !
;-*

NB. Ce fut affiné tout au long des conversations, après des questions générales pour choisir le logiciel d'encodage (ffmpeg finalement), puis les paramètres structurants libx265 pour gagner en volume de sortie sans trop perdre en qualité (crf et préset), puis reporter et corriger les erreurs rencontrées avec certains formats d'images qui ont abouti aux calculs avec les troncatures, juste pour ffmpeg (hors script bash).

Je n'ai pas fait d'essai avec d'autres valeurs pour la compression (crf et préset), mais je conserve les fichiers d'entrées.

J'ai également un historique des trois conversations avec trois LLM différents sur ce sujet, ou plutôt ce qui est devenu ce sujet, sous forme de Mind Map Freeplane.

[Patrick Ruiz]

Le vibe coding est la pire idée en 2025, d’après David Farley
Qui jette un regard sur cette tendance à accepter du code généré par l’IA, souvent sans le comprendre

Avec l'essor d'outils d'IA tels que ChatGPT, il est désormais possible de décrire un programme en langage naturel (français par exemple) et de demander au modèle d'IA de le traduire en code fonctionnel, souvent sans comprendre comment le code fonctionne. Andrej Karpathy, ancien chercheur d'OpenAI, a récemment donné un nom à cette pratique, le « vibe coding », qui gagne du terrain dans les milieux technologiques. Google a même déclaré générer 25 % de son code par IA. David Farley pour sa part est d’avis que c’est la pire idée en 2025.

« Le 2 février dernier, Andre Karpathy, fondateur d'OpenAI et ancien responsable de l'IA chez Tesla, a introduit un nouveau terme pour désigner un style de programmation assisté par l'IA. Il l'a appelé « vibe coding ». Il s'agissait d'un tweet de mille caractères, et il semble que peu de gens aient lu la seconde moitié. Andre décrit ce qu'il entend par « vibe coding » dans les 300 premiers caractères environ.

Le reste décrit certaines des conséquences de cette approche naïve et simpliste de la programmation. Je ne connais pas André personnellement, je ne peux donc pas dire ce qu'il avait en tête lorsqu'il a publié ce tweet, mais cela me semble être du sarcasme. « Ce n'est pas trop mal pour des projets éphémères du week-end, mais ce n'est pas vraiment du codage », dit-il vers la fin du tweet », souligne-t-il.

Le cas René Turcios suggère pourtant que tout le monde peut coder ce qu’il souhaite grâce à la disponibilité de l’intelligence artificielle

Lors de son tout premier hackathon, il a conçu un programme qui transformait des chansons en version lo-fi simplement en décrivant son concept à une IA, sans écrire la moindre ligne de code. Depuis, il reproduit cette approche en enchaînant les hackathons et en présentant des projets entièrement générés par l’IA. Au fil des ans, René Turcios a remporté divers prix : de l'argent, des crédits logiciels et une véritable aura dans la communauté technologique.

« Rene est le premier véritable vibe codeur », a déclaré RJ Moscardon, un hacker qui a vu René Turcios remporter la deuxième place lors de son tout premier hackathon au manoir AGI House à Hillsborough. « Tous les ingénieurs titulaires de diplômes prestigieux se sont d'abord moqués de lui. Mais maintenant, ils font tous exactement la même chose ». Satya Nadella, PDG de Microsoft, a déclaré que 30 % du code de l'entreprise est maintenant généré par l'IA.

Au lieu de coder frénétiquement jusqu'à la date limite, il a terminé ses projets des heures à l'avance en laissant l'IA faire le travail technique à sa place. « Je n'ai pas écrit une seule ligne de code », a-t-il déclaré à propos de son premier hackathon. Lorsque les organisateurs ont annoncé que Turcios avait remporté la deuxième place, il a poussé un cri de joie : « j'ai réalisé que je pouvais rivaliser avec des gens qui ont des diplômes et des emplois prestigieux ».

Rene Turcios est désormais connu pour sa capacité à créer rapidement n'importe quoi. Les entreprises font appel à lui pour lui confier des projets qui prendraient des semaines à des équipes d'ingénieurs logiciels, et il les réalise en quelques heures. Il a même commencé à animer des ateliers pour enseigner à des groupes non techniques et à des ingénieurs logiciels expérimentés comment tirer le meilleur parti des assistants d'IA dans les tâches de codage.

« Tout le monde peut construire ce qu'il veut », affirme Rene Turcios. Il a récemment réduit son programme prolifique de hackathon pour se concentrer sur la création de sa propre startup d'agents d'IA. Il n'a pas embauché d'ingénieurs ; il est le seul fondateur et l'IA se charge de tout le codage. Rene Turcios utilise l'environnement de développement en ligne Replit. Replit permet de créer des logiciels à l'aide l'IA grâce à une plateforme appelée Agent.

Des retours d’autres intervenants de la filière permettent d’effectuer une immersion plus profonde dans les réalités qui entourent l’utilisation de ces outils

Dette technique et illusion de productivité sont des facteurs que le développeur doit intégrer de façon plus aigüe lorsqu’il opte pour l’utilisation de l’intelligence artificielle aux fins de codage.

En gros, l’intervention de personnes avec un bagage conséquent en développement informatique demeure nécessaire comme le souligne Cendyne sur developpez.com :

« 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. »

Et vous ?

Cette tendance pourrait-elle mener à une perte de savoir-faire en programmation, comme certaines technologies disparues dans le passé ?

Les écoles et universités doivent-elles adapter leur enseignement pour intégrer cette nouvelle réalité ou au contraire insister sur les bases traditionnelles de la programmation ?

À terme, pourrait-on imaginer un monde où les programmeurs ne codent presque plus, mais supervisent uniquement des IA qui génèrent et corrigent le code ?

Si l’IA prend en charge l’écriture du code, quelles compétences deviendront essentielles pour les développeurs de demain ?

Le développement logiciel pourrait-il devenir une activité davantage conceptuelle, centrée sur la conception et la validation plutôt que sur l’implémentation ?

Peut-on comparer cette évolution à l’histoire d’autres métiers automatisés, comme les calculs comptables ou le design assisté par ordinateur ?

Quels sont les dangers d’un code adopté sur la base de son apparence fonctionnelle plutôt que de sa compréhension ?

Comment garantir la sécurité et la robustesse d’un code généré par IA si les développeurs ne comprennent pas entièrement son fonctionnement ?

Faut-il imposer des normes ou des certifications pour encadrer l’utilisation de l’IA dans le développement logiciel ?

Voir aussi :

L'IA peut écrire du code mais ne parvient pas à le comprendre, selon une étude d'OpenAI. Testés sur des tâches réelles de programmation, les modèles les plus avancés n'ont pu résoudre qu'un quart des défis

« Jusqu'à 90 % de mon code est désormais généré par l'IA », d'après Adam Gospodarczyk, qui ravive le débat sur l'impact de l'IA et son aptitude à remplacer les humains dans la filière du génie logiciel

Le « premier ingénieur logiciel IA » loin d'être à la hauteur : Devin a un taux de réussite de 15 %. Des chercheurs notent que l'IA prend des jours pour faire des tâches simples qui auraient pris des heures

[Souil002]

Je pense surtout que tout ceux qui se reposent uniquement sur le "vibe-coding" pour créer leur application n'ont aucune vision de l'avenir de leur produit et cherchent surtout à faire un produit qui fonctionne le plus rapidement possible pour mettre en place leur idée.

Certains iront plus loin et si l'idée fonctionne ils essaieront de faire un produit plus fiable et d'autre verront juste leur produit couler quand les utilisateurs se rendront compte qu'il n'évolue pas ou quand les créateurs eux-mêmes verront que ce n'est pas maintenable.

Le vide-coding pour faire des petites applications qui simplifient le travail ou la "vie" en général, ça reste intéressant car ça fait gagner du temps tout en étant des petites bases de code maintenable même si la qualité du code n'est pas là.

[Alex]

Le vibe coding gagne du terrain : un tiers des développeurs seniors affirment que plus de la moitié du code qu'ils livrent est généré par l'IA, soit près de deux fois et demie du taux des développeurs juniors.

L'enquête menée en juillet 2025 par Fastly auprès de 791 développeurs a révélé une différence notable dans la quantité de code généré par l'IA qui est mis en production. Environ un tiers des développeurs seniors (plus de 10 ans d'expérience) déclarent que plus de la moitié du code qu'ils livrent est généré par l'IA, soit près de deux fois et demie le taux déclaré par les développeurs juniors (0 à 2 ans d'expérience), qui est de 13 %.

Pour de nombreuses personnes, le codage est synonyme de précision. Il s'agit de dire à un ordinateur ce qu'il doit faire et de faire en sorte que l'ordinateur exécute ces actions de manière exacte, précise et répétée. Avec l'essor d'outils d'IA tels que ChatGPT, il est désormais possible de décrire un programme en langage naturel (français par exemple) et de demander au modèle d'IA de le traduire en code fonctionnel sans jamais comprendre comment le code fonctionne.

Andrej Karpathy, ancien chercheur d'OpenAI, a récemment donné un nom à cette pratique, le « vibe coding », qui gagne du terrain dans les milieux technologiques (Google a même déclaré générer 25 % de son code par IA). Selon cette approche, le développeur ne révise ni ne modifie le code, mais utilise uniquement des outils et les résultats d'exécution pour l'évaluer et demande au LLM d'apporter des améliorations. Contrairement au codage assisté par l'IA ou à la programmation en binôme traditionnels, le développeur humain évite d'examiner le code, accepte les compléments suggérés par l'IA sans révision humaine et se concentre davantage sur l'expérimentation itérative que sur l'exactitude ou la structure du code.

Cette évolution suggère-t-elle un avenir où le développement logiciel reposera davantage sur des intuitions et du « vibe coding » que sur une connaissance technique rigoureuse ? L'enquête menée en juillet 2025 par Fastly auprès de 791 développeurs a révélé une différence notable dans la quantité de code généré par l'IA qui est mis en production. Environ un tiers des développeurs seniors (plus de 10 ans d'expérience) déclarent que plus de la moitié du code qu'ils livrent est généré par l'IA, soit près de deux fois et demie le taux déclaré par les développeurs juniors (0 à 2 ans d'expérience), qui est de 13 %.

« L'IA teste le code et détecte les erreurs beaucoup plus rapidement qu'un humain, puis les corrige de manière transparente. Cela s'est produit à de nombreuses reprises », a déclaré un développeur senior. Un répondant junior a souligné les compromis : « C'est toujours difficile lorsque l'IA présume de ce que je fais et que ce n'est pas le cas, car je dois alors revenir en arrière et refaire le travail moi-même. »

Les développeurs seniors étaient également plus susceptibles de déclarer qu'ils consacraient du temps à corriger le code généré par l'IA. Un peu moins de 30 % des seniors ont déclaré modifier suffisamment les résultats de l'IA pour compenser la plupart des gains de temps, contre 17 % des juniors. Malgré cela, 59 % des seniors affirment que les outils d'IA les aident à livrer plus rapidement dans l'ensemble, contre 49 % des juniors.

Les développeurs seniors sont plus optimistes quant au gain de temps apporté par l'IA

Un peu plus de 50 % des développeurs juniors déclarent que l'IA les rend modérément plus rapides. En revanche, seuls 39 % des développeurs seniors partagent cet avis. Mais les développeurs seniors sont plus susceptibles de signaler des gains de vitesse significatifs : 26 % déclarent que l'IA les rend beaucoup plus rapides, soit le double des 13 % de développeurs juniors qui sont d'accord.

L'une des raisons de cet écart peut être que les développeurs seniors sont tout simplement mieux équipés pour détecter et corriger les erreurs de l'IA. Ils ont l'expérience nécessaire pour reconnaître quand un code « semble correct » mais ne l'est pas. Cela leur permet d'utiliser les outils d'IA avec plus de confiance et d'efficacité, même pour des codes à haut risque ou critiques pour l'entreprise. En revanche, les développeurs juniors peuvent ne pas avoir pleinement confiance en leur capacité à détecter les erreurs, ce qui peut les rendre plus prudents quant à l'utilisation de l'IA, ou plus enclins à éviter de l'utiliser en production.

Cela correspond à la quantité de code généré par l'IA qui est réellement utilisé en production. Parmi les développeurs juniors, seuls 13 % déclarent que plus de la moitié du code qu'ils livrent est généré par l'IA. En revanche, 32 % des développeurs seniors affirment la même chose, ce qui suggère que les ingénieurs plus expérimentés non seulement utilisent l'IA de manière plus intensive, mais lui font également davantage confiance dans les environnements de production. Cela est surprenant compte tenu des préoccupations croissantes concernant le « vibe coding », qui introduit des vulnérabilités dans les applications.

Perception vs réalité

Près d'un développeur sur trois (28 %) déclare devoir fréquemment corriger ou modifier le code généré par l'IA, ce qui annule la plupart des gains de temps réalisés. Seuls 14 % déclarent rarement avoir besoin d'apporter des modifications. Et pourtant, plus de la moitié des développeurs continuent de se sentir plus rapides avec des outils d'IA tels que Copilot, Gemini ou Claude. L'enquête de Fastly n'est pas la seule à remettre en question les gains de productivité liés à l'IA. Une récente étude randomisée contrôlée (ERC) menée auprès de développeurs open source expérimentés a révélé un résultat encore plus frappant : lorsque les développeurs utilisaient des outils d'IA, ils mettaient 19 % plus de temps à accomplir leurs tâches.

Ce décalage peut s'expliquer par des raisons psychologiques. Le codage par IA semble souvent fluide : le code s'auto-complète en quelques frappes. Cela donne une impression de dynamisme, mais les gains de vitesse initiaux sont souvent suivis de cycles d'édition, de test et de retouche qui annulent tout gain. Ce schéma se retrouve à la fois dans les conversations que nous avons eues avec les développeurs de Fastly et dans de nombreux commentaires que nous avons reçus dans le cadre de notre enquête.

Un répondant l'a formulé ainsi : « Un outil de codage IA comme GitHub Copilot facilite grandement mon travail en suggérant des extraits de code et même des fonctions entières. Cependant, il a un jour généré un algorithme complexe qui semblait correct mais contenait un bug subtil, ce qui m'a obligé à passer plusieurs heures à le déboguer. » Un autre a fait remarquer : « L'outil d'IA permet de gagner du temps en utilisant du code standard, mais il nécessite également des corrections manuelles pour remédier aux inefficacités, ce qui freine la productivité. »

Pourtant, l'IA semble toujours améliorer la satisfaction professionnelle des développeurs. Près de 80 % des développeurs affirment que les outils d'IA rendent le codage plus agréable. Pour certains, il s'agit d'éviter les tâches fastidieuses. Pour d'autres, c'est peut-être la montée de dopamine provoquée par le code à la demande. « Cela m'aide à accomplir une tâche dans laquelle je suis bloqué. Cela me permet de trouver les réponses nécessaires pour terminer la tâche », explique l'un des participants à l'enquête.

Le plaisir n'est pas synonyme d'efficacité, mais dans une profession confrontée à l'épuisement professionnel et aux retards, ce regain de moral peut tout de même avoir son importance.

Le coût caché du codage par IA

L'enquête de Fastly a également exploré la sensibilisation des développeurs au codage vert, c'est-à-dire la pratique consistant à écrire des logiciels économes en énergie, et le coût énergétique des outils de codage IA. La pratique du codage vert augmente fortement avec l'expérience. Un peu plus de 56 % des développeurs juniors déclarent tenir compte de la consommation d'énergie dans leur travail, tandis que près de 80 % des ingénieurs de niveau intermédiaire et senior en tiennent compte lors du codage.

Les développeurs sont très conscients du coût environnemental des outils d'IA : environ deux tiers des développeurs, tous niveaux d'expérience confondus, déclarent savoir que ces outils peuvent avoir une empreinte carbone importante. Seule une petite minorité (moins de 8 %, même parmi les plus juniors) n'en avait absolument pas conscience. Dans l'ensemble, les données suggèrent que la durabilité est de plus en plus ancrée dans la culture des développeurs.

Cependant, ces conclusions ne sont pas partagées par tous les développeurs. Pour David Farley, le vibe coding est la pire idée en 2025. Pour Cendyne, 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. Pour Kush Creates, le « Vibe Coding » lui donne envie de vomir. Il qualifie notamment le vibe coding, de "chemin le plus rapide vers la catastrophe technique".

Source : Fastly

Et vous ?

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

Voir aussi :

Plus de la moitié des développeurs pensent que l'IA code mieux que les humains et 78 % d'entre eux s'appuient régulièrement sur l'IA, selon une enquête de Clutch

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

L'IA aurait radicalement transformé le codage au point de remplacer bientôt tous les développeurs ? Il n'y a pas de "Vibe Engineering", par Sergey Tselovalnikov

[selmanjo]

Ce fut une expérience dévastatrice pour mes 3 neurones me restant. Ça bousille le cerveau pour les gens pure en abstraction.

[selmanjo]

Je ne recommande pas pour/sur un projet sérieux.