Kitze : Pourquoi le 'Vibe Engineering' fonctionne et le 'Vibe Coding' non

Pourquoi Kitze distingue le Vibe Engineering du Vibe Coding

Kitze est le createur de Sizzy (un navigateur pour developpeurs), Zero to Ship et plusieurs autres outils. Cette conference distingue le “vibe coding” (accepter tout ce que l’IA produit) du “vibe engineering” (guider les agents avec des connaissances techniques). Sa these : les sceptiques au milieu de la distribution des competences ont tort, tandis que les juniors qui adorent ca et les seniors qui le maitrisent ont tous deux raison - pour des raisons differentes.

Sur le spectre de l’adoption : “On one hand you have juniors who are like ‘hell yeah, give me the thing, I love doing my own SaaS.’ Then you have super senior people doing libraries and frameworks. And then you have the majority in the middle like ‘this will never be good enough, my code is perfect.’ It’s hilarious, but it’s a pattern.” (D’un cote vous avez les juniors qui sont genre “ouais genial, donne-moi le truc, j’adore faire mon propre SaaS.” Puis vous avez les super seniors qui font des librairies et frameworks. Et puis vous avez la majorite au milieu genre “ca ne sera jamais assez bien, mon code est parfait.” C’est hilarant, mais c’est un pattern.) La distribution est bimodale : des debutants enthousiastes et des praticiens experimentes, avec des niveaux moyens sceptiques entre les deux.

Sur ce qu’est vraiment le vibe engineering : “I’m not vibe coding. I love this term someone coined—vibe engineering. When you’re actually using agents to code all the time but you just look at your screen like ‘I’m going to catch you.’ You’re suspicious of the code because it’s based on our knowledge.” (Je ne fais pas de vibe coding. J’adore ce terme que quelqu’un a invente - vibe engineering. Quand vous utilisez vraiment des agents pour coder tout le temps mais vous regardez juste votre ecran genre “je vais te choper.” Vous etes mefiant du code parce qu’il est base sur nos connaissances.) La distinction : les vibe coders acceptent aveuglement, les vibe engineers supervisent activement.

Sur Composer One qui change tout : “Composer One made me realize I missed coding. What I would do is let a model run like GPT-5 Codex and it would take 37 years. Now I’m back in the driver’s seat. I can be like ‘Stop. No no no. We do the other thing.’ It feels like coding.” (Composer One m’a fait realiser que le codage me manquait. Ce que je faisais c’etait laisser tourner un modele comme GPT-5 Codex et ca prenait 37 ans. Maintenant je suis de retour aux commandes. Je peux faire “Stop. Non non non. On fait l’autre truc.” Ca fait comme du codage.) La vitesse des boucles de feedback compte plus que la capacite du modele.

Sur les devs PA (prise-de-tete) : “You leave a nitpick comment on a two-line PR. You spend more than 2 minutes on a PR review. The thought of agreeing with a colleague causes stomach pain. You say ‘well actually’ in code comments.” (Vous laissez un commentaire pinailleur sur une PR de deux lignes. Vous passez plus de 2 minutes sur une revue de PR. La pensee d’etre d’accord avec un collegue cause des douleurs d’estomac. Vous dites “en fait” dans les commentaires de code.) La plus grande barriere a l’adoption de l’IA n’est pas la capacite - c’est le perfectionnisme qui etait deja contre-productif.

Sur les vrais gains de productivite : “I achieved in two weeks more than I achieved in last year. This was solely due to Composer One. I was about to abandon projects… I moved Benji to Next 16 with App Router, TRPC, Monorepo, Turbo Repo, React Native app, and put in 90% of the features—in less than a week.” (J’ai accompli en deux semaines plus que j’ai accompli l’an dernier. C’etait uniquement grace a Composer One. J’etais sur le point d’abandonner des projets… J’ai migre Benji vers Next 16 avec App Router, TRPC, Monorepo, Turbo Repo, application React Native, et j’ai mis 90% des fonctionnalites - en moins d’une semaine.) La vitesse permet des projets qui n’existeraient pas autrement.

6 enseignements de Kitze sur le developpement assiste par IA

• Vibe engineering != vibe coding - Le vibe coding c’est accepter aveuglement la sortie ; le vibe engineering c’est superviser les agents avec des connaissances techniques et attraper les erreurs en temps reel
• Donnez l’IA aux seniors, pas aux juniors - “Ne donnez pas les outils IA a vos stagiaires et juniors. Si vous prenez votre senior sceptique et le convainquez de faire du vibe engineering, vous obtenez des resultats 10x”
• Composer One est un changement de paradigme - Les boucles de feedback rapides vous permettent de rester aux commandes ; les modeles lents poussaient les gens vers les YouTube Shorts en attendant
• Les devs PA sont le vrai bloqueur - Le perfectionnisme qui exige des abstractions optimales et pinaille les PRs de deux lignes est contre-productif avec ou sans IA
• Les LLM ne se soucient pas du code repetitif - C’est une fonctionnalite : les humains sur-abstraient trop tot, les LLM dupliquent joyeusement quand c’est approprie
• Les exigences de competences ont change, pas disparu - Connaitre les limites des modeles, la gestion du contexte, l’ingenierie de prompt et juger le code “assez bon” sont de nouvelles competences requises

Ce que cela signifie pour la productivite des developpeurs

La conference de Kitze recadre le debat sur le codage IA : le probleme n’est pas la capacite de l’IA, c’est le perfectionnisme humain. Le “vibe coding” echoue parce que c’est du jeu non supervise. Le “vibe engineering” fonctionne parce qu’il combine la vitesse de l’IA avec le jugement humain sur ce qui est assez bien. L’ironie : les developpeurs qui etaient deja pragmatiques sur la qualite du code (vs les perfectionnistes sur-abstracteurs) sont ceux qui prosperent. La competence n’est pas d’ecrire en anglais - c’est de savoir quand le code est assez bien, ce qui a toujours ete la partie la plus difficile de l’ingenierie.