Sortez du goulot d'étranglement. Gardez le métier.

Avec un seul agent de code, vous êtes en pair programming : il tape plus vite, vous dirigez. Avec plusieurs, le rôle change de nature. Les agents cloud tournent dans leurs propres environnements isolés, travaillent sur leurs propres branches et renvoient des pull requests — rien de tout cela ne touche votre machine. [1] La promesse du parallélisme est réelle. Mais votre débit cesse d'être votre vitesse de frappe. Il devient votre capacité à garder toute une flotte alignée dans une direction.

Et les flottes échouent d'une manière bien précise. Pointez un deuxième agent sur le même checkout que le premier et, en quelques minutes, les deux modifient le même fichier — l'un écrase l'autre en pleine modification, et vous vous retrouvez avec des diffs à moitié appliqués et un build cassé sans savoir quel agent a fait quoi. [2] Le coût ne se limite pas au code cassé. Ce sont les tokens que vos agents brûlent à découvrir la collision, à la résoudre et à reconstruire — un éditeur d'outils pour agents parallèles évoque des crédits API gaspillés dans des conflits de merge et des changements à moitié finis [3] — et c'est vous, au bout du compte, qui démêlez des diffs qui n'auraient jamais dû exister.

La solution n'est pas un agent plus intelligent. C'est de traiter la coordination comme de l'infrastructure : des frontières de tâches explicites, une exécution isolée, et des merges fondés sur des preuves. [2] Réussissez cela, et vous cessez vraiment d'être le goulot d'étranglement — les agents construisent, et vous consacrez vos heures aux décisions que vous seul pouvez prendre.

La plupart des agents de code supposent qu'ils possèdent le répertoire du projet — ils lisent et écrivent les fichiers directement. Placez-en deux dans un même checkout et trois choses tournent mal rapidement : des collisions de fichiers, où l'agent A réécrit un fichier pendant que l'agent B le refactorise et où git ne voit que la dernière écriture ; une contamination de contexte, où B lit un fichier qu'A est en train de modifier à moitié et raisonne sur un état qui n'a jamais existé ; et une interférence de build, où les deux agents déclenchent des builds et des tests qui se disputent les mêmes répertoires de sortie et les mêmes ports. [4] Aucun de ces cas n'est rare. Ils apparaissent dès la première fois que vous essayez deux sessions sur un seul dépôt.

La solution standard, ce sont les git worktrees : un répertoire de travail relié, sur sa propre branche, qui partage le même historique .git — une isolation sans clonage. La commande existe depuis 2015 ; ce qui a changé, c'est qu'elle est devenue la façon standard de faire tourner plusieurs agents contre une même base de code. [2] Chaque agent reçoit son propre répertoire et sa propre branche, si bien qu'il ne peut toucher les fichiers de personne d'autre — et les conflits se déplacent au moment du merge, où les outils git habituels les détectent, au lieu de se produire silencieusement pendant que le travail est en cours. [5]

Les worktrees isolent les fichiers, mais pas tout le reste. Chaque agent a aussi besoin de sa propre base de données (ou branche de base de données) et d'un port de serveur de développement unique — sinon deux agents entrent quand même en collision sur les données et sur le réseau. [2]

Combien, c'est trop ? Ceux qui utilisent des worktrees locaux rapportent cinq à sept agents sur un même ordinateur portable comme plafond pratique — au-delà, les limites de débit, l'espace disque et la charge de relecture finissent par rattraper. [2] D'autres recommandent trois à cinq, disons donc trois à sept, selon à qui vous demandez. [4] Les agents cloud suppriment les limites liées à l'ordinateur portable, mais pas celle de la relecture.

L'isolation empêche les agents de se marcher sur les pieds. Elle ne les empêche pas de construire des choses incompatibles. Les vrais dépôts ont des fichiers "points chauds" partagés — routes, configurations, registres — et dire aux agents de rester dans des fichiers différents aide moins qu'on ne l'espérerait : un éditeur d'outils fait remarquer qu'un refactoring touchant l'interface d'un module affecte tous les fichiers qui l'importent, et que deux agents ajoutant des endpoints différents ont souvent besoin du même fichier de routage. [6]

La seconde moitié de la solution, c'est donc le découpage. Attribuez des tâches qui ne se chevauchent pas, pour que le chevauchement soit difficile par conception plutôt qu'évité par chance. [5] Le test est simple :

"Si deux tâches ont des listes de fichiers qui se chevauchent, elles doivent être séquentielles, pas parallèles." [7]

D'après notre expérience, la coupe la plus propre se fait par frontière, pas par couche : donnez à chaque agent une fonctionnalité ou une couture, pas une tranche de la même story verticale. Mergez ensuite les branches une par une, dans l'ordre des dépendances, en lançant build et tests après chaque merge, afin que chacune atterrisse dans une base de code sur laquelle l'agent suivant peut construire. [2]

Quand deux tranches dépendent vraiment l'une de l'autre, ne les faites pas tourner en parallèle en espérant que ça passe. Marquez l'une comme bloquée par l'autre dans Linear, et laissez la seconde démarrer seulement quand la première a été mergée. La dépendance devient visible sur le tableau au lieu de ne vivre que dans votre tête.

