Comment recréer Claude Code en 200 lignes de code

 (mihaileric.com)
7 points par GN⁺ 2026-01-09 | 1 commentaires | Partager sur WhatsApp
  • L’architecture centrale d’un assistant de code IA n’est pas une magie complexe, mais environ 200 lignes de code Python simple
  • Le système repose sur une boucle de conversation avec un LLM : lorsque le LLM demande un appel d’outil, le code local l’exécute puis lui renvoie le résultat
  • Les trois outils de base nécessaires sont la lecture de fichier (read), la liste des fichiers (list) et l’édition de fichier (edit), ce qui permet d’explorer un projet et de modifier du code
  • Le LLM décide lui-même quel outil appeler et à quel moment à partir de la signature et de la description (docstring) des outils
  • Cette structure est identique au cœur de produits commerciaux comme Claude Code, et une architecture simple suffit à créer un agent de code puissant

Concept de base d’un agent de code

  • Un agent de code est un système conversationnel basé sur un LLM qui reçoit une instruction utilisateur et effectue de vraies opérations sur les fichiers via des appels d’outils
    • L’utilisateur saisit par exemple une demande comme « créer un nouveau fichier contenant une fonction hello world »
    • Le LLM répond avec les appels d’outils nécessaires au format JSON
    • Le programme exécute ensuite l’outil concerné et renvoie le résultat au LLM
  • Le LLM n’accède pas directement au système de fichiers : il se contente de formuler des requêtes, tandis que le travail réel est pris en charge par le code local

Les trois outils nécessaires

  • read_file : lit et renvoie l’intégralité du contenu du fichier indiqué
  • list_files : renvoie la liste des fichiers et dossiers dans un répertoire
  • edit_file : remplace une chaîne existante par une nouvelle, ou crée un nouveau fichier si old_str est vide
    • Si la chaîne à remplacer n’est pas trouvée, l’outil renvoie « old_str not found »
    Publicité
  • Ces trois outils suffisent déjà pour créer, modifier et explorer des fichiers

Enregistrement des outils et intégration au LLM

  • Tous les outils sont enregistrés dans TOOL_REGISTRY avec leur nom et leur fonction, ce qui permet au LLM de les appeler
  • La docstring et la signature de chaque outil sont extraites puis transmises au LLM
  • Le prompt système indique clairement au LLM la liste des outils disponibles et le format d’appel
    • Les appels d’outils sont limités au format 'tool: TOOL_NAME({JSON_ARGS})'
    • Les résultats d’exécution sont renvoyés au LLM sous la forme tool_result(...)

Analyse des appels d’outils et traitement des réponses du LLM

  • Dans la réponse du LLM, le système recherche les lignes commençant par tool: afin d’extraire le nom de l’outil et ses arguments (JSON)
  • Après exécution de chaque outil, le résultat est sérialisé en JSON puis ajouté à l’historique de conversation
  • La fonction execute_llm_call appelle l’API du LLM et renvoie le texte de réponse
  • run_coding_agent_loop reçoit l’entrée utilisateur et maintient la boucle de conversation avec le LLM
    • La boucle interne se répète jusqu’à ce que le LLM ne demande plus d’appel d’outil
    Publicité

Exemple d’exécution et possibilités d’extension

  • Exemple de conversation :
    • « crée le fichier hello.py et implémente hello world » → création d’un nouveau fichier via un appel à edit_file
    • « ajoute à hello.py une fonction qui multiplie deux nombres » → appel à read_file, puis à edit_file
  • Il est possible d’implémenter un assistant de code complet avec environ 200 lignes de code
  • Les produits commerciaux y ajoutent ensuite la gestion des erreurs, les réponses en streaming, la gestion du contexte, des outils supplémentaires et des procédures d’approbation
  • La structure centrale reste la même : une boucle simple où le LLM décide et le code exécute

Mise en pratique et extension

  • Le code source complet tient en environ 200 lignes et peut être étendu en remplaçant le fournisseur de LLM ou en ajoutant de nouveaux outils
  • Même avec une structure simple, il est possible d’implémenter soi-même un prototype puissant d’agent IA de codage

