Comment gagner en productivité avec Claude Code

• 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

[t7vonn]

En tant que reviewer, mon expérience n’est franchement pas terrible quand je vois une PR Description écrite par une machine. Je me dis que ça pourrait peut-être s’améliorer avec un bon prompt tuning, cela dit...

[GN⁺]

Réactions sur Hacker News

• On a l’impression du retour de l’indicateur « lignes de code par semaine » des années 90
  Dire qu’on « fait plus de PR » ne prouve pas que l’IA fonctionne bien, seulement qu’on fusionne davantage
  Juger la performance uniquement au volume produit, sans tenir compte de la qualité du code, des bugs ni de la charge de maintenance, ne vaut pas mieux que les mauvais indicateurs poussés par les managers d’autrefois
  Au fond, on dirait qu’on n’était pas contre les mauvais indicateurs, mais contre le fait même d’être mesuré

  • J’utilise aussi l’IA tous les jours, mais je vise plutôt la réduction des commentaires de PR, des itérations et des bugs que le « nombre de lignes »
    Le vrai objectif, c’est d’obtenir des résultats simples et à fort impact
    J’expérimente aussi le fait de lancer plusieurs agents en parallèle pour tester différentes implémentations, puis fusionner les meilleures idées
    Je rassemble aussi la documentation et les exigences pour poser des questions à l’agent, et je généralise les retours de code review en checklists à réutiliser dans les revues suivantes
  • L’auteur a aussi écrit un billet sur le burn-out et l’anxiété, et cette obsession de la productivité semble liée à ça
    Travailler au point d’en être malade n’est pas une fierté, c’est le signe d’un système défaillant
  • Dès la première phrase, l’auteur reconnaît que « les commits sont un mauvais indicateur, mais c’est le signal le plus visible dont je dispose »
  • Le nombre de lignes de code n’a pas de sens à l’échelle individuelle, mais il peut en avoir pour estimer la taille d’un système dans son ensemble
    Par exemple, le modèle COCOMO est suffisamment crédible pour être utilisé même devant les tribunaux afin d’estimer la valeur d’un système
  • Dire qu’on n’était pas contre les mauvais indicateurs mais contre la mesure elle-même revient au fond à se demander s’il existe vraiment de bons indicateurs
    La plupart des développeurs n’ont pas envie d’être réduits à des chiffres
    En revanche, les défenseurs de l’IA estiment qu’il faut mesurer pour prouver les améliorations

• Je pense qu’il faut utiliser les LLM de manière à réduire la charge cognitive
  Les humains sont mauvais en multitâche, et les LLM ne compensent pas vraiment cela
  Au lieu de demander à Claude d’implémenter à ma place, je l’utilise plutôt pour me guider pas à pas dans l’implémentation
  De cette façon, je comprends l’ensemble du processus tout en gardant à la fois les détails et la vue d’ensemble
  Il suffit de confier à Claude les parties répétitives et mécaniques

  • J’utilise aussi un workflow centré sur le POC
    Je pose des questions au LLM pour qu’il comprenne le problème, j’écris moi-même le code essentiel, puis je lui fais élaborer le plan du reste de l’implémentation
    Le LLM est très bon pour lire du code, l’expliquer et effectuer des tâches simples, tandis que je me concentre sur le choix de la direction de résolution du problème
  • J’aime tellement cette idée que je vais l’essayer tout de suite
    J’expérimente des prompts comme « dresser la liste des hypothèses » ou « lister les décisions non prévues dans le plan » pour suivre ce que le LLM a décidé à ma place
  • Certains trouvent ce type de collaboration intensive amusant et immersif
    Si l’on comprend bien le fonctionnement de Claude, la vérification devient plus efficace, et plus on accumule d’expérience, plus la gestion de la qualité devient facile

• Quand on fait tourner plusieurs agents pour construire une grosse fonctionnalité, on finit par rencontrer un énorme problème d’augmentation du temps de review
  Lire le code de quelqu’un d’autre (ou d’une IA) est plus difficile que l’écrire soi-même
  On peut compenser en partie avec l’automatisation des tests, mais il est difficile d’avoir une confiance totale

  • C’est pourquoi j’insiste sur la rigueur de la phase de planification
    Il faut clarifier le périmètre, les tests et le plan de documentation, puis appliquer des bots de code review (Sourcery, CodeRabbit, Codescene) ainsi que des règles de linting strictes
    J’utilise aussi le BDD, les property tests, les tests e2e, les audits de code et même les tests de mutation/fuzzing
    L’avantage du code produit par des agents, c’est qu’il libère du temps pour ce type de contrôle qualité
  • Le goulot d’étranglement vient aussi du fait que les LLM produisent souvent des modifications inutilement verbeuses et superflues, ce qui élargit le périmètre de review
  • En revanche, pour des changements à faible risque comme de petites corrections ou des améliorations UI, un déploiement automatique est envisageable
    Certains testent un déploiement progressif avec des approches comme 100 PRs a day
  • Je ne déploie pas tel quel le code généré par l’agent, je n’utilise que le résultat qu’il produit
  • La code review peut devenir bien plus rapide avec la pratique
    Si l’on découpe le travail finement et qu’on fait confiance aux tests, la review de code IA devient aussi plus légère
    Je regarde les cas de test avec plus d’attention et je termine la review du code rapidement
    Je ne fais pas tourner plusieurs agents en parallèle, mais grâce à l’IA ma productivité a clairement augmenté

