Donner le bon contexte
Ni deviner, ni tout lire : montrer précisément ce qui décide du résultat.
Donner le bon contexte à un agent de code
Vous demandez un nouvel endpoint. L'agent le produit : correct, testé, lisible. Il utilise requests alors que tout le projet est en httpx, renvoie un dictionnaire brut là où vos douze autres routes renvoient un schéma Pydantic, et écrit ses messages d'erreur en anglais dans une base entièrement francophone. Vous passez vingt minutes à remettre ce code aux normes de la maison — vingt minutes que vous auriez économisées en écrivant trois lignes de contexte au départ.
C'est l'erreur de cadrage la plus fréquente et la plus mal diagnostiquée. On l'attribue à l'outil (« il ne comprend pas mon projet ») alors qu'elle est purement informationnelle : un agent ne voit que ce qui entre dans sa fenêtre de contexte. Vos conventions ne sont écrites nulle part, elles vivent dans la répétition d'un motif à travers des dizaines de fichiers — quelque chose qu'un humain absorbe en une semaine de lecture et qu'une machine ne peut inférer que si vous lui montrez les fichiers concernés. Le réflexe inverse est tout aussi coûteux : tout montrer dégrade la qualité au lieu de l'améliorer. La compétence, ici, consiste à choisir.
Commentaires
Les commentaires sont alimentés par GitHub Discussions
Connectez-vous avec GitHub pour participer à la discussion