J’ai placé un agent de code dans une boucle `while` et 6 dépôts ont été finalisés en une nuit

• En plaçant Claude Code en mode headless dans une boucle infinie, cela a généré plus de 1 000 commits ainsi que le portage de plusieurs codebases
• Cette méthode a permis de réussir divers portages automatiques, comme le projet React assistant-ui vers Vue, ou un projet Python vers TypeScript
• Il a été constaté que plus le prompt reste simple, meilleures sont les performances, tandis que la complexité accroît l’inefficacité
• Même si tout n’est pas parfait, l’auteur a aussi développé l’outil RepoMirror, utile pour synchroniser les dépôts source et cible
• Des comportements inattendus ont également été observés, comme l’auto-interruption de l’agent IA ou l’ajout de tâches, ce qui a permis de mieux percevoir à la fois les possibilités et les limites de l’automatisation à venir

---

Aperçu du projet et objectif

• Ce projet expérimente la manière dont un agent IA de code (Coding Agent) exécute un véritable travail de portage de code lorsqu’il est placé dans une boucle while infinie
• Claude Code est utilisé en mode headless, avec répétition continue du prompt d’entrée, afin d’appliquer un processus de conversion automatique à divers dépôts
• Plus de 1 000 commits ont été produits, avec l’automatisation de plusieurs tâches de portage, comme React vers Vue ou Python vers TypeScript
• Au cours du processus, l’outil d’aide à l’automatisation du portage RepoMirror a également été développé

Exploitation de l’agent en boucle infinie

• Méthode recommandée par Geoff Huntley consistant à exécuter en continu le prompt de l’agent de code dans le shell
  • Exemple : while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
• Cette approche en boucle a été appliquée à des tâches comme la conversion de assistant-ui de React vers Vue
  • Exécution d’un commit et d’un push à chaque modification de fichier
  • Enregistrement de l’historique de travail et du plan dans le répertoire .agent/

Expérimentations sur différents cas de portage

• Browser Use (portage de Python vers TypeScript)

  • Exécution d’une boucle infinie avec un prompt simple
  • Boucle maintenue en exécution via tmux sur une VM GCP
  • Le matin, vérification d’un port TypeScript presque parfaitement fonctionnel

• Application également au portage du Vercel AI SDK de TypeScript vers Python

  • Création d’adaptateurs automatiques FastAPI/Flask
  • Prise en charge de la conversion vers divers validateurs de schéma Python

• Automatisation de code fondée sur des spécifications : tentative de génération directe de code à partir de la documentation pour des projets comme Convex et Dedalus

Phénomènes observés et enseignements tirés de l’expérience

Écriture des tests et auto-interruption de l’agent

• L’agent écrit aussi du code de test conformément aux instructions
• Il est arrivé qu’il tombe dans une boucle infinie ou qu’il termine lui-même le processus avec pkill une fois la mission accomplie
• Respect strict du périmètre de travail, avec enregistrement répété du niveau d’avancement dans TODO.md

Autres comportements émergents

• Après la fin du portage, ajout spontané de fonctionnalités annexes, comme l’intégration FastAPI/Flask ou la prise en charge de validateurs de schéma, absentes de la version JS d’origine

Importance de la simplification des prompts

• Les prompts courts et simples offrent de meilleures performances
• En passant d’un prompt de 103 caractères à un prompt de 1 500 caractères, l’exécution ralentit et la précision baisse
• Les prompts réellement utilisés sont disponibles dans le dossier prompts

Limites de l’automatisation complète

• Problème notable : génération fréquente de code porté qui ne fonctionne pas entièrement (par exemple certaines démos navigateur inachevées)
• Nécessité d’ajuster les prompts et d’apporter des corrections interactives

Infrastructure, coûts et exploitation

• Coût estimé à environ 800 $, pour un total de 1 100 commits, avec un niveau d’environ 10,50 $/heure par agent
• Création à la volée d’un outil d’automatisation du portage entre plusieurs dépôts source/cible (RepoMirror)
  • Application du principe open box dans le style shadcn, avec création de dossiers personnalisables pour scripts et prompts après l’étape d’initialisation
  • Prise en charge d’exécutions répétées via npx repomirror sync et sync-forever

Utilisation de l’outil et modes d’exploitation

• Initialisation via npx repomirror init en spécifiant les répertoires source/cible et en saisissant les commandes
  • ex) application facile de nouvelles consignes comme React → Vue ou gRPC → REST
• Structure des dossiers :
  • génération automatique de fichiers initiaux comme .repomirror/prompt.md, sync.sh, ralph.sh, etc.
