Les inefficacités cachées dans la programmation avec l'IA (et comment nous les trouvons)

Une tâche est terminée. Le code compile, les tests sont verts, tout le monde passe à autre chose. Mais que se passe-t-il si cette tâche « réussie » a nécessité 17 tours parce que l'agent n'arrivait pas à trouver un fichier qui était juste là? Que se passe-t-il si elle a englouti des tentatives sur un modèle de commande shell qui n'allait jamais fonctionner?

Les benchmarks ne détectent pas cela. Les métriques de réussite/échec voient un succès et passent à autre chose. Nous voulions creuser plus profondément, examiner le chemin complet parcouru par l'agent, pas seulement où il a terminé. Nous avons donc construit un système spécialisé pour l'optimisation continue par le raisonnement et l'apprentissage adaptatif — surnommé affectueusement CORAL à l'interne.

Les agents de programmation avec l'IA sont généralement évalués sur des benchmarks : taux de réussite, nombre de jetons, latence. Ces métriques vous disent ce qui s'est passé, mais pas pourquoi, et elles ne vous disent pas comment améliorer le processus global.

Une tâche peut « réussir » alors que l'agent gaspille des tours sur des modèles de recherche défectueux. Une autre échoue non pas parce que le modèle est faible, mais parce qu'une description d'outil est trompeuse. Lorsque vous traitez des milliers d'interactions d'agent chaque jour, la révision manuelle n'est pas viable à grande échelle.

Nous avions besoin d'un système capable d'apprendre automatiquement de la production, en trouvant les modèles que les benchmarks manquent.

Notre système d'apprentissage adaptatif analyse de vraies interactions avec Kiro pour faire ressortir les inefficacités que les métriques de réussite/échec ignorent.1

Pensez-y comme un joueur d'échecs qui révise ses parties. Après chaque partie, il ne se contente pas de vérifier le résultat. Il se demande : Où ai-je perdu du tempo? Quels modèles ont mené à des erreurs? Que devrais-je faire différemment la prochaine fois? Notre système fait cela pour l'agent de Kiro, automatiquement et à grande échelle.

Pour ce faire, il utilise l'apprentissage basé sur les trajectoires. Plutôt que de simplement vérifier si le code compile, notre système examine la séquence complète des actions entreprises par l'agent : chaque appel d'outil, chaque point de décision, chaque tentative de récupération. Une tâche qui réussit en 5 étapes claires est très différente d'une qui réussit en 17 étapes désordonnées, et il peut faire la différence.

Chaque jour, nous échantillonnons des milliers de vraies sessions Kiro provenant d'utilisateurs qui nous en ont donné la permission et les examinons à l'aide d'une analyse basée sur les grands modèles de langage. Pour chaque trajectoire, il se demande : qu'est-ce que l'agent a fait, qu'est-ce qui a mal (ou bien) tourné, et pourquoi?

Il ne voit pas seulement des résultats superficiels comme « la recherche n'a retourné aucun résultat ». Il retrace la séquence complète des actions : ce que l'agent a essayé, comment il a récupéré, et où il a perdu du temps. À partir de cette séquence, le grand modèle de langage effectue une analyse des causes profondes et en extrait une leçon généralisable, pas une correction ponctuelle, mais quelque chose qui s'applique à travers les tâches.

Cette leçon est vérifiée par rapport à tout ce qu'il a déjà appris. Est-elle nouvelle? Est-elle suffisamment précise pour agir? Entre-t-elle en conflit avec une observation existante? Si elle passe, elle est ajoutée à une base de connaissances structurée organisée par catégorie : utilisation des outils, modèles de flux de travail, récupération d'erreurs, orientation comportementale.

Chaque observation suit également les preuves. Si un modèle continue d'apparaître à travers de nombreuses trajectoires, la confiance grandit. Si une observation antérieure s'avère causer des problèmes, elle est révisée ou supprimée. La base de connaissances n'est pas statique; elle évolue à mesure que l'agent et les outils changent.

Lorsque nous trouvons une observation à haute confiance, nous la transformons en correction concrète : une mise à jour de description d'outil, un changement d'invite système, ou une modification du comportement de l'agent. Celles-ci sont déployées immédiatement, sans nécessiter de réentraînement du modèle. À mesure que l'agent s'améliore, nous recueillons plus de données provenant de vraies sessions, et le cycle continue.

Voici un modèle que nous avons détecté et que la plupart des métriques pourraient manquer.

Ce qui se passait : les agents recherchaient des fichiers en utilisant des modèles comme *.py et obtenaient zéro résultat. Les recherches étaient marquées comme des appels d'outil réussis (aucune erreur déclenchée), alors l'agent supposait que les fichiers n'existaient simplement pas. Mais ils existaient bel et bien. L'agent ne pouvait simplement pas les trouver.

