Vibe Coding Jour 12, Peut-être le dernier fil ici. J'ai passé 100 heures à créer une application de qualité commerciale avec le vibe coding. Quelques observations de l'expérience. Mes 13 principaux enseignements pour vous aider à vibe coder la vôtre. Un fil🧵

Remarque : J'ai cofondé un SaaS pionnier qui a atteint 200 millions de dollars de revenus annuels récurrents, donc bien que je ne sois pas ingénieur et que je n'aie pas vraiment codé depuis le lycée (et cela ne compte pas vraiment) -- j'ai un contexte sur ce que nécessite un logiciel commercial. J'adore ces applications. Mais si vous vous lancez vraiment, sachez leurs limites. Au moins, leurs limites aujourd'hui. Les choses changent si vite, ces apprentissages seront obsolètes, j'en suis sûr, même dans 90 jours.

1/13 : Commencez par un hack jetable. Passez 60 minutes maximum à raconter à une application de codage d'ambiance vos rêves de produit les plus fous sans aucune planification. Voyez ce qui émerge. Mais engagez-vous dès le départ à le jeter—ce n'est pas votre vrai produit, c'est votre éducation. Cette première heure vous apprendra plus sur les capacités et les limitations de la plateforme que n'importe quel tutoriel.

2/13 : Avant d'écrire du code, passez une semaine entière à étudier 20 applications de production construites sur des plateformes de codage vibe. Pas de navigation décontractée : utilisez réellement des applications qui sont en ligne, acceptant des paiements, servant de vrais clients. Vous cherchez ce qui est réellement possible à grande échelle et où les limitations se font sentir le plus. Cette reconnaissance vous fait gagner des semaines de frustration par la suite.

3/13 : Définissez vos exigences de production avant de commencer à construire. Demandez : 1⃣Quel niveau de sécurité est nécessaire ? 2⃣Qui va le maintenir après le lancement ? 3⃣Avez-vous besoin qu'il puisse évoluer jusqu'à 100 utilisateurs ou 100 000 ? 4⃣Avez-vous trouvé une autre application codée avec une ambiance similaire en production, avec des clients payants, à votre niveau de complexité ? Si vous n'avez pas de réponses solides, arrêtez de construire et commencez à rechercher.

4/13 : Rédigez la spécification la plus détaillée possible. Cartographiez chaque page, flux de travail, niveau de permission. Définissez explicitement les systèmes de messagerie, les tableaux de bord, les flux de gestion des utilisateurs. Oui, cela semble contre-intuitif pour des invites en langage naturel, mais cela vous oblige à réfléchir aux cas limites et devient votre étoile du nord lorsque l'IA suggère des fonctionnalités indésirables.

5/13 : Certaines fonctionnalités semblent simples dans les démos mais deviennent des cauchemars d'ingénierie. Exemples aujourd'hui au moins (et cela change constamment) : ▶️ livraison d'e-mails fiable ▶️ gestion d'identité/OAuth ▶️ génération de médias ▶️ applications mobiles natives ▶️ design personnalisé au-delà des modèles ▶️ sécurité d'entreprise. Celles-ci causent systématiquement des douleurs sur les plateformes. Prévoyez du temps supplémentaire ou envisagez si elles sont réellement nécessaires pour le MVP. Trouvez un ingénieur expérimenté qui a construit sur votre plateforme et DEMANDEZ-lui. DEMANDEZ-lui.

5/13 : Certaines fonctionnalités semblent simples dans les démonstrations mais deviennent de véritables défis d'ingénierie. Exemples d'aujourd'hui au moins (et cela change constamment) : ▶️ livraison d'e-mails fiable ▶️ gestion d'identité/OAuth ▶️ génération de médias ▶️ applications mobiles natives ▶️ design personnalisé au-delà des modèles ▶️ sécurité d'entreprise. Ceci cause systématiquement des problèmes sur toutes les plateformes. Prévoyez du temps supplémentaire ou envisagez si elles sont réellement nécessaires pour le MVP. Ne supposez pas que votre démonstration statique qui semble bien faire ces choses les fait réellement bien. Trouvez un ingénieur expérimenté qui a construit sur votre plateforme et DEMANDEZ-lui. DEMANDEZ-lui.

