Contexte
Le modèle voit ce que nous façonnons.
Un LLM est une fonction bornée par son contexte. Même prompt, contexte différent, sortie différente, par ordres de grandeur. Les ingénieurs seniors traitent la fenêtre de contexte comme une surface conçue, pas comme un brouillon de chat.
La boucle du stagiaire
Un junior colle une fonction et demande un correctif. Le modèle ne voit ni consommateur, ni test, ni convention environnante. Il renvoie du code localement correct et globalement faux : l'API dérive, le type ne correspond pas, le nommage jure avec le reste du fichier. Un 'petit changement' casse quatre choses en aval parce que le modèle n'a jamais su qu'elles existaient.
Une fenêtre de contexte façonnée
Chaque tâche significative a son contexte façonné : le fichier modifié, ses consommateurs, les définitions de types, les tests existants, le doc de conventions, les décisions architecturales qui contraignent la réponse. L'outillage de chargement de contexte (fichiers CLAUDE.md, code indexé, agents scopés) garde la vue du modèle sur la codebase plus riche qu'une simple fonction.
Un repo que le modèle peut vraiment voir
Un CLAUDE.md, un fichier de conventions projet, une discipline de contexte explicite. Des sous-agents scopés sur des sujets précis, pas sur tout le repo. Chaque changement futur (par n'importe qui, avec n'importe quel modèle) va plus vite parce que le contexte est façonné, pas improvisé.
- 01Le modèle voit-il plus que le fichier sous votre curseur quand vous demandez un changement ?
- 02Y a-t-il un CLAUDE.md (ou un doc de conventions équivalent) à la racine de chaque repo actif ?
- 03Quand le modèle renvoie du code, respecte-t-il les conventions du reste de la codebase ?
- 04Savez-vous ce qu'il y a dans la fenêtre de contexte du modèle avant d'appuyer sur entrée ?