Comment créer un agent de codage

(ghuntley.com)

62 points par GN⁺ 2025-08-25 | 4 commentaires | Partager sur WhatsApp

En 2025, construire soi-même un agent de codage est l’un des meilleurs projets qu’un développeur indépendant puisse entreprendre
Un agent fonctionne avec 300 lignes de code et une boucle de tokens de LLM seulement, et le fait d’en construire un offre l’occasion de passer du statut de consommateur à celui de producteur d’IA
Les composants de base sont des outils comme lecture de fichiers, liste de fichiers, exécution Bash, édition de fichiers, recherche de code, permettant d’implémenter de vraies fonctions d’automatisation
Pour le choix du modèle, des modèles agentiques comme Claude Sonnet et Kimi K2 sont adaptés, et si nécessaire un modèle oracle comme GPT peut être connecté comme outil pour effectuer une vérification de plus haut niveau
En pratique, des produits commerciaux comme Amp, Cursor, Claude Code et GitHub Copilot reposent eux aussi sur une structure similaire

Aperçu de l’atelier

Atelier gratuit animé par Geoffrey Huntley, avec une approche très pratique pour expliquer comment construire soi-même un agent de codage et en comprendre les principes
Il compare la structure et les principes d’assistants IA commerciaux existants comme Roo code, Cline, Amp, Cursor, Windsurf et OpenCode, tout en offrant l’occasion de les implémenter soi-même
Cette expérience de construction permet de dépasser le simple rôle d’utilisateur d’IA pour devenir un développeur capable de créer des outils d’automatisation en utilisant directement l’IA
La structure centrale consiste à exploiter des tokens de LLM en boucle dans environ 300 lignes de code pour produire les fonctions d’un agent
Des primitives sont ajoutées pour chaque outil (lecture, liste de fichiers, exécution, édition, recherche de code), et des exemples concrets de fonctionnement ainsi que le code sont publiés dans le dépôt GitHub

Qu’est-ce qu’un agent ?

Ces derniers temps, le terme « agent » est utilisé très largement, mais sa signification réelle et son mode de fonctionnement interne restent peu clairs
À mesure que la barrière d’entrée pour créer des agents baisse, il devient possible d’aller au-delà du simple consommateur d’IA pour devenir un producteur capable de piloter l’automatisation du travail
En 2025, à l’image des notions fondamentales de base de données comme la clé primaire, le principe de construction des agents s’impose comme un savoir indispensable
Des entreprises comme Canva recommandent déjà l’usage de l’IA dans leurs processus d’entretien, et la capacité à automatiser avec l’IA devient un élément central du recrutement
Désormais, si l’on prend du retard, ce n’est pas à cause de l’IA, mais parce qu’on n’apprend pas de nouveaux outils par le développement personnel

Principes clés des agents de codage

Un agent de codage se compose uniquement de 300 lignes de code et d’une boucle de tokens de LLM, qui exécute des fonctions via des entrées de tokens répétées
Le concept de travail concurrent (concurrent work) est important
- Exemple : même pendant une réunion Zoom, l’agent peut avancer en parallèle, ce qui améliore fortement l’efficacité du travail
Tous les LLM ne sont pas agentiques
- « haute sécurité » (ex. : Anthropic, OpenAI)
- « basse sécurité » (ex. : Grok)
- « oracle » (avantageux pour les résumés et la réflexion de haut niveau)
- « agentique » (orienté vers l’action, itérations rapides et appels d’outils)
Les développeurs doivent comprendre les caractéristiques propres à chaque modèle et choisir celui qui convient selon l’objectif
Allouer systématiquement toute la fenêtre de contexte nuit aux performances, et il faut garder à l’esprit que « moins on en alloue, meilleurs sont les résultats »
- Enregistrer trop d’outils MCP entraîne aussi une baisse des performances
Règle : « Less is more » → pour obtenir les meilleures performances, il faut placer dans le contexte uniquement les outils et données nécessaires

Flux de construction d’un agent de codage

