Cause première en 33 secondes : Kiro CLI a économisé 4 années de temps de compilation

Le problème : des temps de compilation qui dévorent votre journée

Si vous avez déjà fixé une compilation en cours depuis 30 minutes en vous demandant si quelque chose avait mal tourné, vous connaissez ce sentiment. C'était la réalité d'un ensemble de progiciels internes de compilation de configuration que notre équipe maintenait. Les temps de compilation P99 avaient dépassé 25 minutes, parfois même 30. Avec des centaines de progiciels compilés 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 une base de code inconnue, formuler une hypothèse, puis mettre en œuvre un correctif — pouvait facilement prendre des jours. Nous avons décidé d'essayer autre chose.

Pourquoi Kiro CLI?

Nous utilisions Kiro CLI depuis un certain temps, et cette tâche semblait être exactement le genre de travail pour lequel il avait été conçu. Il ne s'agissait pas d'une simple tâche de génération de code, mais d'une investigation complexe et ouverte. Il nous fallait un agent capable de raisonner sur plusieurs fichiers, d'interpréter les résultats de profilage et d'établir des liens entre le comportement à l'exécution et le code source.

Les outils conçus expressément pour générer du code excellent dans ce qu'ils font, mais pour analyser la cause première dans une base de code inconnue, nous voulions un agent plus généraliste. Kiro CLI était le bon choix.

Kiro en action : des données de profilage au correctif en 33 secondes

Nous avons commencé par recueillir des données de performance avec perf et par les reformater dans un format clair et structuré. (Nous y reviendrons dans la section des leçons; cette étape est importante.) Nous avons ensuite donné une seule requête à Kiro :

Une investigation entièrement autonome a suivi.

Les données de profilage racontaient une histoire claire, à condition de savoir les lire. L'arbre d'appels montrait que l'analyseur du fichier de configuration consommait une part énorme du temps processeur : près de 80 % du chemin d'exécution remontait aux routines principales de l'analyseur :

Kiro a lu ces résultats, les a mis en correspondance avec le code source de l'outil de compilation de configuration et a trouvé le coupable : l'analyseur de configuration était réinitialisé à chaque appel de fonction dans plusieurs sous-routines. Chaque appel créait une toute nouvelle instance de l'analyseur, qui relisait et analysait de nouveau les mêmes fichiers de configuration sur le disque.

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

Les outils qui ont rendu cela possible

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

• Outils d'intelligence du code (generate_codebase_overview, search_codebase_map) pour comprendre rapidement les bases de code inconnues
• Outils du système de fichiers (fs_read, fs_write, glob) pour lire les données de profilage, examiner le code source et mettre en œuvre les changements
• Délégation à un sous-agent (use_subagent) pour confier des tâches d'analyse ciblées sans encombrer le contexte principal

Sous le capot : comment Kiro a examiné le problème

Pour comprendre ce qui a rendu cette investigation si rapide, il vaut la peine d'examiner comment Kiro a concrètement abordé le problème. En 10 tours autonomes, Kiro a utilisé une combinaison d'outils d'intelligence du code et du système de fichiers pour parcourir une base de code inconnue, corréler les données de profilage au code source et mettre en œuvre un correctif.

Comprendre la structure de la base de code

Kiro a commencé par s'orienter. Il a utilisé generate_codebase_overview pour dresser une carte générale de la structure du dépôt, puis search_codebase_map pour repérer les principaux répertoires et progiciels. Ces outils ont fourni à Kiro un modèle mental de l'organisation du projet sans qu'il ait à lire chaque fichier.

Il a ensuite utilisé fs_read en mode Directory pour énumérer le contenu du répertoire cible et confirmer la présence du fichier de rapport de performance.

Pourquoi c'est important : avant de se plonger dans les données de profilage, Kiro devait comprendre son environnement de travail. Ces outils de reconnaissance lui ont permis d'établir efficacement le contexte, comme le ferait un ingénieur qui parcourt un README et l'arborescence des fichiers avant d'examiner le code.

Lire et interpréter les données de profilage

Kiro a ensuite lu le fichier de rapport de profilage avec fs_read en mode Line.

Les données de profilage indiquaient que 79,41 % du temps processeur était consacré à la fonction principale de l'analyseur, avec une surcharge importante liée à l'analyse des jetons et aux opérations d'E/S. C'était la preuve déterminante, mais Kiro devait encore comprendre pourquoi l'analyseur consommait autant de temps.