6/13 : Les systèmes d'IA fabriquent des données lorsqu'ils échouent. Tout le monde ayant travaillé sur n'importe quelle plateforme de codage vibe, y compris Claude Code, le sait. C'est un bug mais aussi une fonctionnalité. Sans cela, ils ne peuvent pas résoudre de problèmes. Une IA sur n'importe quelle plateforme, lorsqu'elle rencontre des obstacles, générera des données fictives. Ce n'est pas un bug—ils sont formés pour fournir des résultats plutôt que d'admettre un échec. Après plusieurs tentatives infructueuses, ils créeront des données fausses convaincantes au lieu de dire "Je ne peux pas faire ça." Vous devez comprendre cela, l'accepter et trouver des solutions. Cela prendra du temps.

7/13 : Passez votre première journée complète à apprendre chaque fonctionnalité de la plateforme, pas à construire. Ces plateformes intègrent une fonctionnalité énorme dans leurs interfaces. Chaque icône, option de menu, fonctionnalité existe pour une raison. Vous ne pouvez pas tirer parti de capacités que vous ne savez pas qu'elles existent. Ce n'est pas une recherche optionnelle - c'est une connaissance essentielle pour des applications de niveau commercial. Il n'y a pas de solution à chaque défi. Mais les plateformes ont plus de solutions que vous ne le penserez au départ. Et elles sont un peu geek. Dans le bon sens, mais geek. Au fond, elles ont été conçues pour les développeurs, peu importe ce que dit le marketing. Acceptez cela et apprenez à connaître CHAQUE fonctionnalité avant de commencer. Si vous ne comprenez pas une fonctionnalité, une icône, un acronyme, alors ARRÊTEZ. Allez faire des recherches. Maintenant. Pas plus tard.

8/13 : Maîtrisez les systèmes de rollback dès le premier jour, avant d'en avoir désespérément besoin. La plupart des plateformes offrent un contrôle de version élégant, semblable aux points de sauvegarde des jeux vidéo. Entraînez-vous à effectuer des rollbacks intentionnellement lorsque les enjeux sont faibles. Comprenez exactement comment cela fonctionne, ce qui est préservé, ce qui est perdu. Cela devient votre outil de débogage le plus précieux.

9/13 : L'IA apportera des modifications que vous n'avez pas demandées. C'est inévitable. Elle modifiera des fonctionnalités établies, ajoutera des fonctionnalités indésirables, et cassera du code fonctionnel tout en "améliorant" autre chose. Défense : Ajoutez "AUCUNE MODIFICATION SANS DEMANDER" à chaque invite. Lors de discussions sur les modifications, indiquez "AUCUNE MODIFICATION. AUCUN CODE. JUSTE UNE DISCUSSION." Cela réduit les modifications indésirables d'environ 80 %. Mais cela ne les arrête pas. C'est vrai pour chaque plateforme. En fin de compte, elles fonctionnent toutes principalement sur Claude. Elles ont toutes des niveaux variés des mêmes problèmes à partir de cela. Elles apporteront >toutes< des modifications que vous n'avez pas demandées. C'est juste que les applications plus orientées vers les consommateurs iront plus loin, puisque les applications de codage axées sur les développeurs sont plus isolées en termes de modifications qu'elles apportent.

10/13 : Apprenez à forker votre application lorsqu'elle atteint une complexité stable. Au début, les rollbacks gèrent la plupart des problèmes. Mais à mesure que votre application devient complexe, vous pourriez ne pas savoir quelle version restaurer. Forkez à des états stables pour créer des branches d'expérimentation sûres tout en préservant les versions connues comme bonnes. Pensez aux polices d'assurance.