1. Enregistrement des outils et appel de fonctions
- On enregistre par exemple un outil de consultation météo auprès du LLM afin qu’il puisse répondre au bon moment sous forme d’appel de fonction
- MCP (Model Context Protocol) ressemble à une « bannière d’information sur une fonction » : il suffit d’enregistrer la description d’une fonction pour permettre son appel automatique
2. Fonctions essentielles par outil primitif
- Lecture de fichier (ReadFile) : lit le contenu d’un fichier dans le contexte lorsqu’un chemin est fourni
- Liste de fichiers (ListFiles) : fournit la liste des fichiers et dossiers d’un répertoire
- Exécution de commande (Bash) : permet au LLM d’exécuter des commandes du shell système et d’en récupérer le résultat
- Édition de fichier (Edit) : automatise la création ou la modification d’un fichier désigné
- Recherche de code (CodeSearch) : effectue une recherche rapide dans toute la base de code à partir de motifs, mots-clés ou noms de fonctions (avec ripgrep)
3. Exemples et déroulement des résultats
- En intégrant chaque outil au LLM, on peut automatiser des tâches successives à partir de simples prompts en langage naturel (ex. : générer du code FizzBuzz → vérifier son exécution, explorer un répertoire → analyser son contenu, etc.)
- Les fonctions-outils sont appelées séquentiellement selon l’entrée utilisateur ou le scénario, et le renvoi des résultats se répète dans la boucle
- Séquence principale de fonctionnement d’un agent : entrée utilisateur → décision d’appeler ou non un outil → exécution de l’outil → ajout du résultat au contexte → répétition

Extensibilité et open source

Aujourd’hui, la plupart des agents de codage fonctionnent à partir d’outils open source existants comme ripgrep
Sur GitHub, on trouve des projets d’agents simples mais puissants comme SST Open Code et mini-swe-agent, implémentés en à peine 100 lignes, qui peuvent servir de référence pour la performance et la structure
Il est recommandé aux développeurs de ne pas se contenter de comparer les produits existants, mais de les construire eux-mêmes pour en comprendre et en exploiter les principes
Lorsqu’ils sont appliqués au travail réel et à l’automatisation, la création d’agents internes et leur diffusion dans l’organisation deviennent un avantage compétitif

Conclusion et implications

Un agent de codage n’est pas une technologie complexe, mais une combinaison de boucle simple et d’assemblage d’outils
L’essentiel pour créer un agent de codage est de comprendre sa structure et savoir l’exécuter rapidement, et l’expérience de construction permet de répondre activement aux évolutions des technologies d’IA
Plus que l’IA elle-même, l’élément le plus important aujourd’hui comme stratégie de croissance personnelle est l’investissement en soi, à travers le développement continu et la capacité à créer des outils
« Ce n’est pas l’IA qui va vous prendre votre travail, c’est votre collègue équipé d’agents, qui automatise et travaille plus vite »

4 commentaires

GN⁺ 2025-08-25

Commentaires sur Hacker News

Notre équipe Princeton SWE-bench a créé, avec environ 100 lignes de code, un agent qui obtient de bons résultats sur SWE-bench ; si cela vous intéresse, cela vaut le coup d’y jeter un œil : mini-swe-agent
- Je suis surpris de voir à quel point la structure est vraiment assez simple ; merci d’avoir partagé ça.
  En réalité, tout le code tourne sur la base de ces prompts : code source du prompt de base de l’agent
```
Your task: {{task}}. Please reply
with a single shell command in
triple backticks.

To finish, the first line of the
output of the shell command must be
'COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT'.
```
- Parmi les exemples de prompts de l’agent, la partie « 1. trouver et lire les fichiers pertinents dans la codebase 2. créer un script de reproduction du bug 3. corriger le bug 4. vérifier la correction avec le script 5. tester les edge cases » est utile.
  J’utilise moi aussi un type de prompt similaire dans ma boucle de débogage.
  La méthode « analyser la codebase, lister les causes possibles, les classer par probabilité, puis valider les hypothèses avec des scripts ou des logs de debug » m’aide beaucoup dans ma propre routine de résolution de problèmes.
- Quand le problème est autonome et contenu dans un seul fichier, le corriger avec un LLM est très facile.
  En revanche, dans une codebase classique, les fichiers et le contexte sont dispersés un peu partout, et il n’est pas simple de les comprendre en respectant l’intention d’architecture structurée et l’organisation du développeur.
- Bravo pour cette belle tentative, même si je trouve dommage qu’il n’y ait pas beaucoup d’outils.
  La majeure partie du code relève du framework d’agent, et il n’y a pas tant de code spécialisé pour le SWE qu’on pourrait le penser.
  J’ai aussi créé un agent SWE pour le plaisir, donc cela peut valoir le coup de regarder autocode
