Première prise en main de Kiro d'AWS

Dans la bataille que se livrent fournisseurs de cloud et éditeurs dans l’IA à l’attention des développeurs, AWS a présenté à la mi-juillet Kiro. Se définissant comme une IDE à base d’agents IA, il introduit un workflow axé sur les spécifications reflétant la manière dont les grandes équipes d'ingénieurs planifient, conçoivent et livrent le code. Le développeur se servant de Kiro crée une spécification pour le programme souhaité. L’outil utilise Claude Sonnet (3.7 ou 4.0) d’Anthropic pour générer de manière itérative un ensemble d’exigences, un document de conception et une liste de tâches pour la construction de l'application. Il est possible de superviser chaque étape du processus, intervenir pour modifier les spécifications ou les commandes, ou laisser le système fonctionner en pilote automatique. Notre confrère d’Infoworld a pu prendre en main Kiro en version préliminaire.

Configurer un projet

L’IDE à base d’IA est basé sur une version dérivée de Visual Studio Code, ce qui facilite l'accès aux fonctionnalités pour les utilisateurs de VS Code. On ne comprend pas pourquoi Kiro est un produit à part entière plutôt qu'une simple suite de plugins pour l'IDE VS Code ; peut-être pour éviter la concurrence avec Copilot de Microsoft. Quoi qu'il en soit, vous pouvez migrer les plugins de votre configuration VS Code existante vers Kiro si vous souhaitez vous en servir dans le cadre du processus de développement Kiro, ou simplement les installer depuis la place de marché OpenVSX.

Lorsque vous ouvrez un nouveau dossier de projet dans Kiro, une invite Claude Sonnet s'affiche, que vous pouvez utiliser pour « viber » (décrire votre projet de la manière la plus générale possible et l'explorer en détail) ou « spec » (utiliser une conception formelle comme décrit précédemment). L'option « vibe » convient aux projets simples et ponctuels, et a été utilisée pour générer un projet Python qui vérifie si les environnements virtuels d'autres projets Python sont invalides. Il n’a pas été difficile de vérifier si le code résultant fonctionnait, car des dizaines de projets avec des venvs (environnements virtuels) ont été cassés grâce à une récente mise à niveau du système.

Conception d'un outil de ligne de commande simple dans Kiro pour vérifier si les projets Python ont des environnements virtuels valides. (Crédit Photo: IDG)

Pour le choix des spécifications, un projet plus ambitieux a été mis en place : un générateur de site statique en ligne de commande. Kiro utilise les invites pour générer les documents d'exigences, de conception et de liste de tâches afin de mettre en place un processus de création étape par étape.

Vous pouvez également créer une documentation de pilotage, qui fournit des règles constantes sur la façon dont Kiro doit interpréter les instructions : la finalité du projet, la pile à utiliser et la disposition des fichiers dans le référentiel. Ces documents peuvent être générés au début du projet, puis modifiés pour guider le développement, ou générés a posteriori et utilisés pour guider les améliorations du code pilotées par l'IA.

Le document d'exigences généré suit le schéma familier « user story »/« QUAND/ALORS » du développement agile :

Un exemple de document d'exigences agile généré dans Kiro. (Crédit Photo: IDG)

Le document de conception décrit les composants et l'architecture de l'application et peut entrer dans beaucoup plus de détails que le document de la pile technique :

Un exemple de document de conception. (Crédit Photo: IDG)

La liste des tâches détaille chaque étape de la création du projet. Elle est interactive et il est possible de la déclencher en cliquant sur les liens « Démarrer » ou « Réessayer » générés automatiquement à chaque étape :

Une liste de tâches détaille chaque étape du développement de l'application. (Crédit Photo: IDG)

Guider Kiro tout au long du processus de développement

Pour chaque élément de la liste des tâches, Kiro fournit un retour en temps réel sur son activité, les fichiers modifiés et les commandes à exécuter. À chaque étape, vous pouvez intervenir manuellement en modifiant les fichiers ou les commandes à exécuter :

Kiro fournit des commentaires en direct tout au long du processus de développement. (Crédit Photo: IDG)

Vous pouvez mettre Kiro en pilotage automatique et tenter de le laisser générer autant que possible par lui-même, mais le choix a été fait de surveiller chaque étape pour voir les retours en détail. Cela s'est avéré nécessaire, car il fallait intervenir constamment, par exemple pour s'assurer que toutes les commandes Python étaient exécutées avec py (sous Windows). Demander à Kiro de le faire systématiquement n'a fonctionné qu'une seule fois, et modifier les documents de pilotage pour le mentionner explicitement n'a pas semblé résoudre le problème non plus.