Pourquoi c'est important : les données de profilage sont denses et difficiles à interpréter. Kiro n'a pas seulement lu le fichier, mais aussi l'arbre d'appels complet, repéré les chemins de code les plus sollicités et les reliés à des noms de fonction précis. C'est là qu'un agent généraliste excelle : il peut raisonner sur des formats de données structurés comme les résultats de perf sans avoir besoin d'un analyseur spécialisé.

Déléguer l'analyse du code à un sous-agent spécialisé

À ce stade, Kiro avait repéré le goulot d'étranglement (l'analyseur de configuration), mais devait trouver où l'analyseur était instancié dans la base de code. Kiro a délégué cette tâche à un agent spécialisé dans l'analyse du code au moyen de use_subagent.

Le sous-agent a reçu une requête ciblée : « Repérez les emplacements des progiciels d'outils de compilation où nous pouvons mettre en œuvre des optimisations de performance fondées sur l'analyse des données de perf. »

Pourquoi c'est important : il s'agit de l'une des fonctions les plus puissantes de Kiro. En déléguant à un sous-agent spécialisé, Kiro a gardé son propre contexte épuré tout en confiant une sous-tâche ciblée à un agent optimisé pour l'analyse du code. Le sous-agent a travaillé en parallèle, analysé la base de code et retourné les résultats, sans encombrer la conversation principale.

Localiser le code problématique

Fort des conclusions du sous-agent, Kiro a utilisé glob pour trouver tous les fichiers du progiciel de l'outil de compilation, puis fs_read pour examiner les modules sources pertinents.

Il a lu les modules d'extension et de configuration, cherchant où l'analyseur était instancié. La tendance est devenue claire : chaque fonction du module de configuration créait une nouvelle instance de l'analyseur avec des paramètres identiques.

Pourquoi c'est important : Kiro ne s'est pas contenté de rechercher la classe de l'analyseur et de conclure. Il a lu le code réel, analysé le flux de contrôle et repéré la répétition de l'instanciation. Cela exigeait de raisonner sur le comportement du code, pas seulement d'effectuer une recherche de motifs.

Tour 10 : mettre en œuvre le correctif

Enfin, Kiro a mis en œuvre la solution. Il a utilisé fs_write avec la commande str_replace pour modifier le module de configuration et introduire un mécanisme de mise en cache :

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

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

Pourquoi c'est important : Kiro ne s'est pas contenté de suggérer un correctif; il a écrit le code et l'a mis en œuvre. L'opération str_replace nécessitait de comprendre la structure du code existant, de repérer les lignes précises à modifier et de générer du code syntaxiquement correct qui s'intégrait parfaitement à la base de code existante.

Kiro a directement mis en œuvre de 80 à 90 % des changements de code requis. Nous avons examiné et validé le tout, puis lancé une compilation pour confirmer l'hypothèse. Les résultats ont été immédiats : les temps de compilation P99 sont passés de plus de 30 minutes à moins de 1 minute.

Ce que nous avons appris

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 « écris-moi une fonction qui fait X » —, un agent généraliste capable de raisonner sur plusieurs fichiers, outils et 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 particulièrement adapté à ce type de travail exploratoire.

Faites confiance à l'agent pour approfondir, mais vérifiez les résultats. Kiro a mis en œuvre la majeure partie du correctif de façon autonome, mais nous avons tout de même compilé le progiciel et validé les résultats avant de le livrer. Le développement assisté par l'IA accélère considérablement les phases d'investigation et de mise en œuvre, mais ne devrait pas remplacer le jugement de l'ingénieur quant à l'exactitude et à la sécurité.

Le rendement du capital investi s'accumule à grande échelle. Une compilation de 30 minutes peut sembler un désagrément personnel. Multipliez-la par des centaines de milliers de compilations par mois et elle devient un problème de coûts d'infrastructure. Kiro a aidé à mettre au jour et à corriger un problème dont l'ampleur n'est visible que dans son ensemble.

Ce qui a rendu cette réussite possible n'était pas un outil en particulier, mais la capacité de Kiro à les enchaîner de façon autonome. Kiro a établi le contexte, formulé une hypothèse, l'a validée au moyen du code et mis en œuvre un correctif, le tout sans intervention humaine au-delà de la requête initiale.