Mon Workflow AI

Il y a quelques mois, j'avais posté sur LinkedIn qu'en gros le Vibe Coding c'est de la merde, et que j'ai détesté l'expérience. Mais j'ai aussi dit que paradoxalement j'aimerais un jour trouver une solution efficace pour coder avec l'IA.

Quand j'avais testé le vibe coding l'année dernière, mon problème c'était que j'avais mon projet, je le configurais, puis je me demandais quelle était la prochaine tâche (en me basant sur un Kanban, ou des TODOs dans le code), et je promptais à Claude Code de faire la tâche, puis je vérifiais, et éventuellement je demandais à produire des tests si c'était de la logique sensible. Si j'observais des anomalies, je promptais de les corriger. Puis quand j'étais satisfait je commitais. J'avais un fichier specs qui était là au début, et que j'oubliais par moment, qui dérivait au fil du temps par rapport à l'état réel du projet. Donc quelque part, c'était peut-être pas le vibe coding le problème, c'était moi qui ne savais pas encore comment faire. Alors qu'est-ce qui a changé ? Déjà je préfère parler de workflow AI.

BMAD Method

Il y a quelques temps Benjamin Code dans une vidéo nous parlait de son nouveau workflow AI, la BMAD Method. Une méthode avec un setup d'agents, commands, tools. Pour résumer, ça consiste à concevoir en profondeur un projet façon scrum avec plusieurs agents ayant chacun leur rôle (product owner, UX designer, marketing, QA, etc etc.). Chaque agent aura plusieurs ateliers de brainstormings, pour recueillir les besoins, mettre en place des specs, définir les personas et beaucoup d'autres. Chaque atelier produit un document qui est utilisé par l'agent suivant.

J'ai testé cette méthode sur un projet vraiment très basique. Un timer d'interval pour le sport. J'ai passé presque une semaine à passer d'un agent à l'autre, à faire des ateliers de brainstorming, et à attendre des cooldown d'usage de Claude (j'étais en abonnement Pro à ce moment là).

Je n'ai pas été convaincu. Il y avait beaucoup trop d'ateliers, trop de documents générés. Ça m'a épuisé. Zéro plaisir. C'était lourd et pénible MAIS... aussi très enrichissant. Parce que force est de constater, que j'ai été obligé de réfléchir plus profondément à la conception du projet, mieux le préparer en amont, et donc au final mieux le cerner avant même de commencer à coder. J'ai réalisé que la clé était peut-être dans la conception et le workflow finalement.

Harper Reed Workflow

Il y a quelques semaines, je fais ma veille quotidienne, et je tombe sur une vidéo qui parle d' un article qui propose un workflow AI avec seulement 4 prompts très simples, qui génère seulement 3 fichiers markdown : la spec du projet, le plan d'implémentation, la todo de vérifications. En mettant l'accent sur une boucle d'itération qui sera quasiment toujours la même. C'est à dire ; lire les docs, comprendre l'objectif, comprendre le projet, l'étape en cours, lire le code, écrire le code, build le projet, corriger les erreurs, rédiger et lancer les tests, corriger les erreurs, si tout est ok mettre à jour les docs, passer à l'étape suivante.

Et ça a tout changé. Parce que cette fois, j'ai passé seulement une après-midi à brainstormer et une journée à implémenter un MVP fonctionnel et relativement complet. Et c'était vraiment fun de voir mon projet prendre vie étape par étape et aussi rapidement.

J'ai maintenant une méthode simple, relativement légère, facilement réutilisable, et j'ai suffisamment confiance dans ce qui a été produit. Le côté fun c'est que je vois le projet avancer tout seul un commit après l'autre. A la fin j'écris "Continue" et c'est reparti. C'est étonnamment satisfaisant.

Post-greenfield

Maintenant le workflow est terminé, j'ai mon MVP, il fonctionne. Et maintenant ? Comment j'ajoute une fonctionnalité sans casser mon workflow ? C'est là où je me suis un peu senti sans filet. Le workflow de base ne prévoit pas ça, il était idéal pour un projet dit "Greenfield", c'est à dire qui part d'une page blanche, mais maintenant que le projet est là, comment faire ?

J'ai essayé de prompter ce dont j'ai besoin. Ca peut fonctionner pour certains cas, mais je sais maintenant que ce n'est pas efficace de travailler comme ça. J'aimerais garder ce workflow mais pour rajouter ou modifier l'existant. Est-ce que je fais grossir les fichiers existants ? Est-ce que je repars de zéro avec de nouveaux fichiers ? Est-ce qu'il y a un risque de tout casser ?

Je suis donc retourné brainstormer avec Claude, et on a mis en place un workflow pour ce post-greenfield. En gardant la même boucle d'itération, de contrôle et de mise à jour. En gros, on garde le fichier de specs qu'on avait avant, mais maintenant il devient notre référence pour comprendre le contexte du projet. Et on a maintenant nos 3 fichiers specs/plan/todo spécifiques pour la feature.

Ça marche pas trop mal, mais tout n'est pas encore au point concernant les instructions que je dois mettre dans claude.md de projet en projet. Pareil avec l'emplacement de ces fichiers post-greenfield mais ça viendra avec l'expérience. Je dois encore rendre le tout robuste, mais l'essentiel est là, et ça fonctionne. Je mettrai à jour cet article quand j'aurai résolu ce problème.

Conclusion

Ce que je retiens de tout ça, c'est l'importance d'un brainstorming poussé en amont du projet, produire des documents d'implémentations simples mais denses en informations, mettre en place une boucle d'implémentation qui inclut des tests et une mise à jour des documents à chaque étape.

Au final, là où il y a quelques semaines encore, j'avais beaucoup de frustrations à laisser trop de responsabilité à l'IA dans mes projets, maintenant j'ai une vraie satisfaction à regarder mon repo git progresser tout seul commit après commit. Et finalement je fais ce que je préfère dans ce métier, c'est trouver des solutions à un problème.

Je crois que j'ai débloqué une nouvelle compétence : Coder efficacement avec l'IA. J'ai un backlog d'idées et de projets long comme le bras que je n'arrivais pas à dépiler, je sens que je vais pouvoir changer ça dans les mois à venir.