Ingénierie des boucles : trois boucles clés pour créer de bons logiciels

Chers amis,

« L'ingénierie des boucles » est une expression à la mode après que ses mentions par Boris Cherny (le créateur de Claude Code) et Peter Steinberger (le créateur de OpenClaw) soient devenues virales sur les réseaux sociaux. Les boucles sont désormais un élément clé de la façon dont nous amenons les agents d’IA à itérer longuement pour créer des logiciels. Dans cette lettre, j'aimerais partager mes 3 boucles clés, illustrées dans l'image ci-dessous, pour créer des produits 0 à 1. Ces boucles guident non seulement la manière dont je crée des logiciels, mais également la manière dont je décide quel logiciel créer.

Boucle de codage d'agent : À partir d'une spécification de produit et éventuellement d'un ensemble d'évaluations (c'est-à-dire un ensemble de données par rapport auquel mesurer les performances), nous pouvons demander à un agent d'IA d'écrire du code, de tester son travail et de continuer à itérer jusqu'à ce que le code soit exempt de bogues et réponde à ses spécifications. Cette idée de boucler la boucle a pris son essor vers la fin de l’année dernière et a changé la donne en permettant aux agents de codage de travailler plus longtemps de manière productive sans intervention humaine. Par exemple, pendant le week-end, je développais une application pour que ma fille s'entraîne à taper, et mon agent de codage pouvait facilement travailler pendant environ une heure, en utilisant un navigateur Web pour vérifier ce qu'il avait créé plusieurs fois avant de me répondre, sans avoir besoin de mon intervention.

La boucle d'ingénierie s'exécute rapidement. Toutes les quelques minutes, l'agent de codage peut créer et tester une nouvelle version du logiciel. J'entends fréquemment des développeurs qui trouvent de nouvelles façons de concevoir des boucles d'ingénierie plus efficaces. C'est un domaine d'invention actif !

Boucle de rétroaction du développeur : Dans cette boucle, un développeur examine le produit actuel et oriente l'agent de codage pour l'améliorer. L'année dernière, de nombreux développeurs (dont moi) assuraient le rôle de fonction d'assurance qualité (assurance qualité) pour nos agents de codage, trouvant manuellement les bogues puis demandant à l'agent de les corriger. Mais comme les agents de codage sont bien plus capables de tester leur propre code, le temps que nous devons consacrer à cette fonction a considérablement diminué. Cela nous permet de prendre des décisions de niveau supérieur concernant les produits, telles que les fonctionnalités clés à proposer, les domaines dans lesquels l'interface utilisateur doit être améliorée, etc.

La boucle de retour des développeurs fonctionne sur des intervalles de temps compris entre des dizaines de minutes et des heures : c'est la fréquence à laquelle un développeur peut examiner un produit et donner son avis. Dans le cas de l'application de saisie, j'ai changé d'avis à plusieurs reprises sur la conception visuelle, les costumes de chat qu'elle peut débloquer au fur et à mesure de son apprentissage (elle adore les chats) et le flux d'utilisateurs permettant à un adulte de se connecter et de piloter l'expérience d'apprentissage de l'enfant.

Lorsqu'un développeur a une vision claire de ce qu'il doit construire, il faut encore beaucoup de travail pour traduire cette vision en spécifications à mettre en œuvre par un agent de codage. De plus, une fois que le développeur a vu une implémentation, il peut mettre à jour (ou peut-être clarifier) ​​la spécification pour l'orienter vers ce qu'il souhaite. Si vous constatez que le système rencontre certains problèmes à plusieurs reprises, il devient utile de créer un ensemble d'évaluations pour l'agent.

Les équipes natives de l'IA utilisent de plus en plus l'IA pour déterminer l'orientation des produits, par exemple en automatisant la collecte et l'analyse des données d'utilisation, en résumant les commentaires écrits et verbaux des clients ou en effectuant une analyse concurrentielle. Cependant, pour presque tous les produits dans lesquels je suis impliqué, je considère que les humains ont un avantage contextuel significatif par rapport aux systèmes d’IA actuels – nous en savons beaucoup plus que le système d’IA sur les utilisateurs et le contexte dans lequel le produit doit fonctionner – et les humains jouent donc un rôle essentiel. Beaucoup de gens décrivent cette contribution humaine comme du « goût », mais je préfère la considérer comme un avantage contextuel pour les humains, car cela nous donne une voie plus claire pour aider les systèmes d’IA à s’améliorer. Cela explique également pourquoi cette étape ne peut pas être automatisée : tant que l'humain sait quelque chose que l'IA ne sait pas, l'humain dans la boucle est nécessaire pour injecter ces connaissances dans le système.

Boucle de rétroaction externe : cela inclut un large éventail de tactiques comme demander des commentaires à quelques amis, lancer auprès des testeurs alpha ou mettre le code en production avec des tests A/B. Ces tactiques sont généralement lentes, prennent rarement moins de quelques heures et prennent parfois des jours, voire des semaines. Ces données informent la vision du développeur, qui à son tour continue de piloter les spécifications détaillées du produit, qui à son tour pilotent l'agent de codage.

Les agents de codage accélérant le développement de logiciels, de plus en plus d'ingénieurs commencent à jouer un rôle partiel dans la gestion des produits. Pour de nombreux ingénieurs qui évoluent dans ce rôle, le plus difficile est de façonner la vision du produit et de trouver un équilibre entre la construction (combler le fossé entre la vision et les spécifications) et obtenir les commentaires des utilisateurs pour faire évoluer la vision. Il est important de faire les deux !

J'écrirai davantage sur la façon de procéder dans de prochaines lettres, mais pour l'instant, je trouve encourageant que les ingénieurs jouent un rôle élargi (tout comme les chefs de produit et les concepteurs font désormais davantage d'ingénierie).

Continuez à construire !

André