Six ingénieurs ont réalisé un projet de 30 personnes en 76 jours

Un défi de 30 personnes

Amazon Bedrock est le socle du développement d'applications d'intelligence artificielle générative dans l'ensemble d'AWS : il donne aux clients accès à des modèles de fondation de premier plan au moyen d'une API entièrement gérée. Derrière ce service, le moteur d'inférence traite des milliards de demandes, acheminant les requêtes vers les modèles et retournant les réponses à grande échelle.

Lorsque l'équipe a constaté la nécessité de reconstruire une portion critique de cette pile d'inférence, l'estimation conventionnelle était claire. Il faudrait 30 ingénieurs, de 12 à 18 mois. L'architecture existante utilisait un répartiteur de charge pour distribuer les demandes et des bassins de capacité dédiés à chaque modèle, ce qui limitait l'efficacité et l'utilisation pour des demandes d'inférence très variables et de longue durée.

Anthony Liguori, vice-président et ingénieur émérite chez AWS, voyait une autre voie. Plutôt que d'agrandir l'équipe pour respecter l'échéancier, il voulait mettre une hypothèse à l'épreuve : un petit groupe d'ingénieurs seniors, avec l'IA comme fondement de leur flux de travail, pourrait livrer le même résultat en une fraction du temps.

Il a réuni six ingénieurs. Tous seniors, de niveau L7 ou plus. Tous profondément immergés dans le domaine du problème. Et il a fait un choix délibéré qui allait définir l'expérience : Kiro serait l'environnement de développement principal, et l'équipe repenserait toute sa façon de travailler autour de lui.

Pas une astuce de productivité; une refonte du flux de travail

Il ne s'agissait pas d'ajouter un assistant d'IA à un processus existant et d'en mesurer l'accélération. L'équipe a passé ses premières semaines à faire quelque chose de contre-intuitif : ralentir.

Elle a repensé son flux de travail à partir des principes fondamentaux. Comment le code doit-il être organisé pour qu'un modèle d'IA puisse raisonner efficacement à son sujet? Comment les tâches doivent-elles être délimitées pour qu'un agent puisse les mener à terme de façon autonome? Quelle infrastructure doit exister pour que le code généré par l'IA puisse être validé avec une grande confiance avant d'atteindre la production?

Les réponses sont devenues le système d'exploitation du projet :

Développement piloté par les tâches. Le travail complexe est découpé en petites requêtes gérables, chacune délimitée pour produire un seul commit révisable. Non pas « construis-moi un répartiteur de charge », mais « implémente la logique d'acheminement des demandes en suivant le motif du module X ».

Ingénierie du contexte. Le code est organisé en de nombreux petits modules isolés pour que le modèle n'ait à considérer qu'une portion restreinte à la fois. Une structure de monodépôt où tout le code et toute la documentation se trouvent à un seul endroit repérable.

Outillage soigneusement choisi. Un serveur MCP minimal, conçu expressément, axé sur les opérations et le débogage, plutôt qu'un énorme ensemble d'outils par défaut qui fait exploser la fenêtre de contexte.

Pas de revues de code traditionnelles. Les ingénieurs seniors examinent directement tout le code généré par l'IA. Chaque commit est attribué et reproductible. L'équipe fait confiance au processus parce qu'elle comprend chaque ligne.

Ce que je pensais devoir prendre plus d’un an

Les attentes initiales étaient modestes. Liguori espérait une amélioration de 10 à 20 pour cent de la vélocité.

Ce qui s'est produit a plutôt surpris tout le monde.

En quelques semaines, l'équipe a découvert que des tâches qui prenaient normalement une ou deux semaines pouvaient être accomplies en une heure environ. L'effet cumulatif a été spectaculaire. Les ingénieurs n'écrivaient pas seulement du code plus vite; ils traversaient tout le cycle de développement sans les goulots d'étranglement traditionnels que sont le débogage de la compilation, l'échafaudage des tests et le changement de contexte entre les réunions et le travail en profondeur.