- Je l’ai ajouté aux ressources de référence pour vous remercier.
Il existe aussi chez AmpCode How To Guide un « guide pour construire un agent » très similaire, écrit par Thorsten Ball.
Globalement, Amp est lui aussi assez intéressant.
Ce n’est plus un service secret désormais, mais je suis content de voir que des outils liés au code agentique continuent d’être publiés.
Je pense qu’à l’avenir, ce type de modèles agentiques sera inclus par défaut dans divers logiciels.
- C’est bien plus agréable à lire, merci pour ça.
- Il est aussi mentionné que l’auteur travaille chez Amp.
- Ghuntley travaille aussi chez Amp.
On dit qu’une image vaut généralement mille mots, mais dans ce document, on a l’impression que la valeur des images a été bradée à -99,6 %.
Je me demande bien ce que c’est.
- Ce sont des slides d’atelier de conférence.
  Le texte correspond à une dictée de la formulation réellement utilisée pendant la présentation.
Je me demande si quelqu’un pourrait confirmer comment fonctionne l’usage des outils.
Je comprends que Claude, ChatGPT, etc. fournissent des « outils » via leur API et que, lorsqu’une requête d’appel d’outil arrive, le répondant exécute réellement l’outil puis renvoie le résultat.
Mais comme le modèle, en pratique, est strictement basé sur des caractères, je me demande comment l’API transforme les réponses du modèle en plusieurs structures.
J’imagine qu’au fine-tuning, on a dû lui montrer des exemples où certains appels d’outils étaient insérés sous forme de blocs spéciaux, puis que les serveurs de Claude/ChatGPT les interprètent.
Je me demande s’il existe de la documentation à ce sujet ou des informations sur des tokens spéciaux utilisés en interne, ainsi que sur la manière d’empêcher les entrées utilisateur d’abuser de ces tokens « porteurs de sens ».
- Il existe une documentation d’implémentation publiée par Anthropic.
  Anthropic Tool Use Documentation
  On y voit clairement que le modèle ne fonctionne en réalité pas avec du « texte », mais au niveau des tokens.
  C’est similaire au fait qu’un compilateur parse du code source pour produire une séquence de « tokens » — mots-clés, parenthèses, structures, etc.
  La sortie peut inclure des mots réels ainsi que des métadonnées.
- Sur le plan conceptuel, vous avez bien compris.
  La seule véritable interface avec un LLM, ce sont les « tokens », et il n’existe pas de séparation entre canal de contrôle et canal de données.
  La couche API du modèle insère dans le prompt les instructions d’appel d’outil ainsi que la liste des outils disponibles, avec leurs descriptions.
  Quand un appel d’outil est nécessaire, le modèle insère dans sa réponse un bloc spécial (incluant des tokens spéciaux, avec le nom de l’outil et ses paramètres), que la couche API extrait ensuite pour le convertir en JSON.
  Les résultats d’exécution de l’outil sont eux aussi injectés sous forme encodée avec des tokens spéciaux.
  La couche API empêche l’utilisateur d’injecter lui-même ce type de tokens.
  Les modèles les plus récents (SoTA) ont fait l’objet d’un fine-tuning important pour les appels d’outils, à la fois sur des cas génériques et sur des outils spécifiques (par exemple, le modèle Claude Sonnet spécialisé pour les outils de Claude Code).
  C’en est presque étonnant que tout fonctionne aussi bien ; dans les appels d’outils, le fine-tuning joue vraiment un rôle central.
  Cela peut fonctionner même sans fine-tuning, mais le taux de réussite chute fortement.
- Je pense que l’hypothèse « ils ont fine-tuné le modèle pour qu’il renvoie les exemples nécessitant un appel d’outil sous forme de blocs spéciaux » est correcte.
  Il a été entraîné à répondre au format d’appel d’outil quand il ne connaît pas bien la réponse ou quand on lui donne cette instruction.
  Il y a eu à la fois un entraînement sur le format des exemples d’appel d’outil eux-mêmes, et un entraînement spécialisé sur certains outils.
  Par exemple, gpt-oss a tendance à vouloir utiliser un outil de recherche même quand rien ne le mentionne.
  La documentation d’Anthropic liste aussi à part des outils familiers (par ex. text_editor, bash), et il est probable que leur usage, jusqu’à sa sémantique profonde, ait fait l’objet d’un entraînement spécifique.
  En pratique, la structure reste assez fragile et repose sur des signaux de bas niveau comme des « tokens spéciaux ou des séquences de tokens ».