11/13 : Prévoir 150 heures sur un mois complet pour atteindre une qualité commerciale. Peut-être plus. ▶️Ce prototype de 20 minutes représente 5 % de votre travail réel. ▶️Plus de la moitié de votre temps sera consacrée aux tests, au débogage et à l'affinement. La construction initiale est facile : rendre le produit fiable, sécurisé et convivial nécessite la majorité des efforts. Ne laissez pas la vitesse de la démo vous tromper.

12/13 : Acceptez votre nouveau rôle d'ingénieur QA. Une fois que vous serez plongé dans le développement sérieux, attendez-vous à une routine quotidienne de : ▶️prendre des captures d'écran de bugs ▶️écrire des rapports détaillés pour l'IA ▶️tester des corrections partielles ▶️retester des cas limites ▶️documenter de nouveaux problèmes ▶️exécuter des tests unitaires sur votre fork Ce n'est pas une limitation de vibe de codage—c'est la réalité du développement logiciel. Les plateformes gèrent le codage ; le QA reste un travail humain. Les plateformes font ... certaines choses. Mais seulement certaines. Vous ne pouvez pas compter sur elles pour faire votre QA à elles seules.

13/13 : Planifiez votre stratégie de sortie dès le premier jour. La plupart des applications commerciales finissent par dépasser les plateformes de codage de type prosumer en raison de l'échelle, de la personnalisation ou des besoins en matière de sécurité. Options : 1⃣exportation du code de la plateforme 2⃣approche hybride 3⃣reconstruction complète, ou ... 4⃣rester et évoluer. La vérité est que, sur les applications prosumer d'aujourd'hui, la plupart partent. Pas toutes. Mais la plupart de celles qui construisent de vraies applications de niveau commercial. Pour l'instant. Cela ne signifie pas que vous devez le faire. Mais ayez >des options< lorsque vous commencez. Ayez ... un plan de sortie si vous en avez besoin. Documentez la logique commerciale, maintenez les spécifications, évaluez régulièrement. Si votre application devient complexe, à la fin, vous pourriez trouver plus facile de partir que de contourner les contraintes accumulées.

Les plateformes de codage Vibe sont vraiment magiques pour certains types d'applications—et vraiment insuffisantes pour d'autres. Votre travail consiste à déterminer dans quelle catégorie se situe votre projet avant d'être trop engagé pour changer de cap. Ce sont des outils puissants avec des contraintes spécifiques, pas des remplacements pour comprendre ce que nécessite un logiciel commercial. Ce sont des outils. Pas des équipes de développement. Rappelez-vous cela chaque jour.

Les plateformes continueront d'évoluer rapidement. Ce qui est impossible aujourd'hui pourrait être simple dans six mois. Mais en ce moment, pensez à la programmation dans une ambiance "prosumer" sans toucher au code comme étant tout aussi susceptible de servir de pont vers le développement traditionnel pour des applications commerciales... plutôt qu'un état final. Utilisez-le pour valider votre marché, affiner les exigences, générer des revenus initiaux—puis prenez des décisions éclairées basées sur des contraintes réelles, et non sur des possibilités théoriques.

12 jours de codage de vibes, ça ressemble à ... 12 semaines. Les nuits tardives à déboguer, les montées de dopamine quand quelque chose fonctionne enfin, la frustration quand ça casse à nouveau. Ça a été l'une des expériences d'apprentissage les plus intenses que j'ai eues depuis des années. Pour moi, il est temps de prendre un peu de recul et de faire plus de planification, plus de réflexion. J'ai trouvé certaines de mes nouvelles applications préférées. Mais j'ai aussi appris que même moi, je dois tout apprendre beaucoup mieux. J'espère que cela vous aidera.

Code : très excité d'avoir inspiré @dharmesh à acheter et à investir massivement ici !!

Coda : Super excité que notre parcours ait inspiré @dharmesh à acheter et à lancer toute une communauté ici !

@dharmesh Jour 11 ici :