Le créateur de MoltBot : « Je déploie du code que je n’ai pas lu »
(newsletter.pragmaticengineer.com)- Un article d’entretien sur le workflow de Peter Steinberger, qui a enregistré plus de 6 600 commits rien qu’en janvier en utilisant des agents IA en solo
- Moltbot (anciennement Clawdbot) affiche actuellement la croissance en étoiles la plus rapide de l’histoire de GitHub et dépasse Claude Code et Codex dans les volumes de recherche Google
- Peter développe en faisant tourner 5 à 10 agents simultanément et en se concentrant sur les discussions d’architecture plutôt que sur la revue de code
- Pour collaborer efficacement avec l’IA, il est indispensable de concevoir une boucle où l’agent peut compiler, lancer le linting et les tests, puis valider lui-même
- Les ingénieurs qui pensent davantage en termes de résultat et de conception de systèmes qu’en détails d’implémentation s’adaptent mieux au développement natif IA
Qui est Peter Steinberger ?
- Le fondateur qui a fait de PSPDFKit une activité mondiale d’outils pour développeurs
- Il est revenu après 3 ans de pause, en plaçant cette fois les LLM et les agents IA au centre de son workflow
- Son expérience à la tête d’une équipe de plus de 70 développeurs lui a appris à abandonner le perfectionnisme, ce qui améliore aujourd’hui son efficacité avec les agents IA
- En janvier 2026, il a enregistré plus de 6 600 commits en un seul mois, un niveau de productivité inhabituel pour un développeur individuel
- Tout ce travail a été réalisé sur des projets personnels, et non dans une entreprise, et il prend simplement plaisir à développer
Moltbot et sa croissance explosive
- Le projet a enregistré le taux de croissance en étoiles le plus rapide de l’histoire de GitHub ; même comparée à Tailwind CSS, sa courbe de croissance est sans précédent
- La semaine dernière, il a enregistré sur Google un volume de recherches supérieur à celui de Claude Code et Codex réunis
- Selon Peter : « Si l’on ne regarde que les commits, on pourrait croire à une entreprise, mais en réalité, c’est juste une personne qui code chez elle pour le plaisir. »
10 leçons clés d’un workflow fondé sur les agents IA
- Abandonner le perfectionnisme : accepter que le code ne corresponde pas toujours à ses préférences permet de travailler plus efficacement avec des agents
- Fermer la boucle : il faut concevoir un système dans lequel les agents IA peuvent eux-mêmes compiler, faire le linting, exécuter et valider
- La Pull Request est morte, la « Prompt Request » monte en puissance : il devient plus important d’examiner le prompt qui a généré le code que le code lui-même
- La revue de code disparaît au profit des discussions d’architecture : même sur Discord, avec l’équipe cœur, les échanges portent uniquement sur l’architecture et les grandes décisions, pas sur le code
- Faire tourner 5 à 10 agents en parallèle permet de rester dans un état de flow
- Chaque agent travaille en parallèle sur une fonctionnalité différente
- Investir beaucoup de temps dans la planification, avec une préférence pour Codex
- Il construit des plans solides via des échanges itératifs avec les agents
- Il challenge le plan, le modifie, le contredit, puis, une fois satisfait, l’exécute avant de passer au suivant
- Codex travaille de manière autonome sur de longues durées, tandis que Claude Code revient souvent demander des clarifications, ce qui le distrait
- Il utilise parfois des prompts volontairement moins précis pour découvrir des solutions inattendues
- Le CI local est supérieur au CI distant : au lieu d’attendre 10 minutes sur un CI distant, les agents exécutent les tests en local
- La majeure partie du code n’est que de la transformation de données ennuyeuse : inutile de s’y accrocher ; l’énergie doit être concentrée sur la conception du système
- Les ingénieurs davantage intéressés par le résultat que par les détails d’implémentation collaborent mieux avec l’IA
- Les ingénieurs qui aiment résoudre des puzzles algorithmiques ont plus de mal à devenir « AI native »
- Les personnes qui aiment livrer des produits s’adaptent mieux
Sa vision de l’avenir du software engineering
- L’IA n’a pas tué le software engineering, bien au contraire
- Peter est un architecte logiciel qui garde en tête la structure de haut niveau du projet
- Il accorde une grande attention à l’architecture, à la dette technique, à la scalabilité et à la modularité
- L’une des raisons du succès de Moltbot est sa très bonne scalabilité
- Il investit de l’énergie pour que l’ajout de nouvelles fonctionnalités soit facile
- En tant que « dictateur bienveillant » du projet, il maintient la cohérence de la direction et du style
Contexte et limites
- Moltbot est un projet expérimental fondé sur l’itération rapide et reste encore en cours de développement
- « Aller vite et casser des choses » est la seule manière de réussir pour ce type de projet
- Il est difficile d’appliquer la même approche à toutes les équipes ou à tous les produits
- Malgré cela, le projet est considéré comme un cas ayant révélé une demande que même les grands laboratoires d’IA n’avaient pas anticipée
26 commentaires
Je ne comprends pas pourquoi on continue de prendre une machine à prédire pour une machine capable de penser.
Comme une calculatrice fonctionne sur la base d’un algorithme déterministe, je pense que cette analogie n’est pas appropriée.
Et je ne suis pas opposé à l’utilisation de l’IA en soi, mais je considère qu’il y a un problème avec la manière d’utiliser l’IA présentée dans cet article.
C’est parce que cela a été conçu selon la structure que nous imaginions.
Le principe de base est d’avoir repris tel quel le mode de connexion entre les neurones, et il n’est pas possible de voir clairement par quel processus la pensée se forme.
Comme on ne sait pas non plus par quel processus la « pensée » émerge dans le cerveau, la forme de base et les phénomènes sont identiques.
C’est pourquoi on considère que le cerveau humain est identique à une machine de prédiction.
Il existe aussi des domaines qui estiment que ce que nous appelons pensée est un phénomène mécanique et qu’un « brain hacking » est donc possible.
Les deux sont des boîtes noires, et leur structure de base est la même, mais cela ne signifie pas qu’on puisse affirmer qu’ils se ressemblent.
Ce n’est pas complètement identique, mais ce n’est pas non plus complètement différent en même temps.
Dire que c’est similaire signifie qu’il y a des points communs,
donc au final, si les gens ont des avis divergents entre eux, c’est probablement une question de point de vue sur le degré de ressemblance.
On ne peut pas vraiment dire que c’est identique, mais je pense que c’est similaire,
et sous l’angle des prédictions et des idées dans le commentaire de geek12356, je pense aussi que c’est le cas.
J’ai aussi en même temps le point de vue selon lequel l’intelligence est supérieure à celle des humains, et qu’en ce sens c’est différent des humains.
Ne devenons pas ce senior qui, alors que les autres calculent en une seconde des centaines de lignes avec des fonctions Excel, fait tous ses calculs un par un à la calculatrice en disant : « N’utilisez pas les fonctions. »
L’analogie avec les fonctions Excel et la calculatrice me semble erronée.
Si les LLM avaient une précision de 100 %, je l’admettrais..
Je ne comprends pas pourquoi on s’oppose à l’idée de ne pas utiliser de calculatrice tout en continuant à faire glisser un boulier.
Pour commencer, je n’aurais pas envie d’utiliser un produit développé de cette manière.
Si un véhicule ou un logiciel d’aviation était développé de cette manière, je pense que je ne l’utiliserais encore moins.
C’est pour ça que les Japonais utilisent encore majoritairement le fax.
Même si cela a l’air impressionnant en apparence, si des problèmes surviennent plus tard et qu’il faut les corriger, ou si des vulnérabilités apparaissent, le coût risque d’être énorme..
On dirait que plusieurs vulnérabilités ont déjà été signalées.
Au final, c’est l’humain qui redevient important.
Je ne sais pas s’il faut voir ça de manière positive ou négative..
Vous l’utilisez probablement déjà, consciemment ou non.
Si le code pondu comme ça pose un problème, qui va donc devoir en assumer les conséquences et nettoyer derrière... Si on continue à fabriquer du code de cette manière, ce genre d’enfer finira forcément par arriver un jour.
"Prompt Request" au lieu de Pull Request, c’est surprenant.
Je m’étais beaucoup intéressé au MDA il y a très longtemps, puis j’avais abandonné en trouvant ça irréaliste, et voilà que cela se concrétise ainsi.
Ce serait bien que ce soit proposé comme fonctionnalité sur des plateformes comme GitHub.
« Aller vite et casser des choses »
Cette phrase me parle bien
Ma grande erreur a été d’essayer de lire du code écrit par l’IA.
Les MoltBots envoient un nombre énorme de PR d’auto-réparation, donc j’imagine qu’il est impossible pour lui de tout relire lui-même lol. Le fait qu’il y ait presque autant d’issues que de PR, c’est sans doute parce qu’au lieu d’écrire une issue et d’attendre, il suffit de demander à MoltBot de créer une PR et de la pousser, et c’est réglé lol.
On a simplement un tout petit peu rapproché de nous la situation où l’IA distinguait les chiens des chats… Je ne sais pas si cela a une valeur au-delà de ça.
Il dit préférer Codex, donc je suis curieux de connaître sa configuration.
Avec Codex, sur 140 jours, j’ai réalisé 115 projets et j’ai apparemment dépensé plus de 250 milliards de tokens - link
Ça fait dans les 75 millions de wons. Un développeur IA native solo doit d’abord réussir son exit et avoir déjà pas mal d’argent..
2500 milliards de tokens... c'est difficile à se représenter.