Chaque tranche a quand même besoin du même contrat que n'importe quelle story pour un seul agent : la mission, les contraintes, ce qui est hors limites, et ce que signifie "terminé". Une story bien cadrée est ce qui rend compatibles les hypothèses de deux agents sans réunion — nous expliquons comment en écrire une dans notre guide sur les stories pour agents de code.

Avec plusieurs agents en vol, vous ne pouvez pas parcourir chaque diff d'un coup d'œil — et vous ne devriez pas avoir à le faire. Notre conseil : déplacez la barre de qualité vers l'automatisation. Exigez des tests et une vérification automatisée avant que quoi que ce soit ne merge, et faites du merge lui-même un acte fondé sur des preuves plutôt qu'un acte d'espoir. La répartition des rôles qui en résulte est coordinateur, spécialistes et vérificateur — vous planifiez et jugez, les agents exécutent, et les vérifications contrôlent.

C'est aussi ce qui garde les tokens orientés vers un travail utile. Quand les critères d'acceptation vivent dans la story, un agent qui dérive échoue à ses propres tests au lieu de livrer sa dérive à un relecteur — ou pire, à un autre agent qui construit par-dessus. Quand ce n'est pas le cas, l'échec apparaît sous forme de conflit entre deux pull requests confiantes, plausibles et fausses.

Le bénéfice se voit dans ce vers quoi va votre attention : du temps de relecture consacré au jugement — est-ce le bon comportement, la bonne forme, le bon nom — plutôt qu'à l'archéologie des conflits et aux diffs mystérieux.

Il existe un coût plus discret que les conflits de merge, et il touche des gens qui codent depuis toujours. Les agents dévorent exactement le travail qui rendait la journée satisfaisante — les petites victoires complètes — et ce qui reste, c'est décider quoi construire, juger des compromis, relire et repérer les subtilités. [8] Certains qui livrent des fonctionnalités de cette manière ne ressentent plus rien ensuite : le travail s'est produit près d'eux au lieu de passer par eux. [9]

Un développeur a fait remonter ce sentiment à ses propres choix. L'IA ne lui a pas pris le plaisir, a-t-il conclu — il l'a cédé en choisissant la vitesse :

"J'arrête d'être la personne qui l'a fait et deviens la personne qui l'a approuvé." [11]

Un autre en fait une question de valeurs : nous automatisons les tâches auxquelles nous n'accordons pas de valeur — soyez donc honnête sur ce que vous voulez vraiment, le résultat ou la compréhension, et quand c'est la compréhension, faites-le à la dure. [10] C'est le sentiment derrière "je suis devenu un robot de relecture de code". Ce n'est pas une loi du développement avec l'IA. C'est ce qui se passe quand la répartition du travail est décidée par défaut plutôt que par choix. Alors décidez — avec intention — ce qui vous revient :

Le plaisir, finalement, est aussi un problème de conception. Laissez les agents prendre le code répétitif, et restez vous-même sur les problèmes difficiles et satisfaisants. [8] Un développeur plaide pour une lenteur intentionnelle et pour choisir des projets ambitieux :

"La clé pour s'amuser, c'est de se challenger juste à la limite de ses capacités." [9]

Optimiser purement pour livrer vite draine exactement cela. Comme l'écrit le même auteur : "La capacité à réfléchir à des problèmes complexes disparaît tout simplement." [9]

Il existe un contre-argument honnête, qui mérite d'être entendu : "Si vous faites tourner cinq agents en parallèle, vous ne programmez plus, vous faites du contrôle aérien." [8] C'est vrai quand la coordination vit dans votre tête. C'est précisément pourquoi la coordination — qui tourne ensuite, ce qui est bloqué, ce qui doit être relu — devrait être de l'outillage, pas de votre attention.

Quelques gestes concrets qui survivent au contact d'une vraie semaine : prenez pour vous la tranche la plus difficile d'une story et confiez le reste à la flotte. Gardez une partie du système qui reste toujours la vôtre — l'endroit où vous écrivez encore chaque ligne. Terminez la journée par une relecture qui relève de l'architecture, pas de l'inspection : c'est vous qui décidez de ce que le code doit devenir ensuite.

Ce n'est pas de la nostalgie. La motivation est un intrant de production : personne ne tient dans la durée une flotte à partir d'un travail qui ressemble à de la surveillance de machines. Gardez le métier, et les agents deviennent un levier.

Le conseil de ce guide se résume à trois habitudes : découper le travail pour qu'il ne puisse pas entrer en collision, merger une branche à la fois dans l'ordre des dépendances, et laisser les vérifications — pas vos yeux — être la première barrière de qualité. Aerunit transforme ces habitudes en automatisation pour les équipes qui utilisent Linear et Cursor Cloud Agents.

Il suit les relations blocks / blocked-by de Linear : quand une pull request merge, Aerunit trouve les issues que cette PR bloquait et les met en file vers Cursor Cloud Agents, afin que la tranche suivante démarre sur un code déjà mergé. C'est du merge séquentiel, fait pour vous. Quand un agent ouvre une PR, Aerunit lance une relecture de code dessus et peut renvoyer les constats à la session de l'agent. Et Aerunit lit chaque dépôt qu'une story touche avant de l'écrire, si bien que le travail multi-dépôts obtient un plan cohérent et une sous-issue par dépôt. Vous décidez toujours ce qui tourne ; Aerunit gère le "quoi ensuite" dès qu'un bloqueur merge.