10 principes du codage IA par le créateur d'OpenClaw
Peter Steinberger, créateur du projet le plus rapidement starré de l'histoire de GitHub, partage 10 principes pour travailler avec les agents IA.
L’interview de Peter Steinberger, créateur d’OpenClaw (anciennement Clawdbot), m’a véritablement marqué. Il est aussi l’auteur du projet ayant atteint la croissance de stars la plus rapide de l’histoire de GitHub.
Peter est un vétéran qui a dirigé une entreprise de 60 à 70 personnes pendant 13 ans, l’a vendue, a pris trois ans de pause, puis est revenu. Sa vision du développement à l’ère de l’IA est fondamentalement différente de ce que la plupart d’entre nous supposent.
Un début simple
Il n’y avait aucun plan d’affaires ambitieux au départ. Il voulait simplement « jouer avec l’IA » et a fini par créer un outil parce qu’il souhaitait discuter avec son ordinateur personnel via WhatsApp en déplacement.
Le déclic
Le moment décisif est survenu lors d’un voyage. Il a envoyé un message vocal à son agent - mais il n’avait jamais codé de support vocal. L’agent a identifié le format Opus par lui-même, trouvé ffmpeg pour le convertir, localisé une clé API, transcrit et traduit le message, puis renvoyé une réponse. C’est à cet instant qu’il a compris que les agents sont des « bêtes intelligentes et débrouillardes ».
Fort de ces expériences, Peter a formulé ses 10 principes du codage IA.
Abandonner le perfectionnisme pour travailler avec l’IA
Gérer une équipe de 70 personnes lui a appris à accepter un travail qui ne correspond pas à son style personnel. Du code qui ne reflète pas exactement vos préférences mais qui fonctionne correctement, c’est suffisant. Cette flexibilité est devenue son atout majeur dans la collaboration avec les agents.
Concevoir des systèmes où les agents vérifient leur propre travail
Peter appelle cela « fermer la boucle (Close the loop) ». Compilation, lint, exécution, vérification - l’agent gère tout. Quand les humains doivent valider des étapes intermédiaires, ils deviennent un goulot d’étranglement qui ralentit l’ensemble.
Les Pull Requests sont mortes - bienvenue aux Prompt Requests
Le code lui-même compte moins que le prompt qui l’a produit. Peter rejette la plupart des PR externes, n’en extrait que l’idée clé et la recycle sous forme de prompt. Son frère travaille de la même manière - signe que ce modèle se répand déjà.
Remplacer les revues de code par des discussions d’architecture
Même sur Discord, l’équipe principale ne parle pas de code. Ils discutent de la structure du système, des décisions majeures et de la direction. Toute l’équipe a intériorisé l’idée que les détails d’implémentation relèvent de l’agent.
Faire tourner 5 à 10 agents simultanément
Au lieu de s’acharner sur une seule tâche, il met plusieurs tâches en file d’attente en parallèle. Planifier, déléguer à un agent, passer immédiatement au suivant. C’est ainsi que Peter maintient son état de flow tout au long de la journée.
Consacrer un temps étonnamment long à la planification
Peter échange longuement avec les agents durant la phase de planification - il questionne, révise, conteste, et itère jusqu’à ce que le plan soit solide. Il préfère Codex à Claude Code pour l’exécution, car Claude Code pose des questions de clarification en cours de route, ce qui brise le flow. Quand le plan est béton, l’exécution ne nécessite quasiment aucune intervention.
Donner des instructions volontairement vagues
Des instructions trop précises cantonnent l’IA dans un périmètre restreint. Laisser intentionnellement de la marge permet à l’agent de découvrir des pistes que vous n’aviez pas envisagées. L’ayant testé personnellement, je confirme que ça fonctionne - des solutions inattendues émergent régulièrement. Cela dit, ce n’est pas toujours l’approche adaptée.
Tester en local plutôt qu’attendre 10 minutes le CI distant
Attendre 10 minutes qu’un pipeline CI distant s’exécute, c’est du temps perdu. Concevez le système pour que les agents lancent les tests en local. Plus la boucle de feedback est courte, plus l’itération est rapide.
La majorité du code n’est que de la transformation de données ennuyeuse
L’essentiel du code applicatif consiste à « convertir des données d’un format à un autre ». Inutile de s’y accrocher - déléguez-le à l’agent. Concentrez votre énergie sur la conception du système, pas sur la tuyauterie de données.
Ceux qui aiment livrer des produits s’adaptent mieux à l’IA
Les développeurs passionnés de puzzles algorithmiques ont en réalité plus de mal avec la transition vers l’IA. Ceux qui s’intéressent davantage aux résultats et au lancement de produits s’adaptent rapidement. C’est un schéma que j’observe régulièrement autour de moi.
La vision de Peter pour l’avenir
Il prédit que d’innombrables applications disparaîtront, ne laissant que des API. Plus besoin d’ouvrir MyFitnessPal pour saisir manuellement vos repas : envoyez simplement une photo à votre agent, qui calculera les calories et ajustera vos objectifs de santé automatiquement.
Ce qu’il faut retenir
Le débat reste ouvert, mais les 10 principes de Peter convergent vers une seule direction : abandonner le perfectionnisme, discuter d’architecture plutôt que de réviser du code, laisser les agents vérifier leur propre travail, et en faire tourner plusieurs en parallèle.
Tout cela tend vers la création d’un environnement où le développeur n’a plus besoin d’écrire le code lui-même. Si c’est la direction que nous prenons, alors la véritable compétence à l’ère de l’IA n’est pas d’écrire du bon code - c’est de concevoir le système qui résout les problèmes sans que vous ayez à en écrire une seule ligne.
Références :
Rejoindre la newsletter
Recevez des mises à jour sur mes derniers projets, articles et expériences en IA et développement web.