Après deux ans de « vibecoding », j’ai recommencé à écrire du code à la main

• En utilisant des outils de codage par IA pour leur confier des tâches de plus en plus importantes, l’auteur a d’abord été impressionné, avant de constater un manque de cohérence et de solidité structurelle dans les résultats
• Même avec des spécifications détaillées, les agents IA ne parviennent pas à maintenir le contexte sur le long terme ni à faire évoluer la conception, si bien que l’ensemble du codebase finit par devenir un assemblage de fragments hétérogènes
• Les morceaux de code peuvent sembler complets pris isolément, mais à l’échelle globale apparaissent un désordre structurel (sloppy) et un effondrement du contexte
• Au terme de cette expérience, l’auteur a estimé que du code produit par l’IA ne permettait pas de garantir la confiance des utilisateurs ni la protection des données, et est revenu à une approche où il écrit lui-même le code
• Le codage avec l’IA reste utile, mais son usage demande de la prudence car il peut entraîner de la dette technique et une perte de contrôle du développeur

---

Enthousiasme initial pour le codage par IA et prise de conscience de ses limites

• La plupart des utilisateurs commencent le codage avec l’IA sur des tâches simples, puis lui confient progressivement des problèmes plus complexes, en s’émerveillant de ses performances
  • Mais passé un certain seuil, les erreurs et les incohérences de l’IA apparaissent, créant un décalage entre attentes et réalité
• Quand le résultat n’est pas satisfaisant, les utilisateurs ont tendance à en attribuer la cause à leurs prompts et essaient de rédiger des spécifications plus précises
  • Ils utilisent des outils comme Obsidian pour écrire des documents de spécification détaillés, mais l’IA n’arrive pas à les faire évoluer sur la durée

L’échec de l’approche fondée sur les spécifications

• Dans le développement réel, les documents de conception sont des documents vivants, qui évoluent en permanence au fil de la découverte et de l’implémentation
  • Or, les agents IA restent figés sur la spécification initiale et ne peuvent ni l’adapter avec souplesse ni la réinterpréter
• Lorsqu’ils manipulent des structures complexes, les agents ont tendance à perdre le contexte global du problème ou à forcer la progression coûte que coûte
  • En conséquence, même si le code semble complet en apparence, il manque de cohérence interne et d’intégrité structurelle

Dégradation de la qualité du code et limites du « vibecoding »

• Le code écrit par l’IA peut paraître excellent par endroits, tout en formant au final un assemblage dénué de sens
  • Après avoir passé en revue l’ensemble du codebase, l’auteur y a découvert une forme de « pure pagaille (slop) »
• L’IA reste fidèle au prompt et à sa propre cohérence locale, mais ne prend pas en compte l’harmonie du système dans son ensemble ni la cohérence des patterns voisins
  • C’est un phénomène comparable à une forme de « vibewriting » où certains paragraphes d’un roman sont excellents, mais où le chapitre dans son ensemble est raté

Retour à un développement centré sur l’humain

• L’auteur a jugé qu’il ne pouvait pas déployer en production du code généré par l’IA ni l’utiliser pour protéger les données des utilisateurs
  • Avec la décision de « ne pas mentir aux utilisateurs avec ce code », il est revenu à l’écriture directe du code
• En codant lui-même, il a constaté une amélioration de la vitesse, de la précision, de la créativité et de la productivité
  • Évalué non pas sur la simple vitesse de génération de code, mais sur l’efficacité globale du développement, l’avantage humain se confirme

Usage continu de l’IA pour coder, mais avec vigilance

• L’auteur continue malgré tout à utiliser les LLM de façon limitée (environ 40 %) pour certaines tâches
  • Ils sont utiles pour les tâches répétitives ou la génération de code simple, mais la dette technique et la baisse de compréhension du code s’accumulent
• À long terme, il existe un risque que le développeur perde son modèle mental du codebase et devienne incapable de résoudre des problèmes sans l’IA
  • En déplacement (train, avion, etc.), cette dépendance à l’IA peut même mener à une productivité tombant à 0 %
• D’autres développeurs soulignent aussi que l’idée selon laquelle « il suffirait de bien écrire les spécifications » reproduit le modèle waterfall, alors que le développement réel repose nécessairement sur l’exploration improvisée et l’interaction

Conclusion

