Spécifier avant de déléguer

« La machine » l’a posé : un prompt est une spécification, et tout ce qu’elle ne dit pas sera comblé par la moyenne du corpus.

Avec un agent, la règle change d’échelle. Vous ne demandez plus une réponse à relire, vous déléguez une tâche à une boucle qui agit. Une ambiguïté ne vous rend plus un paragraphe à jeter : elle vous rend une exécution complète, cohérente, et parfaitement convaincue du malentendu.

La qualité de la sortie ne dépasse jamais la qualité de la demande. C’est la phrase que je me répète avant d’appuyer sur Entrée.

---

Pourquoi une demande floue coûte-t-elle plus cher avec un agent ?

Parce que chaque blanc comblé devient le socle de l’itération suivante. En chat, une demande floue coûtait une réponse à jeter. La boucle agentique change complètement l’arithmétique : l’agent exécute son interprétation, puis il bâtit dessus, appel d’outil après appel d’outil, avec une cohérence parfaite. Au bout : un diff de huit cents lignes, plausible, soigné, et complètement à côté.

Le piège, c’est que les coûts sont asymétriques. Dix minutes passées à fermer une spécification, ça se voit — ça ressemble même à du sur-place pendant que l’agent « pourrait déjà être en train ». Le prix de l’autre option, lui, ne se voit qu’après, quand vous relisez un grand diff convaincant en cherchant où exactement il a divergé.

Le travail de spécification n’a pas disparu avec la délégation. Il s’est juste déplacé avant l’exécution, là où il est bon marché.

Et le blanc le plus coûteux, ce n’est jamais le contenu de la tâche. C’est la condition de fin. La boucle converge vers ce que vos outils vérifient : une demande sans critère de fin vérifiable laisse l’agent décider lui-même quand c’est terminé. Et un modèle optimise la vraisemblance — y compris celle d’un rapport de succès.

Que contient une demande exécutable ?

Trois choses : un objectif en comportement observable, un périmètre fermé en négatif, et des critères d’acceptation qui servent de conditions de sortie à la boucle. « Prompting pour développeurs » a donné la grammaire — objectif, contraintes, périmètre. La délégation y ajoute ses exigences propres.

L’objectif, en comportement observable. Comparez ces deux formulations et demandez-vous laquelle une boucle peut atteindre :

Améliore la gestion d'erreurs

ou

Toute réponse 5xx de l'API amont doit être réessayée deux fois,
puis journalisée avec son corps

La première est une intention. La seconde est une spécification, qu’un agent peut viser et que vous pouvez vérifier.

Le périmètre, fermé en négatif. Les agents débordent par défaut. Ce qui ne doit pas bouger se dit explicitement : pas de nouvelle dépendance, pas de changement de schéma, uniquement ce module.

Les critères d’acceptation, comme conditions de sortie. Chaque critère que l’agent peut exécuter lui-même (« pnpm build passe », « ce test, écrit d’abord, passe au vert ») transforme la délégation en boucle qui converge sans vous. Chaque critère que vous seul pouvez juger marque l’endroit où la session devra s’arrêter et vous attendre. Distinguez les deux dès la demande : vous venez de placer les points de rendez-vous de la session.

Une dernière frontière, souvent floue au début : la spécification dit ce qui doit changer ; le dossier de contexte dit ce qui est vrai et interdit en tout temps. Si vous vous surprenez à recopier vos conventions dans chaque demande, c’est un bug du dossier — à corriger là-bas, une fois pour toutes les sessions.

Jusqu’où faut-il spécifier ?

Jusqu’au niveau que justifie le coût du malentendu, pas plus. Tout ne mérite pas une spécification écrite : l’exiger partout produit de la bureaucratie, puis de la triche.

Ce coût, c’est le produit de trois facteurs : la taille du diff attendu, sa réversibilité, et l’écart entre ce que vous voulez et ce que ferait la moyenne du corpus. Ce qui donne trois régimes :

• Petite, réversible, conventionnelle : une phrase suffit. L’agent comblera les blancs avec la moyenne, et la moyenne vous convient.
• Touche ce qui fait votre singularité (vos déviations délibérées, vos invariants) : chaque écart à la moyenne doit être écrit, sans quoi il sera « corrigé ».
• Structurante ou difficile à défaire : traitement complet. Spécification écrite, puis plan validé avant exécution.

Le calibrage rend aussi un verdict sur vous, et celui-là pique un peu. Si vous n’arrivez pas à écrire le critère d’acceptation, ce n’est pas votre formulation qui coince : c’est que la tâche n’est pas claire pour vous non plus. Ne déléguez pas un flou. Découpez jusqu’à la première sous-tâche dont la fin se décrit, et commencez là.

Pourquoi demander un plan avant le code ?