À lire aussi

1 commentaires

 
GN⁺ 2026-01-09
Avis sur Hacker News

  • Ce que j’ajouterais, c’est le planning
    La clé d’un usage efficace des outils, c’est de réaliser qu’ils fonctionnent au-dessus d’une liste TODO dynamique
    Le mode Plan sert à amorcer la manière dont cette liste est initialisée et le moment où chaque élément est exécuté
    L’interaction avec l’utilisateur consiste à réordonner cette liste
    Le mois dernier, j’ai testé à quel point Claude Code résolvait bien les problèmes de CTF, et quand on désactive l’outil TodoList et le planning, les performances chutent d’un à deux niveaux
    Voir aussi cette vidéo connexe : Breaking Bots: Cheating at Blue Team CTFs with AI Speed Runs
    Ce qui est intéressant, c’est que beaucoup de gens se concentrent uniquement sur « utiliser ou non le mode plan », alors que la liste TODO est toujours active
    Et ça me fait aussi sourire de voir des billets qui réduisent la « gestion intelligente du contexte » à de simples éléments TODO
    Beaucoup essaient de l’implémenter eux-mêmes et finissent par perdre un an à cause de résultats d’évaluation qui cassent en production

    • Si l’on regarde ce gist qui extrait le prompt système de Claude Code, il y a beaucoup de détails sur l’itération TODO
      On pourrait simplement l’ajouter sous forme de tokens de reasoning, mais en pratique il est bien plus prévisible et efficace de l’implémenter comme un outil explicite de stockage à clé unique
      J’ai l’impression que cette approche simple pourrait aussi fonctionner pour d’autres idées d’outils stockant des structures de langage
    • Pour les agents CLI, maintenir un fichier de « working memory » a très bien fonctionné
      En testant Codex, j’ai passé environ 10 minutes à organiser la spécification, à la découper en liste de changements, à lui faire enregistrer cela dans un fichier, puis à lui demander de revoir et corriger le plan après chaque modification
      Cela permet au LLM de se concentrer sur des tâches courtes orientées objectif sans nécessiter d’alimentation continue en prompts
      En pratique, cela produit un effet proche de celui de sous-agents
    • Moi aussi, j’ajoute souvent à la fin du prompt : « utilise une liste todo très détaillée pour cette tâche »
      Il m’arrive aussi d’indiquer comme dernière todo : « revois l’ensemble du travail et vérifie la qualité avec le linter, etc. »
    • La liste TODO est souvent réinsérée en tête du contexte pour que le LLM garde en tête le passé et les étapes suivantes
      Lors de la compression du contexte, elle sert aussi de représentation concise de la session
    • D’ici la fin de l’année, on verra peut-être passer une blague du genre « How to Code Claude Code in 200 Million Lines of Code »

  • Le cœur d’un agent de code, c’est en fait une simple boucle avec une structure d’appel d’outils
    Mais si l’on veut écrire un billet comme « The Emperor Has No Clothes: How to Code Claude Code in 200 Lines of Code », il faut absolument consulter How to Build an Agent de Thorsten Ball
    C’est ce texte qui a d’abord formulé l’idée que « l’essence d’un agent est simple »
    Bien sûr, en pratique, il faut des TODO et divers échafaudages (scaffolding), et Claude Code lui-même comporte de nombreux réglages complexes, des plugins et des fonctions d’interface
    Malgré cela, avec la boucle minimale, on peut aussi amorcer une extension autonome des fonctionnalités
    Si vous voulez voir le fonctionnement interne, claude-trace permet de suivre les interactions entre le LLM et les appels d’outils

    • J’ai analysé les transcriptions locales de Claude Code et de Codex pour examiner leur structure interne
      Au-delà de la simple boucle, on trouve beaucoup d’éléments complexes : threading par uuid, traitement de files de messages, snapshots de modifications de fichiers, sidechains de sous-agents, etc.
      Donc « 200 lignes » est juste sur le plan conceptuel, mais un niveau réellement production est bien plus complexe
      Codex n’a pas encore de fonction de mise en file, mais reste très puissant
      J’ai créé une app macOS appelée Contextify qui surveille en temps réel les transcriptions CLI de Claude Code et de Codex, et permet d’interroger l’historique des conversations avec la fonction Total Recall
    • L’édition de code est la partie la plus importante
      Les modèles Claude sont entraînés avec leur propre schéma d’outil str replace
      Réécrire le fichier entier est inefficace ; la clé, ce sont les modifications partielles
    • Certains ont aussi réagi en disant : « J’ai cru que c’était le même billet republié »
    • Il y a aussi eu une demande du type : « Peux-tu montrer directement cette boucle centrale si simple ? »

  • En réalité, il y a davantage d’éléments
    Par exemple, il arrive qu’un agent déclenche un early stopping et termine la tâche prématurément
    Même les modèles de reasoning les plus récents ne règlent pas cela
    Claude Code résout le problème en injectant les TODO dans chaque prompt afin de rappeler le travail restant
    Le dépôt public de HolmesGPT contient divers benchmarks expérimentaux

    • Une question a été posée : « Pourquoi l’early stop se produit-il ? »

  • Le concept « il suffit de donner au LLM la liste des outils et le format d’appel » m’avait choqué au début
    Je me demandais comment un LLM, qui ne fait que générer du texte, pouvait appeler des outils, mais quand j’ai compris que c’était vraiment tout, cela m’a paru magique

  • Pendant les vacances, j’ai fabriqué avec Opus un agent de code basé sur une DSL Prolog (ça dépassait les 200 lignes)
    Et, étonnamment, ça a presque fonctionné tout de suite
    Les modèles de dernière génération semblent avoir atteint un stade où l’importance du harnais d’agent diminue
    Voir aussi cette expérience dans ce billet

  • Il y a un an, ce billet était assez exact, mais aujourd’hui le harnais a beaucoup progressé, au point que le modèle de boucle simple explique difficilement le fonctionnement réel de Claude Code

    • Bien sûr, les harnais modernes ont plus de fonctionnalités, mais le concept de base reste valable
      Même un agent simple n’a pas un écart de performances énorme s’il utilise le même modèle
      C’est un peu comme un tutoriel « construire sa propre base de données » qui montre un B-tree de base
    • Selon le leaderboard tbench.ai, la complexité améliore légèrement les performances, mais des boucles simples comme « Terminus » restent tout à fait puissantes
    • Il y avait aussi la remarque : « Ce billet a été publié en janvier 2025 »
    • En réalité, les progrès de l’année écoulée se sont surtout concentrés sur la simplification des prompts et de la conception des outils
      Les subagents, MCP et Skills sont d’un niveau intermédiaire, et l’optimisation du contexte n’est vraiment significative que pour les longues exécutions
    • Le dépôt codex-cli permet une meilleure analyse des modèles

  • Je construis moi-même des boucles d’agents pour l’entreprise, en traitant plus d’un milliard de tokens par mois
    La boucle simple est bien au cœur du système, mais dans un environnement réel, une foule de détails fait exploser la complexité
    Par exemple, comment gérer la boucle si l’utilisateur envoie un message en cours de route, comment synchroniser des entrées webhook comme Slack,
    ou encore tout ce qui touche aux validations, aux garde-fous et au traitement asynchrone des tâches
    Je songe à rassembler cette expérience dans un billet de blog

  • Parmi les textes utiles à consulter, il y a You Should Write An Agent et How To Build An Agent

  • Notre équipe SWE-bench a publié un agent open source de 100 lignes
    Il s’agit de mini-swe-agent, très populaire à la fois dans le monde académique et dans l’industrie
    C’est un bon point de départ pour découvrir l’univers des agents

  • En 2023, il y avait eu un billet intitulé « réimplémenter LangChain en 100 lignes »
    En voyant ce billet, je l’ai effectivement implémenté et utilisé dans plusieurs projets

    • Il y a aussi eu la réaction : « Déjà 3 ans ? »