• Si la rédaction des PR devient une simple automatisation, on perd une occasion d’auto-vérification
  En écrivant la description d’une PR, je repérais souvent des bizarreries dans mon code
  Le moment où je devais l’expliquer en anglais était mon dernier sanity check

• Grâce au système de worktree, les changements de contexte sont devenus plus faciles, mais en même temps la fatigue mentale a augmenté

  • J’ai le sentiment qu’il faut davantage de recherches sur l’impact réel du parallélisme entre plusieurs agents sur la vitesse ou la précision
  • Pour ma part, je préfère me concentrer sur 1 ou 2 tâches à la fois
    En divisant en petites unités et en gardant des cycles de review courts, il est plus facile de maîtriser la qualité
  • J’utilise une stratégie qui consiste à empiler une file d’attente en laissant l’agent générer les PR, puis à tout relire plus tard
  • Je fais tourner plusieurs worktrees en parallèle, mais je ne les surveille pas en permanence
    Ce qui me plaît, c’est de pouvoir revenir le lendemain sans casser mon flux et constater que ça a avancé entre-temps

• Je reste sceptique face à l’idée que Claude écrive du code immédiatement de grande qualité
  En pratique, il faut plusieurs cycles de feedback et de correction, et gérer plusieurs tâches en parallèle devient alors plutôt inefficace

• Claude Code est révolutionnaire comme outil d’apprentissage, mais la qualité du code généré reste irrégulière
  En apprenant Flutter/Dart, j’ai étudié en demandant à Claude de m’expliquer les concepts, et j’ai pu créer une application en une semaine sans livre
  Cela ressemble à une encyclopédie interactive

  • Je suis entièrement d’accord pour cet usage. C’est vraiment révolutionnaire
  • Beaucoup de gens l’utilisent de cette façon
    À des questions comme « quelle est la manière idiomatique de faire X dans ce langage ? », il donne immédiatement des réponses utiles
    Mais plutôt qu’un agent qui change le monde, ce n’est au fond qu’un très bon outil
  • Il faut utiliser l’IA non pour remplacer les humains, mais pour accélérer l’apprentissage et la montée en compétence
    Cependant, le marketing excessif a des effets négatifs sur l’économie dans son ensemble
    On s’inquiète aussi de voir de jeunes générations renoncer à certaines carrières à cause du mirage selon lequel l’IA remplacerait les emplois

• Il était dit que « le redémarrage du serveur est passé sous la seconde après le passage à un build avec SWC »,
  SWC signifie Speedy Web Compiler et c’est un outil de transpilation rapide sans vérification de types
  La documentation NestJS explique la même chose

• Utiliser un LLM n’est pas en soi une raison de se vanter d’une explosion de productivité
  Si tout le monde emploie les mêmes outils, la ligne de base monte simplement
  De plus, si de grands volumes de code générés par l’IA ne sont pas correctement relus, la qualité à long terme reste incertaine

  • La performance doit être jugée non par simple comparaison, mais à partir de ses propres résultats et de la valeur produite
  • Dire qu’on est devenu plus productif grâce à des compilateurs modernes (comme GHC) relève du même raisonnement

• Les LLM améliorent bien la productivité, mais mesurer cela avec un graphique du nombre de commits n’a aucun sens
  C’est aussi absurde que de juger la qualité avec le LOC

  • Grâce à Claude, j’ai moi aussi implémenté en quelques jours une fonctionnalité que je repoussais depuis des mois
    J’écris moi-même le code pour le comprendre, et Claude m’aide beaucoup comme partenaire de décomposition des tâches et de review
  • Le meilleur indicateur d’amélioration d’une codebase, c’est le LOC négatif, autrement dit la suppression de code inutile
  • D’après mon expérience, les meilleurs ingénieurs sont ceux qui réduisent le code
    La vraie productivité, c’est la capacité à remplacer du code complexe par des abstractions simples