- Retour sur six semaines au cours desquelles le nombre de commits a fortement augmenté grâce à des améliorations de l’infrastructure de développement : automatisation des tâches répétitives d’un agent IA, suppression des temps d’attente liés aux builds, mise en place d’un système de worktrees parallèles, etc.
- Avec la commande
/git-pr, le processus de création de PR a été automatisé, ce qui élimine le coût du changement de contexte, et l’agent rédige lui-même des descriptions de PR plus détaillées
- En basculant l’outil de build vers SWC, le redémarrage du serveur est passé à moins d’une seconde, ce qui garantit un environnement de développement sans rupture de flux
- Grâce à la fonction de prévisualisation de Claude Code, l’agent peut vérifier lui-même l’UI, supprimant ainsi le goulot d’étranglement où le développeur devait valider chaque changement manuellement
- En supprimant chaque point de friction l’un après l’autre, on retrouve exactement le schéma de la théorie des contraintes (Theory of Constraints), où le goulot suivant apparaît immédiatement
- Désormais, l’attention se porte moins sur l’implémentation des fonctionnalités que sur la mise en place d’une infrastructure permettant aux agents de travailler efficacement et l’accélération de la boucle
Automatiser les tâches répétitives
- Au début, tout était fait manuellement : mise en staging des changements, rédaction du message de commit, rédaction de la description de PR, push, puis création de la PR GitHub
- Le premier tournant a été de reconnaître que ce travail relevait du pur travail répétitif (grunt work), avec un changement de rôle : de l’implémenteur au manager chargé de piloter des agents
- Une première compétence Claude Code,
/git-pr, a été créée pour automatiser l’ensemble du processus de création de PR
- Comme l’agent lit l’intégralité du diff et résume correctement les changements, la description de PR est plus détaillée que lorsqu’elle était rédigée à la main
- Le fichier
CLAUDE.md du codebase indique l’usage de Graphite, mais l’auteur préfère personnellement plain git et utilise donc /git-pr
- Plus encore que le gain de temps, l’effet majeur est la suppression de la surcharge mentale : le petit changement de contexte qui consistait à passer de « réfléchir au code » à « réfléchir à la manière d’expliquer le code » à chaque PR disparaît
Supprimer les temps d’attente
- Pour une prévisualisation locale, il fallait sans cesse quitter le travail en cours, arrêter le serveur de dev, puis le redémarrer sur une nouvelle branche
- Le build du serveur prenait environ une minute : assez long pour casser la concentration, mais trop court pour faire autre chose utile
- Le passage du build à SWC a ramené le redémarrage du serveur à moins d’une seconde
- Dès qu’un fichier est enregistré, le serveur est déjà prêt, sans laisser le moindre espace pour que l’attention se disperse
- La différence est comparée à celle entre « une conversation avec des silences gênants » et « une conversation qui coule naturellement »
Vérification autonome de l’UI par l’agent
- Auparavant, chaque changement d’UI devait être vérifié manuellement en prévisualisation locale, faisant du développeur le goulot d’étranglement de toutes les fonctionnalités
- Après les crashs répétés de l’extension Chrome, l’auteur est passé à la fonction de prévisualisation de Claude Code
- L’agent peut configurer la prévisualisation, conserver les données de session et voir directement à quoi ressemble réellement l’UI
- Cette logique a été intégrée au workflow : une tâche n’est considérée comme « terminée » que si l’agent a lui-même validé l’UI
- Comme la vérification peut lui être déléguée, le développeur n’intervient plus qu’au moment de la revue finale, et l’agent peut fonctionner de manière autonome pendant plus longtemps
- Le fait que l’agent repère lui-même ses erreurs s’est révélé bien plus important que prévu
Système de worktrees parallèles
- Une fois les rebuilds rapides et les prévisualisations automatisées en place, une nouvelle friction est apparue : il restait difficile de travailler confortablement sur plus d’une tâche à la fois
- Pour relire la PR d’un autre agent ou d’un collègue, il fallait checkout depuis la branche principale vers la branche de PR, puis rebuild et tester, mais cela entrait en conflit avec les changements non commités
stash → checkout → rebuild → test → switch back → pop stash, ou création manuelle d’un worktree, avec en plus des conflits de ports
- L’application nécessitait des ports distincts pour le frontend et le backend, et tous les worktrees partageaient les mêmes variables d’environnement, essayant donc de se binder aux mêmes ports
- Pour résoudre cela, un système a été mis en place afin d’attribuer automatiquement une plage de ports unique à chaque serveur lors de la création d’un worktree
- Il devient alors possible d’exécuter simultanément 10 prévisualisations
- On est passé d’une situation déjà écrasante avec seulement 2 branches parallèles à un fonctionnement avec 5 worktrees exploités en même temps
- Plusieurs agents peuvent travailler dans des worktrees séparés, chacun sur une fonctionnalité différente, et tourner de manière autonome jusqu’à ce que la vérification de l’UI soit terminée
- Après une forte implication dans la phase de planification, l’auteur n’intervient plus avant l’étape de revue de code
- Même la revue devient bien plus fluide : sans configuration, rebuild ni conflits de ports, le flux devient simplement lire, vérifier et merger
Le point clé, ce n’est pas l’IA mais l’infrastructure
- Le rôle change : au lieu de passer du temps à résoudre soi-même des problèmes complexes et à peaufiner une UI parfaite, il devient plus intéressant de construire l’infrastructure qui rend les agents efficaces
- Cela ressemble au passage d’un développeur solo à un manager d’une équipe d’une dizaine de personnes
- C’est un travail de plomberie (plumbing) peu spectaculaire, mais c’est lui qui détermine si l’on reste en état de flow ou si l’on se bat contre son environnement
- Chez Tano, le travail à plus fort levier n’a pas été le développement de fonctionnalités, mais la construction de l’infrastructure qui a transformé le flux de commits en torrent
La boucle : application de la théorie des contraintes
- Chaque étape supprime un type de friction différent :
/git-pr : suppression de la friction de formatage qui transforme des changements de code en PR- SWC : suppression de la friction d’attente entre le changement et l’observation du résultat
- Fonction de prévisualisation : suppression de la friction de validation lors de la vérification des changements
- Système de worktrees : suppression de la friction de changement de contexte entre plusieurs flux de travail
- Chaque fois qu’un goulot est éliminé, le suivant devient immédiatement visible : un schéma typique de la théorie des contraintes (Theory of Constraints)
- La nature même du travail change : ce n’est plus « utiliser des outils pour écrire du code », mais faire tourner une boucle de feedback serrée : démarrer une tâche → l’agent écrit le code → vérifier la prévisualisation → lire le diff → faire un retour ou merger → passer à la tâche suivante
- Quand cette boucle devient suffisamment rapide, l’attention n’a plus le temps de s’échapper, et le gain de vitesse devient un jeu en soi
- Au final, l’objectif du développement ne se déplace plus vers l’implémentation des fonctionnalités, mais vers la question de savoir à quel point on peut encore accélérer la boucle
- Le moment où la vitesse elle-même devient un plaisir d’ingénierie
Aucun commentaire pour le moment.