Pour exécuter le malentendu à blanc, pendant qu’il coûte encore zéro ligne de code. Sur les tâches structurantes, intercalez un artefact entre l’intention et le code : le plan.

La plupart des harnais ont un mode dédié — un agent en lecture seule, qui explore et propose sans rien toucher. Mais vous n’avez même pas besoin de la fonctionnalité :

Propose un plan. N'écris rien pour l'instant.

Ça marche partout, et l’interprétation de l’agent devient visible avant d’être exécutée.

Un plan se relit comme une revue de conception, pas comme de la prose. Quels fichiers, dans quel ordre, quelle stratégie de vérification ? Et surtout : qu’est-ce qui manque ? Les tests dont il ne parle pas, le module que vous pensiez central et qu’il ignore, la migration qu’il ne mentionne nulle part. Ce sont exactement les malentendus que vous payerez dans le diff.

Le plan travaille aussi dans l’autre sens, et c’est ma partie préférée. L’agent vient d’explorer votre repo : il est très bien placé pour interroger votre intention. Demandez-lui de poser ses questions avant de proposer. Chaque question révèle un point que votre demande laissait à sa discrétion, et chaque réponse rejoint la spécification.

LE CRAFTOMANCER

Un plan approuvé en diagonale est un chèque en blanc. Valider engage : à partir de là, l’agent traite chaque point du plan comme une consigne de votre main, et exécutera sans hésiter le point que vous n’avez pas lu. Le plan est le seul moment où le malentendu coûte zéro ligne de code. Dépensez-y l’attention que vous comptez économiser sur le diff, et lisez d’abord ce que le plan ne dit pas.

Où écrire la spécification ?

Ailleurs que dans le fil de la session, parce qu’une spécification qui ne vit que là meurt avec elle. Un ticket, un fichier de travail dans le repo, peu importe le support du moment qu’il persiste. Trois raisons :

• Elle survit au redémarrage. Les longues sessions diluent l’attention, et il vaut souvent mieux redémarrer qu’insister. Repartir d’une session vierge ne coûte presque rien quand la spécification est un fichier à recharger. Ça coûte toute la négociation quand elle est éparpillée dans quarante tours de conversation.
• Elle se relit et se partage. Un collègue — ou vous dans deux semaines — peut auditer ce qui a été demandé, pas seulement ce qui a été produit. Bonus non négligeable : la description de la PR est déjà à moitié écrite.
• Elle s’amende explicitement. Le périmètre bougera en cours de route, c’est certain. Quand il bouge, c’est le document qu’on corrige, pas une consigne de plus empilée dans le contexte par-dessus celles qu’elle contredit.

Un dernier réflexe pour la route : quand une exigence revient de spécification en spécification, elle demande sa promotion. Ce n’est plus une consigne, c’est une convention. Sa place est dans le dossier de contexte, payée une fois pour toutes les sessions à venir.

En pratique

• Calibrez l’effort de spécification sur le coût du malentendu : taille du diff attendu, réversibilité, écart entre votre projet et la moyenne du corpus.
• Donnez toujours une condition de fin vérifiable. Sans elle, c’est l’agent qui décide quand c’est fini.
• Fermez le périmètre en négatif : ce qui ne doit pas bouger se dit explicitement.
• Pour les tâches structurantes, exigez un plan avant le code, faites poser les questions, et lisez ce que le plan ne dit pas avant de valider.
• Persistez la spécification hors de la session : elle survit aux redémarrages, se relit, et nourrit le dossier de contexte quand une exigence se répète.
• Si le critère d’acceptation refuse de s’écrire, ne déléguez pas encore : découpez jusqu’à une fin descriptible.

Vérifiez votre modèle

Quatre questions pour voir si la demande tient debout. Cliquez une réponse : le verdict s’affiche.

RUN · III 0 / 4

jack in — choisissez votre réponse

Dans une demande floue, quel blanc coûte le plus cher ?

▶ la condition de fin ▶ le détail de l’implémentation attendue ▶ le nom des fichiers à modifier

Sur quoi calibrer l’effort de spécification ?

▶ le coût du malentendu ▶ toujours au maximum, par rigueur ▶ le temps disponible avant la fin du sprint

L’agent vous propose un plan. Vous cherchez quoi en priorité ?

▶ ce que le plan ne dit pas ▶ que chaque étape annoncée soit correcte ▶ qu’il tienne en peu d’étapes

La même exigence revient dans cinq spécifications de suite. Vous en faites quoi ?

▶ vous la promouvez dans le dossier de contexte ▶ vous continuez à la recopier, c’est plus explicite ▶ vous la redites à l’agent à chaque début de session

La demande est posée ; reste à tenir la barre pendant qu’elle s’exécute. Prochaine étape : conduire la session. Lire ce que fait l’agent, corriger tôt, et savoir quand redémarrer.