IA au quotidien - Paralléliser sa production agentique de code

Je suis développeur fullstack senior et, depuis 3-4 mois, je code presque exclusivement avec Claude Code.

Ce n'est pas une figure de style : je ne tape quasiment plus de code à la main, parce que je suis dorénavant convaincu que Claude est plus rapide et généralement plus fiable que je ne le suis moi-même sur l'activité de production "brute" de code. J'ai fini par l'accepter et me faire une raison : mon métier va changer.

Dans une série de posts, j'ai envie de raconter comment ça se passe pour de vrai : ce que ça change dans mon quotidien, les limites, les petites habitudes bizarres que j'ai prises et en quoi ça transforme en profondeur mon métier de développeur.

Précédemment, j'ai partagé un retour d'expérience sur un sujet très concret : comment je gère les quotas et la consommation quotidienne de Claude Code.

Aujourd'hui, j'aimerais aborder un autre aspect, beaucoup plus structurant dans mon usage au quotidien.

Le jour où ma production de code a cessé d'être mono-thread

Pendant longtemps, mon mode de fonctionnement était simple : une tâche, une branche, un seul flux de travail à la fois.

Bien sûr, il m'arrivait de gérer des urgences ou de contribuer a plusieurs branches en parallèle. Mais même dans ces cas-là, ma production de code restait fondamentalement séquentielle, tel un (mono)thread qui saute d'unité de travail en unité de travail dès qu'il est bloqué.

C'est un modèle très naturel pour un développeur. Le coût principal de mon métier a toujours été la concentration : comprendre un contexte, se représenter un modèle mental du système, éviter les erreurs introduites par les changements de contexte.

Pendant des années, optimiser ma productivité consistait surtout à protéger mon focus : éviter les interruptions, limiter le context switching, préserver le "flow" de développement.

… Et puis Claude Code est arrivé dans mon quotidien.

Au début, je l'utilisais comme un simple accélérateur : je lui confiais une tâche pendant que je réfléchissais au(x) "coup(s) d'après" (quelle tactique allais-je adopter pour enchaîner les incréments/commits afin de réaliser mon objectif de plus haut niveau (Sprint ou Epic))

Ce n'était pas tout le temps simple car, bien souvent, le LLM cassait ma réflexion d'anticipation en me ramenant brutalement au concret de la tâche qu'il implémentait : il fallait répondre à ses demandes de précisions, relire un plan que j'avais déjà relu et annoté 3 fois, review le code qu'il avait produit ou encore valider et vérifier que la feature qu'il avait implémenté fonctionnait comme attendu.

Pendant plusieurs semaines, j'ai travaillé avec des Scratch files dans IntelliJ, dans lesquels j'essayais d'organiser ma pensée textuellement et chronologiquement, en listant les 2 ou 3 prompts à enchaîner une fois la tâche courante terminée.

Je me forçais à ne me focaliser que sur des tâches de réflexion pendant que l'agent codait. Je pense que ça n'était pas optimal mais c'était une première étape nécessaire pour prendre confiance, solidifier ma pratique d'utilisation de l'IA tout en gardant très fortement le contrôle sur le code produit.

Et puis j'ai eu un déclic.

J'ai réalisé que je pouvais produire du code en parallèle, et pas seulement réfléchir en parallèle.

Pour la première fois, la limite n'était plus ma capacité à écrire du code dans sa forme la plus brute (taper au clavier), mais ma capacité à organiser plusieurs flux de travail simultanément.

C'est ce qui a entraîné un premier changement : je me suis mis à utiliser les worktrees de Git. On était alors mi-octobre 2025 et c'est à ce moment que ma production de code a cessé d'être mono-thread.

Un worktree Git, qu'est-ce que c'est ?

Tu ne connaîs peut-être pas la commande git worktree, je vais tâcher de te l'expliquer rapidement et simplement.

Si tu connais et utilises déjà cette commande, je vais t'économiser quelques tokens : tu peux sauter à la section suivante :-)

Un worktree c'est :

• Une duplication de ta working copy git d'origine, dans un répertoire à part
• Le graphe git est partagé entre la working copy d'origine et le worktree (un commit réalisé d'un coté se voit immédiatement de l'autre ; si tu fetch ton remote, les commits fetchés seront accessibles sur les 2 working copy, etc.)
• Une contrainte : une même branche ne peut être référencée par la HEAD que d'une seule working copy à la fois
• De manière plus terre à terre, et pour garantir que la configuration git de ton repository local soit la même au sein de tes worktrees, le .git d'un worktree n'est plus un répertoire, mais un fichier, dont le contenu est simplement :

