Accéléré par l’IA, piloté par l’humain : mon vrai flux de travail

Au début du travail sur yesid.dev, j’ai fixé une frontière claire pour le CMS : le contenu d’interface commun et répété devait venir du CMS plutôt que de rester dans les fichiers du frontend. Claude a produit l’implémentation, et j’ai vérifié les fichiers par rapport à cette frontière. J’y ai trouvé du texte partagé encore codé en dur dans le frontend. Du texte codé en dur et du texte alimenté par un CMS peuvent produire les mêmes pixels. Une vérification dans le navigateur prouve que la page s’affiche, pas quel système en est responsable. La vérification des fichiers a montré que l’implémentation ne respectait pas encore le modèle de contenu que j’avais choisi.

Claude était mon principal outil d’implémentation pour yesid.dev et transit.yesid.dev. Codex a surtout révisé le travail et a parfois pris le relais pour l’implémentation. J’ai supervisé les deux projets de A à Z et pris les décisions d’architecture. J’ai gardé le contexte des projets, décidé comment les différentes parties devaient s’intégrer, donné des directives, inspecté les résultats, trouvé les problèmes et fait avancer le travail.

Le travail s’est rapproché de la direction de projet. Au lieu d’écrire le code moi-même pour chaque implémentation, je dirigeais les projets, gardais l’architecture en tête et vérifiais les résultats.

Le dépôt de yesid.dev comporte aujourd’hui des contrôles automatisés du contenu généré et des avertissements Svelte. Le hook de précommit et la CI des PR comparent les modules générés par le CMS au manifeste qui les répertorie. La CI des PR exécute ce contrôle pour les pull requests visant main ou develop. La comparaison détecte les écarts ordinaires entre les modules et le manifeste, mais elle vérifie leur cohérence, pas si le CMS a réellement produit les fichiers. Le hook local peut ne pas être exécuté, et une modification coordonnée d’un module et du manifeste peut tout de même les laisser cohérents.

La vérification web utilise un verrou configurable sur le nombre d’avertissements, précisément pour Svelte. Elle échoue lorsque les avertissements signalés dépassent ce seuil. Ces vérifications couvrent des conditions reproductibles dans le dépôt. Elles ne décident pas si l’architecture du CMS est la bonne ni si un contenu appartient au frontend. Cela reste une décision liée au projet et à l’architecture.

Mon processus commence par une conversation où mes idées partent dans tous les sens. L’IA organise la matière en une structure et propose des formulations bloc par bloc. Un article ne porte mon nom qu’après que j’en ai vérifié et corrigé la structure, les affirmations et le choix des mots, intégré ces corrections dans une autre ébauche produite par l’IA, lu chaque bloc de A à Z et décidé ce qui reste.

Si un client veut savoir si je comprends ce que je publie, qu’il m’interroge sur n’importe quel élément de ce site.

L’IA est un outil parmi tant d’autres. Elle n’est pas le résultat final. Les résultats sont yesid.dev, transit.yesid.dev et les systèmes qui font fonctionner leur contenu et leurs services.

Après avoir déployé Transit, j’ai aussi dû le maintenir en fonction et payer la facture mensuelle d’infrastructure.

Voici le chapitre 4 d’une épopée en six chapitres. Chapitres 1 à 3 : qui je suis. Chapitres 4 à 6 : ce que je construis. Précédent : Penser en matrices · Suivant : De 50 $ à 0 $ : une VM Oracle Always Free.