Cadrer une tâche pour un agent

« Améliore la gestion des erreurs dans le module de paiement. » Vous lancez, vous partez chercher un café, vous revenez sur un diff de 600 lignes : l'agent a enveloppé quatorze appels dans des try/except, créé une hiérarchie de cinq classes d'exceptions maison, ajouté une bibliothèque de retry et modifié le format des logs. Rien n'est faux ligne à ligne. Rien n'est utilisable non plus, parce que vous ne pouvez ni valider ni rejeter l'ensemble : il n'existe aucun critère qui dirait que c'est fini et réussi. Vous jetez, et vous avez payé le prix complet de la génération et de la relecture pour zéro.

Le problème n'est pas la longueur du prompt, c'est son absence de condition de succès. Un agent optimise vers un signal ; si vous ne lui en donnez aucun, il se rabat sur « produire quelque chose qui ressemble à ce qu'on demande », et c'est justement le pire des résultats — assez crédible pour ne pas être rejeté d'emblée, assez arbitraire pour ne pas être fiable. Cadrer une tâche, c'est fournir trois choses : un état final observable, la façon de l'observer, et les limites de ce qu'il est permis de toucher. Le reste — le ton, la politesse, les « s'il te plaît » — n'a aucun effet mesurable.