Retrospective : Un mois de Vibe Coding intensif avec Claude pour le stockage local du jeu

Le mois dernier au taf, je me suis mis à fond au "vibe coding" avec Claude (d'habitude, je tourne plutôt sur Gemini pour mes side projects). La boîte nous a filé un quota d'API de malade, et on m'a collé le développement d'une toute nouvelle feature de stockage local pour la galerie photo du jeu. Du coup, j'ai inversé mon workflow habituel : je joue l'architecte qui gère la vision globale, et je laisse Claude Opus 4.6 faire le code monkey (le pisseur de code).

Après un mois complet à ce rythme, voilà la réalité du terrain : quand tu sais exactement ce que tu veux, l'IA est une vraie machine de guerre. Mais à la seconde où tu commences à itérer sur les specs ou à chasser des bugs, l'expérience humaine est 100 % irremplaçable.

Quand tu sais ce que tu veux, ça déchire

Pendant la phase de scaffolding initiale, tant que je posais des limites ultra strictes, Claude me sortait exactement ce qu'il me fallait.

Par exemple, pour éviter de corrompre les fichiers de l'album, j'ai demandé une sécu sur les données. Claude a pigé le truc direct et m'a pondu un pattern WAL (Write-Ahead Logging) parfait, pompé tout droit de la doc de SQLite. Il a géré la logique des fichiers temporaires, des échanges atomiques et du crash recovery au poil. À ce stade, si tes specs sont carrées, l'IA fait le sale boulot à la perfection et t'économise des heures à écrire du boilerplate.

Le retour à la réalité : la vision étriquée de l'IA sur les bugs

Mais la lune de miel s'est terminée dès qu'on a commencé à ajuster des features et à corriger des bugs. C'est là que les limites de Claude te sautent à la figure.

Le plus gros angle mort de l'IA, c'est qu'elle n'a aucune vision globale de l'architecture. Quand la logique coince, son premier réflexe est de mettre une rustine (un pansement). Elle adore inventer des flags booléens crades ou ouvrir de nouvelles branches if-else au lieu de prendre du recul et d'intégrer le correctif proprement dans le système. Si tu écoutes l'IA aveuglément à ce moment-là, ta base de code devient un enfer à maintenir en un temps record.

L'erreur de manuel : le Reference Counting du cache Texture2D

Je me suis pris un mur classique en bossant sur un système de reference counting pour le cache Texture2D en C#.

L'idée, c'était de gérer la mémoire des pages de l'album. J'ai divisé le cache en deux zones : active et inactive. Si une texture a des références, elle reste active ; si ça tombe à zéro, elle dégage dans le pool inactif, prête à être poubellisée.

Ça a dérapé quand on a mixé les callbacks asynchrones avec les références du cache. Claude a écrit une logique de timing complètement pétée : il poussait la page dans le pool inactif avant de marquer la référence. Ça a créé une race condition fatale. Si le cache était déjà plein, balancer la page dans le pool inactif déclenchait le nettoyage instantanément, flinguant la page avant même que le callback asynchrone ait eu le temps de marquer la référence.

La brillante idée de Claude pour fix ça ? Ajouter un flag bien dégueu appelé is_early_marked dans la structure de données pour esquiver le problème de cycle de vie.

J'ai stoppé le délire direct. Sachant comment fonctionne réellement le cycle de vie du composant, je lui ai imposé une règle stricte : tu retardes le nettoyage de la page inactive jusqu'à après que l'opération asynchrone ait marqué la référence. En ajustant le timing au niveau de l'architecture, le bug a été exterminé — sans avoir besoin d'ajouter des flags pourris.

En résumé

Toute cette histoire prouve que, même si l'IA te fait coder dix fois plus vite, elle est aussi très forte pour planquer la dette technique.

Si un dev junior était tombé sur ce bug asynchrone, il aurait probablement juste mergé le fix crade de Claude. Avance de quelques semaines, et tu te retrouves avec une douzaine de flags et de branches qui ne servent à rien, et un module irrécupérable. Avec le vibe coding, tu n'es plus obligé d'écrire chaque ligne toi-même, mais garder un œil sur la vision globale et empêcher ton app de devenir un plat de code spaghetti, c'est un taf que seuls les humains peuvent faire.