Cause profonde en 33 secondes : comment Kiro CLI a permis d'économiser 4 années de temps de génération

33 secondes. C'est tout ce qu'il a fallu à Kiro CLI pour examiner un goulot d'étranglement de performance coriace, cerner la cause profonde enfouie dans un code source hérité, et implémenter un correctif qui a fini par économiser environ 4 années de temps de calcul par mois, répartis sur 381 paquets construits 550 000 fois chaque mois au sein d'EC2 et de nombreuses autres équipes AWS.

Si vous vous êtes déjà retrouvé à regarder une génération qui tourne depuis 30 minutes en vous demandant si quelque chose a mal tourné, vous connaissez cette sensation. C'était la réalité d'une suite de paquets internes de génération de configuration que notre équipe maintenait. Les temps de génération P99 avaient dépassé 25 minutes — parfois plus de 30. Avec des centaines de paquets construits des centaines de milliers de fois par mois, ces minutes s'accumulaient rapidement.

Nous devions comprendre pourquoi. L'approche habituelle — lire manuellement les données de profilage, les recouper avec un code source peu familier, formuler une hypothèse, puis implémenter un correctif — pouvait facilement prendre des jours. Nous avons décidé d'essayer autre chose.

Nous utilisions Kiro CLI depuis un moment, et cela ressemblait exactement au genre de tâche pour laquelle il a été conçu. Il ne s'agissait pas d'un simple travail de génération de code, mais d'une investigation complexe et ouverte. Nous avions besoin d'un agent capable de raisonner à travers plusieurs fichiers, d'interpréter les données de profilage et de relier le comportement d'exécution au code source.

Les outils conçus expressément pour la génération de code excellent dans ce domaine, mais pour une analyse de cause profonde dans un code source peu familier, nous voulions un agent plus généraliste. Kiro CLI était le bon choix.

Nous avons commencé par capturer des données de performance à l'aide de perf et en les reformatant dans un format clair et structuré. (Plus de détails à ce sujet dans la section des leçons apprises — cette étape compte.) Nous avons ensuite donné à Kiro une seule requête :

Ce qui a suivi était une investigation entièrement autonome.

Les données de profilage racontaient une histoire claire une fois qu'on savait comment les lire. L'arbre d'appels a montré que l'analyseur de fichiers de configuration consommait une part massive du temps CPU — près de 80 % du chemin d'exécution remontait aux routines centrales de l'analyseur :

Kiro a lu cette sortie, l'a mise en correspondance avec le code source de l'outil de génération de configuration, et a cerné le coupable : l'analyseur de configuration était réinitialisé à chaque appel de fonction, à travers plusieurs sous-routines. Chaque appel créait une toute nouvelle instance d'analyseur, relisant et réanalysant les mêmes fichiers de configuration à partir du disque à chaque fois.

Le correctif était élégant : introduire un cache partagé indexé sur les paramètres de configuration pertinents. Analyser une fois, réutiliser partout.

L'investigation s'appuyait sur quelques capacités clés :

• Les outils d'intelligence du code (generate_codebase_overview, search_codebase_map) pour comprendre rapidement des codes sources peu familiers
• Les outils de système de fichiers (fs_read, fs_write, glob) pour lire les données de profilage, inspecter le code source et implémenter les changements
• La délégation à des sous-agents (use_subagent) pour déléguer des tâches d'analyse ciblées sans polluer le contexte principal

Pour comprendre ce qui a rendu cette investigation si rapide, il est utile d'examiner comment Kiro a réellement travaillé sur le problème. Au cours de 10 tours autonomes, Kiro a utilisé une combinaison d'outils d'intelligence du code et de système de fichiers pour naviguer dans un code source peu familier, corréler les données de profilage avec le code source et implémenter un correctif.

Kiro a commencé par s'orienter. Il a utilisé generate_codebase_overview pour construire une carte de haut niveau de la structure du dépôt, suivi de search_codebase_map pour cerner les répertoires et paquets clés. Ces outils ont donné à Kiro un modèle mental de l'agencement du projet sans avoir à lire chaque fichier.

Il a ensuite utilisé fs_read en mode Répertoire pour lister le contenu du répertoire cible, confirmant la présence du fichier de rapport de performance.

Pourquoi cela compte : Avant de se plonger dans les données de profilage, Kiro devait comprendre avec quoi il travaillait. Ces outils de reconnaissance lui ont permis de bâtir le contexte efficacement, de la même façon qu'un ingénieur parcourrait un README et naviguerait dans l'arborescence des fichiers avant de plonger dans le code.

Ensuite, Kiro a lu le fichier de rapport de profilage à l'aide de fs_read en mode Ligne.