L'équipe a livré environ 100 000 lignes de nouveau code Rust en 76 jours. Les développeurs ont réalisé individuellement 40 commits ou plus par semaine. Liguori lui-même a livré 951 changements en production; selon ses propres calculs, plus de code que durant les six à huit années précédentes de sa carrière réunies.

L'équipe est convaincue qu'elle pourrait soutenir plus de 100 commits par semaine par développeur si les temps de compilation étaient inférieurs à 45 minutes, ce qui donne à penser que la vélocité actuelle est limitée par l'infrastructure, et non par l'approche elle-même.

Le travail créatif a pris de l’ampleur

Le changement le plus profond n'était pas dans la vitesse. Il était dans la façon dont les ingénieurs occupent leur temps.

Avant Kiro, le développement était fragmenté. Des problèmes de compilation. Le débogage des échecs de tests unitaires. L'attente des compilations. Le changement de contexte entre les réunions et le travail en profondeur. Les aspects créatifs de l'ingénierie, la conception, l'architecture et l'exploration d'approches inédites, étaient constamment interrompus par des tâches mécaniques.

Avec Kiro, cette dynamique s'est inversée. Le travail fastidieux de débogage, de compilation, de génération de tests et de code passe-partout est devenu automatisé. Ce qui a pris de l'expansion, c'est le travail créatif.

L'équipe passe maintenant beaucoup plus de temps devant des tableaux blancs. Quand on peut programmer 10× plus vite, on investit davantage pour bien concevoir. Elle a exploré des algorithmes sophistiqués et des motifs d'architecture inédits qui auraient été économiquement irréalisables auparavant. C'étaient des idées pour lesquelles personne n'aurait approuvé d'effectifs selon les estimations traditionnelles.

Comment l'équipe fonctionne réellement

Les mécanismes quotidiens n'ont rien à voir avec ceux d'une équipe d'ingénierie typique :

Un minimum de réunions. Une mêlée quotidienne de 30 minutes. Aucune rencontre individuelle. Aucune cérémonie de sprint. Une politique de porte ouverte. Une communication à large bande passante et à faible latence.

Colocalisation physique. Tout le monde est assis côte à côte. À la vitesse où cette équipe fonctionne, être ensemble est essentiel à la coordination. Des décisions qui prendraient une journée sur Slack prennent cinq minutes en personne.

Progression asynchrone grâce aux agents. Les ingénieurs lancent des tâches, s'occupent d'autres responsabilités et reviennent à un résultat terminé. Un ingénieur principal a livré des changements complets avec seulement « a couple of hours of contiguous time », parce que l'agent travaillait pendant qu'il passait d'une responsabilité à l'autre.

Des tests exhaustifs comme couche de confiance. Une simulation haute fidélité des services externes. Des canaris complets de bout en bout. Un cycle dev/test serré où les changements peuvent être poussés en production avec une confiance de 99 % depuis le poste d'un développeur. C'est ce qui rend la vélocité soutenable, non seulement rapide, mais sûre.

Des agendas dégagés. L'équipe considère le temps de concentration comme non négociable. Aucune réunion récurrente propre au projet au-delà de la mêlée quotidienne. Aucune taxe de changement de contexte.

Une base de code conçue pour l'IA

Le taux de réussite élevé de l'équipe, environ 95 % des requêtes produisant du code utilisable, n'est pas le fruit du hasard. Il est attribuable à une base de code conçue expressément pour la productivité de l'IA.

Les principes, notons-le, reflètent ce qui rend le code bon pour les humains :

Une documentation abondante. Beaucoup plus de markdown et de commentaires de code que dans tout autre projet auquel Liguori a travaillé. Kiro génère la documentation à mesure qu'il programme, créant une boucle de rétroaction autorenforçante où une bonne documentation rend la requête suivante plus efficace.

Une logique simple et de la modularité. De petits modules que le modèle peut lire en entier dans sa fenêtre de contexte. Les bonnes requêtes font référence à des motifs existants, par exemple : « suis le motif du module X pour implémenter Y ».

