Donnez aux agents de codage le bon contexte (pas plus de contexte)

Une seule phrase demandant un endpoint de login n’est pas suffisante. L’agent a encore besoin de connaître votre format d’erreur, la structure des dossiers, la bibliothèque d’auth, le pattern de validation, et à quoi ressemble « done ». La courte vidéo IBM Technology de Legare Kerrison Context-Aware Coding: Give AI Agents the Right Context (publiée le 2 novembre 2026) rend le point concret et pratique pour les équipes qui utilisent déjà des agents de codage.

Ce n’est pas un autre essai de haut niveau sur les goulots. C’est une courte liste d’inputs qui changent réellement l’output.

Les inputs qui comptent

1. Fichiers et structure. Les agents forts peuvent chercher et ouvrir des fichiers eux-mêmes. Votre job est de les pointer dans la bonne direction (« suivez le pattern dans le README ») et, idéalement, de leur donner une carte compacte du repo des fichiers et symboles pour qu’ils voient la forme sans lire chaque ligne.

2. Versions exactes des dépendances. Savoir que vous utilisez une bibliothèque n’est pas assez. Le lockfile enregistre les versions résolues (y compris les transitives) et donc quelles APIs existent réellement. Beaucoup de fonctions « hallucinées » sont simplement des mismatches de version.

3. Un test que l’agent peut passer. Un test qui échoue transforme la session en une boucle write–run–fix. Le coding agentique marche mieux quand l’agent sait à quoi ressemble le bien.

4. Conventions et contraintes. Mettez les commandes de build, les standards de codage, et les règles dures (« ne touchez pas à ce dossier ») dans un AGENTS.md versionné (ou l’équivalent que votre outil lit déjà). Cela devient une interface d’équipe partagée.

5. Intent. Seul un humain sait ce que done signifie, quelles sont les contraintes, et ce que l’agent ne doit pas faire. L’agent ne peut pas découvrir cela en lisant le repo.

Trois mouvements avant que n’importe quel code soit écrit

• Demandez à l’agent de vous interviewer et de continuer à poser des questions jusqu’à ce qu’il comprenne la tâche.
• Dites-lui d’explorer le repo et de vous expliquer la structure en langage clair. Maintenant vous partagez tous les deux une carte.
• Faites-le écrire un plan et lister ses assumptions. Revoyez ces assumptions avant l’implémentation. Quand la session se termine, écrivez les découvertes utiles dans le fichier d’instructions pour que la prochaine personne (ou agent) commence plus loin.

Ne déversez pas tout le repo

Les modèles ne prêtent pas une attention égale à tout dans un long contexte. L’information au début et à la fin tend à être mieux utilisée que le matériel enterré au milieu (« lost in the middle »). Chaque fichier non pertinent compétitionne avec un pertinent. Pour un changement de login-flow l’agent a besoin du module auth, de ses tests, et des conventions — pas du service de billing ou des logs de build vieux de trois semaines.

Conséquences pratiques :

• Commencez une session fraîche pour chaque nouvelle tâche.
• Pointez vers des fichiers spécifiques et nettoyez le bruit quand une session grandit.
• Préférez un orchestrateur qui lance des sous-tâches focalisées avec un contexte propre plutôt qu’une conversation surchargée.

Le but n’est pas plus de contexte. C’est le bon contexte, avec un humain qui prend encore les décisions.

La discussion liée sur Hacker News continue de noter que les agents génèrent plus de code qu’ils ne génèrent de logiciel fini et maintenable ; la revue et la vérification restent les étapes rares. Un meilleur contexte ne retire pas ces étapes, mais il réduit la quantité de slop qui les atteint.

Sources : la vidéo IBM Technology liée ci-dessus. Les mêmes thèmes apparaissent dans des talks récents de l’Agentic AI Foundation et AI Engineer sur la readiness des agents et les interfaces partagées, mais la checklist courte et concrète est ce qui rend cette vidéo utile un lundi matin.