Au-delà de grep : plaidoyer pour un harnais IA riche en contexte

La thèse : la qualité d'un assistant IA de code se joue moins dans son modèle que dans son « harnais » - la couche qui décide quels bouts de codebase mettre sous ses yeux. Décryptage d'un billet qui remet l'ingénierie du contexte au centre.

Le point de départ

Un cas concret que tout dev senior a vécu : on ouvre son IDE, on demande à l'assistant « refactorise cette fonction pour utiliser la nouvelle API interne » - et il produit un code plausible, syntaxiquement propre, mais qui ignore trois conventions du projet, deux dépendances internes et un helper qui existe déjà à trente lignes plus loin. Le modèle n'est pas « bête », il n'a simplement pas vu ce qu'il fallait voir.

C'est exactement la thèse défendue par Vinay Perneti (Augment Code) dans un entretien à Ars Technica intitulé « Beyond grep : The case for a context-rich AI coding harness » : le harnais - l'ensemble des mécanismes qui choisissent, ordonnent et injectent le contexte dans le prompt - pèse aujourd'hui plus lourd que le choix du modèle sous-jacent.

Ce que fait un harnais « pauvre »

C'est essentiellement du grep sophistiqué :

• un embedding search naïf sur les fichiers du repo,
• une fenêtre de contexte ouverte autour du curseur,
• éventuellement le fichier courant en entier.

Ça marche pour les tâches locales (renommer une variable, corriger une signature). Ça s'écroule dès qu'il faut comprendre pourquoi un test échoue trois modules plus loin.

Ce que fait un harnais « riche »

Trois briques cumulées, dans la ligne de ce que défend Perneti chez Augment Code :

1. Graphe de dépendances de code - importer, appeler, hériter : le harnais suit les arêtes pour ramener les définitions vraiment utiles, pas les fichiers proches textuellement.
2. Historique d'exécution - traces de tests, logs, sortie du dernier pytest ou cargo test. Le modèle voit ce qui a cassé, pas seulement le code qui casse.
3. Mémoire de session - les décisions prises dans les précédents échanges (« on a choisi la lib X, pas Y »), pour éviter que l'assistant les re-remette en cause à chaque tour.

Des projets open source récents illustrent chacune de ces briques - l'écosystème tree-sitter pour l'analyse structurelle, les outils autour de ripgrep combinés à des index sémantiques, et les frameworks d'agent qui tiennent un « scratchpad » persistant.

Pourquoi c'est le nerf de la guerre

Deux raisons économiques :

• Le prix du token descend, la fenêtre de contexte monte : on peut se permettre d'envoyer plus. Mais on ne peut pas envoyer tout - un monorepo de 500 000 lignes reste hors de portée. Il faut donc sélectionner.
• Le modèle raisonne mieux sur ce qu'on lui montre au bon moment que sur ce qu'on lui déverse en vrac. Le harnais qui priorise correctement bat le modèle qui trie mal dans sa propre fenêtre.

Autrement dit : la différence entre un assistant qu'on tolère et un assistant sur lequel on s'appuie n'est plus dans le poids du modèle. Elle est dans l'ingénierie logicielle de son environnement de perception.

À retenir

• Le « harnais » (context engineering) est devenu le vrai différenciateur des assistants de code - thèse défendue publiquement par Vinay Perneti chez Augment Code.
• Un harnais riche combine graphe de code, historique d'exécution et mémoire de session - pas seulement de la recherche textuelle.
• Choisir un outil aujourd'hui, c'est autant évaluer son harnais que le modèle qu'il embarque.