Reconstruire Manus avec Manus : ce qui a changé, ce qui s'est brisé et notre façon de travailler aujourd'hui
Par Tao Zhang, cofondateur et directeur produit, Manus
Fin septembre, lors de la dernière ligne droite de Manus 2.0, j'ai envoyé à l'un de nos ingénieurs quelques demandes de fonctionnalités et rapports de bugs sur Slack. Plus tard, je suis allé voir où il en était. Son écran affichait une série de sessions d'agents ouvertes, certaines dans Manus et d'autres dans Codex. J'ai cliqué sur l'une d'elles. Le prompt était mon message Slack, collé mot pour mot.
Il y a un an, il aurait lu mon message, compris ce que je voulais dire, puis écrit le code. Désormais, un Agent lit la demande, trouve le code concerné et propose une modification. Le rôle de l'ingénieur consiste à diriger le travail, le vérifier et en assumer le résultat. La plupart du temps, une demande est en cours d'exécution et ne l'attend pas. Aujourd'hui, il est courant ici qu'un ingénieur ait 10 à 20 demandes en cours simultanément.
Je suis fier de la rapidité avec laquelle notre équipe s'est adaptée. Je suis aussi inquiet. Ce rythme est-il le bon ? Qu'avons-nous encore manqué ?
Chez Manus, nous construisons des agents, nous nous imposons donc deux règles. Nous utilisons notre propre produit pour un travail réel. Et nous cherchons constamment les endroits où l'AI cesse de fonctionner.
J'aimerais documenter ce qui se passe à l'intérieur d'une entreprise lorsque les personnes et les agents travaillent côte à côte par défaut. Ce billet couvre trois équipes — ingénierie, produit et marketing — et il inclut ce qui n'a pas fonctionné. Il s'agit d'un rapport sur une expérience en cours, non d'une définition d'une « organisation AI-native ».
Ce que nous avons appris jusqu'à présent :
•Il n'y a pas de demi-mesure. Ajouter de l'AI aux anciennes méthodes de travail n'a parfois fait qu'ajouter du bruit. Les choses n'ont changé que lorsque la boucle s'est refermée.
•Les agents ont besoin de la vue d'ensemble. Un meilleur contexte nous a plus apporté que de meilleurs prompts.
•La confiance vient des tests et du contexte, pas seulement de la qualité du modèle.
•L'autonomie a besoin d'une ligne d'arrivée. Les agents ne peuvent fonctionner seuls que lorsque le succès peut être vérifié. Partout ailleurs, c'est une personne qui décide.
•Le goulot d'étranglement se déplace. Lorsque l'ingénierie est devenue plus rapide, décider quoi construire est devenu la contrainte.
•Le rôle des personnes n'a pas diminué. Il s'est recentré sur des choses à plus fort impact.
1. Il n'y a pas de demi-mesure
Avant 2026, nous faisions comme la plupart des entreprises : nous ajoutions de l'AI à notre façon de travailler existante. Cela signifiait que le support signalait les problèmes avec un résumé AI, que les ingénieurs utilisaient des assistants de code, et que des bots publiaient des analyses dans les canaux. Chaque élément était utile en soi, mais peu d'entre eux étaient reliés les uns aux autres. Jusqu'à ce que la boucle se referme réellement, nous travaillions simplement de la même vieille manière, mais avec beaucoup d'AI qui se parlaient par-dessus.
Il y a une phrase à laquelle nous revenons souvent : l'ingénierie logicielle, c'est la programmation intégrée dans le temps. Écrire du code est facile à mesurer ; maintenir un produit complexe en bonne santé pendant des années ne l'est pas. Un pourcentage élevé de code écrit par AI peut signifier de réels progrès, ou cela peut signifier accumuler du laisser-aller que quelqu'un devra nettoyer plus tard.
Le test qui compte pour nous est plus difficile. Manus est un produit complexe qui est en service depuis plus d'un an. Peut-il continuer à s'améliorer sous de nouvelles méthodes de travail sans s'effondrer, tandis que chaque personne accomplit davantage ? Jusqu'ici, la réponse est oui.
2. Donnez à l'Agent la vue d'ensemble
Comme la plupart des entreprises tech, nous perdions le plus de temps aux transitions. Un ingénieur frontend et un ingénieur backend interprétaient chacun une demande, s'accordaient sur une interface, puis passaient des jours à corriger les incohérences. Deux personnes comprennent rarement une exigence de la même manière.
Si l'AI peut écrire du code à travers toute la stack, une seule personne pourrait-elle prendre en charge une demande de bout en bout ? L'obstacle était le contexte. Notre code vivait dans des dépôts séparés, de sorte qu'aucun Agent ne pouvait voir l'ensemble du système à la fois.
Notre réponse à cette question a commencé par une expérience interne. Nous voulions voir jusqu'où l'AI pouvait aller dans la construction d'un produit avec le moins d'intervention humaine possible et quasiment aucun code écrit à la main. La méthode que nous avons développée en cours de route est devenue l'outil interne que nous appelons désormais Manus-mono, ou Mono.
Mono ne fusionne pas nos dépôts. Il s'agit d'un point d'entrée unique accompagné d'un manuel rédigé pour l'Agent : ce que fait chaque dépôt, comment ils s'articulent ensemble et comment nous travaillons. L'Agent récupère ce dont il a besoin. Nous maintenons également une bibliothèque de décisions d'architecture consignées, afin que chaque session de l'Agent commence par le raisonnement derrière les décisions passées, et pas seulement par le code. Lorsque quelqu'un travaille avec un Agent, cet Agent dispose du contexte de tous ceux qui l'ont précédé.
Mono s'est développé par étapes, et chaque étape a résolu le goulot d'étranglement révélé par la précédente :
1.Voir l'ensemble du système. Nous avons ajouté le contexte métier qu'aucun dépôt unique ne contient, et utilisé les worktrees Git pour le travail en parallèle.
2.Vérifier localement. Un push vers l'environnement de test prenait auparavant 5 à 10 minutes. Désormais, l'ensemble de la stack Manus fonctionne sur un ordinateur portable, et les vérifications prennent quelques secondes.
3.Déboguer les problèmes en production. Avec des autorisations limitées, Mono peut lire les logs, la configuration et les rapports d'erreur dont il a besoin pour diagnostiquer les bugs en production.
4.Gérer les releases de bout en bout. Mono prend désormais en charge les étapes de release où le travail avait tendance à stagner. Les décisions d'approbation restent entre les mains des personnes.
5.Tester de bout en bout. Lorsque la vérification est devenue l'étape la plus lente, Mono a commencé à exécuter de vrais parcours utilisateurs avec des comptes de test, dans un navigateur et dans un simulateur mobile.
(Comment Mono fonctionne et comment il a évolué. Réalisé par un coéquipier avec Manus.)
On nous demande parfois si Mono est un wiki de code. La documentation en est une partie, mais le reste correspond à tout ce qui entoure le code : comment nous testons, comment nous publions, ce que nous décidons et pourquoi, et ce à quoi l'Agent est ou n'est pas autorisé à toucher.
Au fil du temps, Mono est devenu une base de connaissances partagée qui s'améliore à mesure que les gens y contribuent. Par exemple, notre ingénieur ops en avait assez qu'on lui demande de l'aide pour les releases, alors il a inscrit le processus de release dans Mono. Désormais, n'importe qui peut lancer une release, l'Agent aussi, mais l'approbation revient toujours aux personnes disposant des droits de release. J'adore la façon dont l'équipe fonctionne : une personne a résolu sa propre frustration, ce qui a permis à toute l'entreprise de gagner un peu en rapidité.
L'équipe part désormais du principe qu'une seule personne peut livrer une demande sur toutes les plateformes. Notre équipe mobile compte sept personnes depuis le début. Elle maintient quatre applications réparties sur deux produits et suit le rythme du web.
Mono s'est répandu dans l'entreprise sans directive descendante. Je pense que la culture explique cela autant que l'outil lui-même. Tester les limites de l'AI fait partie de notre raison d'être, et notre organisation est horizontale. Un outil ne va que là où l'organisation lui permet d'aller.
3. Boucler la boucle : du signalement d'un bug par l'utilisateur à un correctif vérifié
Mono a permis à chacun de travailler sur n'importe quelle partie du produit. C'était la moitié du chemin. L'autre moitié consistait à laisser les Agents trouver eux-mêmes les problèmes.
Dans la plupart des entreprises Internet, le signalement d'un bug par un utilisateur passe par le support, le produit et le triage avant d'atteindre un ingénieur capable de le corriger.
Chez nous, un Agent interne enquête désormais d'abord sur le signalement et remonte le problème jusqu'à la modification qui l'a provoqué. Puis il poste sur Slack et mentionne l'ingénieur responsable de cette modification. L'ingénieur décide s'il lui revient de la corriger et la confie à son propre Agent. Un Agent distinct vérifie le correctif en exécutant les tests et les parcours qui comptent.
Trois Agents, trois rôles : l'un trie, l'un effectue le travail, l'un le vérifie. La personne au milieu prend les décisions. Une part croissante de notre travail d'ingénierie commence désormais ainsi, avec un Agent qui soumet un problème à une personne.
Cette boucle a des limites claires. L'Agent qui lit les signalements des utilisateurs ne peut pas modifier le code. Il peut seulement enquêter et nous faire un retour. Les modifications proviennent du propre Agent de l'ingénieur, après que l'ingénieur a pris sa décision. Rien n'est livré sans l'approbation d'une personne disposant des droits de release.
4. Comment nous avons appris à faire confiance au code écrit par les agents
Pendant longtemps, chaque modification intégrée à notre branche principale nécessitait l'approbation de l'un de nos deux ingénieurs seniors. Nous ne faisions pas assez confiance à l'AI pour sauter cette étape. À mesure que les agents produisaient plus de code, cette étape de revue est devenue le goulet d'étranglement.
En matière de pure capacité de codage, les modèles étaient déjà solides. Nous avons reconnu que la différence tenait à deux choses. Premièrement, les humains savent comment tester leur travail. Deuxièmement, les humains ont participé aux discussions en amont et en aval, donc ils savent ce que « correct » signifie pour l'entreprise. Un code correct n'est pas la même chose qu'un produit correct.
Nous avons résolu les deux problèmes :
•Laisser les agents participer à la discussion. L'agent de chaque ingénieur siège désormais dans les fils Slack auxquels il a été ajouté et suit le contexte. Lorsque quelqu'un dit enfin « Go », l'agent sait déjà ce que l'équipe a décidé et pourquoi.
•Laisser les agents tester de bout en bout. En collaboration avec notre équipe backend, nous avons donné aux agents la possibilité d'exécuter de vrais flux et tests de régression dans Manus après chaque modification. À mesure que la couverture des tests augmentait, notre confiance grandissait avec elle.
Aujourd'hui, chaque modification passe par cette vérification et par un bot de revue de code exécutant le modèle le plus performant disponible, avec des règles supplémentaires pour les domaines sensibles tels que les paiements. Le bot a remplacé la file d'attente, pas la décision humaine. Un agent peut ouvrir une pull request, mais il ne peut pas fusionner dans notre branche principale sans l'approbation explicite d'une personne. Ce sont toujours les humains qui décident de ce qui est construit et de qui peut publier.
5. L'autonomie a besoin d'un objectif final
La confiance a ses limites, et nous l'avons appris à nos dépens.
À un moment donné, tout le monde était enthousiasmé par les boucles d'agents entièrement autonomes, alors nous en avons essayé une. Un agent a recueilli les retours de nos canaux de feedback internes et a lancé un projet pour chaque élément. Un coéquipier l'a laissé tourner tout un week-end. Le lundi matin, plus de 200 éléments attendaient sa décision.
Pourquoi ne pas laisser l'agent prendre également ces décisions ? Les boucles autonomes fonctionnent lorsque le système peut vérifier si l'objectif a été atteint. Les tests réussissent ou échouent ; une page se charge ou non. La plupart du travail réel n'a pas de telle vérification. Une personne doit juger si c'est terminé, et si cela en valait la peine.
Nous avons tiré deux leçons de ce week-end. Premièrement, les humains ne peuvent pas prendre des décisions aussi rapidement qu'une boucle non contrôlée en génère. Deuxièmement, si personne ne décide si quelque chose doit être fait, personne n'est responsable du résultat. La boucle de correction de bugs de la section 3 fonctionne parce que les tests définissent le succès. Les décisions produit n'ont pas de tests, donc chaque changement produit chez Manus commence toujours par une personne qui décide si cela en vaut la peine.
6. Quand l'ingénierie est devenue plus rapide, le produit est devenu le goulet d'étranglement
Un processus produit traditionnel comporte de nombreux transferts, et les priorités dérivent un peu à chacun d'eux. À mesure que les agents de codage rendaient les ingénieurs plus rapides, un nouveau problème est apparu : il n'y avait pas assez de chefs de produit pour rédiger de bonnes exigences. Pour la première fois, l'ingénierie n'était plus la contrainte.
Chez Manus, notre première solution a été de demander à quelques ingénieurs de devenir des « builders » qui prennent en charge un problème de la découverte au lancement. Peu de personnes avaient à la fois le jugement technique et produit. Ensuite, nous avons laissé les PM modifier le code. Cela a également calé. Les transferts étaient toujours là, et sans les instincts d'un ingénieur, les PM pouvaient modifier le texte et les interactions, mais pas la logique sous-jacente.
Mono a résolu les deux problèmes car il porte les règles avec lui :
•Toute modification qui touche aux appels de modèles ou aux coûts nécessite l'approbation du propriétaire avant que le code ne soit écrit.
•Chaque modification passe par la même revue et les mêmes tests qu'une modification d'ingénieur.
•Mono peut parcourir l'inscription et le paiement avec des comptes de test et enregistrer chaque étape, afin qu'un PM puisse pointer le moment exact où quelque chose se casse.
Voici à quoi cela ressemble en pratique. Une PM travaillant sur la reconnaissance vocale a demandé à Manus de comparer plus de 10 modèles, puis en a choisi un. Elle a extrait le code frontend via Mono, a construit une démo dans notre design system, et a demandé à Manus de rendre chaque scénario utilisateur sous forme d'image pour qu'elle puisse les examiner. Elle a transformé la démo en vidéo. Le plan était suffisamment clair pour qu'elle construise la fonctionnalité elle-même, y compris l'interface utilisateur web et desktop.
Les personnes ont pris trois décisions en cours de route. Elle a choisi le modèle. Les équipes produit et design ont examiné la démo. Un ingénieur disposant des droits de publication a revu le code. Il y a un an, rien de tout cela n'aurait été possible.
Nous décrivons cela comme le passage de l'humain dans la boucle à l'humain sur la boucle. L'AI effectuait auparavant 70 à 80 % d'une tâche et les personnes complétaient le reste. Désormais, les personnes définissent les règles, supervisent plusieurs agents, vérifient les méthodes et les résultats à des moments clés, interviennent lorsque nécessaire et assument le résultat.
Certains PM remettent désormais une courte vidéo au lieu d'une spécification écrite ou de maquettes. En quelques minutes, elle montre le cas d'usage, chaque écran, ce que fait chaque clic, le comportement des cas limites et comment tout cela fonctionne en coulisses. Pour nous, le design, l'ingénierie et le QA s'accordent plus vite sur ce que signifie « terminé », et le PM l'explique une seule fois.
(Vidéo d'exigences produit pour la saisie vocale)
Aujourd'hui, environ la moitié de nos PM livrent des fonctionnalités par eux-mêmes, et chaque PM a validé du code. Les designers s'y sont aussi mis. Un PM a écrit la majeure partie de l'interface Manus Studio dans Manus 2.0. Un autre a écrit le Video Editor. Derrière chacun d'eux se trouve une personne qui a passé des mois à dépasser ce que son rôle couvrait auparavant. C'est ce dont je suis le plus fier.
Cela ne veut pas dire que tout le monde doit être un bâtisseur. Lorsque n'importe qui dans une entreprise peut construire, les gens risquent de livrer des choses qui ne devraient pas exister. Notre équipe produit pose souvent une question : « Si cela prenait une seconde et ne coûtait rien, le livreriez-vous ? » Parfois, la réponse est non. Nous avons encore besoin de responsables de modules qui décident de ce qui est construit, de ce qui ne l'est pas et de ce que les utilisateurs voient finalement. Nous avons également besoin de personnes qui maintiennent l'infrastructure comme Mono. Lorsque construire devient facile, décider quoi construire compte davantage.
7. Un coéquipier AI au sein du flux de travail marketing
Un partenariat marketing passe par la revue du script, la tarification, les contrats, les approbations, le paiement, le lancement et l'analyse des résultats. Ces étapes se déroulent dans les e-mails, les outils de contrat, les systèmes d'approbation, les feuilles de calcul et les plateformes publicitaires. Une grande partie du travail consistait auparavant à faire circuler l'information entre ces outils, ce qui laissait peu de temps pour le travail créatif qui exige du jugement.
Nous avons commencé par un petit problème : lorsqu'un contenu partenaire ou une publicité était mis en ligne, nous en étions souvent informés tardivement. Nous avons donc demandé à l'AI d'écrire un script qui détecte la publication des contenus. Puis nous avons voulu des données de performance. Ensuite, une revue des partenariats passés. Puis tout le flux de travail interne a été connecté : lorsqu'un contrat est signé ou qu'une approbation est validée, l'Agent met à jour le statut et notifie la personne responsable de l'étape suivante.
Manus a intégré tout cela dans un site interne. Pour les personnes, ce sont des tableaux de bord et un calendrier. Pour l'Agent, c'est un ensemble d'outils. L'Agent qui utilise ces outils au sein de notre flux de travail est ce que nous appelons un coéquipier AI. Il ne fonctionne que dans les canaux et systèmes auxquels l'équipe l'a connecté, avec un accès limité à ce flux de travail.
Voici ce qu'il fait :
•Il gère sa propre file d'attente. Beaucoup de personnes lui envoient des messages en même temps, il parle donc à tout le monde dans une session unique de « réception » et transmet les tâches à des sessions parallèles. Il décide si un message le concerne, puis s'il faut interrompre le travail en cours ou attendre. Il a proposé ces règles lui-même pendant le développement, et nous les avons examinées avant de les conserver.
•Il apprend du contexte qui lui est transmis. Un changement de stratégie signifiait auparavant une réunion et un brief écrit. Désormais, notre responsable marketing transmet la discussion et dit : « Apprends ceci. »
•Il garde en vue les objectifs à long terme. À une occasion, des coéquipiers dans un fil Slack auquel il avait été ajouté ne se souvenaient plus où en était un projet. Sans être mentionné, il a répondu : « B est encore en test. Devrions-nous attendre les résultats de A avant d'examiner B ? »
•Il vérifie les faits auprès d'autres équipes. Après le lancement du rigging de modèles 3D, il a demandé à l'équipe produit ce qui était pris en charge. Il a appris que le rigging couvre sept catégories, dont les poissons, les serpents et les quadrupèdes, afin que nos descriptions restent exactes.
Les coéquipiers l'intègrent désormais aux revues de script et de tarification, car il a lu nos dossiers de partenariats passés. Ce sont encore les personnes qui tranchent.
Le site interne peut également s'améliorer grâce à ses propres utilisateurs, y compris l'Agent. Lorsque l'Agent rencontre une friction, il dépose une demande via un endpoint de retour. Cela ouvre une tâche de développement dans Manus via les Automations de Manus 2.0, et un ingénieur examine la modification avant qu'elle ne soit livrée. Cela fonctionne depuis environ une semaine. Nous avons besoin de beaucoup plus de cas avant de nous appuyer dessus.
Alors, que font les personnes de l'équipe ? Trois choses leur reviennent. Elles prennent et assument chaque décision importante. Elles traitent les cas que l'Agent n'a pas vus, et lui apprennent quoi faire ou à qui s'adresser. Et elles le réorientent chaque fois que son analyse ouvre un nouvel angle.
8. Moins s'interrompre les uns les autres
Dans toutes ces équipes, de nombreuses questions ne nécessitent plus d'interrompre quelqu'un.
Demandez d'abord à l'agent. Un coéquipier a construit un bot Slack sur Mono qui s'exécute sur un ordinateur cloud et répond dans le fil de discussion. Ce sont surtout les non-ingénieurs qui l'utilisent. Comment fonctionne cette fonctionnalité ? Où se trouve cette chaîne ? Est-ce que ça a été livré ? Ils n'ont plus besoin de trouver le propriétaire en premier.
Ouvrez la session au lieu de demander une mise à jour sur l'état d'avancement. Les progrès d'un ingénieur étaient autrefois enregistrés dans ses propres conversations AI, invisibles une fois qu'il se déconnectait. Nous avons donc créé une fonctionnalité interne qui permet aux membres d'un projet de voir les sessions des autres et de demander à les rejoindre. Un ingénieur peut construire la majeure partie d'une fonctionnalité avec l'agent, puis un PM rejoint la même session pour ajuster l'espacement, les styles et le texte. Publier dans la session de quelqu'un d'autre nécessite son approbation, et nous travaillons encore sur les permissions.
(Exemple illustratif : comment un ingénieur, un PM et un designer travaillent dans une seule session. Il ne s'agit pas d'un vrai changement de tarification.)
L'objectif n'est pas de moins se parler. C'est de moins s'interrompre.
Ne décidez que ce qui doit être décidé. Notre plus gros utilisateur d'AI maintient une session principale avec une seule tâche : lister ce qui nécessite sa décision, avec une recommandation pour chaque élément. Lorsque Slack devient chargé, il reste à l'écart et demande : « Que dois-je décider en ce moment ? »
Je fais quelque chose de similaire. J'ai plus de 20 tâches par jour et, comme je l'ai partagé publiquement, j'ai un TDAH. Commencer est le plus difficile pour moi. Maintenant, chaque tâche va dans un projet Manus dédié qui transforme chacune d'elles en sa propre tâche. Il démarre ce qu'il peut. Lorsqu'il n'est pas sûr, il me demande le contexte et quel PM devrait s'en charger. Ensuite, en utilisant l'accès que je lui ai donné à mon propre Slack, Gmail et Notion, il rassemble le contexte et remet au PM une demande complète au lieu d'une note en une ligne. Pour moi, le changement ne concerne pas seulement l'efficacité. Je passe maintenant beaucoup moins de ma journée à être anxieux de savoir par où commencer, ce qui est énorme sur le plan personnel.
9. Est-ce que ça vaut le coût ?
Nous dépensons beaucoup en AI, et nous suivons ces dépenses de près. Nous ne les utilisons pas pour juger les performances de qui que ce soit. Nous les utilisons pour juger les dépenses elles-mêmes : sont-elles rentables maintenant, ou nous préparent-elles pour plus tard ?
Voici ce que nous pensons que cela nous apporte, et où nous nous attendons à ce que les coûts aillent :
•Cela nous achète du temps et de l'attention. À mesure qu'une équipe grandit, la coordination mange l'attention de chacun. L'AI protège l'attention de chaque personne et lui donne une appropriation plus complète de son travail. Et nous embauchons toujours.
•Utiliser les meilleurs modèles est la façon dont nous apprenons où se trouvent les limites de l'AI. La configuration de vérification et de revue de code décrite dans la section 4 fonctionne sur les modèles les plus puissants que nous puissions obtenir. Le collègue qui dirige la productivité des développeurs l'appelle notre dépense au meilleur rapport qualité-prix.
•Le coût devrait baisser grâce au produit. Une plus grande partie de notre développement se fait désormais dans Manus Studio, notre propre produit, donc nos données d'utilisation nous montrent où les tokens sont gaspillés. Les corrections sont intégrées au produit, elles devraient donc rendre Manus plus efficace pour les utilisateurs aussi. Nous nous attendons à ce que les coûts actuels baissent considérablement à mesure que les modèles deviennent moins chers et que nous éliminons le gaspillage. C'est une conviction, pas une promesse !
10. Ce qui ne fonctionne pas encore
Il y a moins d'interruptions, mais l'attention est plus fragmentée. Quelqu'un qui gérait auparavant quatre ou cinq choses par jour peut maintenant faire avancer 20 ou 30 choses à la fois. Chaque changement signifie recharger le contexte. L'AI étend ce que les gens peuvent faire, et elle les pousse aussi à en faire plus. Un PM m'a dit que chaque fois qu'une tâche est en cours d'exécution, elle ne peut pas résister à démarrer un autre agent. Faire plus de choses n'est pas l'objectif. Nous traitons cela comme un problème à résoudre, pas comme un rythme à célébrer.
Les informations sont plus dispersées. Notre responsable produit connaissait auparavant chaque changement et la raison de celui-ci. Maintenant, il fait parfois une capture d'écran d'un problème et demande à Mono : « Qui a changé cela ? » C'est drôle, mais la question est réelle. Quand tout le monde est habilité à modifier le produit, qui est responsable de l'ensemble ?
Les permissions de partage ont besoin d'une refonte. Lorsque le travail peut être partagé et transféré, et que les agents participent à davantage de nos conversations, nous devons décider ce qui est ouvert et ce qui nécessite une approbation.
Nos solutions sont encore basiques. Pour l'instant, un agent supervise les autres et ne signale que ce qui est bloqué et ce qui nécessite une décision humaine. Nous savons que cela peut être amélioré.
11. Ce que nous construisons ensuite
Ces problèmes mettent en évidence un travail produit dont d'autres équipes auront probablement besoin aussi. Nous n'avions pas planifié ces fonctionnalités à l'avance. Elles sont nées de problèmes que nous rencontrions nous-mêmes sans cesse.
•Les sessions comme espaces de travail partagés. Une personne soulève un problème, un designer propose une solution, un ingénieur la développe et un PM la met en œuvre, le tout au même endroit.
•Un travail qui circule entre les appareils et les personnes. Les machines locales et cloud restent connectées, pour que le travail puisse continuer lorsque les gens s'absentent.
•Des Agents qui trouvent des options auxquelles les gens n'avaient pas pensé. Un Agent travaillant au sein des systèmes d'une entreprise, avec les bonnes autorisations, devrait pouvoir proposer des solutions, et pas seulement exécuter des instructions.
Nous les essaierons d'abord sur nous-mêmes, puis nous les proposerons aux utilisateurs.
12. Ce que les gens font aujourd'hui
L'ingénieur avec une rangée de sessions d'Agent ouvertes n'est pas qu'une histoire d'efficacité. C'est un changement de ce sur quoi repose une organisation. Les entreprises faisaient autrefois circuler l'information à travers les rôles et la hiérarchie. Ce qu'une personne pouvait faire dépendait du nombre de personnes et de ressources qu'elle pouvait mobiliser. Désormais, nous passons un peu de temps à fournir du contexte et des outils à l'AI, et plus de temps à porter des jugements et à prendre des décisions. De plus en plus souvent, c'est un Agent qui nous apporte un problème. Décider quoi en faire reste notre travail.
Nous en avons plaisanté : si Manus peut en faire autant, pourquoi venir au bureau ? Laissons les Agents s'en occuper. Mais les questions importantes doivent encore être soulevées, débattues et tranchées par des humains. Par exemple, qu'est-ce qu'un bon produit ? Ou, pour exagérer un peu : construire un excellent produit avec de vrais revenus qui continue de repousser les limites de l'AI, ou viser la marge ? L'AI ne sait pas lequel nous voulons. Nous, oui. La culture et la confiance naissent du fait de résoudre les choses ensemble, jour après jour et dans les moments qui comptent. C'est le socle sur lequel repose le travail de chaque session.
Alors, pour l'instant, voici notre réponse. Dans notre expérience en tant qu'organisation AI-native, le rôle des personnes n'a pas diminué. Il s'est recentré sur les domaines où elles peuvent avoir le plus grand impact : définir le problème, juger de la qualité, décider ce qui vaut la peine d'être fait, assumer le résultat.
C'est aussi pour cela que nous continuons à recruter. Les compétences et le jugement des personnes sont au cœur de cette manière de travailler — et cela ne changera pas de sitôt.
Au moment où j'écris ceci, je suis curieux de savoir ce que dirait ce billet dans un an. Chaque entreprise a des objectifs, des structures et une culture différents, il n'y a donc peut-être pas de réponse standard ni de forme définitive. Mais pour une entreprise qui conçoit des Agents, trouver comment les personnes et l'AI travaillent ensemble n'est pas optionnel. Cela fait partie du travail. Nous continuerons à y travailler et à partager ce que nous apprenons.
Note sur les chiffres. Les chiffres de ce billet proviennent de registres internes. La taille des équipes et les chiffres de livraison des PM sont à jour fin octobre. Certains éléments sont des estimations ou l'expérience d'une seule personne plutôt que des mesures.
