Les composants d’un agent de codage

• Un agent de codage est un système composé d’une boucle de contrôle et d’un harnais logiciel centrés sur un LLM, qui répète l’écriture, l’exécution et le retour d’information sur le code
• Le harnais d’agent gère le contexte, l’accès aux outils, la composition des prompts et le contrôle d’état, tandis que le harnais de codage, spécialisé pour les tâches de développement, gère le dépôt, les tests et la vérification des erreurs
• Un agent de codage fonctionne autour de six composants : contexte du dépôt en temps réel, cache de prompts, accès aux outils, gestion du contexte, mémoire de session, délégation à des sous-agents
• À LLM identique, les performances et l’expérience utilisateur peuvent varier fortement selon la qualité de conception du harnais, et un bon harnais fournit un environnement de développement continu et conscient du contexte
• Mini Coding Agent est un exemple minimal implémenté en Python pur de cette architecture, avec des différences vis-à-vis d’OpenClaw sur le degré de spécialisation pour le codage et le périmètre d’exploitation

---

Les composants d’un agent de codage

• Un agent de codage est un système composé d’une boucle de contrôle centrée sur un LLM et d’un harnais logiciel (harness) qui l’entoure, avec une structure répétant l’écriture, la modification, l’exécution et le retour d’information sur le code
• Un LLM est fondamentalement un modèle de prédiction du token suivant, tandis qu’un modèle de raisonnement (reasoning model) est un LLM entraîné à effectuer davantage de raisonnement intermédiaire et de vérification
• Un agent est une boucle de contrôle qui répète l’appel au modèle, l’utilisation d’outils, la mise à jour de l’état et la décision d’arrêt afin d’atteindre un objectif
• Un harnais d’agent (agent harness) est la structure logicielle qui enveloppe cette boucle et prend en charge notamment la gestion du contexte, l’accès aux outils, la composition des prompts et le contrôle d’état
• Un harnais de codage (coding harness) est une forme spécialisée pour les tâches de développement, qui gère le contexte du dépôt, l’exécution du code, les tests et la vérification des erreurs

Relation entre LLM, modèle de raisonnement et agent

• On peut comparer le LLM à un moteur, le modèle de raisonnement à un moteur renforcé, et le harnais d’agent au système qui pilote ce moteur
• LLM et modèles de raisonnement peuvent effectuer seuls des tâches de codage, mais dans un environnement de développement réel, il faut gérer un contexte complexe : exploration du dépôt, recherche de fonctions, exécution des tests, analyse des erreurs
• Le harnais de codage permet d’exploiter au maximum les performances du modèle et offre une expérience de codage bien plus puissante qu’une simple interface de chat

Le rôle du harnais de codage

• Il s’agit de la couche logicielle qui entoure le modèle et assure l’assemblage des prompts, l’exposition des outils, le suivi de l’état des fichiers, l’exécution de commandes, la gestion des permissions, le cache, le stockage de la mémoire, etc.
• Même avec le même LLM, les performances et l’expérience utilisateur varient fortement selon la conception du harnais
• Par exemple, un modèle open weights comme GLM-5 peut atteindre des performances comparables s’il est intégré à un harnais du niveau de Codex ou Claude Code
• OpenAI a déjà maintenu séparément des modèles de post-traitement selon le harnais, comme GPT-5.3 et GPT-5.3-Codex

Les 6 composants clés d’un agent de codage

• 1. Contexte du dépôt en temps réel (Live Repo Context)

  • L’agent doit connaître l’état actuel du dépôt Git, la branche, la documentation et les commandes de test
  • Une instruction comme « corriger les tests » dépend de la structure et du contexte du dépôt ; il faut donc collecter un résumé du dépôt avant de commencer
  • Cela évite de repartir d’un état zéro à chaque fois et permet de disposer de faits de travail stables (stable facts)

