Faire jouer ses tickets par un agent

L’idée de départ tient en une phrase : un ticket entre dans la colonne « à faire », un agent le prend, une pull request en sort. Pas de chat, pas de copier-coller de contexte, pas d’humain qui joue les intermédiaires entre l’outil de suivi et l’éditeur.

La boucle

1. Lire le ticket et son contexte projet depuis Notion.
2. Ouvrir un espace de travail isolé et jetable.
3. Lancer une session d’agent avec ce contexte, et rien d’autre.
4. Ouvrir une pull request, remettre le lien sur le ticket.

Le point important est le troisième : une session par ticket. La tentation est de garder une session longue qui enchaîne le travail — elle finit toujours par mélanger deux sujets et par produire un diff que personne ne veut relire.

Ce qui n’a pas marché

Les tickets vagues. Un agent ne pose pas de question au bon moment ; il comble. Un ticket qui dit « améliorer la page profil » produit un diff plausible et inutile. Le travail de cadrage n’a pas disparu, il s’est déplacé : il est maintenant entièrement dans le ticket.

L’absence de garde-fou automatique. Tant que la vérification reposait sur ma relecture, la boucle n’allait pas plus vite qu’avant. Ce qui a changé les choses, c’est de faire tourner lint + types + tests à l’intérieur de la session, avant l’ouverture de la PR — l’agent corrige ses propres erreurs pendant qu’il a encore le contexte en tête.

Faire confiance au récit. Un agent qui dit « c’est fait et testé » se trompe parfois. La seule chose qui compte, c’est la sortie de commande dans les logs de session.

Ce que ça a vraiment changé

Pas la vitesse d’écriture du code — la vitesse de démarrage. Les tâches qui traînaient parce qu’elles demandaient trente minutes de remise en contexte pour dix minutes de travail effectif partent maintenant toutes seules. Le reste du temps est passé là où il sert : à décider quoi construire.