Quand on lit « si on continue à injecter des tokens dans la boucle, un agent apparaît », remplacer « tokens » par « argent » donne une satire très réaliste.
En fin de compte, cela revient à dire que si on continue à brûler de l’argent, un agent apparaît.
- Je ne pense pas qu’on puisse dire que les tokens, c’est entièrement de l’argent.
  Les modèles locaux continuent eux aussi de s’améliorer.
  Pour l’instant, obtenir les meilleurs résultats demande encore des tokens (= de l’argent), mais il est fort possible que cela change à l’avenir.
Quand il n’y a que des images comme ça, ça devient beaucoup trop difficile à lire.
On a l’impression de regarder un simulateur de scroll.
Je me demande pourquoi on aurait besoin d’autres outils que bash.
Parcourir la liste des fichiers, trouver et explorer un dépôt, modifier le contenu d’un fichier, tout cela n’est-il pas faisable uniquement avec bash ?
Ou bien est-ce le genre de cas montré dans l’exemple mini-swe-agent ci-dessus ?
- Techniquement, bash seul permet déjà de réaliser une grande variété de tâches, et j’ai moi-même eu des succès de cette manière.
  Ce qui est intéressant, c’est que plus on limite les outils, plus l’agent aborde les choses de façon créative.
  Mais lorsqu’on fournit divers outils entraînés, le modèle sait déjà bien comment les utiliser, donc la consommation de tokens est plus efficace et le taux de réussite global est meilleur.
  En n’utilisant que bash, il se perd aussi souvent dans les bashisms, la gestion des arguments ou le traitement des espaces.
- Utiliser des outils séparés est bien plus simple que de tout concentrer dans bash.
  Si tout passe par bash, il faut alors implémenter séparément un système qui exécute immédiatement les commandes toujours sûres (par ex. lister des fichiers) et demande une approbation utilisateur pour les autres commandes plus risquées.
  Fournir la consultation de la liste des fichiers comme outil séparé permet aussi d’empêcher l’exposition de fichiers en dehors du répertoire du projet.
- En pratique, un agent de code peut fonctionner avec seulement un outil bash et un outil Edit (même si Edit n’est pas strictement indispensable, l’inefficacité augmente sans lui).
  En revanche, cela peut compliquer la recherche dans le code.
  On pourrait probablement compenser en ajustant le prompt pour qu’il utilise ripgrep via bash.
- Pourquoi a-t-on besoin d’un IDE ? On peut tout faire dans le shell, alors pourquoi en utiliser un ?
  Une UI sert précisément à fournir au bon moment les informations et les actions nécessaires.
- À la question de savoir pourquoi il y a autre chose qu’un outil bash, je pense que c’est probablement parce qu’on commence avec le minimum d’outils, puis qu’on peut toujours ajouter bash plus tard.
Plutôt que d’expliquer longuement « comment construire un agent », j’aimerais qu’on me montre un projet réellement construit par un agent.
- Ce serait super si vous fabriquiez directement un agent et le partagiez sur HN sous forme de « Show HN ».
Je demande si quelqu’un peut expliquer ce que signifient les axes Oracle, Agent, high safety et low safety.
J’ai essayé directement avec les modèles on-device d’Edge et de Chrome (phi4-mini, gemini nano), et j’ai été surpris de voir que, vu la taille des modèles, cela fonctionnait plutôt bien.
cas d’expérimentation : how to build an agent on device

crawler 2025-08-25

On dit souvent qu’une image vaut mille mots, mais dans ce document, on a l’impression que la valeur des images est soldée à -99,6 %. Je me demande bien ce que c’est.

C’est vraiment hilarant hahaha, je me demandais ce que ça voulait dire, puis en ouvrant le lien, j’ai tout de suite compris.

savvykang 2025-08-25

Les miniatures des autres articles du blog sont aussi nulles, elles donnent vraiment envie de ne surtout pas cliquer dessus.

nemorize 2025-08-25

Hahahahahahahahahahahahaha