Quasi quotidiennement, je vois des messages fortement moinssés, avec comme argument « c’est du vibe coding, donc c’est de la merde ».
Comme d'autres journaux récents, je souhaite alimenter votre réflexion.
Aimant bien comprendre les choses, et ayant quitté le monde du codage depuis fort longtemps, je me suis documenté (pas via une IA générative, il faut rester sérieux), fait quelques tests avec l’IA mise à disposition par mon entreprise. Je vais vous expliquer ce que j’ai compris, et si l’équation vibecoding = merde est toujours vraie
Tout d’abord, il faut que je vous parle rapidement de mon parcours avec le codage afin que vous compreniez mes biais.
J’ai appris le codage dans les années 80 (1980, faut il le préciser …), en assembleur.
J’ai ensuite appris le Pascal, et c’était une révolution pour moi. On pouvait coder en langage humain (if, then, else , ..) , et non plus en langage machine
Dans mon premier emploi, on codait du temps réel. 2 équipes s’affrontaient :
Les anciens, qui ne juraient que par l’assembleur (exécution plus rapide, moins gourmand en ressources, ..)
Les modernes qui programmaient en C (codage plus rapide, code sensiblement aussi performant que l’ASM, maintenable, ..)
Pour ma part, j’avais le choix des armes. J’ai codé en C, en intégrant des bouts d’assembleur (le meilleur des 2 mondes)
Puis je me suis éloigné du codage, me contentant de quelques scripts Python ou Bash pour me faciliter la vie. J’ai suivi de loin l'arrivée de nouveaux langages et le revival d'anciens(PASCAL, FORTRAN), puis l’arrivée de l’Orienté Objet ..
Chacun étant supposé remplacer définitivement les prédécesseurs, mais certains sont toujours là car ils répondent à un besoin (FORTRAN ..). Pour moi il n'y a pas de "meilleur langage", chaque langage est adapté à un besoin.
Et maintenant, c’est le vibe coding. C’est-à-dire décrire en langage courant ce que doit faire un logiciel, et laisser une IA générative s’occuper du code.
Ce que je retiens de tout ça, c'est que le code n'est pas une fin en soi. Ce n'est qu'un intermédiaire qui permet à un humain d'expliquer à une machine ce quelle doit faire.
Le plus important dans le projet, c'est ce qui se passe avant:
- clairement définir le besoin (et vérifier que quelqu'un ne l'a pas déjà fait)
- bien penser l'architecture globale
- intégrer la cyber sécu
Et ce qui se passe après:
- tests unitaires
- tests d'intégration
- crash test (par ex fuzing, test du singe)
Les "pisseurs de code", ça n'est pas nouveau, c'est juste que maintenant c'est une machine qui le fait.
Même quelqu'un qui serait un excellent codeur, mais néglige ces étapes, ferait aussi de la merde.
Donc avant de conclure instantanément vibecoding = merde, posez d'abord la question de ce qui s'est fait en amont et en aval., ça sera plus constructif.
Reference:
https://www.youtube.com/watch?v=AiytemqB_F0
# Mauvais problème
Posté par Colin Pitrat (site web personnel) . Évalué à 7 (+5/-0). Dernière modification le 07 octobre 2026 à 09:08.
Le problème ce n'est pas le vibe-coding, les problèmes ce sont:
- vibe-écrire son journal
- venir faire de la pub (plus ou moins déguisée) pour son projet vibe-codé dans un journal à l'intérêt limité
- contribuer à noyer les modérateurs et les utilisateurs (moins grâce aux modérateurs, les utilisateurs de RSS peuvent en témoigner) sous un déluge de vomi
Il y a toujours eu des journaux qui ne m'intéressaient pas. La différence c'est qu'en les regardant, je me disais "ça peut intéresser quelqu'un". Depuis peu il y a énormément de journaux (dont beaucoup supprimés rapidement par les modos) pour lesquels je me dis "ça n'intéressera personne".
Un indice que c'est du contenu de merde: bien souvent l'auteur(e) ne répond à aucun commentaire. Il/elle a coulé son bronze sur linuxfr puis a abandonné son compte.
EDIT: Je n'ai pas cliqué dessus, mais avec son lien YouTube, ce journal me semble aussi être une tentative de pub déguisée derrière un sujet maintes fois discutés dans des journaux et commentaires et d'un intérêt limité. Mais qui sait, peut-être l'auteur me répondra?
[^] # Re: Mauvais problème
Posté par piratebab2 . Évalué à 1 (+1/-1).
Merci pour ton commentaire argumenté. Je ne parle pas du contenus de journaux écrit par les LLM, je les déteste aussi, mais c'est un autre sujet.
L'idée de mon journal, c'est de ne pas faire le lien entre vibe coding et merde sans se poser un peu de questions.
En gros, est ce que c'est un logiciel qui tient la route, répond à un besoin, et est robuste, ou bien est ce juste une preuve de concept faite rapidement.
Dans ce 2eme cas, il faut que le concept soit innovant pour mériter un journal. Je trouve que les jugements sont trop souvent à l'emporte pièce, et videcoding = merde n'est pour moi pas un argument.
Le lien c'est une video du site underscore, que certains doivent connaître. Ils interviewent un chef d'entreprise de logiciel qui explique comment il a intégré l'IA dans ces process. C'est très pragmatique, et intéressera les codeurs. C'est une bonne vision de ce que leur métier est en train de devenir.
# oui mais
Posté par passant·e . Évalué à 5 (+3/-0).
C'est un peut le but du journal. La personne prend la temps d'expliciter son problème et sa démarche.
T'as quand même remarqué que ce sont les personnes qui débarquent du contenu qu'ils n'ont pas produit eux-mêmes qui se font descendre en flèche?
C'est pas la même chose entre s'aider d'un outil pour produire son code et de venir en discuter ou demander à son outil de faire le programme et de publier un journal "sympa" pour faire sa promotion.
Dans le deuxième cas, le prompteur n'a AUCUNE valeur ajoutée et n'importe qui ayant envie de brûler des tokens peut avoir la même application en quelques minutes. De plus, il n'y a aucun intérêt à venir demander des retours sur le code source vu que c'est un blob qui va changer au prochain prompt.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: oui mais
Posté par piratebab2 . Évalué à 1 (+0/-0).
Tout à fait d'accord avec toi. Mais ce que je veux dire, c'est que le problème n'est pas le vibe coding, mais tout le reste!
# Logiciel Libre
Posté par Krunch (courriel, site web personnel) . Évalué à 4 (+2/-0).
Il existe des excellent compilateurs C libres (au sens FSF et OSI). Si tu veux utiliser Grand Theft Autocomplete pour générer du code, ça passe par des services et/ou modèles privateurs qui, de plus, ingèrent des corpus de code libre en contrevenant à leur licence. De ce que je comprend il existe des modèles sois-disant libres mais environ personne ne les utilise pour cet usage et leur conformité avec les quatre libertés est douteuse.
Donc, dans le cadre d'un site web qui a pour objectif de promouvoir les Logiciels libres, il me semble bien légitime de rejeter ce genre d'outils.
Sans même parler des aspects environnementaux, économiques, sociaux et éthiques plus larges.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Ce n'est pas ça
Posté par Julien Jorge (site web personnel) . Évalué à 3 (+1/-0).
Je trouve que tu vas un peu vite. Le moinsage en masse de ces derniers temps concerne surtout les journaux générés par LLM. Parce que nous ne voulons pas lire ce que vous n'avez pas écrit.
Et il s'avère que c'est un peu pareil avec le vibe coding, nous ne sommes pas intéressés par l'existence d'un logiciel que personne n'a écrit. Il y a quelques journaux qui s'en sortent, probablement parce que leur contenu va bien au delà de la superficialité du descriptif typiquement généré. Il y a d'un côté l'objet (le logiciel développé, quel que soit l'outil utilisé), et de l'autre côté le retour d'expérience (le contenu du journal). Les journaux sont principalement jugés sur leur contenu donc n'y mettez pas de la m
Et puis c'est fatiguant ce discours disant que le vibe code c'est le turfu et que ceux qui ne s'y mettent pas sont destinés à rester sur la touche, comme [insérer une analogie du siècle passé]. Nous vivons très bien sans vos outils qui résolvent des problèmes que nous n'avions pas et qui en plus introduisent de nouveaux problèmes. Tout allait très bien, merci, gardez vos trucs pour vous.
[^] # Re: Ce n'est pas ça
Posté par piratebab2 . Évalué à 0 (+0/-1).
Je te conseille de regarder la video d'underscore que j'ai mis en lien. C'est le retour d'expérience d'un développeur qui a intégré intelligemment l'IA dans ses équipes.
# Méthode de travail
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Tu décris une méthode qui ressemble beaucoup au cycle en V traditionnel.
Il y a beaucoup de gens qui ne travaillent pas comme ça, mais avec des méthodes dites "agiles" ou ces étapes ne sont pas du tout découpées de la même façon.
En ce qui me concerne, l'écriture de code n'est pas seulement pour dire à la machine ce qu'elle doit faire. Il s'agit d'une méthode de formalisation des besoins exprimés. Cette formalisation dans un langage strict et structuré fait que on se rend compte, lors de l'écriture du code, qu'il y a des cas non prévus dans la spécification, voire des informations contradictoires. Cela permet aussi de se poser la question des bonnes structures de données à adopter pour faire le traitement de façon efficace.
Il y a donc constamment des allers-retours entre l'écriture du code et la rédaction de la spécification.
Je ne suis pas capable de faire ce travail en exprimant les choses en langage naturel (français ou anglais). Je ne pense pas que la personne qui rédige la spécification pourrait remplacer mon travail par l'utilisation d'un LLM. Je ne pense même pas qu'elle pourrait réduire mon travail: si une partie du code était générée par un LLM, ça me ferait d'autant plus de code à relire et à comprendre. Pour moi cela demande plus d'effort de lire et comprendre le code de quelqu'un d'autre, que d'écrire moi-même du code. De plus, le processus mis en place (écriture par une personne et relecture par une autre) est un moyen supplémentaire de détecter les divergences avec la spécification et les oublis. Lors de l'utilisation d'un LLM, c'est la première chose qui va sauter: le développeur ayant demandé au LLM de générer le code, ne l'a pas écrit, mais il l'a relu. Il va donc penser qu'une deuxième relecture n'est pas utile.
Il y a des cas où le code n'est pas critique, suffisamment simple, et où ça peut marcher. Mais dans ce cas, je ne vois pas l'intérêt d'en faire un journal sur linuxfr, car on apprendra rien de nouveau.
[^] # Re: Méthode de travail
Posté par piratebab2 . Évalué à 2 (+1/-0).
Ce que je décris de façon simpliste et probablement maladroite, c'est le "code driven by tests".
Je que je veux dire, c'est que la vrai valeur ajoutée, c'est la réflexion en amont, et les boucles de test.
Dans mon boulot, je gere des projets qui incluent du logiciel. Le codage représente une infime partie du travail. Le gros du boulot (et des couts), ce sont la spécification et les tests.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.