Vibe coding: quand explorer et quand spécifier

Définition utile (pas le hype)

Le vibe coding désigne un mode de développement assisté par LLM où tu décris l'intention en langage naturel, tu laisses générer le code, et tu te concentres sur le résultat visible (démo, tests manuels rapides), souvent sans relecture profonde du diff. Le terme a été popularisé en février 2025 (Andrej Karpathy) et a vite glissé du « weekend throwaway » au discours produit.

Ce n'est pas tout usage d'IA dans l'IDE. L'ingénierie assistée (spec, revue, tests, ownership) reste du craft. Le vibe, au sens strict, c'est accepter de « oublier que le code existe » le temps d'itérer.

Time-to-demo excellent. Produit durable seulement si tu poses une frontière. Les critiques récurrentes: accountability floue, maintenabilité, surface de sécu (auth, secrets, dépendances inventées).

Où le vibe coding marche

Spikes, preuves de concept, UI jetable, scripts one-shot, exploration d'une lib inconnue, scaffolding. Branches throwaway/ avec date de péremption.

Solo ou fondateur: valider une hypothèse en heures. Apprentissage: lire le code généré comme un tuteur, à condition de le comprendre avant de merger.

Règle: l'échec doit être bon marché. Si un client paie, si des données perso ou un paiement passent, tu sors du mode vibe pur.

Où ça casse en production

Confusion démo/produit: la dette silencieuse (styles divergents, tests absents, secrets dans le chat) coûte plus cher que le gain initial.

Sécu: auth bricolée, validations oubliées, dépendances non auditées. Le code généré « skip » souvent les revues si l'équipe ne force pas une checklist.

Lucidité: plus personne n'ose toucher le module. Plus de commits ne veut pas dire plus de valeur. On regarde les incidents et le temps de revue.

Arrête de prompter en boucle quand le besoin n'est pas clair. Spécifie. La clarté du besoin bat la créativité du prompt.

De la vibe aux specs et au RPI

Spec minimale: objectif utilisateur, hors-scope, données interdites, critères d'acceptation testables, risques. Une page suffit.

Boucle Research → Plan → Implement: chercher le contexte, planifier fichiers et tests, n'implémenter qu'après un plan validable. Sur bases complexes, un RPI trop court ne suffit pas: on ajoute design et des handoffs entre phases (lien compact Claude Code si la session est longue).

Subagents pour research isolé: leur contexte ne pollue pas l'agent d'implémentation.

Code jetable: autorisé en branche isolée. Interdit en main sans rewrite sur chemins critiques.

Planning vs acting

Agir sans plan accélère le bruit. Planifier sans shipper non plus. Règle d'équipe: plan court reviewable, puis action; si l'action dérape, on re-planifie, on ne « vibe » pas plus fort.

Checklist merge: spec versionnée, tests ou scénarios, pas de secrets, revue humaine auth/paiement/PII, métrique de succès.

Si vous voulez un atelier vibe coding / specs sur un repo réel, on peut cadrer en 20-40 minutes.