IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Peut-on laisser un agent IA coder sans supervision ? Six dépôts en une nuit grâce à un agent IA autonome : l'expérience repomirror comme miroir des défis de la programmation automatisée

Le , par Stéphane le calme

347PARTAGES

15  0 
Dans l’univers des hackathons, certaines idées ressemblent d’abord à des blagues de développeurs… avant de révéler un potentiel insoupçonné. C’est exactement ce qui s’est produit avec le projet repomirror, né lors du hackathon YC Agents. Le principe ? Placer un agent de codage dans une boucle infinie (while true) et observer ce qu’il produisait. Résultat : en une seule nuit, l’agent a livré six dépôts GitHub fonctionnels. Derrière l’anecdote volontairement provocante, se cachent des questions fondamentales sur l’avenir du développement logiciel automatisé, le rôle des ingénieurs et les risques de confier la production à des entités autonomes.

Depuis une dizaine d’années, les pratiques CI/CD (intégration et déploiement continus) ont profondément transformé le développement logiciel. Tests automatisés, pipelines de déploiement, monitoring et rollback rapides sont devenus la norme. L’expérience repomirror pousse la logique un cran plus loin : et si l’on retirait complètement l’humain de la boucle, en laissant un agent IA coder, commiter et pousser en continu ? On passe alors d’un paradigme « l’humain valide l’automatisation » à « l’automatisation valide elle-même ses actions ».

C'est l'expérience menée par l'équipe derrière le projet RepoMirror, qui a placé un agent de codage, Claude Code, dans une simple boucle while.

Ce week-end, lors du hackathon YC Agents, nous nous sommes posé la question suivante : quelle est la façon la plus étrange d'utiliser un agent de codage ?

Notre réponse : exécuter Claude Code en boucle indéfinie et voir ce qui se passe.

Il s'avère que ce qui se passe, c'est que vous vous réveillez avec plus de 1 000 commits, six bases de code portées et un petit outil bancale que nous appelons RepoMirror.t.
L'expérience : un concept d'une simplicité redoutable

Inspirée par une idée de Geoff Huntley, l'équipe a mis en œuvre une approche minimaliste. Le dépôt GitHub du projet documente l’expérience. L’idée était simple :
  • Lancer un agent de codage IA (similaire à ceux proposés par GPT ou Claude).
  • L’enfermer dans une boucle while où il doit générer du code et créer des dépôts Git.
  • Observer jusqu’où il pouvait aller sans intervention humaine.

Au lieu de donner des instructions complexes, ils ont utilisé une invite (prompt) concise et précise pour guider l'agent. Celui-ci a ensuite été placé dans une boucle, le laissant travailler de manière indépendante pour identifier les tâches à accomplir et générer le code nécessaire.

Cette méthode a permis à l'agent d'opérer sans surveillance humaine, se contentant de suivre une seule directive : porter une base de code d'un langage (ou d'un framework) à un autre. Le résultat a été spectaculaire : en une seule nuit, l'agent a réussi à porter pas moins de six bases de code, dont le portage de assistant-ui de React vers Vue.js et celui de Vercel AI SDK de TypeScript vers Python : preuve que, même sans supervision directe, il peut livrer des artefacts logiciels complets.

Comment ça marche ?

Les développeurs se sont servis de Claude Code pour la boucle :

Code : Sélectionner tout
while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
Le prompt était simple

Ton travail consiste à porter le monorepo assistant-ui-react (pour react) vers assistant-ui-vue (pour vue) et à maintenir le référentiel.

Tu as accès au référentiel assistant-ui-react actuel ainsi qu'au référentiel assistant-ui-vue.

Effectue un commit et pousse tes modifications après chaque modification de fichier.

Utilise le répertoire assistant-ui-vue/.agent/ comme bloc-notes pour ton travail. Stocke tes plans à long terme et tes listes de tâches dessus.

Le projet original a été principalement testé en exécutant manuellement le code. Lors du portage, tu devras écrire des tests de bout en bout et des tests unitaires pour le projet. Mais veille à consacrer la majeure partie de ton temps au portage proprement dit, et non aux tests. Une bonne règle empirique consiste à consacrer 80 % de ton temps au portage proprement dit et 20 % aux tests.
Forces démontrées :
  • Vitesse d’exécution : la capacité de livrer plusieurs dépôts en quelques heures est impressionnante.
  • Autonomie : l’agent s’auto-alimente en tâches, sans avoir besoin d’ordres supplémentaires.
  • Expérimentation continue : la boucle favorise la génération de variations de projets.

Limites évidentes :
  • Qualité incertaine du code : rien ne garantit que les dépôts générés soient robustes, testés ou maintenables.
  • Sécurité inexistante : sans garde-fous, l’agent pourrait introduire des vulnérabilités.
  • Risque de dérapage : une boucle infinie sans contrôle peut rapidement saturer l’infrastructure ou générer du « spam code ».


Leçons...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Zulut
Candidat au Club https://www.developpez.com
Le 28/08/2025 à 10:56
Indépendamment des défis liés à la qualité, la sécurité, etc.. la pertinence de ce service "en continu" me semble dépendre de l'expression du besoin. Dans l'exemple, il était très simple (porter un code dans un autre langage). Or la plupart du temps les besoins réels sont difficiles à capter et evoluent, nécessitant des allers/retours fréquents entre les devs et les décideurs. Du coup ça me semble bien, mais réservé à une minorité de cas.
2  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 30/08/2025 à 0:30
On peut faire de tout avec un LLM tant qu'on lui donne un prompt et des outils qui le permettent. Il suffit d'expérimenter un peu avec pour s'en rendre compte. Or ils répondent à une question encore plus simple que ça : peut-on le faire tourner en boucle et que peut-il se passer ? Ils ont fait la partie facile de l'expérience parce que c'était facile à faire (on lance et on revient voir plus tard), mais on laissé la partie difficile de côté alors que c'est là qu'est tout l'intérêt (comme très souvent dans tout travail de recherche) : évaluer la qualité de ce qui a été produit pour pouvoir le contre-balancer avec les gains observés.

Ce genre de travail n'a aucun intérêt à part générer du buzz facile. Ils ont juste consommé de l'électricité pour rien.
2  0