De la spec à la PR : mon cycle de développement avec des agents

Les agents écrivent aujourd'hui l'essentiel de mon code. On pourrait croire que j'ai gagné du temps libre. En réalité, mon temps s'est déplacé.

L'étape où j'en passe le plus n'est ni l'écriture ni la review. C'est le cadrage : décider précisément ce qu'il faut construire, avant qu'un seul agent ne touche au code.

Ce n'est pas un hasard. Un agent exécute très bien une tâche claire, et très mal une tâche floue. Plus j'ai d'agents en parallèle, plus une imprécision au départ se multiplie à l'arrivée.

Dans l'article précédent, je décrivais ma configuration de Claude Code. Celui-ci montre comment je l'utilise, du premier échange sur une idée jusqu'au merge de la PR.

Le cycle en six étapes

Deux étapes sont vraiment les miennes : la première et la dernière. Entre les deux, mon rôle consiste surtout à organiser le travail et à faire respecter les règles.

1. Cadrer : se faire interroger avant de coder

Tout commence dans la session principale, celle qui tourne sur Fable. Je n'y demande pas de code. Je lance grill-me.

Le principe est simple : au lieu de répondre à ma demande, l'agent me pose des questions. Quels cas limites ? Quel comportement en cas d'erreur ? Qu'est-ce qui est hors périmètre ? Il continue tant que ma demande laisse des zones floues.

C'est souvent là que je découvre que je n'avais pas vraiment décidé ce que je voulais. Mieux vaut le découvrir à ce moment qu'en relisant une PR de 800 lignes.

Quand les questions s'épuisent, to-spec transforme la discussion en spec : l'objectif, le périmètre, les comportements attendus, les critères d'acceptation. Je la relis et je la corrige à la main. C'est le seul document du cycle que je considère comme entièrement à moi.

C'est l'étape qui me prend le plus de temps. C'est aussi celle qui en fait gagner le plus.

2. Découper : des tickets qu'un agent peut prendre seul

to-tickets découpe ensuite la spec en tickets. Un bon ticket, pour un agent, respecte trois conditions :

• Il est autonome. L'agent peut le terminer sans poser de question, parce que tout ce qu'il faut savoir est dans le ticket ou dans la spec.
• Il est indépendant. Il ne modifie pas les mêmes fichiers qu'un autre ticket traité en parallèle. Sinon, deux agents règlent le même problème de deux façons différentes.
• Il est vérifiable. Il se termine par un critère objectif : un test qui passe, une commande qui renvoie le bon résultat.

Le découpage décide aussi de l'ordre. Ce qui dépend d'autre chose attend. Ce qui est indépendant peut partir en parallèle.

3. Distribuer : un orchestrateur, plusieurs workers

La session Fable garde la vue d'ensemble : la spec, la liste des tickets, ce qui est en cours et ce qui est terminé. Elle ne code pas. Elle distribue.

Chaque ticket part dans une session worker séparée, qui tourne sur Opus. Je préfère des sessions séparées à une seule session qui lancerait des sous-agents : chaque worker peut lui-même déléguer à ses propres sous-agents, et chaque tâche garde son historique à part. Quand je veux savoir ce qui s'est passé sur un ticket, je n'ai qu'une conversation à relire.

Le nombre de workers dépend du découpage. Il n'y a pas de bon chiffre : autant que de tickets vraiment indépendants, et pas un de plus.

Pour lancer ces sessions, j'ai deux modes :

• À la main, pour une ou deux tâches. J'ouvre les sessions moi-même, et handoff transmet au worker le contexte dont il a besoin.
• Avec Pupitre, dès qu'il y a beaucoup de tickets indépendants. Pupitre crée un worktree par ticket, lance les sessions, détecte les conflits entre elles et me présente un résumé vérifié quand une branche est prête.

4. Exécuter : un worktree par ticket

Chaque worker travaille dans son propre worktree Git, sur sa propre branche. Jamais sur main. Deux agents ne peuvent donc pas écraser le travail l'un de l'autre, et un essai raté se supprime en une commande.

Pendant l'exécution, j'interviens peu. C'est là que la configuration décrite dans l'article précédent fait son travail :

• les rules injectent les conventions de la zone dès que le worker touche un fichier ;
• git-safety bloque les commandes dangereuses ;
• quality-checks relance formatter, linter et typecheck à chaque fin de tour, et renvoie les erreurs au worker tant qu'il y en a.

Quand un worker bloque ou part dans une mauvaise direction, je ne corrige pas son code. Je reviens au ticket ou à la spec, et je relance. Une dérive vient presque toujours d'un cadrage insuffisant.

5. Contrôler : rien n'arrive en review sans passer la gate

Avant qu'une branche m'arrive, elle doit passer une quality gate. Quand je passe par Pupitre, elle enchaîne cinq contrôles :

La référence fonctionne comme un cliquet : elle ne peut que s'améliorer. Un worker qui veut prendre un raccourci doit le déclarer explicitement avec --accept-debt <raison>, et ce raccourci entre dans un registre avec une date de réexamen. La dette existe toujours, mais elle n'est plus invisible.

Enfin, chaque merge produit une fiche de décision : ce qui a changé, et pourquoi. Six mois plus tard, c'est elle qui répond à la question « pourquoi ce code est-il écrit comme ça ? ».

6. Relire : comprendre avant de merger

C'est la seconde étape qui m'appartient vraiment. Quand une PR arrive, je suis toujours le même ordre :

1. Je lis d'abord la review CI. Des agents reviewers ont déjà analysé la PR et laissé leurs commentaires. Je commence par là pour savoir où regarder.
2. Je demande à l'agent de m'expliquer ce qu'il a fait, avec wait-what. Avant de lire le code, je veux comprendre l'intention et les choix.
3. Je lis le diff en entier. Ligne par ligne. La gate a déjà vérifié que le code compile, passe les tests et respecte les conventions. Moi, je vérifie qu'il résout le bon problème, de la bonne façon.
4. Je teste en local. Je lance l'application ou les tests moi-même. Un test vert ne prouve pas qu'une fonctionnalité fait ce que l'utilisateur attend.

Si je ne comprends pas une PR, je ne la merge pas. C'est la règle qui me protège de la saturation : mieux vaut une PR en attente qu'une PR validée sans être comprise.

Ce que j'en retiens

Les agents ont déplacé le travail vers les deux extrémités du cycle. En amont, il faut décider précisément quoi construire. En aval, il faut comprendre ce qui a été construit. Entre les deux, les agents exécutent, et les hooks et la quality gate font respecter les règles.

• Le temps gagné sur l'écriture se réinvestit dans le cadrage. Une heure de grill-me évite plusieurs heures de review sur une PR qui résout le mauvais problème.
• Le parallélisme se décide au découpage. Autant de workers que de tickets vraiment indépendants, pas plus.
• Quand un agent dérive, on corrige le ticket, pas le code.
• On ne merge que ce qu'on comprend.

Dans le prochain article, je détaille la review CI : comment six agents reviewers, un validateur et un script sans accès en écriture analysent chaque PR avant qu'elle m'arrive.