gitdir: /absolute/path/to/original/working-copy/.git/worktrees/<worktree_identifier>

(oui, ça fait penser à un lien symbolique - mais les liens symboliques n'existant pas sur tous les OS, il fallait avoir quelque chose de portable)

Le fait que le .git soit un fichier peut d'ailleurs poser des problèmes à certains outils qui considèrent que le .git est tout le temps censé être un répertoire : perdu ! Ce n'est pas tout le temps le cas !

Le cycle de vie (création/suppression) d'un worktree est le suivant :

# Let's assume this is a git working-copy (there is a .git inside)
cd /path/to/original/working-copy

# Let's create a new worktree from current working copy
# new-branch is going to be created and checked out on worktree
git worktree add -b new-branch ../working-copy-wt1

# Let's list worktrees
git worktree list
/path/to/origin/working-copy     8a1a180 [main]
/path/to/origin/working-copy-wt1 8a1a180 [new-branch]

# Let's remove a worktree
git worktree remove /path/to/original/working-copy-wt1

Et concrètement, ça donne quoi au quotidien ?

Lorsque tu commences à travailler avec des worktrees, tu es rapidement confronté à plusieurs problématiques liées à la duplication de workspaces.

Comment gérer les fichiers ignorés ?

Lorsque tu crées un worktree, les fichiers en .gitignore de ton workspace d'origine ne sont pas recopiés car il les considère comme en-dehors de son périmètre.

La réponse (quasi) universelle à ce problème : les liens symboliques !

J’ai commencé par migrer de npm à pnpm sur mes frontends, afin de bénéficier de liens symboliques dans mon node_modules. Ça permet de dupliquer l’arborescence des node_modules de manière quasi instantanée là où, auparavant, la copie était longue et prenait de la place sur le disque.

Ensuite, je me suis rapidement outillé avec de petits scripts utilitaires me permettant de rapidement bootstrap un nouveau worktree en faisant un ln -s sur un ensemble de fichiers (majoritairement ceux que j’avais dans mon .gitignore), considérant ceux de mon workspace d’origine comme la référence. Le répertoire .claude se retrouvait notamment dans ce cas de figure, et me permettait de partager très simplement ma configuration claude (permissions, MCPs, skills et autres commandes spécifiques au projet) d’un worktree à un autre.

Sur ce sujet, l’utilitaire Worktrunk (partagé par mon ancien collègue Maxime Ribera) s'est mis à remplacer efficacement mes scripts maison depuis quelques jours: il me permet de copier automatiquement les fichiers ignorés, allouer des ports spécifiques au worktree (db, frontend, etc), gérer les stacked branches etc.

Et puis si tu utilises Claude Code Desktop, sache que ce dernier peut gérer les worktrees pour toi, et qu'il est possible de définir un .worktreeinclude qui est pris en compte à chaque fois que Claude Desktop crée un worktree.

Enfin, il y a le fait de gérer l'état de son backend, et notamment de la persistence (db). Je n'ai pas de silver bullet à te partager ici, car ça dépendra beaucoup de ton contexte et de la db que tu utilises :

• Si tu ne travailles que sur des frontends dans tes worktrees : le plus simple sera de démarrer une instance unique de backend partagée entre tous les frontends de tes worktrees, qui pointeront dessus
• Si ta DB n'est pas trop volumineuse : essaies d'embarquer la persistance de ta DB au niveau du filesystem de ton worktree.
• Dans le cas de DB volumineuses, l'objectif sera d'avoir du branching incrémental de DB (peu d'I/O pour garder une rapidité et un espace raisonnable) : features de templating de DB (CREATE DATABASE ... WITH TEMPLATE), snapshoting de volumes Docker ou de filesystem (ZFS), ou encore DBs Copy-on-write (type Xata). Je te laisse creuser car je n'ai pas moi-même encore beaucoup de recul là-dessus.

Comment gérer les worktrees dans Intellij ?

Au départ, et pour éviter d'avoir à configurer mon setup IDE à chaque worktree, j’ai rajouté tous mes worktrees dans un unique workspace Intellij.

C’était une mauvaise idée :

• Les recherches de fichiers retournent les mêmes fichiers en N exemplaires (sauf à constamment scoper les recherches aux bons modules) => beaucoup de bruit inutile
• La vue Project est problématique : il est possible de créer des scopes (ex: 1 par worktree) pour filtrer les répertoires affichés dans l’arborescence de la vue Project. Problème: dès lors que tu appliques un filtre en mode allow list, il est impossible d’inclure les répertoires ignorés (ex: node_modules) au niveau du filtre : c’est très handicapant !
• La vue git présente 1 graphe Git complet par worktree. L'entièreté de chaque DAG est donc dupliqué N fois ! (sauf là encore, à jongler constamment entre les filtres de paths dans cette vue)
• Les runners sont tous dupliqués en N exemplaires, tous nommés de la même façon mais intervenant sur des arborescences différents.

... Bref: c'était un enfer, j'ai changé assez rapidement mon setup !

J’ai plutôt fait en sorte de créer un workspace Intellij distinct par worktree.

L’inconvénient : il a fallu enrichir le process de création de worktree en pré-configurant mon workspace Intellij (spoiler alert: tout n’est pas configurable facilement car certaines infos sont persistées en-dehors de l’espace de travail et nécessitent une configuration manuelle).

Sur ce point, mise (et son plugin intellij) m'a beaucoup aidé pour pré-configurer les runtimes nécessaires à mes projets (en plus de rendre cet aspect reproductible en CI/CD).

Je n’ai pas tenté de faire l’exerice sous VSCode car ce n’est pas un IDE que je maîtrise aussi bien qu’Intellij, mais je pense que la plupart des problèmes que j’ai rencontré sous Intellij se retrouvent sur VSCode car aucun de ces 2 IDEs ne considère les worktrees comme de réels "first class citizens".

Quelle stratégie de création de worktrees ?

Une autre problématique rencontrée a été de déterminer le moment où j'avais réellement besoin d'un worktree : par exemple, est-il raisonnable de créer un nouveau worktree dès que je commence à travailler sur une nouvelle feature ?

Dans les sections précédentes, tu as pu constater que le setup d’un worktree n’est pas toujours une opération indolore : même si on peut automatiser un certain nombre d’étapes, il en reste certaines manuelles (config IDE notamment).

D’autre part, mes premiers usages des worktrees m'ont fait prendre conscience d'une limite forte : ma capacité cognitive à pouvoir gérer plusieurs tâches en parallèle.

🤫 Je vais te faire un aveu : au-delà de 3 tâches en parallèle, mon cerveau 🤯

J’ai donc fait en sorte de me limiter à seulement 3 worktrees, que j’ai passé du temps à configurer une fois pour toutes à tous les niveaux (liens symboliques, intellij, etc.).

Et au sein de chacun de ces worktrees, je bascule de branche en branche (feature branch par-ci, hotfix par-là).

J’ai utilisé ce mode de fonctionnement entre fin novembre et mi-janvier environ, et franchement j’en était plutôt satisfait ! J’étais limité à 3 tâches de production en parallèle (maximum), mais c’était OK compte tenu de mes limites cognitives.

… et puis le 13 janvier, un message anodin de Tristan DEBROISE sur le Slack Dev with AI a tout remis en question

(en vrai, Maxime Ribera m’en avait aussi un peu parlé avant ce message, mais je n’avais pas pris le temps de tester vibe-kanban à ce moment-là 🙇)

Un scaling au-delà de 3 tâches avec Vibe Kanban !

Je t'avoue que je n’étais pas prêt : Vibe Kanban est l’outil qui est venu adresser la plupart des problèmes que j’avais rencontré les semaines précédentes, en fluidifiant certaines aspects et en y rajoutant un aspect visuel !

• Le lancement se fait en 5 secondes : npx vibe-kanban@latest et c’est parti ! (je ne suis généralement pas fan d’utiliser des @latest, mais depuis 3 semaines d’utilisation avec des releases quasi quotidiennes, je peux te garantir que mettre à jour au fil de l’eau est à la fois stable et utile !)
• Très simple d’utilisation : très visuel avec une représentation Kanban (TODO / In Progress / In Review / Done / Cancelled)
• L’implémentation d’une Tache (notion d’Attempt) crée un worktree Git dédié et démarre une session/conversation avec un Agent donné (Claude Code, Gemini, Codex, OpenCode, Copilot, Cursor, etc.) et en réutilisant ton assistant installé localement sur ta machine (avec ses préférences, ton authent, etc.)
• Chaque discussion avec l’AI Assistant utilise un Profile d’Agent : mode plan (ou non), quel modèle, quel prompt, etc
• Il est possible de customiser ce qui se passe lors de la création d’un worktree sur un repository donné (possibilité d’exécuter des commandes suite à la création du worktree, possibilité de copier des fichiers/répertoires depuis le workspace d’origine, etc.)
• Il est possible de rassembler plusieurs repositories au sein d’un projet (utile si tu n'es pas sur un monorepo)
• Toutes les discussions/prompts sont historisés
• Il y a un indicateur visuel qui montre, sur chaque tâche, si le LLM est en train de travailler … ou qu’il est en attente d’un input de ta part (très pratiques pour s'y retrouver lorsque tu parallélises plusieurs tâches).
• Des notifications visuelles ou sonores (bien identifiables 🐄 si tu laisses les défauts) te permettent d'être directement mis au courant d'un agent qui s'est suspendu.
• Il y a la possibilité de créer plusieurs sessions de discussions autours de la même tâche, si tu souhaites utiliser des contextes cloisonnés sur le même worktree
• Un raccourci existe pour ouvrir ton IDE favori dans le worktree de la discussion courante
• Depuis mardi et l’annonce de la version Cloud, il est même possible d’utiliser une base de données partagée et donc de consulter, revoir et collaborer sur les tâches de tes collègues. Pour moi c’est une killer feature car revoir le prompt et la discussion va être, dans un monde où le vibe coding devient prépondérant, encore plus important que de revoir le code généré !
• Un Diff editor est intégré pour comparer le contenu du worktree avec une branche cible et faire des commentaires sur les lignes du diff
• Un Rebase est possible depuis l'UI sur une branche cible, et il est possible de résoudre les conflits via l’AI (et franchement, je suis assez étonné du résultat !.. l'AI sait très bien résoudre les conflits !). Sur ce point, il faut vraiment que je me force à utiliser jujutsu car il possède des propriétés très intéressantes.
• On peut créer une PR très facilement depuis l'UI (en ciblant une branche en particulier)
• Il est possible de démarrer et visualiser le frontend dans une iframe intégrée à vibe-kanban (une ligne de commande est paramétrable pour lancer un “dev server” depuis le worktree cible). Très pratique pour tester rapidement un bugfix sur le front.
• Il est possible qu’une Tâche créée des sous-taches via le MCP de vibe-kanban
• Tu as accès à un terminal positionné au niveau du worktree
• … et je suis sûr que j’en oublie !

Ça fait plus de 3 semaines que j’utilise vibe-kanban au quotidien et c’est vraiment l’outil qui m’a fait changer de dimension au niveau de la parallélisation de mes tâches agentiques (fini le jonglage avec les worktrees dans intellij, tout est maintenant géré dans/par Vibe Kanban !)

Il me permet notamment de rentabiliser plus qu'avant mes fenêtres de tokens inutilisées pour traiter des tâches en background pendant que je travaille sur des tâches non-IA. Et puis lorsque je veux débugger / zoomer sur un problème, j'ouvre le worktree dans Intellij et je fais comme avant.

EDIT: Le 10 avril, Bloop, la société derrière Vibe-kanban, a annoncé fermer. Le projet restera opensource, mais on peut imaginer qu'il n'évoluera pas (plus ?) à la même vitesse qu'avant malheureusement.

Le temps n’est plus la bonne unité

Lorsque je lance un Agent sur 5 Tâches le soir en partant me coucher, et qu'il m'en one-shot 2 pendant la nuit : cela a produit la même valeur que ce que j’aurais sûrement passé 1j ou 2j à produire pendant la journée, il y a de ça 2 ans.

Ça m'interroge énormément sur la valorisation du temps passé versus la valeur produite.

Sachant que je reste le garant du code produit, particulièrement celui qui part en prod (à l'opposé des outils dont je suis le seul consommateur/utilisateur). Qu'il m'incombe donc d'être absolument vigilant sur ce qui est généré. Mais qu'il est très difficile de maintenir cette vigilance dans le temps, sans qu'elle ne s'érode à force d'être grisé par les features qui s'enchaînent et la performance des modèles qui sans cesse s'améliorent.

Et puis il y a des effets pervers à tout ça : la barrière entre le travail et le perso n'a jamais été aussi fine depuis qu'il m'est très facilement possible de lancer un agent sur un sujet dès qu'une idée me passe par la tête (j'en ai beaucoup en ce moment !)

Et puis il y a l'IA fatigue dont on ne parle que trop peu (ainsi que cette étude qui évoque aussi ces sujets, ainsi que l'article sur The AI Vampire - merci Sylvain Wallez dans les commentaires)

Tout ceci me fait de plus en plus m’interroger sur mon rapport à la valeur travail (une auto-introspection ici et là)

Je n’ai pas les réponses, et je dois encore y réfléchir avant de pouvoir coucher tout ça par écrit (peut-être dans un futur article).