- 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
Aucun commentaire pour le moment.