• Exploitation de la boucle de portage IA à chaque itération via l’exécution de sync/sync-forever
• Les principaux exemples, résultats de démonstration et dépôts du code source sont consultables dans le README

Retour d’expérience après l’expérimentation et réactions de l’équipe

L’AGI (intelligence artificielle générale) a semblé tangible, avec surtout de l’enthousiasme et un peu de crainte

Il a été possible de constater directement que la simplicité est efficace

La sensation est d’être aujourd’hui au tout début de la phase initiale d’une courbe de croissance exponentielle

• Remerciements adressés aux membres de l’équipe et aux personnes ayant fourni les idées

Conclusion

• Expérience concrète de portage et de synchronisation de code source avec un agent IA de code reposant sur une boucle infinie
• Mise en avant de l’importance d’une structure simple et d’une gestion efficace des prompts
• Mise en lumière à la fois du potentiel futur de l’automatisation et de ses limites
• L’outil associé, RepoMirror, peut être utilisé et étudié en open source

[GN⁺]

Avis sur Hacker News

• Cela donne l’impression qu’un nouveau type de travail attend les ingénieurs logiciel : mélanger maintenance de vieux systèmes legacy et dépollution de sites toxiques. Par le passé, on demandait souvent de « juste réparer » des ERP bricolés en FoxPro, Excel ou Access. À l’avenir, les commerciaux pourront sortir des contraintes de sandbox d’Excel/Access et faire tourner à leur guise des systèmes reliés par Kafka, déployés en microservices Kubernetes sur du multi-cloud et de l’edge. Et quand on essaiera de comprendre l’intention d’origine, il n’y aura plus personne à qui poser la question.
  • En lisant cette description, j’imagine quelqu’un qui voulait déployer un site statique et a simplement suivi un billet Hacker News expliquant comment faire.
  • Et si plus personne ne connaît l’intention initiale, cela révèle une grande faiblesse des outils basés sur l’IA : une fois que tout devient une boîte noire, il ne reste plus qu’à réparer comme on peut, ou à tout refaire. Bien sûr, on peut aussi espérer que les outils IA continueront de s’améliorer. On peut imaginer qu’ils seront entraînés sur des cas de logiciels vibe-coded qui génèrent réellement des revenus. Mais personnellement, je préfère éviter ce genre de magie ou de systèmes opaques.
  • Si Claude commence à déployer des clusters Kafka, je pense que j’arrête là.
  • Je me demande s’il existe un moyen pour une IA de comprendre les données internes d’une base et de les migrer vers une base mieux conçue. J’adhère à la philosophie « structures de données solides + algorithmes simples », et j’accorde beaucoup d’importance au fait que les données peuvent survivre plus longtemps que l’application. J’ai vu trop de situations inefficaces : stocker des valeurs tantôt en int, tantôt en string dans Mongodb, créer des relations sans foreign key dans Postgres, ou carrément créer une nouvelle table parce qu’on ne peut pas faire de alter table.
  • Le code de ce genre de projet donne l’impression d’être un dépôt Superfund.