• Le codage par IA reste un outil puissant, mais il manque encore de capacité à préserver le contexte global du système et sa cohérence structurelle
• L’intuition du développeur humain et sa capacité d’ajustement improvisé restent essentielles,
  et l’IA doit être utilisée comme un moyen d’assistance, dans un cadre soigneusement maîtrisé

[alfenmage]

Le concept de vibe coding n’a même pas encore un an d’existence, alors c’est quoi cette pose à la sauce SNS, sérieux mdr

[jjw9512151]

Il faut en effet investir des efforts dans le peaufinage des spécifications... Si on élabore et affine les spécifications vraiment selon les méthodes formelles apprises en génie logiciel, puis qu’on les met à jour en travaillant avec une gestion de la traçabilité, ça fonctionne bien.

En menant des projets, je fais toujours évoluer les modèles de cahier des charges ainsi que les versions des prompts, mais dernièrement je me suis dit qu’il était peut-être temps d’étudier le génie logiciel de façon un peu plus approfondie.

[dopeflamingo]

L’auteur continue d’utiliser les LLM de manière limitée pour certaines tâches (environ 40 %)

---

À en juger par ce qui est écrit ci-dessus, il semble que l’auteur ne défende pas non plus l’idée d’abandonner complètement l’IA.

[zkj9404]

On dirait qu’il faut continuer à réfléchir à la meilleure manière de bien l’utiliser. Je pense qu’abandonner l’IA pour développer, c’est prendre peu à peu du retard.

L’auteur de cet article utilisait déjà de bonnes méthodes, mais malgré cela, je pense qu’il faut encore réfléchir à la façon de mieux exploiter l’IA.

(Il y a simplement encore beaucoup d’essais et d’erreurs...)

[goodnvin]

Mettez à jour les spécifications.

[cosine20]

Oui, c’est ça. En utilisant un hook, on peut aussi mettre à jour les spécifications une fois l’implémentation terminée, et sinon il suffit d’ajouter une commande ou une skill pour mettre à jour les spécifications manuellement, haha

[cshj55]

Ah, je veux pas vieillir.

[GN⁺]

Avis sur Hacker News

• Je pense que le fait que l’IA soit trop bonne sur les bases est justement dangereux
  Les étudiants finissent par ne plus écrire de code eux-mêmes en se disant « l’IA le fait à ma place », et du coup ils n’apprennent pas physiquement les étapes intermédiaires ni les concepts difficiles
  En tant qu’enseignant en informatique, j’insiste auprès de mes élèves : « c’est toi qui dois écrire le code, pas la machine »

  • L’apprentissage ressemble à un entraînement musculaire
    Soulever une charge avec un chariot élévateur est facile, mais ça ne développe pas les muscles
    La douleur du processus d’apprentissage est justement au cœur de la progression
    Bien sûr, au travail, le résultat compte davantage, mais on a quand même besoin de personnes capables de pensée de haut niveau
  • J’ai récemment vu ce problème en entretien
    Le candidat avait une connaissance théorique parfaite, mais il était totalement incapable d’expliquer le fonctionnement du code qu’il avait écrit
    Il a fini par avouer que « GenAI avait écrit l’essentiel », et l’écart entre « ce qu’on a appris » et « ce qu’on a vraiment fait soi-même » était énorme
  • La manière d’enseigner doit aussi évoluer
    Il est plus important d’enseigner non pas « comment écrire du code », mais « comment le code fonctionne »
    Il fut un temps où l’on écrivait directement en assembleur, mais aujourd’hui il est plus utile de comprendre les principes d’un compilateur
    En pratique, la plupart des gens ne construiront jamais eux-mêmes un compilateur ou un OS, mais en comprendre les principes aide à saisir les limites des langages de programmation
  • On disait déjà autrefois qu’« il ne faut pas laisser les machines écrire le code »
    Le même débat existait à l’arrivée des compilateurs, et au final nous sommes montés vers des niveaux d’abstraction plus élevés
  • Je vois le code comme un « outil de pensée »
    Une simple implémentation n’approfondit pas la réflexion
    Si on confie l’implémentation à l’IA, on finit par avoir « des aveugles qui cherchent leur chemin ensemble »
    Le processus de réflexion en manipulant directement le code est indispensable

