Renforcer Kiro grâce aux diagnostics de l'IDE
Les premiers agents de programmation avaient ce problème : l'IA génère du code qui semble correct, mais les erreurs de l'IDE ne sont pas immédiatement visibles pour l'agent. Cela s'explique par le fait que les agents n'avaient pas de visibilité sur ces erreurs sans exécuter des outils supplémentaires. Par conséquent, l'agent poursuivait avec confiance tandis que la base de code accumulait de la dette technique. Cela représente une lacune dans la façon dont tout agent de programmation qui n'intègre pas l'information des diagnostics fonctionne.
Bien que la plupart des IDE modernes exécutent continuellement des outils sophistiqués d'analyse de langage qui détectent les erreurs en temps réel, les agents ont besoin d'un moyen efficace d'accéder à cette richesse d'information. Sinon, ils doivent se rabattre sur l'exécution de commandes de build/test (coûteuses) pour valider le code, ce qui est plus lent, consomme des jetons, et manque la rétroaction nuancée que votre environnement de développement fournit déjà. Le résultat? Une validation de code plus gourmande en ressources qu'elle ne devrait l'être.
Lorsque les agents ne peuvent pas voir les diagnostics de l'IDE, ils ne peuvent pas itérer vers la qualité. Ils génèrent plutôt du code qu'ils présument correct avant de passer à la tâche suivante. Il vous revient alors d'effectuer l'assurance qualité pour l'agent — corriger manuellement les erreurs de type (p. ex. appeler user.getName() alors que la propriété est en fait user.name), ajouter les importations manquantes (l'agent utilise Button mais a oublié import { Button } from '@/components/ui/button'), et résoudre les violations de linting (variables inutilisées, indentation incohérente). Cela ne fait pas que ralentir les développeurs, cela vous entraîne à ne plus faire confiance du tout au code généré par l'agent.
Les IDE modernes sont propulsés par une infrastructure sophistiquée d'analyse de langage. Les serveurs de langage effectuent une analyse en temps réel de votre base de code. Par exemple, une extension TypeScript effectue la vérification de type, ESLint valide le style de code, les extensions Java fournissent une rétroaction instantanée sur la compilation, les extensions CloudFormation et Terraform valident les configurations d'infrastructure telles que les propriétés de ressources, les arguments requis et les références de ressources avant le déploiement.
Cette analyse se produit continuellement pendant que vous programmez pour faire ressortir les erreurs sous forme de diagnostics — les traits ondulés rouges et les marqueurs de problème que vous voyez dans votre éditeur. Ces diagnostics représentent une riche source de rétroaction immédiate et précise sur l'exactitude du code.
Pourtant, les premiers assistants de programmation par IA ne pouvaient pas accéder à cette information. Ils validaient plutôt le code en exécutant des commandes de build (npm run build, npm test, etc.) même si cela pouvait prendre plusieurs secondes, voire des minutes, par invocation.
Dans Kiro, un IDE agentif qui apporte une structure à la programmation par IA grâce au développement piloté par les specs, nous avons réglé ce problème en donnant à l'agent un accès direct aux diagnostics de l'IDE. Maintenant, quand Kiro écrit du code, il voit immédiatement les mêmes erreurs que vous verriez, et peut les corriger dès qu'elles surviennent; avant même que vous ne révisiez les changements. L'impact sur la qualité du code a été significatif : moins de corrections manuelles et une meilleure adhérence aux normes de qualité du projet. Les agents de programmation de Kiro s'intègrent étroitement à ces diagnostics côté client pour améliorer à la fois la compréhension et la génération de code. Grâce à leur connexion aux mêmes serveurs de langage qui propulsent l'IDE, les agents peuvent maintenant lire et interpréter en temps réel les erreurs de compilation, les avertissements de type et les résultats de linting. Lorsque Kiro génère ou modifie du code, il interroge cette information de diagnostics pour valider l'exactitude — par exemple, en détectant un symbole manquant en Java ou une erreur de syntaxe en Python — et peut affiner automatiquement sa sortie en fonction de cette rétroaction.
L'approche conventionnelle suit un cycle itératif lent. L'agent génère du code puis exécute une commande de build (et/ou de test) qui peut prendre du temps. Lorsque le build échoue avec une erreur, l'agent génère une correction et exécute à nouveau la commande de build. Ce processus lourd se répète jusqu'à ce que le build réussisse.
L'approche pilotée par les diagnostics est beaucoup plus rapide. Après avoir généré le code, l'agent vérifie les diagnostics en moins de 35 ms. On lui fournit des erreurs précises avec numéros de ligne et descriptions. L'agent génère ensuite une correction ciblée et la vérifie via les diagnostics en 35 ms supplémentaires avant de poursuivre avec du code validé.
L'écart de temps s'accumule sur les tâches en plusieurs étapes. Dans le développement piloté par les specs, où Kiro met en œuvre des dizaines de tâches, l'outil de diagnostics est invoqué environ 4x plus fréquemment qu'en mode de programmation intuitive, car chaque limite de tâche distincte nécessite de confirmer que les critères d'acceptation sont respectés. Cela assure une validation continue tout au long du processus de mise en œuvre.
Nous avons mesuré l'impact de l'intégration des diagnostics sur l'utilisation en production et sur des tests de référence contrôlés. Les résultats démontrent des gains d'efficacité significatifs, accompagnés d'améliorations mesurables de la qualité du code. Sur le plan de l'efficacité, nous avons observé une réduction de 29 % des exécutions de commandes grâce à la diminution des commandes de build/test. Cette mesure a été obtenue en comparant les statistiques d'interaction des agents sur plusieurs jours d'utilisation en production avant et après l'introduction de la fonctionnalité de diagnostics. La qualité du code s'est améliorée tout en réduisant simultanément la latence de bout en bout.
La puissance du système de diagnostics vient de sa généralité. Plutôt que de créer une analyse personnalisée pour chaque langage, Kiro s'appuie sur le Language Server Protocol (LSP) et les API d'extension qui alimentent déjà une myriade de fonctionnalités de l'IDE. Les données de production confirment que cela fonctionne sur des piles technologiques diverses. Par exemple, les extensions populaires pour les langages à usage général tels que TypeScript, Python et Rust, ainsi que les langages spécifiques à un domaine tels que SQL, YAML et GraphQL, fournissent de l'information de vérification de type et de linting. De plus, il existe des extensions pour les principaux outils de build (comme Maven, Make, Cargo, etc.) et les fichiers de configuration programmatiques (Terraform, Kubernetes YAML, Dockerfile, etc.) pour améliorer l'expérience de configuration et de débogage.
L'analyse de l'utilisation en production révèle des motifs communs dans la façon dont l'outil de diagnostics améliore la qualité du code existant ou nouvellement généré :
Scénario 1 [Erreurs de syntaxe] : Dans une base de code Python pour l'analytique, l'agent met en œuvre une nouvelle fonctionnalité pour les agrégations par fenêtre.
L'outil de diagnostics trouve une erreur d'expression régulière (missing ), unterminated subpattern at position 13) qui est ensuite corrigée par l'agent. La revalidation confirme que l'erreur n'est plus présente. En l'absence de l'outil de diagnostics, l'agent devrait se rabattre sur la composition et l'exécution de tests via la ligne de commande pour vérifier les problèmes.
Scénario 2 [Éviter les hallucinations] : Dans une base de code TypeScript, Kiro apporte des changements à un composant et le valide immédiatement :
L'outil de diagnostics signale immédiatement deux incompatibilités de type (Type 'number' is not assignable to type 'string' et Cannot assign to read-only 'executionTime') ainsi qu'une hallucination de propriété (Property 'itemAge' does not exist on type 'StackProps'). Guidé par ces problèmes, l'agent génère des corrections et revalide les changements. Ce motif (générer → valider → affiner) se produit fréquemment dans les langages à typage statique où les erreurs de type sont courantes mais facilement détectées par les serveurs de langage.
Scénario 3 [Validations de type] : Dans un projet Swift, Kiro ajoute une nouvelle fonctionnalité et vérifie les diagnostics des fichiers modifiés :
Les diagnostics révèlent qu'il y a une erreur de type dans l'un des fichiers. L'agent corrige ensuite le problème et revalide le fichier concerné pour s'assurer que la correction est exacte.
Scénario 4 [Infrastructure as Code — alias IaC] : La validation par diagnostics s'étend au-delà du code applicatif. Un utilisateur demande à Kiro de vérifier ses configurations Terraform :
Cela démontre comment le système de diagnostics fonctionne avec les langages spécifiques à un domaine et les formats de configuration, et non seulement avec les langages de programmation conventionnels.
En rapprochant la génération de code et la validation de code, l'outil de diagnostics permet les améliorations suivantes :
Charge cognitive réduite : Les développeurs passent moins de temps à valider manuellement le code généré par l'IA. Lorsque Kiro rapporte « Aucun diagnostic trouvé », les développeurs peuvent poursuivre avec une confiance accrue.
Itération plus rapide : La réduction de la fréquence des commandes bash se traduit par des économies de temps tangibles.
Meilleure qualité de code : Résoudre les problèmes dès qu'ils apparaissent signifie un code plus propre et de meilleure qualité.
Les diagnostics de l'IDE représentent une source importante de rétroaction immédiate pour la validation du code. En intégrant l'information de diagnostics directement dans le flux de travail agentif de Kiro, nous avons éliminé l'écart entre la génération de code et la validation qui affligeait les premiers agents de programmation.
Les résultats parlent d'eux-mêmes : moins d'exécutions de commandes, des cycles de validation rapides, et une qualité de code améliorée sur diverses piles technologiques. Plutôt que de forcer les agents à se rabattre sur des commandes de build/test lentes et coûteuses, Kiro s'appuie sur la même infrastructure sophistiquée d'analyse de langage qui alimente déjà les IDE modernes; de la vérification de type TypeScript à la validation de configuration Terraform.
Cette approche pilotée par les diagnostics accélère la boucle de rétroaction de l'agent. Plutôt que de générer du code à l'aveugle en espérant qu'il fonctionne, Kiro voit les mêmes erreurs que vous verriez et les corrige de façon proactive. Le résultat est un code qui nécessite moins de corrections manuelles, ce qui bâtit une plus grande confiance chez les développeurs.
Prêt à découvrir la différence? Commencez avec Kiro gratuitement et voyez comment des agents propulsés par les diagnostics peuvent transformer votre flux de travail de développement. Joignez-vous à notre communauté grandissante sur Discord pour partager de la rétroaction, poser des questions et entrer en contact avec d'autres développeurs qui utilisent la programmation assistée par l'IA.
Remerciements
Crédits (par ordre alphabétique) Al Harris, Nathan Jones, Nikhil Swaminathan, Siwei Cui, et Varun Kumar