Le mal est fait, script YouTube + prompts

J’ai un réflexe très simple quand je vois du code qui ne ressemble pas à ce que j’avais en tête.

Je corrige. Tout de suite.

L’IA renomme une classe, choisit un pattern différent, structure un fichier autrement, et mes doigts partent direct vers le prompt pour remettre les choses en ordre.

Sauf que depuis quelques mois, j’ai arrêté.

Le mal est fait. Et c’est devenu une de mes méthodes d’apprentissage les plus rentables.

Je bosse tous les jours avec des agents IA. Ils génèrent du code, refactorisent, créent des features. Et régulièrement, ils font des choix différents des miens.

Pas forcément des bugs. Des choix.

Une nomenclature que je n’utilise pas. Un design pattern que je n’aurais pas sélectionné. Une structure de dossier légèrement différente.

Mon réflexe naturel, c’était de corriger. Remettre mon standard. Rétablir l’ordre.

Puis un jour je me suis arrêté sur une question beaucoup plus intéressante.

Et si l’IA avait raison ?

Ou plus subtil encore, et si son choix, même faux selon mes critères, ouvrait une porte que je n’aurais jamais envisagée moi-même ?

Si le code fonctionne, si les tests passent, et si l’utilisateur ne voit rien, qu’est-ce que je suis vraiment en train de corriger ?

Alors j’ai instauré une règle simple.

Le mal est fait.

Au lieu de corriger immédiatement, je laisse vivre le choix jusqu’au prochain passage. Jusqu’au moment où je reviens sur cette feature pour ajouter quelque chose, améliorer un détail, ou corriger un vrai bug.

Et là, je regarde avec du recul.

Parfois je comprends enfin la logique du choix initial, et je réalise que je voulais corriger quelque chose qui n’avait pas besoin de l’être.

Parfois ça m’apprend un pattern ou une manière de penser que je n’avais jamais utilisée.

Et parfois, c’est mon cas préféré, le problème disparaît tout seul. Je touche à la feature, je refais une partie du code, et ce truc bizarre que j’aurais passé trente minutes à nettoyer n’existe plus.

J’ai corrigé sans corriger.

Le vrai argument, ce n’est même pas juste l’apprentissage. C’est le coût d’opportunité.

Quand je passe une heure à renommer des classes, réaligner un pattern, ou restructurer des dossiers alors que tout fonctionne déjà, cette heure est perdue.

L’utilisateur ne voit aucune différence.

J’ai juste échangé du temps de progression contre du confort esthétique.

Chaque minute passée à corriger un mal qui n’en est pas un, c’est une minute volée à quelque chose qui avance vraiment.

Le perfectionnisme, c’est souvent le luxe de ceux qui n’ont pas de deadline.

Et en indie dev, on en a tous, même quand on fait semblant du contraire.

Ce principe dépasse largement le code.

Combien de founders passent des semaines à polir un produit avant de le lancer ? La landing n’est pas assez belle. Le copy n’est pas parfait. L’onboarding manque d’une animation. Alors ils attendent.

Pendant ce temps-là, le marché, lui, ne les attend pas.

Shipper imparfait, c’est exactement la même philosophie.

Le mal est fait, la version un existe, elle a des défauts, mais elle est dans les mains des utilisateurs. Et les utilisateurs, contrairement à ton perfectionnisme, te disent ce qui compte vraiment.

Depuis que j’applique ça, je vois les erreurs autrement. Pas comme des fautes à effacer au plus vite, mais comme des choses à observer avant de juger.

L’IA n’est pas juste un exécutant. C’est aussi un générateur de perspectives.

Le mal est fait. Avance.