• Je n’adhère pas à l’idée selon laquelle « l’IA est bonne sur les petites choses, mais encore meilleure sur les grandes »
  En pratique, je n’ai obtenu que des résultats décevants
  Soit le code ne fonctionnait pas correctement, soit il fallait donner sans cesse de nouvelles consignes de correction
  Si la boucle de feedback est difficile, on devient au final soi-même l’unique source de feedback, et c’est là qu’on mesure vraiment les limites de l’IA

  • Quand je donne à l’IA des spécifications précises, ça marche plutôt bien
    Par exemple, si j’explique clairement la structure de TaskManager ou les règles de possession mémoire, elle produit volontiers du code qui passe même les tests
  • L’usage de l’IA dépend de la qualité de la boucle de feedback
    Il y a des gens comme Ryan Dahl qui disent « je n’écris plus directement le code », mais c’est parce qu’ils l’affinent comme dans une collaboration à travers des feedbacks répétés
    Il faut traiter l’IA comme on éduquerait un enfant
  • Il est utile de documenter ses prompts dans un document séparé
    On y décrit clairement les entrées, les sorties et les erreurs attendues, puis on corrige au fil d’expérimentations répétées
  • J’utilise un outil nommé Beads pour découper le travail en petites unités
    Claude pose des questions, fait de la recherche et va jusqu’à relire le code
    C’est un peu comme encadrer un développeur junior compétent
  • À l’inverse, certaines personnes disent obtenir avec Opus 4.5 un code parfaitement fonctionnel, au point d’avoir l’impression qu’« il existe deux mondes différents »

• J’ai essayé le « vibe coding » avec un esprit ouvert au début, mais je suis devenu de plus en plus sceptique
  C’est bien pour du code répétitif et clair, mais inadapté à la logique métier centrale
  Claude ignore souvent les spécifications, répète plusieurs fois la même logique, ou prétend corriger quelque chose tout en le laissant inchangé
  J’ai aussi l’impression que le modèle devient de plus en plus émoussé
  Maintenant, je ne l’utilise plus que pour discuter de conception ou pour déboguer

  • Un bon code, par essence, c’est la concision
    S’il y a beaucoup de « parties ennuyeuses » à faire remplir par l’IA, c’est peut-être que la structure du code est mauvaise dès le départ
  • La difficulté du développement n’est pas l’écriture du code elle-même, mais la transformation des exigences en plan d’implémentation
    Et sur ce point, les LLM restent utiles
    Beaucoup de développeurs reçoivent de toute façon un design déjà défini et se contentent d’implémenter, donc l’IA peut leur faire gagner du temps

• Je ne suis pas d’accord avec l’idée selon laquelle « l’IA n’arrive pas à intégrer les changements de conception »
  Au contraire, c’est précisément le rôle de l’humain
  Par exemple, si on lui demande de modifier la structure d’une API, l’IA peut retrouver toutes les zones concernées, les modifier et même lancer les tests

  • Mais les tests produits par les LLM sont souvent excessifs ou insuffisants
    Ils s’attachent trop aux détails d’implémentation ou omettent les validations conceptuelles
    Cela dit, les tests écrits par des humains ont souvent les mêmes défauts, donc je peux le comprendre
  • J’ai constaté que le code généré par l’IA peut sembler bon par morceaux, tout en restant bancal dans son ensemble
    Si l’on n’écrit pas le code soi-même, on ne ressent pas les parties rugueuses et déséquilibrées de l’abstraction, et cela finit par dégrader la qualité structurelle
  • Là où l’IA écrit des centaines de lignes d’un coup, moi je construis une fonction à la fois et je découvre des axes d’amélioration en chemin
    C’est cette différence qui détermine le niveau de finition du code
  • Quand je n’aime pas le code produit par l’IA et que je le corrige à la main, il m’arrive de ressentir une forme de « culpabilité »
    Mais l’important, c’est surtout de savoir juger quelles tâches nécessitent réellement une intervention manuelle
  • Depuis Opus 4.5, l’IA accomplit en quelques heures des tâches qui prenaient auparavant une semaine
    Mais il faut un abonnement haut de gamme pour que ce soit vraiment efficace, par exemple Claude Max à 200 dollars
  • D’autres répondent que « le travail d’un développeur est de livrer du code validé, pas de gérer une IA », et soulignent qu’il faut un moyen objectif d’évaluer la maîtrise des outils IA

