#vibecoding

Un an plus tard, la même équipe va plus loin ; parmi les salariés les plus productifs grâce à l’IA, 88 % se disent en burn-out

La vache. Ça va très très vite.

3 semaines plus tard, je n’ai pas encore eu l’envie de regarder. C’est pas sérieux. Je devrais en parler à ChatGPT, peut-être qu’il pourrait tout réparer en quelques instants, si je lui dis les bons prompts.

I’m increasingly hearing from experienced, credible software engineers who are running multiple copies of agents at once, tackling several problems in parallel and expanding the scope of what they can take on. I was skeptical of this at first but I’ve started running multiple agents myself now and it’s surprisingly effective, if mentally exhausting!

Ça se confirme. Une seule requête, en fait, ça ne suffit pas ? Alors faisons-en des dizaines en parallèle, jusqu’à ce que ça tombe en marche.

▻https://seenthis.net/messages/1137739

A very weird form of management. Getting good results out of a coding agent feels uncomfortably close to getting good results out of a human collaborator. You need to provide clear instructions, ensure they have the necessary context and provide actionable feedback on what they produce. It’s a lot easier than working with actual people because you don’t have to worry about offending or discouraging them—but any existing management experience you have will prove surprisingly useful.

Voilà, les petits génies des openspaces n’ont plus besoin de se coltiner les états d’âmes de leurs collègues capricieux.

L’âge d’or des devs vient de prendre un mur dans la gueule.

Celui des logiciels fonctionnels aussi.

J’attends avec impatience l’analogie suivante : les nouveaux logiciels vide-codés sont ce que les meubles en formica ont été pour la menuiserie.

Dans son précédent en mars :

Not all AI-assisted programming is vibe coding (but vibe coding rocks)
▻https://simonwillison.net/2025/Mar/19/vibe-coding

We also need to read the code. My golden rule for production-quality AI-assisted programming is that I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.

If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development.

@monolecte ce n’est pas ce qui est dit, et c’est un très bon développeur/ingénieur/concepteur qui l’a écrit (co créateur de Django et un membre important de la communauté du langage Python).

C’est pas juste de la prospective : il explique clairement depuis plusieurs mois comment il l’utilise réellement au quotidien, à la fois pour tester des intuitions (là juste en vibe coding sans rien contrôler), et pour faire des choses extrêmement propres, testables, et reproductibles (ce qu’il appelle « vibe engineering » dans ce dernier article).

Il me semble qu’on peut lui faire confiance sur le fait de savoir distinguer du code fonctionnel, propre, testable, et explicable.

Encore une fois, je ne trouve pas que la question importante soit « ça marche jamais vraiment bien », car c’est déjà factuellement faux dans un grand nombre de cas d’utilisation, et c’est de plus en plus faux au fil du temps, car tous les 6 mois les nouveaux modèles (avec agents, avec « réflexion par étapes ») produisent vraiment des choses très propres.

Le plus important reste : la pollution, la gabegie d’énergie, et socialement ce que ça implique obligatoirement comme changement d’organisation du travail, avec de la prolétarisation et de la taylorisation de métiers qui y échappaient encore. On est sommé de produire encore pire plus vite, de paralléliser des tâches encore plus pour toujours faire plus en le moins de temps. La base du capitalisme quoi, mais encore pire avec ces outils, et là spécifiquement pour ce métier, encore pire dans le code, même quand on est un⋅e « concepteurice/architecte/ingénieur⋅e ».