Corrigez le contexte, pas l'invite

Réparez-le une fois, pour tout le monde

Lorsqu’un agent se trompe, son instinct est de réécrire l’invite. Cela corrige une conversation. L'écriture de la correction dans le référentiel corrige chaque conversation future, pour vous et pour toute autre personne travaillant ici.

Une correction peut résider à trois endroits, en augmentant la durabilité :

1. La colonne description dans la définition de l'actif. L'agent le lit avant d'écrire du SQL, donc une bonne description oriente la requête suivante.
2. Le fichier AGENTS.md à la racine du projet. Il s'agit d'une instruction que l'agent lit à chaque session, c'est donc l'endroit où sont définies les règles qui couvrent l'ensemble du projet.
3. Un contrôle de qualité qui rend l'erreur impossible à expédier. Le plus durable des trois, car il échoue bruyamment au lieu de compter sur l'agent pour s'en souvenir.

Le contexte n’est pas gratuit. Des recherches sur les fichiers de contexte des agents montrent que des notes soigneuses, écrites par des humains, n’améliorent la réussite d’une tâche que de quelques pourcents, tandis qu’un contexte généré automatiquement peut dégrader les résultats tout en augmentant le coût d’environ 20 %. Le contexte n’est donc pas automatiquement bon. La règle qui suit : écrivez le contexte d’un échec spécifique que vous avez observé, soyez bref et vérifié, et vérifiez qu’il a réellement aidé. Un AGENTS.md long et générique est pire qu’un fichier court et précis.

Deux corrections reviennent le plus souvent avec ce modèle. Enregistrez celle qui correspond à l'erreur que vous avez vue, textuellement :

• Il a supprimé les lignes orphelines. Un INNER JOIN vers products élimine silencieusement les 15 lignes de commande dont l'identifiant de produit n'a aucune correspondance, et 3 637,89 de revenus réels avec elles - le même défaut derrière l'écart de 1 396,89 que vous avez vu dans les chiffres de 2024. La règle à enregistrer : "Lorsque vous joignez order_items à products, utilisez un LEFT JOIN et regroupez les lignes sans correspondance comme 'Inconnu'. Un INNER JOIN supprime silencieusement 15 lignes de revenus réels."
• Il a sélectionné la mauvaise colonne de revenus. S'il a utilisé unit_price au lieu de net_price, enregistrez : "Le revenu est quantity * net_price. unit_price est le prix catalogue avant remise et ne constitue pas un revenu."

Votre tâche

Choisissez quelque chose que l'agent s'est trompé, ou a décidé tranquillement sans vous, au cours des trois dernières leçons - vos notes d'audit dans queries/audit_v1.md constituent la liste de courses. Ajoutez la règle d'une ligne à AGENTS.md. Affinez ensuite le description sur la colonne appropriée dans pipeline/assets/order_items.sql afin que la requête suivante démarre à partir de meilleures informations ; la modification d'une description modifie ce que lit l'agent, pas les données. Posez à nouveau la question d'origine et vérifiez si l'erreur revient.

Si votre agent n'a commis aucune erreur, cela vaut également la peine de le remarquer : ce modèle contient déjà un contexte exceptionnellement bon, ce qui est le but de la leçon. Écrivez la correction de tout ce qui ne va pas, aussi petit soit-il, afin de pratiquer le mécanisme.

Vérifiez votre compréhension

• Nommez les trois endroits où une correction peut vivre, par ordre de durabilité.
• Pourquoi la réécriture d'une invite est-elle moins efficace que l'écriture dans le référentiel ?
• Après votre correction, l'agent a-t-il produit la bonne colonne de revenus, et comment l'avez-vous confirmé ?

Faites-le avec votre agent

Dites next lesson et votre agent vous apprend cela, vous pose ces questions, puis définit la tâche ci-dessus. Faites-le à la main, puis dites review my work - il vérifie votre travail par rapport à une rubrique et vous indique ce qu'il faut corriger ou marque la leçon terminée.