CodeBuddy : Recherche de contexte plus intelligente pour les agents de codage IA
Explique comment un système de récupération de contexte basé sur un graphe de dépendances aide les agents de codage IA à éviter à la fois la pénurie de contexte et la surcharge de contexte dans de grands bases de code.
Le problème négligé dans le codage par agents
L’enthousiasme suscité par les agents de codage basés sur l’IA est tout à fait justifié — Claude, Codex, Cursor et les autres sont devenus des outils véritablement utiles. Mais si l’on passe plus d’une semaine à utiliser un tel agent sur une base de code importante du monde réel, un problème familier finit par apparaître.
L’agent lui-même n’est pas le facteur limitant. Ce n’est pas la capacité du modèle qui pose problème ; c’est plutôt le contexte.
Deux schémas d’échec récurrents se manifestent sans cesse :
- Priver l’agent de contexte — on lui confie une tâche, mais il ne connaît pas les conventions de son projet, n’a aucun souvenir d’un bug similaire qui a été corrigé puis annulé, et ne sait pas quels fichiers dépendent de celui qu’il s’apprête à modifier. Le résultat est une modification qui semble raisonnable isolément, mais qui est erronée pour le système dans son ensemble.
Aucun de ces problèmes ne concerne réellement l’intelligence du modèle. Ce sont tous deux des symptômes d’une mauvaise gestion du contexte. C’est là le véritable problème que CodeBuddy s’efforce de résoudre.
Né comme solution temporaire, pas comme produit planifié
Bien avant que CodeBuddy n’existe en tant qu’outil, son idée de base était déjà mise en pratique manuellement.
Dès qu’il fallait apporter un véritable changement dans un projet utilisant Claude, la procédure était toujours la même : identifier les fonctions concernées, trouver les tests couvrant cette partie du code, consulter toutes les notes expliquant pourquoi les choses avaient été conçues de cette manière, puis coller tout cela dans la conversation avant même de décrire le changement. Cette méthode fonctionnait, mais elle était fastidieuse, répétitive et reposait entièrement sur la mémoire du développeur — une mémoire qui se détériore inévitablement à mesure que le projet grandit.
Finalement, la question évidente est apparue : pourquoi une personne devait-elle assumer le rôle de mécanisme de récupération des informations ? Il s’agit d’une tâche mécanique et répétitive qui devrait être automatisée, et non stockée dans l’esprit de quelqu’un.
C’est vraiment là que CodeBuddy est né — non pas à la suite d’une décision de créer « un outil d’IA pour les développeurs », mais plutôt d’une décision de cesser de effectuer ces recherches manuellement.
Le faux raccourci : éviter Graphify
L’automatisation de cette étape de récupération a nécessité de déterminer comment CodeBuddy comprendrait la structure d’un projet — quels fichiers dépendent les uns des autres, quelles fonctions appellent quoi, et où se situent réellement les limites architecturales.
Un projet distinct, Graphify, avait déjà abordé ce problème en construisant un véritable graphe de dépendances d’une base de code, en cartographiant les relations réelles entre fichiers plutôt que de les déduire à partir de schémas de nommage ou de proximité. L’intégrer en tant que dépendance semblait introduire une complexité inutile — un élément supplémentaire à gérer, une étape d’installation de plus, un point de défaillance potentiel en plus. Le plan initial était de l’ignorer complètement et de faire en sorte que CodeBuddy crée lui-même son propre index architectural léger, en utilisant l’extraction de symboles, la cooccurrence des fichiers et quelques heuristiques — juste assez pour orienter l’agent dans une direction raisonnable.
Cette approche s’est avérée insuffisante.
L’index léger pouvait indiquer ce qui se trouvait à proximité de quoi, mais il ne pouvait pas expliquer de manière fiable pourquoi deux fichiers étaient réellement liés, ni tracer une chaîne de dépendances allant à trois ou quatre niveaux de profondeur — précisément le type d’information la plus importante avant d’intervenir sur du code ayant un large impact. À plusieurs reprises, l’agent effectuait des modifications qui semblaient sûres en apparence mais endommageaient quelque chose à deux niveaux de profondeur, simplement parce que l’index n’avait pas capturé cette relation avec suffisante précision.
Cela a conduit à un revirement. Au lieu de considérer Graphify comme une charge supplémentaire optionnelle à contourner dans la conception, il est devenu une partie essentielle du système : CodeBuddy fonctionne toujours indépendamment, en utilisant son index interne, pour ceux qui préfèrent ne pas ajouter de configuration supplémentaire. Mais si Graphify est installé, CodeBuddy se réfère à son graphe comme source autorisée des relations architecturales, plutôt que de se fier aux suppositions.
Ce changement de direction est la véritable histoire derrière le flux de travail actuel — non pas une nouvelle fonctionnalité ajoutée à la hâte, mais la reconnaissance que le design plus simple était en réalité pire, suivie d’une refonte autour de cette même dépendance qui avait initialement été évitée.
A quoi ressemble CodeBuddy en pratique aujourd’hui
1. Préparation
npm install -g @ayushkumar320/codebuddy
codebuddy
L’exécution de codebuddy à l’intérieur d’un projet gère les étapes de préparation peu glamour mais essentielles :
- Se connecte à une base de données PostgreSQL locale
- Applique le schéma et les paramètres nécessaires à ce projet spécifique
- Génère un fichier de configuration privé dédié à ce projet
- S’intègre avec Claude et Codex, en ajoutant des instructions indiquant à l’agent comment utiliser les outils de CodeBuddy
- Vous demande de décider si vous souhaitez activer Graphify
En choisissant d’activer Graphify, son serveur MCP est connecté, ce qui permet d’exécuter /graphify . une fois pour créer la carte architecturale initiale du projet. En refusant cette option, CodeBuddy recourt à son propre index léger — l’outil continue de fonctionner pleinement, mais la représentation architecturale obtenue est moins précise.
2. Le cycle principal : context_pack
C’est ici que le travail réel a lieu. Lorsque vous confiez une tâche à l’agent — par exemple, « ajouter un authentification OAuth » — il ne commence pas à parcourir les fichiers au hasard ni à analyser l’ensemble du répertoire. Au lieu de cela, il appelle l’outil context_pack de CodeBuddy, qui assemble un ensemble bien défini contenant :
- Les fichiers qui sont réellement importants pour la tâche
- Les fonctions et classes spécifiques concernées, plutôt que des fichiers entiers chaque fois que c’est possible d’éviter cela
Le résultat est un ensemble compact et ciblé plutôt qu’un ensemble étendu mais peu dense. C’est cette différence qui distingue un comportement véritablement conscient du contexte d’un comportement qui ne semble que l’être.
3. L’agent met en œuvre la modification
Muni de ce paquet, Claude ou Codex dispose d’informations suffisantes pour analyser les effets à long terme plutôt que seulement la différence immédiate — des éléments tels que les fonctions qui dépendent de cette fonction, les tests qui doivent continuer à passer, et savoir si cette approche précise a déjà été tentée puis annulée auparavant.
4. CodeBuddy se souvient
Lorsque la tâche est terminée, l’agent peut enregistrer ce qu’il a appris dans CodeBuddy : les décisions prises, les règles découvertes au cours du processus, les problèmes de régression rencontrés, ainsi que les approches qui se sont avérées efficaces. Ces connaissances restent stockées localement, réparties entre Postgres et la mémoire Markdown, puis intégrées au paquet de contexte pour la tâche suivante. Au lieu de reprendre zéro à chaque session, le système devient de plus en plus précis.
5. Les PR sont vérifiés automatiquement
Un workflow GitHub peut générer automatiquement un rapport pour chaque demande de fusion, couvrant :
- Quel est le niveau de risque apparent lié au changement
- Où la couverture des tests fait défaut
- Quels aspects architecturaux sont affectés par le changement
- Si l’implémentation s’est éloignée du plan initial
- Si la vérification a réellement abouti
Pourquoi cela est plus important qu’il n’y paraît
Il est tentant de classer cela parmi « une autre outil de développement basé sur Claude ». Cette approche manque de précision à plusieurs égards :
Cela cible le véritable goulot d’étranglement. Les modèles deviennent de plus en plus performants à un rythme rapide. En revanche, la qualité du contexte fourni à ces modèles n’a pas évolué au même rythme au niveau des outils — la plupart des configurations continuent de se contenter de lire des fichiers entiers ou d’utiliser des recherches simples en espérant le meilleur. CodeBuddy repose sur l’hypothèse que les prochains progrès significatifs en matière de codage agentiel proviendront d’améliorations apportées au contenu fourni aux modèles, et non du modèle lui-même.
Il s’améliore progressivement avec le temps. Une fenêtre de contexte n’a pas de mémoire par défaut — chaque session commence à zéro, sauf si le système environnant conserve délibérément l’état. Comme CodeBuddy suit les décisions, les règles et les régressions, la dixième tâche sur une base de code donnée devrait se dérouler plus facilement que la première, sans qu’il soit nécessaire de réexpliquer les mêmes choses.
Il est transparent sur les compromis plutôt que de les dissimuler. Rendre Graphify optionnel est une réponse directe à une tentative antérieure d’éliminer complètement ce compromis, qui n’a pas fonctionné. Vous pouvez choisir : aucune configuration supplémentaire et un index léger suffisant, ou un graphique d’architecture véritablement précis si vous êtes prêt à ajouter un composant de plus.
Tout reste sur votre machine. PostgreSQL, le stockage en mémoire Markdown, l’index interne ainsi que le graphe de Graphify fonctionnent tous localement. Les identifiants sont stockés dans un fichier de configuration privé. Améliorer le contexte de l’agent ne nécessite pas d’envoyer votre base de code ailleurs.
Ce système s’intègre aux outils que les gens utilisent déjà. Il ne s’agit ni d’un nouvel éditeur ni d’un nouvel agent à apprendre — il se connecte directement à Claude et Codex, vous rejoignant là où vous travaillez déjà, et les rendant simplement plus efficaces pour comprendre la base de code qu’ils ont devant eux.
Ce que cela implique par la suite
Ce projet en est encore à un stade précoce et fait l’objet d’itérations actives ; le système de mémoire, en particulier, présente les plus grandes possibilités d’amélioration — pour l’instant, il se comporte davantage comme des notes structurées que comme un système de mémoire classé par pertinence. Si vous utilisez des agents de codage IA sur une base de code réelle et que vous rencontrez le problème du « il ne comprend pas mon projet », vos retours sont vraiment les bienvenus :
npm install -g @ayushkumar320/codebuddy
Si vous essayez ou si vous avez résolu ce problème d’une manière différente dans votre propre configuration, il serait utile de partager cette expérience.
CodeBuddy est une couche de gestion du contexte pour des agents de codage IA tels que Claude et Codex. Elle prépare un contexte ciblé et pertinent au lieu d’obliger à des lectures complètes du répertoire, et peut être intégrée éventuellement à Graphify pour obtenir une carte d’architecture plus détaillée. Elle est disponible sur npm sous le nom @ayushkumar320/codebuddy.
Lectures complémentaires
- Comprendre les agents IA : objectifs, outils, mémoire et la boucle de l’agent — Une explication adaptée aux débutants sur les différences entre les agents IA et les chatbots, abordant les composants clés, la boucle de décision, les niveaux d’autonomie et les cas d’usage concrets.
- Comparer les agents IA Frontier : Astra, Flash, Fable et Mythos — Une analyse des performances des dernières versions des modèles GPT, Gemini et Claude sur des tâches réelles d’agentivité telles que le codage, la navigation et l’utilisation d’outils, et non seulement sur des benchmarks.