• 2. Structure des prompts et réutilisation du cache (Prompt Shape and Cache Reuse)

  • Comme le résumé du dépôt, la description des outils et les consignes générales changent peu, ils sont mis en cache sous forme de « préfixe de prompt stable (stable prompt prefix) »
  • Au lieu de reconstruire l’intégralité du prompt à chaque requête, seules les parties modifiées sont mises à jour
  • Dans les sessions répétées, cela réduit le gaspillage de calcul et maintient la cohérence des réponses

• 3. Accès aux outils et usage (Tool Access and Use)

  • Au lieu de seulement proposer des commandes, le modèle peut réellement les exécuter via un ensemble d’outils défini par le harnais
  • Chaque outil a des formats d’entrée et de sortie clairs ainsi que des limites définies, avec validation et procédure d’approbation avant exécution
  • Exemples : « est-ce un outil connu ? », « les arguments sont-ils valides ? », « le chemin de travail est-il dans le workspace ? »
  • Cela renforce la sécurité et la fiabilité ; la liberté du modèle diminue, mais l’utilité pratique augmente

• 4. Réduire au minimum l’encombrement du contexte (Minimizing Context Bloat)

  • Dans les longues sessions, les lectures répétées de fichiers, les logs et les sorties d’outils peuvent faire dépasser la longueur maximale du prompt
  • Le harnais gère cela avec deux stratégies
    • Clipping : raccourcir les longs textes, logs et mémos à une certaine longueur
    • Summarization : compresser et résumer l’historique plus ancien de la conversation
  • Les événements récents sont conservés en détail, tandis que les informations plus anciennes sont dédupliquées et compressées
  • En pratique, la qualité du contexte a plus d’impact sur les performances réelles que la qualité du modèle

• 5. Mémoire de session structurée (Structured Session Memory)

  • L’agent sépare son état entre mémoire de travail (working memory) et transcription complète de la conversation (full transcript)
  • L’historique complet inclut toutes les requêtes, réponses et sorties d’outils, et permet de reprendre la session
  • La mémoire de travail stocke sous forme résumée les informations importantes du moment (tâche en cours, fichiers clés, notes récentes, etc.)
  • La transcription compacte (compact transcript) sert à reconstruire le prompt du modèle, tandis que la mémoire de travail assure la continuité du travail

• 6. Délégation à des sous-agents bornés (Delegation With Bounded Subagents)

  • L’agent principal crée des sous-agents (subagents) pour traiter en parallèle des tâches auxiliaires
  • Exemples : localiser la définition d’un symbole, vérifier le contenu d’un fichier de configuration ou analyser la cause d’un échec de test
  • Les sous-agents n’héritent que du contexte nécessaire et sont limités par des contraintes comme lecture seule ou profondeur de récursion restreinte
  • Claude Code et Codex prennent tous deux en charge les sous-agents, avec des limites définies par le périmètre de la tâche et la profondeur du contexte

Résumé des composants