Les données de profilage ont montré que 79,41 % du temps CPU était consacré à la fonction centrale de l'analyseur, avec une surcharge importante dans l'analyse de jetons et les opérations d'E/S. C'était la preuve irréfutable, mais Kiro devait encore déterminer pourquoi l'analyseur consommait autant de temps.

Pourquoi cela compte : Les données de profilage sont denses et difficiles à interpréter. Kiro n'a pas seulement lu le fichier, mais l'arbre d'appels au complet, a cerné les chemins de code les plus chauds et les a reliés à des noms de fonctions précis. C'est là qu'un agent généraliste brille : il peut raisonner sur des formats de données structurés comme la sortie de perf sans avoir besoin d'un analyseur spécialisé.

À ce stade, Kiro avait cerné le goulot d'étranglement (l'analyseur de configuration), mais devait localiser où, dans le code source, l'analyseur était instancié. Kiro a délégué cette tâche à un agent d'analyse de code spécialisé à l'aide de use_subagent.

Le sous-agent a reçu une requête ciblée : « Identify build tool package locations where we can implement performance optimizations based on perf data analysis. »

Pourquoi cela compte : C'est l'une des fonctionnalités les plus puissantes de Kiro. En déléguant à un sous-agent spécialisé, Kiro a gardé son propre contexte propre tout en déléguant une sous-tâche ciblée à un agent optimisé pour l'analyse de code. Le sous-agent a fonctionné en parallèle, a analysé le code source et a retourné des résultats — tout cela sans encombrer la conversation principale.

Muni des conclusions du sous-agent, Kiro a utilisé glob pour trouver tous les fichiers du paquet de l'outil de génération, puis a utilisé fs_read pour inspecter les modules source pertinents.

Il a lu les modules de plugin et de configuration, en scrutant l'endroit où l'analyseur était instancié. Le motif est devenu clair : chaque fonction du module de configuration créait une nouvelle instance d'analyseur avec des paramètres identiques.

Pourquoi cela compte : Kiro n'a pas simplement effectué une recherche grep sur la classe de l'analyseur et s'est arrêté là. Il a lu le code réel, a analysé le flux de contrôle et a cerné le motif d'instanciation répétée. Cela nécessitait de raisonner sur le comportement du code, pas seulement de faire correspondre des motifs.

Enfin, Kiro a implémenté la solution. Il a utilisé fs_write avec la commande str_replace pour modifier le module de configuration, en introduisant un mécanisme de mise en cache :

• Ajout d'une table de hachage de cache pour stocker les instances d'analyseur
• Création d'une fonction d'aide qui vérifie le cache avant d'instancier un nouvel analyseur
• Refactorisation de toutes les fonctions existantes pour utiliser l'analyseur mis en cache

Le correctif était chirurgical : il a préservé tout le comportement existant tout en éliminant la réinitialisation redondante.

Pourquoi cela compte : Kiro n'a pas simplement suggéré un correctif, il a écrit le code et l'a implémenté. L'opération str_replace nécessitait de comprendre la structure du code existant, de cerner les lignes exactes à changer et de générer un code syntaxiquement correct qui s'intégrait parfaitement au code source existant.

Kiro a implémenté 80 à 90 % des changements de code requis directement. Nous avons révisé, validé et lancé une génération pour confirmer l'hypothèse. Les résultats ont été immédiats : les temps de génération P99 sont passés de plus de 30 minutes à moins de 1 minute.

Utilisez un agent généraliste pour les tâches d'investigation. Lorsque le problème est ouvert — « pourquoi est-ce lent? » plutôt que « écrivez-moi une fonction qui fait X » — un agent généraliste capable de raisonner à travers des fichiers, des outils et des formats de données est le bon choix. La capacité de Kiro CLI à enchaîner les appels d'outils de façon autonome le rendait bien adapté à ce genre de travail exploratoire.

Faites confiance à l'agent pour aller en profondeur, mais validez les résultats. Kiro a implémenté la majorité du correctif de façon autonome, mais nous avons quand même construit le paquet et validé les résultats avant la mise en production. Le développement assisté par l'IA accélère considérablement les phases d'investigation et d'implémentation, mais ne doit pas remplacer le jugement de l'ingénieur quant à l'exactitude et la sécurité.

Le retour sur investissement s'accumule à grande échelle. Une génération de 30 minutes semble être un inconvénient personnel. Multipliez-la par des centaines de milliers de générations par mois, et cela devient un problème de coût d'infrastructure. Kiro a aidé à faire ressortir et à corriger un problème d'une ampleur qui ne devient visible qu'en agrégat.

Ce qui a rendu ce travail possible n'était pas un seul outil, c'était la capacité de Kiro à les enchaîner de façon autonome. Kiro a construit le contexte, formulé une hypothèse, l'a validée par rapport au code, et a implémenté un correctif, tout cela sans intervention humaine au-delà de la requête initiale.