• Je m’interroge sur l’affirmation « je fais du vibe coding depuis 2 ans »
  Karpathy n’a créé ce terme qu’il y a à peine un an (source)

  • Quelqu’un dit avoir créé avec GPT-4 un programmeur Python capable de se modifier lui-même
    Ce qui est intéressant, c’est que GPT a conçu lui-même l’API qu’il allait utiliser, puis l’a implémentée en conséquence
    Mais ensuite, les modèles ont commencé à bloquer les conversations liées à l’auto-modification et à la réplication
  • Une autre personne dit que « le terme est nouveau, mais en pratique tout le monde codait déjà comme ça avec Copilot ou Cursor »
  • Aujourd’hui, on utilise souvent « vibe coding » au sens large pour désigner tout acte où l’IA écrit le code à votre place
    Il n’est même pas nécessaire d’avoir un outil entièrement agentique : ChatGPT ou Claude suffisent largement
  • Certains disent être passés de la phase « le code généré par l’IA avait l’air bien au début, mais c’était le bazar » à une méthode où ils collaborent avec l’IA dès la phase de recherche, avec de bons résultats

• Je dis à mes étudiants que « regarder du sport à la télévision ne fait pas faire d’exercice »
  Le vibe coding, c’est pareil : il y a une satisfaction qu’on n’obtient qu’en écrivant le code soi-même

  • Récemment, j’ai essayé de coder directement sans Copilot, et le fait de résoudre les problèmes un par un jusqu’à terminer m’a procuré une vraie fierté
  • À l’inverse, au travail l’accès aux LLM est limité, mais sur mes projets personnels après le bureau, le « code à moitié terminé » produit par l’IA me redonne de la motivation

• Je doute que les vrais ingénieurs pratiquent le « vibe coding » de manière aveugle
  Pour ma part, j’utilise plutôt une façon de sculpter le code par la conversation
  Je présente les exigences, j’examine avec l’IA les propositions de conception, puis je complète progressivement la structure
  Le processus est lent, mais il permet de préserver la collaboration et la profondeur de réflexion
  L’IA propose de nouvelles idées à partir de l’immense quantité de code sur laquelle elle a été entraînée, et moi je les ajuste avec mon expérience
  Au final, l’IA me donne l’impression d’une version augmentée de moi-même (me++)
  Je ne suis pas encore prêt à tout confier à un agent entièrement autonome, mais c’est cette méthode qui me paraît la plus productive

• J’ai l’impression que le code écrit par l’IA ressemble à un roman excellent par endroits mais raté dans son ensemble
  Pris chapitre par chapitre, tout semble parfait, mais l’ensemble devient confus

  • Quelqu’un rétorque : « as-tu déjà lu un roman de 200 pages écrit par une IA en en sortant satisfait ? »
    Dans ce cas, attendre d’une base de code de 10 000 lignes écrite en vibe coding qu’elle fonctionne correctement paraît excessif
  • Une autre personne affirme que « le roman relève de la création, alors que l’ingénierie obéit à des règles claires, donc ce n’est pas comparable »
  • Quelqu’un d’autre répond en disant que son fils a pris plaisir à lire deux romans longs écrits avec GPT-4.5
  • Cette analogie pourrait aussi devenir un bon critère pour évaluer la capacité à utiliser l’IA
  • Pour ma part, je dis que « je ne ferai jamais confiance à une application entièrement vibe-coded sans intervention humaine »
    Sans pensée ni sensibilité humaines, l’expérience utilisateur perd aussi sa cohérence et génère des frictions cognitives
  • Un développeur explique qu’il développe un logiciel de CAO avec l’aide d’un LLM
    Quand la conception est claire, le LLM accélère de manière explosive le travail de boilerplate
    Mais le design reste toujours du ressort de l’humain
    On peut voir son projet dans la version publique sur GitHub

• Je reconnais que le code produit par un LLM peut être excellent localement mais faible dans sa structure globale
  Mais si l’on comprend la base de code et qu’on la relit soi-même, il est tout à fait possible de compenser cela
  Le vibe coding est excellent pour le prototypage
  Il permet d’aller vite pour trouver la bonne direction, puis de refactorer et d’étendre ensuite

  • Mais certains estiment aussi que « si on ne regarde pas directement le code, alors seulement là on peut parler de vrai vibe coding »
    Autrement dit, selon eux, le vrai vibe coding consiste à juger uniquement sur le résultat final