De l'assistant IA à l'IA native : bâtir une équipe de développement de pointe — Clare Liguori, AWS
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Clare Liguori : Je m'appelle Clare Liguori et je suis ingénieure principale chez AWS.
00:00:17Je travaille principalement sur Kiro, notre assistant de décodage d'agents, mais aujourd'hui je veux parler
00:00:23de certaines des pratiques que nous observons au sein d'Amazon, dans les équipes Amazon, où nous constatons
00:00:28des résultats vraiment passionnants en matière de gains de productivité, qui constituent de véritables sauts qualitatifs par rapport à ce
00:00:35que nous avions vu avec l'IA jusqu'à présent. Je travaille sur l'IA agentique depuis plus de trois ans maintenant,
00:00:43et j'ai pour ainsi dire vu l'évolution qui s'est produite dans notre secteur en matière d'assistance au codage
00:00:48par l'IA. D'abord, nous avons eu cette complétion de code en ligne nous aidant à écrire la ligne suivante,
00:00:55peut-être la fonction suivante. Nous sommes passés au chat, en posant des questions sur notre code. Tout le monde s'est mis
00:01:02au vibe coding l'année dernière, mais maintenant nous commençons à voir une phase de pionniers de ce que
00:01:08nous appelons le développement de frontières. Et de façon purement anecdotique, d'après ma propre expérience,
00:01:14je n'ai vraiment ressenti qu'une augmentation de 10 à 20 % de ma productivité avec toutes ces phases qui ont
00:01:20précédé. Mais maintenant, au sein d'Amazon, nous menons des projets pilotes avec différentes équipes à travers l'entreprise,
00:01:27et nous observons une amélioration médiane de la productivité de 4,5 fois, et parfois de plus de 10 fois. Donc,
00:01:34quelque chose a vraiment changé maintenant que nous constatons ces sauts qualitatifs de productivité.
00:01:40Et j'aime définir ce que nous appelons les développeurs de frontières chez Amazon
00:01:47par trois comportements que j'ai pu observer. Le premier est le codage sans intervention. Les développeurs de frontières écrivent peut-être
00:01:541 à 2 % du code qu'ils produisent. Le reste est géré par des agents. Le deuxième est qu'ils interagissent avec leurs
00:02:01agents de manière infrequent. Ils cherchent à faire tourner leur assistant de codage pendant des heures d'affilée sans
00:02:08intervention de leur part. Et le troisième est qu'ils minimisent les temps morts. Ces développeurs de frontières ont tendance à lancer
00:02:15plusieurs agents en parallèle, qui traitent une liste de tâches en arrière-plan. La première fois que j'ai vu une équipe de développeurs
00:02:24de frontières, c'était l'équipe Bedrock Mantle. Bedrock est notre service d'hébergement de modèles. Il héberge des LLM comme Claude
00:02:34et GPT. Et l'année dernière, nous savions, ou plutôt l'équipe Bedrock savait, qu'elle allait
00:02:43devoir construire un nouveau plan de données d'inférence. Mais elle l'avait estimé à 30 personnes sur 18 mois. C'est un service
00:02:52très important. Et il allait falloir du temps pour construire le nouveau, migrer les clients, migrer les modèles
00:02:58vers celui-ci. Ils ont décidé de prendre du recul. Ils ont pris six personnes et l'ont construit en 76 jours avec Kiro.
00:03:06C'était donc une réalisation immense. C'était la première fois que nous voyions quelque chose de ce genre chez Amazon.
00:03:12C'était vraiment l'équipe pionnière qui a prouvé qu'il était possible d'obtenir jusqu'à 20 fois d'amélioration. Maintenant, ils ont examiné
00:03:21les commits, et je parlerai de quelques autres façons dont nous mesurons les améliorations de productivité. Mais
00:03:27il y avait un problème avec cette histoire, c'est que, oui, cela a été construit avec six personnes. Cela a été construit
00:03:34avec certains des meilleurs ingénieurs de l'entreprise, littéralement, dont deux ingénieurs émérites. Donc ce
00:03:40n'était pas n'importe quelle équipe de six personnes. C'étaient des experts en systèmes distribués, des experts en LLM et en leur
00:03:49architecture. Cette histoire était donc extraordinaire et s'est répandue comme une traînée de poudre à travers Amazon. Mais elle était
00:03:57aussi très difficile à atteindre pour beaucoup d'équipes. De nombreuses questions se sont posées : est-ce que cela peut réellement être reproduit
00:04:03dans une autre équipe ? Une autre expérience dont je veux parler est donc un sprint expérimental réalisé
00:04:10au sein de l'organisation Prime Video. Ils ont fait un sprint de 10 jours et ont mené une expérience en plaçant, là encore, six ingénieurs
00:04:19dans une pièce et en les laissant s'en donner à cœur joie avec Kiro. Ils ont réduit l'estimation du délai de livraison du projet de ce qui
00:04:29allait être 90 semaines à 24, d'après tous les progrès qu'ils avaient faits au cours de ce sprint de 10 jours.
00:04:36Ils ont examiné l'historique de leurs commits et ont regardé ce qu'ils faisaient avant
00:04:42ce sprint de 10 jours et combien de commits ils avaient produits rien que durant ces 10 jours. Ce sprint a donc vraiment
00:04:49prouvé que nous pouvions atteindre, là encore, quelque chose de proche de ce que l'équipe Bedrock Mantle avait réalisé
00:04:58avec un autre groupe d'ingénieurs. Mais encore une fois, il y avait un problème avec cette histoire : c'était six
00:05:05ingénieurs dans une pièce sans service d'astreinte, avec des réunions limitées et très peu de distractions, ce qui, nous le savons
00:05:12tous, fait partie de la vie courante d'un ingénieur. Et l'ingénieur senior de l'équipe avait passé les
00:05:20trois semaines précédentes à créer de petites tâches très détaillées et bien délimitées, avec des exigences précises, pour que ces six
00:05:28ingénieurs n'aient plus qu'à les exécuter pendant ces deux semaines. Ce n'était donc, encore une fois, pas nécessairement la vraie vie.
00:05:35C'était un sprint structuré, un moment donné où ils ont pu réussir cela. Mais de nouveau, la
00:05:41question est de savoir si cela est réalisable pour de vraies équipes dans le cadre du travail quotidien. Ainsi, Amazon Stores, qui englobe
00:05:51Amazon.com, tous nos sites web de vente au détail, ainsi que nos magasins physiques, a mené un projet pilote plus structuré.
00:05:59Ils ont suivi 50 équipes tout à fait normales, avec une distribution normale de débutants, de personnes
00:06:07en milieu de carrière et d'ingénieurs seniors, et qui travaillaient sur des systèmes existants. Rien de greenfield comme l'équipe Mantle
00:06:14a pu en construire à partir de zéro, mais des systèmes existants avec des bases de code existantes. Et ils les ont observés pendant
00:06:21la majeure partie de l'année dernière, et ils ont découvert quelque chose de super intéressant. Ils ont constaté qu'il y avait une grande
00:06:28différence entre les gains de productivité observés par la moitié des équipes et l'autre moitié. Et dans
00:06:34ce cas, ils ont utilisé une métrique de productivité basée sur la vélocité du déploiement en production. Donc pas seulement les commits, combien de
00:06:41commits elles produisent, mais à quelle vitesse envoyons-nous les modifications aux clients ? À quelle vitesse
00:06:48sommes-nous capables de livrer ? Et ils ont vu que pour la moitié des équipes, l'augmentation était inférieure à 3 fois. Et ce qu'ils
00:06:56ont trouvé comme différence entre celles qui ont eu une hausse inférieure à 3 fois et ces équipes qui ont atteint
00:07:01une médiane de 4,5 fois, et parfois plus de 10, c'était la manière d'utiliser les outils. 90 % de ces équipes utilisaient Kiro, parmi
00:07:11d'autres outils internes dont nous disposons. Et ce qu'ils ont découvert, ce n'était pas une question d'outils, mais de méthode de travail.
00:07:18Les équipes qui ont obtenu des sauts qualitatifs ont intentionnellement modifié leur façon de travailler,
00:07:26tandis que les autres se sont contentées de saupoudrer Kiro et quelques autres outils que nous avons par-dessus leur
00:07:31méthode de travail existante. Et pour moi du moins, cela a été le grand moment de déclic : la raison pour laquelle je n'avais pas ressenti
00:07:39potentiellement les gains massifs de productivité que l'IA a promis, c'est qu'il s'agit de changer notre façon
00:07:47de travailler. Ainsi, tout au long de ce projet pilote, ils sont allés interviewer les équipes qui y ont participé, ainsi que certaines
00:07:55autres équipes de l'équipe Bedrock Mantle, de Prime Video, et ils ont identifié cinq habitudes. Et j'emploie
00:08:03le mot habitude très précisément, car encore une fois, il ne s'agit pas de ce seul sprint, mais de le faire au jour
00:08:09le jour. Et ce qu'ils ont découvert lors de leurs entretiens avec ces équipes, c'est qu'il s'agissait vraiment d'habitudes à
00:08:15développer au jour le jour. Lorsque nous modifions notre méthode de travail, il est difficile de prendre ces habitudes, cela prend du temps
00:08:22de les ancrer. Passons donc en revue chacune d'elles. La première habitude est d'investir dans le contexte de l'agent.
00:08:30Nous avons beaucoup de choses en tête, nous avons tendance à transférer tout ce qui se trouve dans notre tête à d'autres personnes
00:08:35via des conversations sur Slack, par le biais de mentors d'intégration, de choses comme ça, lors de revues de code,
00:08:42de points quotidiens et de planification de sprint, et ils ont dû mettre tout cela par écrit. Et l'habitude qu'ils
00:08:50ont prise, c'est qu'à chaque fois que l'agent fait une erreur ou fait quelque chose autrement que vous ne l'auriez fait,
00:08:55qu'est-ce qui manque dans mes fichiers de compétences ? Qu'est-ce qui manque dans mes fichiers de pilotage dont l'agent avait besoin ?
00:09:01Mais comme nous le savons, l'année dernière, nous avons vu des progrès spectaculaires dans les capacités des modèles et leurs comportements.
00:09:09Sonnet 3.7 au milieu de l'année dernière avait beaucoup de spécificités qui nous obligeaient à ajouter de nombreuses interdictions
00:09:16dans nos fichiers de pilotage. Et maintenant, nous n'avons plus à le faire autant avec Opus 4.5 depuis novembre dernier,
00:09:23puis nous avons eu six mois, plus de six mois d'améliorations depuis lors, avec toutes les nouvelles
00:09:29versions de modèles sorties depuis. Et donc la question, la nouvelle habitude à nouveau est : est-ce que
00:09:35j'ai encore besoin de cela dans mes fichiers de pilotage ? Ou est-ce que cela alourdit inutilement le contexte ? La deuxième est de ralentir
00:09:41pour aller plus vite. Dans presque toutes les équipes interrogées, il a été rapporté que leur productivité avait en fait
00:09:48diminué lorsqu'elles ont adopté intentionnellement une nouvelle façon de travailler. C'est contre-intuitif,
00:09:53contre-intuitif, n'est-ce pas ? Vous devez accomplir un travail d'ingénierie intentionnel avant de voir cette
00:09:59courbe en crosse de hockey dans l'amélioration de la productivité. Parce que nous devons d'abord faire un vrai travail dans nos bases de code
00:10:05pour que les agents y réussissent, en particulier dans les bases de code existantes (brownfield). Ils ont donc dû
00:10:11développer ce contexte d'agent, ils ont dû améliorer les messages d'erreur des outils existants pour que le modèle sache
00:10:17ce qui se passait en cas d'échec, ils ont construit de nouveaux outils, de nouveaux serveurs MCP pour aider le modèle à accomplir
00:10:24effectivement ce qu'il devait faire. De nombreuses équipes ont fini par restructurer leur base de code afin que les agents
00:10:29puissent y naviguer plus facilement. Et j'ai même vu des changements drastiques comme modifier le langage de programmation
00:10:36de la base de code. Souvent, j'ai vu des équipes lutter avec Python ou JavaScript parce que ce sont
00:10:43des langages non typés. C'est difficile à tester. Il n'y a pas d'erreurs de compilation. Le modèle devine donc en quelque sorte et
00:10:50vous le restitue. C'est pourquoi j'ai vu des équipes passer à TypeScript. Rust est devenu très populaire
00:10:56chez Amazon. Le compilateur fournit d'excellents messages d'erreur. Pas besoin de faire cela. Mais j'ai vu beaucoup
00:11:03d'équipes faire ces choix intentionnels pour obtenir les gains de productivité qu'elles recherchent.
00:11:09La troisième habitude est de nourrir les agents, pas de les babysitter. Et pour moi, cela a été l'un de ces moments de déclic
00:11:16vis-à-vis de la raison pour laquelle nous constatons ce saut qualitatif de productivité. Si vous faites du vibe coding, si vous
00:11:23avez une conversation aller-retour avec votre agent toute la journée, bien sûr que vous n'allez pas observer
00:11:30de gains de productivité de quatre à cinq fois, car vous êtes dans la boucle tout le temps. Vous êtes probablement
00:11:36assis là pendant 30 secondes à une minute à attendre qu'il génère du code et vous le renvoie
00:11:42pour que vous puissiez l'examiner. Si vous restez planté là à l'attendre, vous ne pouvez pas vaquer à d'autres
00:11:48stuff. It's really difficult to run agents in parallel. It's very difficult to get to to clone yourself
00:11:55into multiple agents. And so if your conversations look a bit like this on the left, then you're
00:12:01babysitting that agent as opposed to the right side where you're feeding it what it needs to do and how
00:12:08it can self-validate. And that's really the key so that agents can self-correct and only come back to you
00:12:14when it meets a certain quality bar, when it when it actually runs and compiles and passes tests, when
00:12:20it's testable, when it actually has high coverage. And of course, the next level is put all of this
00:12:26content into your steering file. So it does it every time without you having to prompt it.
00:12:33The fourth habit is to make intent explicit. At Amazon, we practice a lot of spectrum and development.
00:12:40We've built that into the Kiro product. And so it's very natural for Amazon engineers to adopt it
00:12:46in Kiro. What what I've typically seen with vibe coding as opposed to frontier engineering is giving
00:12:54a very high level prompt, letting the agent generate a ton of code, and then having a back and forth
00:13:02conversation saying, Oh, that's not really what I meant. That you haven't you haven't exactly gotten the requirements right.
00:13:10No, I didn't actually want to build it that way. Here's a technical design. And it is less I find less productive
00:13:17to iterate with the agent on code when the intent itself was incorrect. So often we'll have while see Amazon
00:13:26engineers go through this process for ambiguous, complex features of writing the specification.
00:13:34And in Kiro, of course, you don't have to write this whole specification, you can have the model generate
00:13:39it. But it's a lot easier to iterate with the model in kind of a back and forth conversation about a
00:13:46document than it is about code that's code changes that are spread across a code base. The fifth one is shift testing
00:13:56left. One of the keys here is to give the agent that fast feedback loop, because that's what lets it go off for hours
00:14:04at a time and self correct. The agent is going to make mistakes, and that's fine. But if you give it the right signals, it can
00:14:12self correct and it can spend a while doing that. So I've seen teams adding linters, adding unit tests,
00:14:20integration tests, performance tests, security tests. These are all things we all know we should have
00:14:24been doing all along. This is good engineering hygiene and practices. But now the ROI is, I think, finally
00:14:32high enough for us to actually invest in it. One thing that I've been seeing a lot of teams do is mock out
00:14:40services. Often with integration tests, we would test kind of end to end an entire system, including live
00:14:46services. But we've been investing a lot in mock services that run entirely locally with deterministic
00:14:52responses, because it lets the agent do everything locally. Doing everything on your laptop without
00:15:01having to spin up a bunch of other services and connect to cloud services makes everything a lot faster.
00:15:07Because the more that your agent can get fast feedback means the more loops that it can
00:15:14can do and the more productive your own agent can be. So across all of these, these are some of the
00:15:21habits we've seen. But of course, I would be remiss if I would tell you if you adopt all of these habits,
00:15:28you will achieve nirvana, you will be the most productive engineering organization the world has
00:15:35ever seen. Things are still hard. We are still very much in an early adopter phase and teams are still
00:15:42figuring it out. So one thing that we've been seeing across our teams just organizationally is the risk of
00:15:48burnout. I did not coin this term, I forget who did at what conference, but FOMAT is real. We've been seeing
00:15:56engineers staying up late, late at night, trying to get that perfect prompt that's going to make their
00:16:03agent run for hours overnight so that they wake up in the morning with a code change ready. The cognitive load
00:16:09increases as you run these multiple agents in parallel, you're constantly shifting between
00:16:15terminal tabs. And then we do see that reviewing AI output is often harder for some than than actually
00:16:22writing it, especially early in career. Senior engineers have have already spent a large portion of their
00:16:29career reviewing others code. But early career engineers don't have that muscle yet. And so reviewing
00:16:37it can can feel like a lot more cognitive load than they're used to in actually writing it. The other
00:16:44one is organizational change. So it's already hard to change the way we work as engineers. The way that we
00:16:52spend our entire day completely changes when we're frontier engineers. But also organizations have to
00:16:58change to enable frontier engineering teams. One that I've seen very commonly is accepting slowing down
00:17:07to speed up. And I've been guilty of this myself. My fellow leaders have been guilty of this of saying,
00:17:14well, you have the AI tools now and the models are so amazing now. Why are you not going faster?
00:17:22And that's because you have to take those two months to invest in your code base to figure out the best
00:17:29best practices for your team to make hard habit changes on your team. And if you're constantly expecting
00:17:38shipping features every month, because now we have these amazing models, and we're seeing
00:17:44all of these companies on X saying how they're shipping 20 PRs a day, we have to slow down to speed up.
00:17:54The second one is actually going too broad in the organization too fast. I think that if we had
00:18:01expected all teams in massive organizations to be frontier teams immediately, we would not have had
00:18:08the learnings that we had from the pathfinder, from the from the sprint experiment, from the pilot
00:18:16teams within Amazon. And now the challenge for us is how do we scale it out? And that's what 2026 is about.
00:18:22For Amazon is how do we scale this out to more and more teams to the next 2000 teams instead of 50 teams.
00:18:31And so I think that when you roll it out too quickly, you have a lot of teams who don't know what they're
00:18:37doing. You haven't had time to find the best practices for your own organizations, the the context
00:18:43that your organization needs. And the last one is that you're going to find new bottlenecks.
00:18:49Previously code writing code manually was the bottleneck. I find that within Amazon, we've found
00:18:58the speed of decision making becomes a new bottleneck. The more that you spend reviewing the decision to
00:19:05actually build a new product, the slower it is to build the product now because the code only takes one to two months to write.
00:19:12All of the review processes associated with the launch of a product become the bottleneck.
00:19:20When it used to take nine to 12 months to build a new product, it didn't matter so much in the in the overall
00:19:27wash of things. If it took two months to make the decision to build the product and then two months to
00:19:33approve the launch. But now those are the bottlenecks. Those are the long pole. And so you find all of
00:19:40these all of these things that slow you down. Often I find that frontier engineering teams spend more time
00:19:48making decisions than they do writing code. And so the more that you can make fast decisions, especially ones
00:19:54that are easy to be reversed, the better. So my one big takeaway for for everyone here is that frontier
00:20:03engineering is about intentionally changing the way that you work. And that is difficult. That takes time.
00:20:10It is forming new habits and a new way of working. And that goes across any engineering team as well as your
00:20:18organization. So I encourage you to think about how you're interacting with AI tools and how that can
00:20:27change to free yourself up from being in the loop. Thanks. I'll hang out a little bit if anyone has
00:20:34questions in the back. But thanks for the time today.