Précision chirurgicale grâce à l'édition de code basée sur l'AST dans Kiro
TL;DR : Au cours des dernières semaines, nous avons testé un nouveau moteur de navigation et d'édition de code basé sur l'AST qui réduit l'utilisation de jetons de 20 % sur notre SWE-PolyBench, un benchmark contenant des exemples de demandes de fonctionnalités, le type de requête le plus fréquent dans Kiro. Il permet également des transformations de code précises, résilientes et de qualité production. Fini les regex fragiles ou les extractions de fichiers complets!
Chaque développeur utilisant des assistants de programmation par IA en a fait l'expérience : l'agent lit des milliers de lignes pour trouver une seule fonction, puis échoue à la mettre à jour à cause d'une différence de formatage mineure. L'approche actuelle lit des fichiers entiers et fait correspondre des chaînes exactes, mais elle consomme beaucoup de jetons et se brise facilement. Nous avons créé quelque chose de mieux.
Aujourd'hui, nous présentons un système de navigation et d'édition de code basé sur l'AST qui donne à Kiro une précision chirurgicale lorsqu'il travaille avec votre base de code. Plutôt que de sonder des plages de lignes arbitraires et de faire correspondre des chaînes fragiles, cet outil cible le code par structure — fonctions, classes, imports — et applique des opérations typées avec une compréhension sémantique.
Jusqu'à maintenant, Kiro IDE s'appuyait sur deux outils basés sur le texte : readFile pour examiner le code et strReplace pour effectuer des modifications. Bien que simple, cette approche crée deux problèmes fondamentaux :
1. Coûts élevés en jetons et en latence
Lorsqu'il recherche une fonction spécifique, l'agent doit lire de grandes portions de fichiers, souvent des fichiers entiers, pour trouver ce dont il a besoin. Cela signifie des milliers de jetons dépensés sur du contexte qui n'est pas pertinent pour la tâche.
2. Correspondance de chaînes fragile
Effectuer des modifications nécessite des correspondances de chaînes exactes. Une seule différence dans les espaces, le formatage ou les commentaires entre ce que l'agent attend et le code réel entraîne des échecs d'édition ou des correspondances multiples non voulues. L'agent doit alors faire des itérations supplémentaires pour corriger l'erreur.
Ces problèmes s'accumulent : l'agent fait une erreur, relit le fichier pour établir un diagnostic, tente une nouvelle modification, et le cycle se poursuit. Chaque itération consomme plus de jetons et ajoute de la latence.
Le moteur remplace les opérations basées sur le texte par une analyse AST. Plutôt que de traiter le code comme des chaînes, il comprend le code comme des entités structurées : fonctions, classes, méthodes, imports et leurs relations.
Plutôt que de déverser le contenu complet d'un fichier, l'outil de lecture de code du moteur ne retourne que ce dont vous avez besoin :
- Signatures : définitions de fonctions et de classes sans les détails d'implémentation
- Structure : organisation du code de haut niveau et relations
- Résultats de recherche : définitions spécifiques correspondant à vos critères
Comparez ces deux approches pour examiner une classe Java :
Approche traditionnelle (1 309 jetons) :
Approche basée sur l'AST (545 jetons) :
Dans cet exemple, le moteur fournit 58 % moins de jetons tout en livrant l'information structurelle essentielle nécessaire pour la navigation et la prise de décision.
L'outil d'écriture de code du moteur utilise des sélecteurs pour cibler précisément des éléments de code :
ClassName.methodNamepour cibler une méthode spécifiquefunction:functionNamepour cibler une fonctionfield:fieldNamepour cibler un champ de classeendpour ajouter à la fin d'un fichier
Il prend en charge quatre opérations typées :
- insert_node : ajouter du nouveau code à des emplacements spécifiques
- replace_node : remplacer des fonctions ou des classes entières
- delete_node : supprimer des éléments de code proprement
- replace_in_node : effectuer des modifications chirurgicales à l'intérieur d'un bloc de code
Voici un exemple réel provenant de nos benchmarks, pour l'ajout d'une nouvelle fonction à un fichier TypeScript :
Approche traditionnelle (361 jetons) :
Approche basée sur l'AST (96 jetons) :
Dans cet exemple, le moteur livre 73 % moins de jetons en évitant d'inclure le contexte environnant nécessaire pour la correspondance exacte de chaînes.
Nous avons évalué notre moteur basé sur l'AST par rapport aux outils traditionnels sur deux benchmarks :
L'exécution des opérations de lecture et d'écriture AST sur PolyBench50 (un sous-ensemble de SWE-PolyBench) a montré des améliorations constantes :
| Métrique | Traditionnel | Moteur basé sur l'AST | Amélioration |
|---|---|---|---|
| Appels LLM par tâche | 40,88 | 26,86 | 34,30 % |
| Jetons de sortie | 270 957 | 189 806 | 29,95 % |
| Jetons d'entrée | 680 684 | 541 346 | 20,47 % |
Nous avons testé les deux approches sur une demande de fonctionnalité réaliste : « Ajouter des intégrations tierces à AWS Resource Explorer » (notifications Slack/Teams, billets Jira, exportations SIEM, intégration AWS Config).
| Métrique | Traditionnel | Moteur basé sur l'AST | Amélioration |
|---|---|---|---|
| Temps d'exécution | 9 min 20 s | 4 min 44 s | 49,30 % |
| Appels LLM | 29 | 22 | 24,10 % |
| Jetons d'entrée | 1 350 | 1 192 | 11,70 % |
| Jetons de sortie | 761 | 654 | 14 % |
| Erreurs d'outils | 2 | 0 | - |
Les avantages des opérations de code basées sur l'AST vont au-delà de l'efficacité en matière de jetons :
Résilience : les changements de formatage ne brisent pas les modifications. Que vous utilisiez 2 espaces ou 4, des tabulations ou des espaces, la modification structurelle réussit.
Précision : ciblez exactement ce que vous voulez changer sans vous soucier d'éléments de code similaires ailleurs dans le fichier.
Maintenabilité : les opérations qui fonctionnent aujourd'hui fonctionneront demain, même si le code environnant évolue.
Compréhension : l'analyse AST fournit à l'agent une compréhension véritable de la structure du code, permettant des décisions plus intelligentes sur où et comment effectuer les changements.
Cela importe particulièrement pour les demandes de fonctionnalités, le type de requête le plus fréquent dans Kiro, représentant 45 % du trafic en mode Vibe et 67,6 % du trafic en mode Spec. Ces demandes impliquent souvent des modifications de plusieurs fichiers à travers une base de code, où l'effet cumulatif d'une correspondance de chaînes fragile crée une friction importante. Nous sommes emballés par ces premiers résultats, et cette fonctionnalité est maintenant disponible en production.