De nombreux agents de codage ont une fonctionnalité "modes" qui (en quelque sorte ?) avait du sens à l'époque des RAG ou des premiers agents. Maintenant, ils ajoutent des sous-agents comme Amp (sous-agent de recherche, sous-agents généraux, l'oracle) et Claude Code (qui vient de lancer une fonctionnalité de sous-agents personnalisés vraiment cool). Les modes sont des menus déroulants UI lourds et non composables. Les sous-agents sont invoqués par le langage naturel ("utiliser l'oracle pour ...", "utiliser le sous-agent de problème pour ...", ou implicitement), sont parfaitement composables et s'intègrent parfaitement dans le modèle conceptuel de l'appel d'outils agentiques. Il s'avère que les modes et les sous-agents servent essentiellement le même but. Les sous-agents sont une solution strictement meilleure. Ainsi, les agents de codage de génération précédente qui ont une fonctionnalité "modes" existante font maintenant face à un choix difficile lorsqu'ils ajoutent des sous-agents : garder à la fois les modes et les sous-agents (ce qui est déroutant et complexe), supprimer les modes (ce qui est douloureux pour leur base d'utilisateurs car ils ont investi beaucoup d'efforts dans la création des modes), ou essayer d'étendre le concept de "modes" pour inclure également les sous-agents (ce qui sera également déroutant). Je ne les envie pas. Dans l'équipe Amp, nous vivons dans la peur mortelle d'être dans cette position peu enviable lorsque nous avons mal jugé où le codage agentique sera à l'avenir et que nous devons apporter des changements douloureux au produit. Nous avons commis toutes ces erreurs sur des produits que nous avons construits avant Amp (et nous faisons et ferons des tonnes d'erreurs sur Amp). C'est pourquoi nous avons une barre incroyablement haute pour ajouter de nouveaux concepts UI, c'est pourquoi nous priorisons les membres de l'équipe avec une forte intuition, et c'est pourquoi nous construisons pour où les modèles et le développeur médian seront dans 6-12 mois, pas aujourd'hui. Dans ce cas, je crois que cette orientation nous a conduits à la bonne décision (pas de modes, seulement des sous-agents composables). Nous avons la chance de pouvoir construire pour des développeurs incroyablement intelligents et ouverts d'esprit/pensée avant-gardiste qui partagent souvent leurs retours et par pratiquement tous les canaux sauf les pigeons voyageurs. Nous avons appris à connaître et à comprendre tant d'entre vous. Nous ne pouvions tout simplement pas voir que l'un d'entre vous ou nous-mêmes aimions vraiment les "modes". Mais quand @thorstenball a construit des sous-agents puis l'oracle, et a dit que pour les utiliser, il suffisait de le dire ("utiliser l'oracle pour ...") au lieu de les sélectionner dans un menu déroulant, cela nous a semblé juste à nous et à vous tous, et cela semblait aussi être la direction vers laquelle les modèles allaient. Bravo à lui, et merci à nos utilisateurs formidables d'avoir vu l'avenir. Je voulais juste partager un peu les coulisses sur la façon dont nous pensons à ces choses et pourquoi nous pouvons sembler extrêmes ou rigides sur certains points. ...et restez à l'écoute pour ce week-end, lorsque j'admettrai que j'avais tort sur l'un de nos retours fréquemment ignorés (FIFs) les plus controversés et que je vais le changer, grâce à une tonne de retours que je n'ai pas ignorés.