- Exploitation d’un workflow personnel d’« usine d’IA » qui automatise la génération de code jusqu’à sa vérification à l’aide de plusieurs agents IA (claude/o3/sonnet, etc.)
- En cas de problème, l’idée centrale consiste à améliorer les entrées (Input) comme le plan, le prompt et la composition des agents, plutôt que de corriger directement le code produit (Output), afin d’élever le niveau d’automatisation
- En améliorant itérativement les entrées de cette manière, les agents progressent continuellement et maximisent la productivité sur les tâches répétitives
- Répartition des rôles entre agents : planification (o3/sonnet4), exécution (sonnet3.7/4), vérification (o3/sonnet4), etc., ce qui permet un traitement parallèle et une boucle de feedback automatisée
- Même les erreurs de code ou les problèmes de style sont répercutés dans les modèles de plan pour être améliorés dès la génération suivante ; l’« usine » elle-même grandit grâce à l’amélioration répétée des entrées
Vue d’ensemble de l’usine d’IA et principes clés
- Plusieurs fenêtres claude code sont ouvertes sur différents git-worktree afin de maintenir des environnements de travail isolés
- o3 et sonnet 4 sont utilisés pour établir les plans, sonnet 3.7 ou sonnet 4 pour l’exécution, et o3 pour l’évaluation des résultats
- Planification, exécution et vérification sont réparties en parallèle entre les agents afin d’améliorer l’efficacité
Principe fondamental – « améliorer l’entrée (Input) elle-même plutôt que modifier le résultat (Output) »**
- Lorsqu’un problème survient, au lieu de patcher directement le code généré, l’objectif est d’obtenir une amélioration automatisée en ajustant le plan, les prompts et le mix d’agents
- Le concept s’inspire du jeu Factorio : construire un réseau d’agents IA en forme d’usine qui se développe automatiquement
- Dans cette structure, la boucle planification-codage-vérification-amélioration tourne en continu, créant un environnement où les agents IA produisent, vérifient et améliorent eux-mêmes le code
Workflow quotidien – structure de l’usine
- L’interface principale est claude code ; en local, l’auteur utilise aussi mcp, Goose (pour connecter des modèles Azure OpenAI), o3, etc.
Étape 1 : planification (Planning)
- Saisie d’une tâche de haut niveau dans claude code → o3 pose des questions complémentaires puis génère un plan (
<task>-plan.md)
- Le plan contient à la fois la demande d’origine et le plan d’implémentation
Étape 2 : exécution (Execution)
- sonnet 4 relit le plan puis le convertit en liste de tâches
- claude code exécute le travail et utilise sonnet 3.7 ou 4 selon la complexité de la tâche
- claude laisse un historique de commits à chaque étape du travail, ce qui permet un rollback facile en cas de problème
Étape 3 : vérification et feedback (Verification → Feedback)
- sonnet 4 effectue une première vérification du code généré par rapport au plan
- Ensuite, o3 réalise une vérification plus stricte en le comparant au plan et aux exigences initiales
- o3 signale rigoureusement le code inutile (par ex. des flags
lint ignore) ou les structures obsolètes
- Les problèmes révélés lors de la vérification sont pris en compte non pas via une correction directe du code, mais via l’amélioration des modèles de plan
- Grâce à git worktree, plusieurs instances de claude code peuvent tourner en parallèle, ce qui permet plusieurs tâches simultanées
Pourquoi les « entrées » sont plus importantes que les « sorties »
- Le résultat (Output) peut être jeté, mais les plans/prompts (entrées) sont un actif cumulatif qui continue de s’accumuler et de s’améliorer
- Déboguer au niveau des entrées (plans, prompts) permet d’étendre les bénéfices à tous les travaux futurs
- Les agents cessent d’être de simples générateurs pour devenir des entités capables d’apprendre et de collaborer
- Exemple : faire remplacer un code qui charge un CSV entier en mémoire par un traitement en flux, puis répercuter ce pattern dans le plan pour tous les CSV afin de permettre une vérification automatique par la suite
Extension de l’usine et collaboration entre agents
- Avec MCP, des agents spécialisés sont affectés à différentes tâches et parallélisés
- Exemple : un agent dédié à l’application de règles de style locales en rassemblant tout le code Clojure ; il corrige les problèmes de style apparus dans les cycles lint/test/debug de claude
- Même dans le code des bibliothèques internes, des améliorations de productivité et de cohérence sont apportées, par exemple en remplaçant les anciens usages de retry et de
Thread/sleep par une bibliothèque retry interne
- En construisant plusieurs agents de petite granularité, il devient possible d’automatiser aussi des workflows complexes en les combinant par sous-tâches spécifiques
- Exemple : à partir d’une spécification d’API et de cas métier, une combinaison d’agents peut gérer automatiquement jusqu’à l’intégration, aux tests et à la documentation
- Point clé : continuer à modifier les entrées, relancer de façon itérative, puis réinjecter le feedback dans la tentative suivante en cas d’échec, de blocage ou de manque de contexte
- Le code lui-même est consommable ; les véritables actifs sont les instructions (entrées) et la composition des agents
- Toutes les leçons issues des échecs, blocages ou insuffisances de contexte sont réinjectées dans l’entrée suivante pour compléter la boucle de l’usine
Étapes suivantes et orientations futures
- Renforcer la coordination globale entre agents afin de mieux suivre l’ensemble du workflow et d’y introduire davantage d’automatisation
- Mieux relier les documents métier et les informations des agents, et améliorer l’exploitation d’informations de plus haut niveau d’abstraction
- L’objectif est d’implémenter des workflows de plus en plus complexes et d’élargir la collaboration ainsi que les interactions sophistiquées entre agents
- L’auteur explore aussi des moyens d’exploiter au maximum les quotas de tokens de plusieurs fournisseurs et de basculer facilement entre eux, notamment pour répondre aux limites de tokens de bedrock sonnet 4
Conclusion
- Aujourd’hui, dans cette usine d’IA, la génération et la vérification automatiques du code font partie du quotidien, au point qu’un déploiement peut avoir lieu pendant le temps d’un café
- L’automatisation n’est pas encore totale, mais le principe « améliorer les entrées plutôt que corriger les sorties » s’est imposé comme l’essence même de cette usine
1 commentaires
Commentaires sur Hacker News
Je pense que cet article sera presque impossible à comprendre pour quelqu’un qui n’a pas encore vécu un moment de révélation avec Claude Code
Si on lève les restrictions de permissions avec
claude --dangerously-skip-permissionset qu’on lui confie un problème complexe, on peut voir Claude utiliser librement divers outils pour le résoudreAujourd’hui encore, je lui ai fait compiler, exécuter et même déboguer directement, via Docker, un générateur de fractales de Mandelbrot en assembleur 486
Il s’en est remarquablement bien sorti
lien gist
Je pense que c’est un exemple extrêmement simple pour ce genre d’IDE ou de LLM
L’assembleur est déjà largement présent dans les jeux de données d’entraînement, et Docker aussi
J’ai déjà laissé Cursor explorer librement ma codebase
J’espère que les outils récents finiront un jour par vraiment y arriver, mais j’ai l’impression qu’on n’en est pas encore là
Je voudrais aussi recommander cette vidéo, présentée à la conférence AI Engineer par Dagger (et le fondateur de Docker)
Elle peut elle aussi sembler un peu déroutante
Je l’écris au cas où cela pourrait aider
Je suis passé de Claude max à pro, et à 20 dollars par mois la limite d’usage est largement suffisante
Comme cela semble entrer en concurrence avec Gemini CLI, je suis content de payer moins maintenant
Je pense que pratiquement tous les LLM peuvent résoudre ce genre d’exemple ou de contexte sans grande difficulté
J’ai déjà géré des montées de version de dépendances Rust bien plus complexes, répétées plus de 30 fois, avec du code wasm custom
Claude relie plusieurs outils comme context7 ou mcp-lsp pour rassembler les détails
Mais à force de l’utiliser, on finit par heurter ses limites, et si on pousse vers quelque chose de plus précis et plus difficile, ses faiblesses apparaissent
À propos de cette phrase disant qu’avec
claude --dangerously-skip-permissions, il résout des problèmes complexes en utilisant plusieurs outilsJ’ai déjà vu Claude passer plus d’une heure à essayer de corriger du code de la mauvaise manière
J’ai fini par intervenir moi-même en lui disant : « écris d’abord les tests unitaires, puis écris le code en les faisant passer et reviens me voir »
Claude Code est vraiment un outil impressionnant, mais dans la pratique il faut sans cesse lui redonner une carte architecturale de base
J’ai l’impression qu’il est difficile d’évaluer ce genre de setup sans savoir comment le code produit est réellement utilisé
Pour une app de vibe coding utilisée à titre personnel, c’est facile à croire,
mais j’ai du mal à avaler l’idée qu’on écrive du code de haute qualité dans un environnement de production complexe
Entièrement d’accord
Claude Code m’aide énormément à coder plus vite, mais je vérifie toujours moi-même chaque changement pour m’assurer qu’on construit bien le meilleur système possible
Les quelques fois où je l’ai simplement laissé tourner, il a livré des bugs aux utilisateurs
En réalité, je ne comprends pas très bien le workflow ni les concepts décrits dans cet article
C’est sans doute parce que l’explication reste assez floue
Au quotidien, j’utilise des structures où plusieurs agents se parlent entre eux, des agents asynchrones, des git work tree, etc., pour gérer des systèmes de production complexes
Je ne modifie pas jamais la sortie, bien sûr, mais quand le résultat n’est pas celui que je veux, j’y vois plutôt un signal qu’il faut améliorer mon workflow
J’essaie moi aussi un workflow similaire, donc je voulais partager mon expérience
La codebase Go que je gère compte plusieurs centaines de milliers de lignes, et elle est réellement utilisée par des dizaines à des centaines de milliers d’utilisateurs B2C
Les performances sont confortables, mais on est dans la finance, où la précision et la fiabilité sont cruciales
Comme je n’utilise qu’une clé OpenAI, je me limite à un setup de base avec codex-cli et quelques scripts simples pour cloner les dépôts, configurer les agents, exécuter les prompts, etc.
Une instance codex me notifie via une alerte système quand c’est mon tour, et j’utilise fzf pour me rattacher à une session tmux quand j’en ai besoin
Je n’ai pas encore essayé MCP, mais c’est sur ma liste
Cette façon de faire aide énormément pour les petites tâches dispersées, et aujourd’hui je produis bien plus de petits PR qu’avant
La métaphore « cattle not pets » reste valable : pour les petites tâches, je balance simplement un prompt rapidement afin de réduire la distraction
Pour les tâches plus grosses, ça ne semble pas encore très bien adapté, et il est possible que je n’aie pas encore construit un flywheel de contexte suffisant
La plupart du temps, je lis et retouche toujours moi-même le code produit avant de l’envoyer en review
Je gère aussi presque tout le contrôle des changements manuellement : branch, commit, push, tout est fait à la main
J’ai essayé quelques outils d’automatisation, sans encore basculer complètement
J’adhère à 100 % à l’idée de « corriger l’entrée, pas la sortie »
C’est un principe extrêmement puissant même sans IA, et l’industrie l’adopte de plus en plus
Avec un processus non déterministe comme les LLM, c’est moins simple à appliquer, et cela ressemble davantage à une pratique qu’à une science
Merci pour ce bon article
Dans un texte intitulé « Vibe Specs », je présente un workflow similaire, mais un peu plus simple
article de blog associé
J’applique cette règle à l’ensemble de la codebase, et je fais en sorte que l’IA agisse différemment sur deux points
(1) lui faire poser des questions avant toute chose
(2) lui faire créer un document
spec.mdavant d’écrire du codeL’idée générale est proche, mais je me limite à un seul LLM
J’ai l’impression que la plupart d’entre nous essayons à peu près la même chose
Je suis développeur solo, avec une approche très orientée ingénierie, et j’expérimente différentes automatisations de production
Pour moi, le but ultime est de pouvoir faire confiance au code à partir de tests e2e générés automatiquement par l’agent, indépendamment de son implémentation
Je n’y suis pas encore arrivé complètement
Désormais, Claude Code prend aussi en charge ce type de flux nativement avec le « plan mode »
Créer manuellement des fichiers
.mdme paraît honnêtement lent et pénibleL’idée de base, c’est qu’on peut documenter en continu ce que le système doit faire — à haut niveau comme dans les détails fonctionnels —, comment prouver qu’il le fait, et même la façon de l’implémenter, comme l’architecture ou le style de code
La raison d’utiliser plusieurs modèles est de réduire les biais et d’élargir les options de fine-tuning selon les tâches
Un jour, même des systèmes vastes et complexes pourront peut-être être recréés à partir d’un ensemble d’exigences, et ce sera alors seulement que le logiciel correspondra vraiment à sa spécification
Le seul « legacy code » restant sera alors la documentation de spécification legacy
L’idée est de corriger la spécification, pas le code généré
mème associé
Je me demande ce que les gens construisent réellement, au juste
À chaque fois qu’on parle de workflows IA, il est difficile de savoir si on évoque un flux à moitié fantasmé ou un usage vraiment productif
Si le LLM écrit tout le code, je perds simplement l’intérêt
Sur une cinquantaine de projets, seuls deux ont été faits avec un LLM, et même là je les ai retouchés moi-même
Pour tous les autres, je me suis contenté de penser que « ce serait bien d’avoir ça », sans réellement m’intéresser au résultat
Au final, on se retrouve coincé dans une boucle à batailler avec plusieurs modèles et les détails d’implémentation, à jeter au visage de l’ordinateur des documents de design, des prompts et des données d’exemple quand on n’obtient pas le comportement voulu
Il est bien plus rapide et bien moins stressant de simplement se faire aider pour compléter le code petit à petit
Avec le recul, j’ai l’impression d’y avoir surtout dépensé du temps et de l’argent, pour obtenir un logiciel qui fonctionne à peine
S’il y a des exigences claires ou une codebase existante, et que je guide activement le processus, les agents peuvent être très utiles, mais les approches de type vibe coding ne sont ni amusantes ni vraiment capables de sortir la qualité voulue, sauf peut-être pour de petits scripts ou des apps de niche
C’est beaucoup trop cher, et le code reste brouillon
Au fond, on a l’impression de perdre son temps dans une dispute sans fin avec l’ordinateur
Autant le faire soi-même
Le problème quand plusieurs agents travaillent chacun dans leur work tree, c’est qu’ils arrivent tous à des idées complètement différentes dans les moindres détails, si bien que l’expérience utilisateur n’a plus aucune cohérence
Par exemple, les agents qui construisent un dashboard Documents et un dashboard Design les conçoivent depuis des perspectives totalement différentes
Il n’y a aucune unité, ni dans le design, ni dans la structure, ni dans le schéma de base de données ou la conception de l’API
Même avec la même entrée, la sortie diffère
Au final, à force d’ajouter des fichiers d’instructions pour préserver la cohérence, les gros projets se retrouvent vite avec plusieurs milliers de lignes comme base, et même la fenêtre de contexte ne suffit plus
En conclusion, j’ai l’impression qu’il serait plus pertinent d’utiliser un petit LLM entraîné uniquement sur certaines règles et certains schémas
Plutôt qu’un gros LLM capable de couvrir un univers d’idées immense via le prompt, un petit LLM semble être la bonne réponse
Des résultats totalement différents selon les agents, aucune cohérence de design
Au final, il faut absolument un senior
Que ce soit avec une IA ou avec des humains, il faut bien fournir soi-même le minimum de structure et de flexibilité pour aller dans la direction voulue
Sans structure, il vaut largement mieux coder directement
Moi, j’ai construit moi-même la première version, puis ensuite il était plus facile de garder la cohérence en disant à Claude Code : « fais-le comme cet exemple »
Une forme de code à la ADHD, où l’on essaie de générer un produit au hasard puis on recommence jusqu’à ce que ça colle ?
Ne vaudrait-il pas mieux écrire directement du code pensé pour pouvoir évoluer ?
Inutile d’augmenter encore l’empreinte carbone pour ça
L’objectif final, c’est d’exclure les développeurs de ce processus
Le propriétaire métier demande une nouvelle app CRUD, et elle part directement en production
Bien sûr, le résultat sera truffé de bugs, lent, et stockera les données dans une base non sécurisée, mais ce ne sera pas mon problème
Le tout se termine par une formule très virulente évoquant le fait d’avaler une boisson brûlante d’un trait
La programmation a changé pour toujours, et il faut accepter ce changement rapidement
Dire « écrivez simplement le code » revient un peu à dire qu’il faudrait tous continuer à entretenir nous-mêmes nos calèches
Les voitures tombent aussi en panne, ce n’est pas une raison pour s’accrocher aux anciennes méthodes
Je me demande pourquoi on entend toujours « écrivez simplement vous-même du code évolutif »
Aujourd’hui, même les assistants de code peuvent écrire en zero-shot du code évolutif et maintenable ; j’aimerais demander si vous avez seulement essayé de le leur demander
Les humains aussi avancent finalement par essais et erreurs pour trouver la solution
Avec plus d’expérience, la différence tient surtout au degré de simulation mentale
Et si l’on veut parler d’empreinte carbone, alors faut-il considérer que ce n’est plus un problème si les data centers de l’IA tournent aux énergies renouvelables ?
Je pense qu’il faut trouver comment intégrer l’IA plus efficacement dans le workflow
Ceux qui ont essayé de l’adopter activement ont probablement rencontré les mêmes interrogations, sans qu’il existe encore de solution claire
À ce stade, l’essentiel est selon moi d’assigner à l’IA un rôle minimal mais précis
Par exemple, dans un workflow d’agents utilisé pour la recherche boursière, on peut créer deux IA, « Bullish Guy » et « Bearish Guy », et les faire débattre des avantages et des inconvénients d’une même valeur
En leur faisant mener la recherche depuis des positions opposées, on obtient une analyse à la fois plus complète et plus approfondie
Cette idée m’est venue en observant la manière dont les gens débattent sur les réseaux sociaux
Dans le vibe-coding, j’ai l’impression que le résultat dépasse rarement l’auto-référence, et que cela ressemble surtout à un passe-temps coûteux, fait de fabrication infinie de gadgets, un peu comme ce qu’a été l’impression 3D
Je me demande si l’équivalent du « benchy » en vibe coding aujourd’hui, ce n’est pas simplement l’app todo
Tous ceux qui conçoivent ou développent des produits l’utilisent
La seule raison pour laquelle le grand public ne s’en sert pas davantage, c’est qu’on peut déjà commander immédiatement sur Amazon presque tous les objets en plastique dont on a besoin
À une époque sans achat en ligne, cela aurait été bien plus utile à la personne moyenne
À l’avenir, ce sera probablement une technologie vraiment nécessaire surtout pour les personnes capables de concevoir elles-mêmes des fichiers sur mesure