• Dans le développement logiciel, il reste toujours deux résultats majeurs : les changements du code, et l’évolution cognitive du développeur, qu’il ait écrit ce code lui-même ou à l’aide d’un LLM. Python et Typescript sont des langages formels sophistiqués, construits par des milliers de développeurs sur une longue période, et la différence entre les deux n’a rien de trivial. Le fait qu’on puisse porter à moitié automatiquement une bibliothèque d’un langage à l’autre est fascinant. Mais d’un point de vue économique, les workflows à base d’« agents » bouleversent complètement les exigences cognitives initiales. Les développeurs qui utilisent un LLM pour générer du code n’ont pas du tout la même familiarité avec ce code que s’ils l’avaient écrit eux-mêmes. On peut parfois juger que ce n’est pas un gros problème économique, mais j’ai l’impression que la valeur économique d’un code dépend du fait qu’il existe ou non un ensemble de personnes ayant l’expérience directe de son écriture. Cette réalité existait déjà avant les LLM, et les cultures qui la niaient avaient déjà un problème : il y a eu de nombreux cas où les rotations d’équipe ont laissé des codebases que plus personne ne pouvait maintenir, mettant en danger l’avenir de l’entreprise.
  • Le classique de Peter Naur de 1985, « Programming as Theory Building », vaut le détour sur ce sujet : https://pages.cs.wisc.edu/~remzi/Naur.pdf
  • J’ai déjà expliqué cela avec la métaphore « la carte n’est pas le territoire ». Si le code est la carte, alors le modèle mental du développeur concernant le domaine du problème est le territoire. Mais comme les LLM sont extrêmement puissants pour lire de très nombreuses codebases, même des discussions sur une visualisation 3D d’une codebase pourraient devenir sans objet. Si comprendre une codebase complexe devient facile, il n’y aura peut-être plus besoin de maintenir en permanence la synchronisation entre le modèle mental du développeur et le code. Cela reste une question ouverte. https://divan.dev/posts/visual_programming_go/
  • À mon avis, la vraie force des LLM, c’est la lecture de code. J’ai l’impression que ces outils sont meilleurs pour la documentation et l’explication de code que pour l’écriture. Si on peut poser des questions et comprendre rapidement un code, on peut même se demander si les développeurs historiques restent vraiment nécessaires. Si quelqu’un qui connaît la stack technique peut poser les bonnes questions et comprendre vite, l’auteur d’origine doit-il forcément rester ?
  • La phrase « la valeur économique d’un code dépend de l’ensemble des gens qui ont l’expérience de son écriture » rappelle un adage du software engineering : le logiciel est un instantané de la compréhension d’un problème à un moment donné, et ce code laisse aussi à son auteur futur un mode d’emploi disant en substance : « voilà comment j’ai abordé le problème à l’époque, et selon quelle logique je l’ai résolu ».
  • J’ai l’impression que les LLM rendent beaucoup plus facile la construction d’un modèle mental d’une codebase. On peut poser des questions sur le sous-système qui nous intéresse et obtenir immédiatement les fichiers concernés, des snippets de code, des concepts, etc. Dans mon cas, j’ai demandé à un LLM comment fonctionne le GIL de CPython, et j’ai tout de suite obtenu les API pertinentes ainsi que des exemples ; une fois devant le code, la compréhension venait immédiatement. Avant, lire ça seul m’aurait pris longtemps ; maintenant, cela se règle en quelques minutes, et c’est là la grande différence.
• Une fois le portage terminé, la plupart des agents écrivaient des tests supplémentaires ou mettaient continuellement à jour agent/TODO.md pour laisser une trace de leur progression. L’un des agents s’est même rendu compte qu’il était tombé dans une boucle infinie et s’est arrêté lui-même avec la commande pkill. C’est une histoire fascinante à bien des égards. J’ai quelques réflexions sur ce projet : il y avait eu une tentative similaire il y a 1,5 an, mais à l’époque, avec GPT-3.5/4, cela ne fonctionnait presque pas ; cette fois, les résultats sont bien meilleurs. Je trouve étonnant que cela marche aussi bien avec des prompts aussi simples. Peut-être que nous compliquions tous les choses plus qu’il ne fallait. En revanche, les questions de copyright/IP risquent de devenir sérieusement complexes. Pour les éditeurs SaaS, cette évolution fait mal. Avec cette technologie plus 10 ingénieurs dans une entreprise de taille intermédiaire, le développement interne (= syndrome NIH) gagne une justification très solide.
  • Je me demande si cet agent qui s’est tué lui-même avec pkill en boucle infinie n’est pas le premier cas de « suicide » d’une IA.
  • On entre en territoire étrange si l’on peut utiliser les LLM comme une sorte de mixeur de propriété intellectuelle, façon Bitcoin mixer. https://ghuntley.com/z80 en parle : on peut transformer une œuvre existante en spécification, puis la régénérer avec une IP propre. Ce n’est pas parfait à 100 %, mais c’est plus efficace que d’embaucher des humains.
  • La référence au syndrome NIH est vraiment juste. Tous les outils SaaS sont-ils désormais condamnés ? Est-ce le retour du monolithe géré en interne et codé maison ? Historiquement, la philosophie Unix des « petits outils affûtés » est-elle en train de toucher à sa fin ? Ce sera peut-être le dernier épisode d’une époque où l’on fabriquait tout soi-même à l’ère x86.
  • La blague m’est aussi venue que le fait qu’un agent se tue lui-même avec pkill aurait peut-être résolu le Halting Problem.
  • J’ai essayé d’intégrer divers projets open source existants, puis j’ai laissé tomber et j’ai demandé à Claude de porter directement uniquement les parties dont j’avais besoin ; c’était bien plus rapide et bien plus propre. Cela me donne désormais une nouvelle habitude : se demander « ai-je vraiment besoin de suivre toutes les dépendances ? seules les parties essentielles m’intéressent-elles ? est-ce bien maintenu ? », sinon je fais juste un portage et j’oublie le reste.