• Les six composants sont étroitement liés entre eux, et la qualité de conception du harnais détermine l’efficacité d’exploitation du modèle
• Un harnais de codage bien conçu offre un environnement d’assistance au développement bien plus persistant et conscient du contexte qu’un simple chat avec un LLM
• Mini Coding Agent(https://github.com/rasbt/mini-coding-agent) est un exemple minimal en Python pur de cette architecture

Comparaison avec OpenClaw

• OpenClaw se rapproche davantage d’une plateforme d’agents généraliste que d’un assistant dédié au codage
• Points communs :
  • utilisation de fichiers de prompts et d’instructions dans le workspace (AGENTS.md, TOOLS.md, etc.)
  • présence de fichiers de session JSONL, de compression des conversations et de gestion de session
  • possibilité de créer des sessions auxiliaires et des sous-agents
• Différences :
  • les agents de codage sont optimisés pour l’exploration du dépôt, l’édition de code et l’exécution d’outils locaux
  • OpenClaw met l’accent sur l’exploitation d’agents longue durée entre plusieurs canaux et plusieurs workspaces

Annexe : annonce d’un nouveau livre

• Build A Reasoning Model (From Scratch) est terminé, et une version en accès anticipé (Early Access) est actuellement disponible
• L’éditeur travaille sur la mise en page avec un objectif de publication cet été
• Le livre est centré sur une approche consistant à implémenter et comprendre directement les mécanismes de raisonnement des LLM

[GN⁺]

Avis Hacker News

• Un long context reste coûteux, et s’il contient trop d’informations inutiles, cela crée du bruit
  C’est pourquoi je pense que la génération basée sur des specs vaut mieux que le codage conversationnel
  Ossature, que j’ai créé, prend l’approche inverse. On commence par rédiger une spec qui décrit le comportement, puis avant la génération de code, on audite les manques ou contradictions et on génère un build plan en TOML indiquant à quelle section de la spec et à quels fichiers chaque tâche se réfère
  Le LLM ne voit que les parties nécessaires, sans accumulation d’historique de conversation. Tous les prompts et toutes les réponses sont enregistrés sur disque, ce qui garantit automatiquement la traçabilité
  Récemment, j’ai même créé entièrement un émulateur CHIP-8 uniquement à partir d’une spec avec cette méthode, et il y a aussi des projets d’exemple

  • Je pense souvent qu’il manque aujourd’hui une source centrale de vérité dans les agents de codage
    Avant, toute l’équipe savait ce qu’elle construisait, mais maintenant les agents repartent de zéro à chaque fois
    C’est pourquoi je vois le flux chat → spec → code comme l’avenir. L’étape spec → code devrait fonctionner sans intervention humaine
    Si la spec n’est pas claire, il faut poser explicitement la question à l’humain, puis générer le code sur cette base
    Aujourd’hui, les demandes ambiguës se répètent et l’humain n’apprend même pas pourquoi. Les « memory » ou fichiers d’agent ne sont que des rustines
  • Je construis quelque chose de similaire moi aussi. Ce n’est pas encore public, mais c’est un moteur de workflow centré sur les specs
    Au lieu d’une conversation, je fournis au LLM un context projeté à partir du code et de la spec, et je compose différemment le context à chaque étape
    Cela évite le drift causé par l’accumulation de context, et c’est mon code, pas le LLM, qui contrôle le workflow
    L’idée d’utiliser TOML comme artefact de transmission entre les étapes est intéressante, je vais probablement m’en inspirer
  • Je pense pareil. L’agent A ne modifie que la spec, et l’agent B build uniquement à partir de la spec
    L’utilisateur peut simplement relire le diff produit par l’agent A, sans avoir à refaire sans cesse des vérifications de code répétitives
    Le point essentiel est de toujours préserver l’intention (intent). Il faut conserver tels quels la spec et le contexte
    Le coût sera sans doute 2 à 3 fois plus élevé, mais à long terme cela me semble plus efficace
  • Les workflows basés sur le chat sont fatigants et provoquent beaucoup de pertes d’information
    Je pense qu’une approche fondée sur des specs est bien meilleure. Je suis curieux de savoir comment l’intervention humaine fonctionne — est-ce que l’on édite la spec et l’audit en parallèle, quel est le taux de réussite de la génération de code, et y a-t-il un projet d’application au code existant ?
  • Moi aussi, j’essaie une approche qui part des specs puis améliore le code par itérations avec le duo Claude Code + Cucumber
    Je me demande en quoi Ossature se distingue de cette approche

• Il est impressionnant de voir à quel point le potentiel d’un LLM peut être exploité avec une simple machine à états et une approche bash

  • C’est pour cela que je suis en train de créer moi-même un agent de codage isolé
    L’écosystème des agents est aujourd’hui rempli de fonctionnalités excessives et de mauvaises décisions
    Il y a 10 ans, on disait encore que ce type d’outil exigeait un sens des responsabilités, mais aujourd’hui on traverse une période confuse mêlant peur et hype
  • Au fond, la clé reste le prompt/context engineering
    Le modèle possède déjà les connaissances, mais pour les transformer en actions concrètes, la conception du context est cruciale
    Traduire la demande de l’utilisateur au niveau d’un développeur expérimenté et y raccorder les outils nécessaires est une approche prometteuse
    À mon avis, même les modèles open source peuvent être tout à fait compétitifs avec un agent bien optimisé et un peu de tuning
  • Quand on regarde la version fuitée de Claude Code, sa structure n’est pas simple
    Il faut un harness complexe, mais c’est justement cela qui permet au LLM de fonctionner de manière déterministe comme outil
  • Beaucoup d’agents CLI considèrent qu’un simple accès à bash ne suffit pas, et forcent donc toutes sortes de fonctionnalités dans une TUI JavaScript
  • Au lieu de bash, utiliser Python s’est révélé plus utile
    On peut y assembler librement la logique voulue plutôt que de dépendre d’un pipeline

• L’exemple est concis et clair
  Je n’utilise pas d’agents de codage, mais cet article aide à comprendre l’essence des agents de codage
  Il montre bien comment même 1k LOC de code utile peut se transformer en 500k LOC de confusion

• Beaucoup de gens utilisent déjà des modèles open source comme GLM-5 en les connectant à Claude Code ou à Codex CLI
  La documentation officielle de GLM le recommande aussi

  • Ce n’est pas au niveau d’Opus, mais la combinaison GLM et Qwen3.5-plus est largement suffisante pour des projets personnels

• L’article était marquant. J’ai créé un agent non dédié au code basé sur l’e-mail, et le principe est similaire
  À chaque boucle d’e-mails, le context repart à zéro, ce qui résout naturellement le problème d’accumulation du context
  L’équilibre entre le context à placer dans le prompt initial et celui à séparer dans des outils est important
  Il faut aussi tenir compte du caching et du coût en tokens
  J’ai détaillé cela dans mon billet de blog

• Je n’aime pas le mot « harness ». Je me demande s’il n’existerait pas une meilleure expression

  • Il est souvent utilisé au sens de shim qui gère un programme, comme dans « test harness » ou « fuzzing harness »
  • Ironiquement, aujourd’hui tout est devenu une « app », mais l’application qui exécute le LLM, elle, on ne l’appelle pas une « app »
  • Au fond, « harness » n’est qu’une façon plus élégante de dire scaffolding
  • Du coup, quelqu’un a aussi réagi en demandant qu’on propose alors un meilleur terme

• La troncature des sorties d’outils est très efficace pour réduire le gonflement du context
  J’assemble le context sur une base SQLite, et si besoin je restaure les appels d’outils tronqués via l’ID du message
  J’ai résumé les expériences associées dans cette documentation

• Faire tourner Claude Code avec d’autres modèles est courant
  C’est aussi indiqué dans cette documentation d’exemple
  Mais d’après mon expérience, on n’atteint pas le niveau des modèles Anthropic

  • Selon le projet, même un modèle peu coûteux comme MiMo V2 Pro peut couvrir 70 à 80 % des besoins, mais dans certains cas Sonnet est nettement supérieur
    Opus ne vaut son prix que dans environ 5 % des cas
    Personnellement, je trouve OpenCode bien meilleur que Claude Code, au point d’avoir acheté des crédits API OpenRouter
    OpenCode est déjà très puissant avec de simples commandes personnalisées et une définition d’agent minimale
    Définir le workflow via AGENTS.md, ROADMAP.md, etc., suffit pour la plupart des projets
    Je pense qu’une structure flexible s’adapte mieux aux évolutions rapides des modèles qu’un harness complexe
  • Je me demande si les modèles Anthropic sont meilleurs simplement grâce à la qualité du modèle, ou si c’est aussi dû à une optimisation du harness

• Les progrès des agents de codage viennent davantage de l’amélioration de la structure autour du modèle (scaffolding) que du modèle lui-même
  Une fois les outils, le context du dépôt et une simple machine à états en place, le goulot d’étranglement se déplace vers la qualité du context

• L’article était percutant. Moi aussi, j’explique souvent les agents de codage avec la métaphore moteur/voiture
  Si vous voulez expérimenter les composants de base, le software-agent-sdk d’OpenHands vaut le détour