Contexte et objectifs

Le texte décrit l’expérience d’un ingénieur de 25 ans qui développe des agents autonomes destinés à être utilisés par des utilisateurs finaux. Il distingue ces agents des simples chatbots, dont les réponses restent majoritairement subjectives. L’objectif déclaré est de livrer une expérience « minimally‑embarrassing », c’est‑à‑dire fiable et prévisible, même lorsque l’agent exécute des tâches critiques pour le client.

Limites observées des prompts structurés

Selon l’auteur, les grands modèles de langage ne suivent pas toujours les instructions, ne garantissent pas la vérité et peuvent échouer à accomplir des tâches simples. Il note que, même avec un schéma de sortie structuré (par exemple un JSON généré à partir d’un code Python), le modèle respecte le format la plupart du temps mais produit parfois des réponses complètement incohérentes. Un incident concret a nécessité de renommer le champ title en heading pour rétablir le comportement attendu :

title → heading

L’auteur indique que ces échecs représentent « une petite fraction des requêtes », mais que la proportion varie selon la formulation exacte du prompt. Cette variabilité impose une surveillance continue, car même les modèles les plus avancés peuvent générer du texte non conforme à la spécification.

Mécanismes d’évaluation et d’atténuation

Pour mesurer la stabilité du comportement, l’ingénieur utilise une technique nommée pass^k, qui consiste à exécuter un même test un grand nombre de fois (k fois) afin d’observer les déviations. Un suite de tests automatisés permet de détecter rapidement les cas où l’agent « se prend la tête avec un sac de marteaux », c’est‑à‑dire où il produit des sorties erronées ou incontrôlées. L’évaluation porte également sur des exigences non fonctionnelles : l’agent ne doit pas divulguer d’informations sur son implémentation, ne doit pas accepter des ordres de sources non autorisées et doit respecter une voix de marque définie.

Implications pour l’ingénierie des agents

Le texte conclut que les prompts ne constituent pas un artefact scalable. Chaque nouveau prompt s’insère dans un contexte déjà chargé d’instructions, ce qui modifie le comportement de l’agent de façon imprévisible. Ainsi, la pratique consistant à confier la rédaction de prompts à une équipe de « voice » devient inefficace à grande échelle. L’ingénierie doit plutôt s’appuyer sur des pipelines d’évaluation continus, des tests de robustesse (pass^k) et une surveillance en production pour garantir que les modifications de contexte n’entraînent pas de régressions. Cette approche reconnaît que les modèles peuvent changer de comportement pour des raisons opaques, rendant indispensable une boucle de rétroaction rapide entre les équipes de développement et les systèmes de mesure.