Une infrastructure de test exhaustive. Le modèle peut exécuter des canaris complets de bout en bout et s'autocorriger lorsque les tests échouent. Cela ferme la boucle. Il peut écrire, tester, corriger et faire un commit sans intervention humaine pour les problèmes courants.

Des règles Steering. Des règles minimales qui demandent à l'IA de garder la documentation à jour, créant un cercle vertueux où la base de code devient plus propice à l'IA avec le temps.

Rust, un heureux hasard. Les erreurs détectées à la compilation, accompagnées de messages d'erreur conviviaux, aident l'IA à se déboguer elle-même. « It was a happy accident that Rust is amazing for GenAI development », Liguori notes. Le compilateur agit comme une deuxième couche de validation qui détecte les problèmes avant qu'ils n'atteignent la production.

Au-delà du code; le premier outil pour tout

La transformation dépasse l'écriture de code. Kiro est devenu le premier outil de l'équipe pour les opérations en production.

Lorsqu'il est appelé à 2 h du matin, Liguori se tourne d'abord vers Kiro. Le modèle exécute des requêtes CloudWatch Logs Insights sur plusieurs groupes de journaux et plusieurs régions simultanément, analysant les tendances dans les systèmes de production plus vite qu'aucun opérateur humain ne le pourrait.

L'équipe a mis en place un triage automatisé de chaque billet entrant, le modèle atteignant la cause première 80 % du temps. Toutes les opérations passent par CloudWatch, sans aucun accès des opérateurs aux hôtes de production; le modèle a le même accès aux données opérationnelles que les ingénieurs eux-mêmes.

C'est là que le chiffre de 20× devient tangible. Il ne s'agit pas seulement d'écrire du code 20× plus vite. Il s'agit de comprendre un système, de diagnostiquer un problème, de valider un correctif et de le livrer en toute sécurité 20× plus vite.

Ce que cela signifie pour l'ingénierie à grande échelle

Ce n'est pas une histoire de remplacement des ingénieurs. C'est une histoire sur ce qui devient possible lorsqu'on élimine la friction entre l'intention créative et la réalité de la production.

L'équipe, qui comptait 6 personnes au départ, en compte maintenant 11. Elle a livré ce qui représente, selon les estimations de Liguori, deux années de production d'une équipe dotée d'effectifs traditionnels. Mais le constat le plus profond est structurel : de petites équipes très communicatives peuvent maintenant prendre en charge une portée qui exigeait auparavant des organisations beaucoup plus grandes.

Pour les responsables de l'ingénierie qui envisagent cette approche, les données probantes révèlent cinq conditions déterminantes :

1. Repensez le flux de travail, pas seulement l'outillage. Les équipes qui ajoutent l'IA à leurs processus existants obtiennent des gains modestes. Les équipes qui restructurent leur façon de travailler obtiennent des améliorations d'un ordre de grandeur. La différence ne tient pas à l'outil; elle tient à la volonté de tout repenser autour de lui.

2. Commencez petit, avec des gens d'expérience. Chaque membre de l'équipe doit être profondément engagé dans le projet et travailler concrètement avec l'IA. Une communication à large bande passante. Des agendas dégagés. Aucun participant à temps partiel.

3. Investissez d'abord dans le cycle dev/test. Si vous pouvez écrire, tester et pousser un changement en production avec une confiance de 99 % depuis votre poste de développement, votre projet connaîtra un très grand succès avec l'IA. Si vous ne le pouvez pas, c'est ce qu'il faut corriger avant toute autre chose.

4. Attendez-vous à la courbe en bâton de hockey. Chaque développeur de l'équipe a eu un moment de déclic — ça démarre lentement, puis ça accélère de façon spectaculaire. Les équipes qui abandonnent à la deuxième semaine ne voient jamais les gains cumulatifs qui arrivent à la quatrième semaine.

5. Ne faites pas de programmation intuitive. Comprenez chaque ligne. Traitez l'IA comme un compilateur et la rédaction de requêtes comme un nouveau langage de programmation. Les ingénieurs qui réussissent sont ceux qui conservent la pleine responsabilité de ce que produit le modèle.