Un affichage honnête des délais de votre agent de code

Le premier article posait la question de l’organisation : faut-il attendre, traiter une petite tâche ou entamer un autre sujet pendant que l’agent travaille ? Ce tutoriel crée un petit état local indiquant le prochain créneau où votre attention pourrait être nécessaire.

L’exemple ne prédit pas automatiquement la durée d’une tâche. Vous, ou votre agent, renseignez explicitement un état et, si vous avez de bonnes raisons de le faire, une fourchette approximative. Le but est de rendre cette information lisible et d’éviter qu’une prévision périmée paraisse encore fiable.

1. Essayer un exemple isolé

Il vous faut Python 3 dans un terminal macOS ou Linux. Vérifiez-le avec python3 --version. Téléchargez et examinez agent-eta.py, puis enregistrez-le dans un dossier de travail temporaire. Exécutez les commandes ci-dessous depuis ce dossier. Aucun paquet à installer ni paramètre de Claude Code à modifier.

Chaque tâche doit disposer de son propre fichier JSON local. Ne partagez pas un même fichier entre plusieurs agents. Le dossier parent doit déjà exister.

python3 agent-eta.py --file ./eta-demo.json write --state working --phase verification --min 5 --max 12
python3 agent-eta.py --file ./eta-demo.json show

Au départ, le résultat ressemble à ceci :

verification | WORKING | rough next-attention window 5-12m | declared, not calibrated

La fourchette de cinq à douze minutes est une donnée fictive de démonstration. Ce n’est ni une mesure de performance, ni une garantie, ni une indication sur votre tâche réelle. Elle estime le moment où votre attention pourrait être requise, pas celui où une solution terminée serait garantie.

2. Ne pas inventer les délais inconnus

Si rien ne permet de justifier une fourchette, indiquez seulement l’état :

python3 agent-eta.py --file ./eta-demo.json write --state working --phase research

L’affichage indique next attention window unknown. Il ne remplace pas une estimation absente par zéro. Tant qu’une fourchette reste valable, le rendu en soustrait le temps écoulé. Lorsque sa borne haute est dépassée, il affiche declared window expired; refresh needed au lieu de laisser un compte à rebours trompeur bloqué à zéro.

3. Signaler quand une intervention est nécessaire

python3 agent-eta.py --file ./eta-demo.json write --state needs-input --phase implementation
python3 agent-eta.py --file ./eta-demo.json write --state waiting --phase external
python3 agent-eta.py --file ./eta-demo.json write --state ready --phase review

Exécutez ces commandes séparément pour représenter de vrais changements d’état. Ce n’est pas une suite à lancer aveuglément. INPUT NEEDED prend le pas sur toute estimation de délai. READY FOR REVIEW ne signifie pas que les tests ont réussi. Une attente externe sans fourchette renseignée reste de durée inconnue.

Le script ne voit ni les demandes d’autorisation réelles ni les résultats des tests. Son état ne vaut que par la fraîcheur et l’exactitude des informations fournies.

4. Intégrer des mises à jour explicites au travail

Pour un premier essai, mettez vous-même le fichier à jour à chaque changement de phase. Si vous confiez ensuite cette tâche à un agent, fournissez-lui le script approuvé et un fichier distinct, imposez une mise à jour avant toute demande d’intervention et à l’arrêt du travail, et demandez-lui de ne pas inventer de fourchettes.

C’est une consigne de travail, pas une intégration automatique vérifiée à Claude Code. Une ligne de statut native ou un adaptateur de hooks demanderait un travail séparé. Un appel à show affiche un instantané ; il ne crée ni tableau de bord en direct ni interrogation périodique en arrière-plan. Relancez-le lorsque vous faites le point sur la tâche.

Observez si cela vous aide à choisir une activité adaptée au temps disponible. Le chiffre seul ne signifie pas que vous pouvez partir sans risque : une question peut survenir plus tôt que prévu.

5. Tester les limites, puis supprimer l’état

L’implémentation a été testée avec des horloges et des entrées fictives : fichiers absents ou mal formés, délais inconnus, fourchettes expirées, états nécessitant une intervention, valeurs invalides et changements d’horloge. Un état de plus de 24 heures est signalé comme périmé. Aucune précision de prédiction sur des tâches réelles n’a été établie.

Seuls des noms d’état et de phase prédéfinis, un horodatage de mise à jour et la fourchette fournie sont conservés. Aucun appel réseau, aucune capture de prompt, aucune archive historique. Le même fichier est écrasé à chaque mise à jour et n’est pas supprimé automatiquement. Supprimez eta-demo.json après l’essai avec votre gestionnaire de fichiers. Supprimer le script et ce fichier suffit à annuler l’exemple ; aucun réglage de l’agent n’est à restaurer.

L’étalonnage à partir de l’historique viendra plus tard, lorsque des tâches terminées et comparables seront disponibles. D’ici là, mieux vaut une fourchette déclarée dont l’expiration est visible qu’une prévision faussement précise sans fondement.