De nombreuses actions automatisées de Kiro prennent plusieurs minutes. Vous pouvez donc quitter l'application, effectuer d'autres tâches dans une autre fenêtre et recevoir une notification dans la barre d'état système lorsque Kiro requiert votre attention. Si vous devez interrompre votre travail et revenir en arrière, par exemple pour redémarrer pour des mises à jour, Kiro relira la documentation de votre projet pour déterminer où il s'était arrêté. Cependant, cette opération prend quelques minutes, et à plusieurs reprises des dépassements de délai d'API lors de la reprise d'une session ont été rencontrés.

Un défaut curieux du fonctionnement de Kiro avec le code est qu'il ne semble pas effectuer de vérification mécanique de la syntaxe ni de l'analyse de code avant son exécution. De nombreux exemples de code (sources et tests) présentaient des erreurs de syntaxe qui auraient pu être facilement détectées par une étape d'analyse distincte :

Des erreurs de syntaxe en Python générés par Kiro. (Crédit Photo : IDG)

Développement piloté par les tests

À chaque étape de la construction d'un projet, Kiro écrit des tests unitaires et tente de les valider. Si un test échoue, Kiro décrit ce qui, selon lui, s'est mal passé, tente de le réviser et réessaye. Un premier exemple de test problématique concernait un serveur de prévisualisation pour le générateur de site statique. La façon dont le test a été écrit ne semblait pas tenir compte de la nécessité d'arrêter le serveur après les tests. Après avoir expliqué le problème à Kiro, il a suggéré quelques solutions :

Un test unitaire dans un projet Kiro. (Crédit Photo: IDG)

La première série de correctifs proposée n'a pas résolu le problème. Kiro a alors proposé de réécrire entièrement les tests :

Un autre test unitaire dans un projet Kiro. (Crédit Photo : IDG)

Ces tests échouaient encore, alors Kiro a effectué une sauvegarde et a essayé une autre approche. Cela a nécessité de remplacer tous les appels aux tests défaillants, ce qui a nécessité quelques tentatives supplémentaires (et quelques dépassements de délai Claude). Malheureusement, après un nouveau dépassement de délai, Kiro a recommencé à penser que le test était toujours bloqué (ce qui n'était pas le cas) et il a été nécessaire de recommencer toute l'étape pour éviter d'autres problèmes.

Autre observation, la suite de tests générée couvrait certains aspects très bien, tandis que d'autres ne le couvraient pas du tout. Par exemple, lors des dernières étapes d'intégration, les tests ont échoué car l'exemple de contenu créé pour le générateur de site statique ne comportait aucun modèle. Bien que ce problème ait été soulevé lors d'un test, Kiro n'avait créé aucun des modèles manquants avant la validation du dernier élément de la liste de contrôle. De plus, l'un des exemples de publication, sur les « bonnes pratiques Python », était un non-sens absolu.

Conclusion

À présent, presque tout le monde est conscient des limites et des dangers du code généré par l'IA. La conception itérative de Kiro, basée sur les documents et les directives, tente de résoudre ces deux problèmes, mais même ces solutions ont leurs limites. Les limites de taille du contexte avec l'IA générative, par exemple, posent toujours problème lors de la création de projets comportant plus de quelques fichiers. Par ailleurs, comme les documents de conception sont évalués de la même manière que toute autre instruction envoyée au modèle, leur cohérence n'est pas garantie.

Le code généré par l'IA a également tendance à être verbeux ou sur-conçu, et c'est le cas de celui délivré par Kiro. Le vérificateur d'environnement virtuel généré comptait 230 lignes de Python et incluait divers commutateurs de ligne de commande (dont une option d'exportation vers JSON) pratiques et utiles, mais non explicitement demandés. Une version basique de cet outil ne nécessiterait pas plus de deux douzaines de lignes de code.

L'autre gros problème de Kiro réside dans le fait que toutes ses fonctionnalités utiles proviennent de l'API Claude Sonnet, et que les délais d'expiration constants et la perte de contexte rendent son utilisation difficile. Il vaudra la peine de réévaluer Kiro lorsque sa capacité back-end aura été étendue pour prendre en charge un produit complet, même si on peut imaginer une version concurrente de ce produit qui utilise un modèle local compact pour ceux qui disposent d’une machine suffisamment puissante pour l’exécuter.