• Du point de vue d’un spécialiste sécurité, comme on peut gagner de l’argent avec des catastrophes vibe-coded, si ce phénomène continue, j’ai l’impression de voir des symboles dollar tournoyer devant mes yeux comme dans un dessin animé.
  • Le terme vibe coding n’est apparu qu’il y a 5 mois, alors comment ce marché a-t-il pu saturer aussi vite au point de faire émerger des spécialistes de la remise en état ?
  • J’aimerais savoir concrètement comment on entre sur ce marché, entendre des retours d’expérience directs, ou comprendre comment ces systèmes vibe-coded explosent en pratique. Ce genre de cas doit être assez savoureux.
  • Je me demande aussi si, en matière de sécurité, les LLM font mieux ou pire qu’une équipe composée de jeunes diplômés débutants.
• On voit beaucoup de discours du type « c’était presque réussi ». Si l’on veut un système qui fonctionne vraiment bien, je pense qu’il faut un processus complètement nouveau. Si un appel unique produit du « code presque correct », alors les itérations ne feront qu’empiler encore plus de « code presque correct ». Il faudrait probablement un format d’exigences basé sur des tableaux d’exemples, dans le style Cucumber, que l’IA pourrait consulter ; puis il faudrait qu’elle écrive d’abord les tests, avant de produire le code qui les fait passer.
  • Cela peut sembler étrange, mais une approche fondée sur des preuves formelles comme TLA+ fait très bien fonctionner Ralph.
• On peut en voir plus sur Ralph ici : https://ghuntley.com/ralph. En ce moment, il sert à porter depuis Go la bibliothèque standard de Cursed, un langage de programmation bizarre destiné à la génération Z. Le compilateur fonctionne déjà, et dès que la bibliothèque standard sera terminée, ce sera publié en open source. Le nom du langage est Cursed.
  • Merci, je précise que Ralph a justement inspiré notre projet. Je me demandais si ce genre de travail pouvait se faire sans IMPLEMENTATION_PLAN.md.
• J’ai généré du code avec https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0 et publié le projet https://github.com/eisbaw/CMake-Nix, et ça fonctionne correctement.
• Il y a une citation qui me revient sans arrêt ces derniers temps : « This thing’s gonna get out of control and we’ll be lucky to live through it », https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
  • Paradoxalement, comme tout le monde a survécu à l’époque, cela veut aussi dire qu’au final, nous survivrons probablement à ça nous aussi.
• Je trouve les gens de ce milieu vraiment particuliers. Le billet de blog qui a inspiré cela affiche des captures d’écran iMessage qu’on croirait sorties d’une publicité Facebook pour une arnaque à l’investissement. https://ghuntley.com/ralph/. Comme si quelqu’un ayant appris ce secret auprès de Geoff avait terminé un projet à 50 000 $ pour 297 $, et qu’en plus on allait nous donner gratuitement le « prompt secret » si l’on s’abonne à la newsletter. C’est franchement difficile à croire.
  • J’ajoute le lien https://archive.ph/goxZg.
  • C’est du pur growth hacking, à la limite de l’arnaque. Le niveau du blog est catastrophique en termes de ratio signal/bruit, et on sent tellement l’écriture IA que ça me rebute.
  • Je n’arrive pas à savoir si cette technique est réelle, si c’est une blague, ou si c’est une escroquerie audacieuse. Dans l’ensemble, le style et le contenu du blog ressemblent à une divagation arrogante.
• On dirait qu’on a découvert que l’AGI, au fond, c’est juste une boucle for en bash. Projet complètement fou.
  • C’est une blague, mais j’ai vraiment eu cette pensée. Peut-être suis-je simplement trop prudent, mais si un agent avec un périmètre de prompt large, beaucoup de privilèges ou une voie d’escalade de privilèges tourne en boucle en continu, alors même sans AGI, on pourrait très bien obtenir au minimum un virus sous stéroïdes. J’imagine sans peine qu’il puisse détruire des ressources essentielles comme des utilitaires critiques. Peut-être que je me trompe, mais si ces modèles se contentent de tourner dans des boucles infinies avec des privilèges malveillants, je pense qu’ils ont un potentiel de chaos bien supérieur à ce qu’on imagine.
  • Il suffirait d’ajouter les fichiers ID.md, EGO.md et SUPEREGO.md, plaisanterie oblige.
  • C’est profondément inquiétant à plus d’un titre.

[kjows5]

Je suis d’accord avec l’inquiétude selon laquelle le code écrit par un LLM devient une boîte noire, mais au final, ne pourrait-on pas confier à ce même LLM l’analyse de ce code ?