Pourquoi : les grands modèles de langage apprennent à partir d'outils comme ripgrep, où les recherches *.py sont récursives par défaut. Mais l'API de recherche de Kiro, construite sur Code-OSS, nécessite **/*.py pour la correspondance récursive. Une différence subtile, et la description de l'outil ne le mentionnait pas.

Le coût : plus d'un quart des recherches grep échouaient silencieusement. Lorsqu'une recherche ne retourne rien, l'agent n'abandonne pas. Il improvise. Il lit des fichiers manuellement, réessaie avec des requêtes différentes, explore des arborescences de répertoires. En moyenne, les agents ont gaspillé environ 5 tours supplémentaires pour récupérer de chaque recherche échouée, faisant un travail qui n'aurait pas dû être nécessaire.

La correction : une ligne dans la description de l'outil.

Le résultat :

Un simple changement d'une ligne a réduit les modèles grep incorrects d'environ 99 % en production.

Ce qui se passait : les agents écrivaient des commandes shell comme cd src && npm test. Chacune d'entre elles échouait. L'outil executeBash de Kiro exécute chaque commande depuis la racine de l'espace de travail et rejette l'utilisation de cd par validation des entrées, donc cd n'a aucun effet durable. L'outil fournit un paramètre cwd exactement à cette fin, mais dans environ 4 % des appels bash, le modèle retombait sur des modèles shell familiers appris de ses données d'entraînement plutôt que de suivre la description de l'outil.

Pourquoi : cd dir && command est l'un des modèles courants dans les scripts shell. Les grands modèles de langage l'ont vu des millions de fois. L'approche du paramètre cwd est inhabituelle, alors les agents se rabattaient sur la mémoire musculaire.

Le coût : 3,46 % de tous les appels shell utilisaient ce modèle, touchant 18 % des sessions. Chaque tentative échouait, et les agents ont passé en moyenne 2,7 tours à récupérer : en réessayant des commandes, en explorant des alternatives, parfois sans jamais complètement récupérer au sein de la session.

La correction : plutôt que de simplement renforcer la restriction dans l'invite, nous avons construit une correction automatique. Lorsque l'agent envoie :

Kiro le transforme silencieusement en :

Après l'exécution, un rappel doux renforce le bon modèle :

Cela garde l'agent orienté. Il sait toujours où il se trouve, ce qui évite la confusion et les erreurs en cascade qui suivent la perte du répertoire de travail.

Impact projeté :

L'analyse ne trouve pas seulement de grandes victoires. Elle fait continuellement ressortir de plus petits modèles qui s'additionnent. En voici quelques-uns que nous étudions activement :

Dérive du contenu après la mise en forme. Un agent modifie un fichier, puis un formateur comme Prettier ou Black remodèle les espaces et la structure. La prochaine modification de l'agent suppose que le fichier ressemble toujours à ce qu'il a écrit, mais la réalité a dérivé. Notre analyse a révélé que cela cause des échecs répétés de type « oldStr not found » lorsque l'agent tente d'apporter des modifications de suivi. Nous explorons des façons de faire relire à l'agent les sections modifiées avant de tenter d'autres modifications sur des fichiers qui ont pu être mis en forme automatiquement.

Modifications multi-fichiers dispersées. Lorsque des changements s'étendent sur plusieurs fichiers, les agents qui se lancent directement dans la modification manquent souvent du code lié dans d'autres fichiers. Nous avons constaté que les agents qui cartographient d'abord tous les points de modification à travers la base de code (en utilisant la recherche) avant d'apporter des changements produisent des résultats plus complets et cohérents. Nous étudions des façons d'encourager ce modèle « cartographier d'abord, modifier ensuite » pour les tâches multi-fichiers.

L'impasse de l'accusé de réception. Nous avons repéré des trajectoires où les agents répondent à une demande par « Compris » ou « D'accord » puis ne font rien. L'utilisateur doit relancer une demande pour qu'un travail réel soit accompli. C'est un petit détail, mais cela gaspille un tour et brise le flux. Nous travaillons sur une orientation comportementale pour nous assurer que l'agent agit immédiatement plutôt que de simplement accuser réception.

La taxe de l'ambiguïté. Parfois, la meilleure chose à faire est de poser une question de clarification. Nous avons trouvé des trajectoires où les agents ont mal deviné sur des demandes ambiguës, construit la mauvaise chose, puis ont dû refaire le travail. Une seule question au préalable aurait épargné plusieurs tours d'efforts gaspillés. Nous étudions quand et comment inciter l'agent à demander une clarification plutôt que de deviner.

Chaque correction individuelle est petite : une ligne dans une description d'outil, une incitation comportementale, une correction automatique, mais pour vous, elles s'additionnent. Une recherche qui trouve le bon fichier du premier coup plutôt qu'au cinquième essai. Une commande shell qui fonctionne tout simplement plutôt que d'échouer et de réessayer. Moins de tours gaspillés signifie des résultats plus rapides et moins de temps passé à attendre que l'agent retrouve ses repères.

Nous sommes optimistes quant à l'utilisation de l'analyse au niveau des trajectoires pour corriger rapidement bon nombre de ces problèmes. L'évaluation traditionnelle voit une tâche réussie et passe à autre chose. Le système voit une tâche terminée qui a pris 17 tours avec des modèles de recherche défectueux, et se demande : comment faire pour que ce soit 5 tours la prochaine fois?

Plutôt que de simplement mesurer les résultats, nous analysons activement le chemin d'exécution complet pour trouver les inefficacités que les métriques de réussite/échec peuvent manquer.

Tout cela se déroule en arrière-plan, faisant ressortir des corrections que notre équipe révise et déploie — avec l'objectif de rendre cette boucle entièrement automatique avec le temps. Votre agent Kiro aujourd'hui est meilleur qu'il ne l'était le mois dernier, et le mois prochain, il sera encore meilleur, sans que vous ayez à faire quoi que ce soit. Cependant, lorsque vous laissez une rétroaction sur les suggestions de Kiro, signalez des problèmes, ou soulignez quelque chose qui semblait bizarre, ce signal alimente notre système d'apprentissage. Votre contribution aide Kiro à devenir plus intelligent pour tout le monde.

Les découvertes ci-dessus ne sont que le début. Nous trouvons de nouveaux modèles chaque semaine, et nous continuerons à partager ce que nous apprenons.

Commencez avec Kiro et voyez comment il continue de s'améliorer.

---

1 Vous pouvez refuser le partage de vos interactions avec Kiro. Les utilisateurs d'entreprise sont exclus par défaut.