Comment faire adopter les agents de code par votre entreprise (sans produire du code poubelle) — Eyal Blum, Figma
AAI Engineer
Computing/SoftwareManagement
Transcript
00:00:00Eyal Blam : Bonjour, je m'appelle Eyal Blam, je suis ingénieur logiciel chez Figma, et
00:00:17dans mon intervention aujourd'hui, nous allons voir comment nous avons intégré ou intégrons
00:00:25l'agent dans notre flux de travail chez Figma tout en maintenant une haute qualité pour notre base de code.
00:00:32Comme vous le savez peut-être, Figma est l'éditeur basé sur navigateur où le design, l'ingénierie et maintenant
00:00:40les agents IA collaborent ensemble pour déployer du code.
00:00:44Figma a fortement pivoté d'un outil traditionnel vers un outil axé sur l'IA,
00:00:52mais dans cet exposé, je ne vais pas parler de notre produit, je vais plutôt parler de notre
00:00:55organisation interne et de la façon dont notre service d'ingénierie s'adapte aux agents IA.
00:01:04Et ce que nous avons constaté en interne, c'est que pour les organisations, les entreprises et les particuliers, il y a
00:01:11en quelque sorte un processus d'adoption de l'IA en trois actes.
00:01:16On commence par essayer quelque chose, que ce soit la plupart des gens dans cette salle qui
00:01:21sont passionnés par l'IA et l'utilisent depuis un moment, ils ont essayé un outil et ont obtenu
00:01:27de très bons résultats sur des choses simples, dix fois plus vite.
00:01:30Ensuite, on applique ces mêmes pratiques à des problèmes plus vastes et l'IA échoue assez lamentablement, donne de mauvais résultats,
00:01:40plein de bugs.
00:01:41La confiance que l'on a bâtie s'effondre et à partir de ce moment-là, on commence à acquérir la vraie compétence, c'est-à-dire
00:01:50apprendre à utiliser correctement l'IA, à placer les bonnes barrières de sécurité, à rédiger les bonnes consignes, le bon
00:01:55contexte et tout ce dont nous avons parlé toute la journée ici et dans toutes les conférences, afin de développer une véritable compétence.
00:02:02Et une chose qui se produit en interne, c'est que lorsque nous adoptons l'IA, que ce soit par équipes ou par individus, l'adoption est inégale.
00:02:12Nous avons des équipes qui sont très en avance sur l'IA et ont déjà transformé l'ensemble de leurs flux de travail, et d'autres qui expérimentent encore dans le premier acte ou ont perdu confiance, et elles doivent toutes travailler ensemble pour livrer notre produit.
00:02:28Elles doivent donc coexister au sein de l'organisation et nous devons trouver un moyen de les soutenir tout en emmenant tout le monde dans cette aventure et en amenant chacun au troisième acte de l'histoire.
00:02:44En plus de ce point de friction principal, nous avons également remarqué d'autres frictions qui surviennent lors de l'adoption de l'IA.
00:02:54Une chose que les développeurs signalent souvent et que les managers ont remarquée, c'est que la réduction de l'autonomie des développeurs diminue leur satisfaction au travail.
00:03:04Beaucoup de gens prenaient beaucoup de fierté et de plaisir à écrire du code et à entrer dans le 'flow', et beaucoup ont l'impression d'avoir perdu cela, ou de perdre une grande partie de cet élément pour se retrouver dans un cycle de prompts où ils attendent simplement un résultat de l'IA et lui parlent, ce qui est beaucoup moins amusant qu'avant.
00:03:22Nous avons remarqué un autre phénomène intéressant : nos meilleurs ingénieurs veulent garder tout le contexte en tête, ce qui finit par leur peser, et ce qui se passe, c'est qu'ils connaissent tous les pièges, ils maintiennent ensemble avec du ruban adhésif mental tous les endroits où les agents ne fonctionnent pas bien et empêchent les pires erreurs de passer, ou bien ils détiennent tout le contexte institutionnel qui n'a
00:03:52jamais été écrit dans leur tête, et ils portent une telle charge qu'ils deviennent des goulets d'étranglement et se sentent très frustrés, si bien qu'ils finissent par adopter l'outil plus lentement car ils voient tous les problèmes de première main.
00:04:04C'est un autre gros problème que nous avons observé, et celui-ci fera écho chez tout le monde j'en suis sûr : tout d'un coup, tous les documents de conception, les messages Slack et les e-mails sont devenus trois ou quatre fois plus longs, et nous recevons deux ou trois fois plus d'e-mails, pour dire fondamentalement la même chose qu'avant.
00:04:28La communication est donc devenue assez inefficace, et il est devenu difficile de distinguer ce qui est de haute qualité et important de ce qui ne l'est pas vraiment.
00:04:40Je vais donc passer les prochaines minutes à parler de certaines des leçons que nous avons apprises et de la manière dont nous essayons de les appliquer.
00:04:50C'est un parcours, nous n'en sommes pas encore sortis, mais nous avons constaté des progrès très intéressants sur nombre de ces plans.
00:04:57Je pense que beaucoup d'intervenants ici l'ont mentionné, mais investir dans la vérification est probablement ce qui a le plus de valeur dans notre base de code.
00:05:11Chaque fois que nous pouvons avancer dans notre flux de travail ce qu'un humain devait faire pour le confier à la vérification d'un agent.
00:05:19Par exemple, lorsque Playwright MCP est sorti, au lieu d'avoir des humains naviguant dans le code, l'agent peut désormais l'explorer, ce qui a été un formidable catalyseur de productivité pour bon nombre de nos équipes.
00:05:33C'est vraiment, c'est toujours une grande victoire pour nous.
00:05:37L'autre chose, et c'est encore mieux, c'est que lorsque vous trouvez quelque chose d'utile fait par l'agent, prenez le temps de le formaliser et de l'encoder dans un flux déterministe.
00:05:51Un flux déterministe qui peut être facilement répété permet d'économiser des jetons et du temps, et garantit que l'on utilise le LLM lorsqu'il a réellement besoin de raisonner.
00:06:01Mais lorsque vous avez quelque chose de déjà connu qui peut être encodé dans un test, y consacrer du temps est toujours extrêmement rentable.
00:06:11Et un autre conseil : si vous demandez à vos compétences ou à votre agent d'écrire le code en suivant une approche de type TDD (du rouge au vert), cela donne presque toujours de meilleurs résultats.
00:06:26Parce que vous fixez un objectif, puis vous dites à l'agent de tendre vers cet objectif.
00:06:30Cela donnera presque toujours de meilleurs résultats que d'écrire le code d'abord puis les tests ensuite, car il adaptera alors le test au code plutôt que d'ajuster le code pour satisfaire les critères de vérification.
00:06:42Et voici la pyramide des tests, la pyramide classique mentionnée précédemment : quand on pense aux tests eux-mêmes, on a les tests de bout en bout, les tests d'intégration et les tests unitaires.
00:06:54La démarche similaire consiste à descendre autant que possible vers l'analyse déterministe, comme le linting, le compilateur et les tests unitaires eux-mêmes ; tout ce qui peut être couvert facilement peut faire l'objet de revues par un agent basées sur des critères.
00:07:12Et des normes architecturales qui ont été...
00:07:15Et les normes architecturales qui ont été facilement encodées dans la base de code peuvent être confiées à l'agent.
00:07:19Et ce n'est qu'au sommet qu'il faut une sorte de révision humaine, qui concerne généralement la fonctionnalité et s'assure qu'on construit la bonne chose, en ne laissant aux humains que ce pour quoi leur intervention est réellement requise.
00:07:31Autre point très important : la planification par rapport aux prompts, ce qui est directement lié au fait de redonner de l'autonomie aux développeurs et de trouver un remplaçant à l'art d'écrire du code.
00:07:50Passer beaucoup de temps à rédiger le plan, puis à l'envoyer à l'agent comme une implémentation pouvant être réalisée automatiquement, est une méthode qui, selon nous, réinsuffle la joie de concevoir dans le processus.
00:08:07Il n'est donc pas rare de passer une semaine à rédiger des plans très détaillés, à prendre toutes les décisions, à les approfondir, à les affiner, et à les soumettre à des coéquipiers pour relecture.
00:08:17Et ce n'est que lorsque c'est prêt et que toutes les décisions ont été clarifiées qu'on peut l'envoyer à l'agent, qui vous le renvoie une fois implémenté.
00:08:26Cela a très bien réussi à la fois pour accélérer les choses et pour restaurer une partie du plaisir dans le processus de développement.
00:08:36Alors, qu'est-ce qui fait un bon plan ? Il est très important de commencer par le 'pourquoi' au tout début.
00:08:43Cela aide vraiment à éviter la dérive de l'agent si vous avez une grande section bien en vue, un peu comme lorsque vous rédigez un document de conception.
00:08:49Vous voulez y inclure le résumé exécutif pour l'agent, sinon il commencera à dériver avec le temps et il faut s'assurer qu'il ne revient pas en arrière pour modifier cela selon ses envies.
00:08:58Nous commençons donc par le 'pourquoi' et veillons à ce que le plan puisse être décomposé en petites parties pouvant chacune être vérifiée indépendamment.
00:09:08Et ma méthode personnelle pour juger d'une bonne taille, c'est de me demander si je veux relire la PR correspondant à cette partie, ou si elle sera trop grande pour être lue en une seule fois.
00:09:18Le test consiste à voir si je vais avoir besoin d'aller me chercher une tasse de café avant de lire ceci.
00:09:22Si c'est le cas, c'est trop grand et je vais vouloir le diviser en morceaux.
00:09:26Je m'assure ensuite que chaque partie peut être validée indépendamment, car je ne veux pas me retrouver avec cinq étapes où la première est écrite mais non validée, et où tout le reste est construit en s'appuyant sur des hypothèses non vérifiées.
00:09:41Avoir un point de contrôle de validation ou des critères d'exception pour chaque phase aide vraiment à rendre le plan résistant à la dérive.
00:09:51Il y a toute une technique sur la gestion du contexte et la création d'une usine logicielle par-dessus.
00:09:58Mais une fois que vous avez le plan, vous pouvez utiliser la boucle ou le flux de travail de votre choix pour l'implémenter.
00:10:05Voici une capture d'écran d'un plan que j'ai pris au hasard, mais c'est ce que je recherche habituellement.
00:10:12Le résumé exécutif tout en haut.
00:10:14Les phases décomposées, puis chacune d'elles détaillée de manière à pouvoir être confiée à un sous-agent.
00:10:20Et le sous-agent peut travailler dessus de façon autonome sans avoir à s'en préoccuper.
00:10:24Il existe d'autres flux de travail qui fonctionnent ou d'autres structures pour le plan.
00:10:29Je trouve que l'un des grands avantages des flux de travail IA, c'est que chacun peut configurer ce qui lui convient le mieux.
00:10:41Non merci.
00:10:43Chacun peut très facilement configurer le flux de travail qui lui correspond exactement.
00:10:47Le rendement marginal décroissant consiste à essayer de centraliser tout le monde sur un seul outil.
00:10:51Mais tant que cela fonctionne pour leur méthode et que d'autres peuvent collaborer avec eux, je trouve que cela fonctionne généralement très bien.
00:10:58Et voici juste un exemple, pour se vanter un peu, de ce que peut donner le résultat d'un plan.
00:11:04Il y a probablement 20 PR ici.
00:11:07Certaines font peut-être 10 lignes et d'autres 100 lignes, mais probablement rien de plus grand que cela.
00:11:12Et cela nous permet de... dans le monde pré-IA, j'aurais probablement travaillé sur ce plan pendant une semaine.
00:11:19Je me serais aligné avec trois autres équipes pendant une autre semaine là-dessus, et maintenant je l'envoie simplement à un agent pour qu'il l'implémente pendant la nuit.
00:11:26Et c'est revenu - cela vient probablement de deux plans et non d'un seul - mais c'est essentiellement six semaines de travail de codage qui n'ont pris qu'une seule semaine.
00:11:36C'est de là que j'obtiens cette multiplication par cinq de la vitesse.
00:11:40Si l'on inclut le cycle de relecture à la fin, dont il faut toujours se souvenir.
00:11:45Et pour en revenir à la planification et au problème que nous avions avec les sceptiques et les personnes surchargées de travail.
00:11:53Assurez-vous de les impliquer et de prendre leurs commentaires très au sérieux.
00:11:59S'ils sont sceptiques, c'est parce qu'ils voient là où vous manquez de validation, là où vos outils échouent.
00:12:05Leurs retours constituent donc essentiellement la feuille de route pour améliorer votre agent et vos interactions avec la base de code.
00:12:12Veillez simplement à les intégrer au lieu d'essayer de les forcer à utiliser l'IA.
00:12:19Confiez-leur la responsabilité de la feuille de route pour rendre l'IA sûre dans votre organisation.
00:12:25Et ils suivront le mouvement une fois qu'ils verront que les améliorations qu'ils apportent leur facilitent réellement la vie.
00:12:33Et comme vous pouvez le voir, ils ne se priveront pas de vous dire ce que vous devez corriger.
00:12:37C'est moins d'une heure passée assis avec un groupe de personnes.
00:12:40Et c'est le résultat de séances de brainstorming.
00:12:45Une autre chose qui a été très utile avec mon équipe en particulier, et que nous cherchons à adopter dans l'ensemble de l'organisation,
00:12:53est de s'assurer d'avoir une communication attentive à l'attention.
00:12:58À l'ère de l'IA, l'attention humaine est une ressource rare.
00:13:01Je crois l'avoir entendu dans plusieurs conférences, et beaucoup de gens sont arrivés à la même conclusion.
00:13:06On ne peut pas obtenir plus d'attention humaine.
00:13:08Alors, l'endroit où vous passez votre temps et ce que vous lisez devient vraiment important.
00:13:13Et comme c'est une ressource rare, indiquer ce qui a été généré par l'IA par rapport à ce qui a été écrit par un humain aide vraiment à savoir combien de temps vous devez passer à lire ceci,
00:13:24et à quel niveau de rigueur vous pouvez vous attendre dans cette partie de la communication.
00:13:31Et c'est en quelque sorte bâtir une nouvelle culture autour de ce style de communication.
00:13:35Ça aide vraiment.
00:13:36Et donc par exemple, l'équipe avec qui je travaille, nous avons décidé que nous allons toujours -- chaque description de PR commencera par quelque chose comme ça.
00:13:45Quelque chose que j'ai écrit à la main pourrait être très court pour décrire ce que cela fait, et ensuite la description de l'IA viendra après.
00:13:54C'est juste -- je vais probablement le lire.
00:13:55Je vais probablement le modifier pour enlever des éléments erronés, mais ils n'ont pas écrit chaque ligne ici.
00:14:00Ils devraient donc être plus soupçonneux, faire plus attention à ce que j'ai écrit en haut, et ils devraient l'emporter.
00:14:05Des choses comme ça sur Slack, par e-mail, en acceptant simplement le fait que tout le monde sait que vous utilisez l'IA pour rédiger votre communication,
00:14:15mais n'hésitez pas à leur dire ce qu'ils doivent lire et à quoi ils doivent accorder moins d'attention.
00:14:21Et je me rappelle qu'au début, vers le début de cette année, j'ai essayé de -- j'avais des ingénieurs seniors dans notre entreprise qui étaient très sceptiques face à l'IA,
00:14:35et j'ai essayé de les contacter pour voir quel était le problème, ce qui se passait, et j'ai dit : j'ai essayé de lancer une analyse sur certains commentaires de PR que vous avez faits,
00:14:42et évidemment j'ai utilisé l'IA pour faire cela.
00:14:45Et ensuite je n'ai pas distingué très clairement ce que j'avais écrit par rapport à ce qu'ils -- ce que l'IA a généré, et ils se sont très énervés.
00:14:54Ils ont dit : pourquoi m'envoyez-vous -- je ne m'attendais pas à ce qu'une personne que je respecte autant m'envoie quelque chose d'aussi manifestement bâclé.
00:15:02Et alors, genre, je -- genre, je me suis excusé.
00:15:05J'ai réalisé que j'aurais dû le marquer clairement et exprimer mon intention.
00:15:08Genre, c'est ce que j'ai écrit.
00:15:10C'est ce que l'IA a écrit, et j'ai besoin de vos retours dessus parce que je n'ai pas le contexte pour savoir si c'est bâclé ou non.
00:15:15Et c'est ce que je vous demande.
00:15:17Donc, des leçons comme ça et changer la culture est tout aussi important que certains des défis d'ingénierie auxquels nous avons fait face.
00:15:28Une autre chose qui est vraiment utile concernant l'adoption, c'est qu'au fur et à mesure que l'on progresse dans l'adoption, il y a beaucoup d'outils très sophistiqués et de flux de travail très complexes que nous avons mis en place.
00:15:41Mais l'une des choses vraiment efficaces consiste simplement à laisser les gens utiliser l'IA là où ils sont.
00:15:47Cela aide vraiment à normaliser l'utilisation de l'IA pour les tâches quotidiennes, et cela aide à réduire les frictions.
00:15:54Et vraiment, l'une des choses les plus puissantes est de pouvoir mentionner un agent dans un message Slack avec quelqu'un et de dire : peux-tu juste faire ça pour moi ?
00:16:02Et faire en sorte que les agents bouclent la boucle dans le fil de discussion ?
00:16:07Et ce genre de chose est vraiment puissant.
00:16:09Et ensuite, vous pouvez ajouter par-dessus tout cela l'automatisation et toutes sortes de choses sophistiquées.
00:16:14Mais si vous avez une conversation avec quelqu'un qui n'est pas totalement convaincu, et que vous pouvez le mentionner d'une manière non passive-agressive, vous pouvez le mentionner et dire : essayons de voir si l'agent peut y arriver cette fois.
00:16:26Et ils bouclent la boucle, et si c'est une bonne expérience, cela aide vraiment les gens à l'essayer par eux-mêmes dans d'autres cas.
00:16:33Et notre parcours continue.
00:16:37Nous apprenons toujours, même si nous déployons l'IA en externe, notre adoption de l'IA, et nous expérimentons tellement de choses tout le temps, alors que notre automatisation n'est pas encore tout à fait au point.
00:16:50Nous essayons toujours de comprendre quand nous devrions utiliser, comment nous pouvons utiliser Cloud Agent efficacement, étant donné toutes les dépendances que nous avons pour certains de nos systèmes de build.
00:16:58Et donc nous continuons d'apprendre.
00:17:01C'est un changement culturel.
00:17:02C'est un changement d'ingénierie.
00:17:03Et je ne sais pas pour vous, mais je travaille dans la Silicon Valley depuis 15 ans, et c'est le plus grand changement de loin de tout ce que j'ai vu en termes de culture et de technologie.
00:17:16Nous sommes donc tous là ensemble, et nous découvrons tout cela.
00:17:19Et c'est de cela dont je voulais vous parler aujourd'hui.
00:17:22Merci.
00:17:28Merci.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video