Enseigner de nouveaux trucs à Kiro grâce au steering d'agent et au MCP

Au cours des trois dernières années, j'ai aidé des centaines de clients à adopter des outils d'IA pour le développement logiciel. Bon nombre de ces clients ont développé leurs propres bibliothèques, outils et même des langages spécifiques à un domaine (DSL). Qu'il s'agisse d'un langage d'automatisation de flux de travail, d'une syntaxe de configuration ou d'un moteur de règles, ces personnalisations sont l'épine dorsale des opérations commerciales. Mais que se passe-t-il lorsque vous voulez que votre assistant de programmation avec l'IA comprenne et travaille avec ces bibliothèques propriétaires?

Dans cet article, je vais explorer comment enseigner à Kiro, un agent d'IA et un environnement de développement, à comprendre une bibliothèque appelée MathJSON. Bien que MathJSON soit une bibliothèque fictive créée pour cette démonstration, elle sert de substitut aux langages de flux de travail, aux systèmes de configuration et aux notations spécialisées que les entreprises utilisent quotidiennement. Tout au long de l'article, je vais discuter du steering et du Model Context Protocol (MCP), et de la façon d'utiliser ces deux éléments ensemble pour enseigner de nouvelles compétences à Kiro.

Pour cet article, j'utiliserai MathJSON - un langage d'expression mathématique basé sur JSON qui utilise une terminologie mathématique appropriée. Notez que MathJSON a été créé pour cet article et je ne recommande pas de l'utiliser dans des applications réelles. Voici ce qui le rend intéressant :

• Syntaxe basée sur JSON pour des expressions mathématiques structurées
• Terminologie mathématique appropriée (addende, diminuende, multiplicande, etc.)
• Expressions imbriquées pour des calculs complexes
• Riche bibliothèque de fonctions (trigonométrie, logarithmes, constantes)
• Extension de fichier : .math

Cet exemple calcule l'aire d'un cercle pour un rayon donné passé en tant que variable d'environnement : pi * radius^2

Le steering donne à Kiro une connaissance persistante de votre projet grâce à des fichiers markdown. Ces fichiers sont stockés dans .kiro/steering/ et fournissent le contexte et les instructions pour toutes les interactions au sein d'un espace de travail. Les fichiers de steering peuvent inclure des normes de programmation, la structure du projet, et bien plus encore.

Votre première idée pourrait être d'ajouter simplement la documentation de MathJSON au dossier de steering. C'est exactement ce que j'ai fait, en ajoutant le fichier function_reference.md à mon dossier de steering. C'est un bon début, mais il y a quelques problèmes. Premièrement, la documentation est écrite pour un humain. Par conséquent, elle est verbeuse et souvent répétitive. Deuxièmement, elle manque de bonnes pratiques précises pour Kiro à suivre. Troisièmement, la documentation copiée dans mon dossier de projet sera inévitablement dépassée. Examinons chacun de ces problèmes et la façon de les résoudre.

Le premier problème que nous voulons surmonter est la verbosité de la documentation. Évidemment, je présume que vous avez une bonne documentation. Si ce n'est pas le cas, Kiro peut vous aider à la générer. Souvent, la documentation créée pour les humains est trop verbeuse pour être incluse dans les fichiers de steering. MathJSON est un projet trivial que j'ai créé pour cet article, et pourtant il compte plus de 3 500 lignes de documentation réparties dans une demi-douzaine de fichiers markdown. C'est trop d'information à ajouter à chaque conversation que j'ai avec Kiro.

Heureusement, Kiro peut peaufiner vos fichiers de steering pour vous. Ouvrez simplement votre fichier de steering dans Kiro et sélectionnez le bouton Refine. Kiro lira le fichier et l'optimisera pour vous, comme le montre l'image suivante.

Examinons l'un des changements apportés par Kiro. Dans la documentation originale, l'addition est décrite comme suit.

Kiro a peaufiné cela et l'a remplacé par une seule ligne. Notez que des détails comme les expressions imbriquées ne sont couverts qu'une seule fois dans le fichier peaufiné plutôt que d'être répétés dans les exemples pour chaque opération. Par conséquent, il n'est pas nécessaire de le répéter ici.

Dans l'ensemble, c'est un excellent début. Le fichier de steering compte maintenant 102 lignes, contre 3 500 auparavant. Si vous ne faites rien d'autre, utilisez l'option de peaufinage pour optimiser vos fichiers de steering. Cependant, nous pouvons continuer à l'améliorer.

Le prochain problème que nous voulons surmonter est la spécificité de la documentation. La documentation utilisateur tend à être générale. Elle se concentre sur la couverture de toutes les façons dont vous pouvez utiliser la bibliothèque ou le langage. Cependant, un fichier de steering devrait être tranché. Plutôt que de dire à Kiro comment il pourrait utiliser MathJSON, je veux dire à Kiro exactement comment il devrait utiliser MathJSON.

Kiro a commencé à définir des bonnes pratiques lorsqu'il a peaufiné la documentation pour moi dans la section précédente. Cependant, je vais ajouter une règle supplémentaire. Plus précisément, je veux que Kiro valide et teste tout le code qu'il écrit. Alors, je vais ajouter quelques nouvelles bonnes pratiques.

Notez que le fichier de steering inclut déjà des instructions pour l'utilisation de l'outil de ligne de commande. Je ne le répète pas, mais j'indique à Kiro quand l'utiliser. Le fichier de steering commence à prendre forme, mais comment le tenir à jour dans le temps?

Le premier problème que nous voulons surmonter est la fraîcheur de la documentation. Avec le temps, MathJSON va évoluer et changer. Par exemple, j'ai récemment ajouté la prise en charge de la trigonométrie. Je préférerais que Kiro ait accès à la documentation originale plutôt qu'à une copie que je dois entretenir dans les fichiers de steering. Voici le Model Context Protocol (MCP).

Pour MathJSON, le dépôt GitHub est la source de vérité. Par conséquent, j'ai configuré un serveur MCP pour GitHub. Maintenant, Kiro peut lire la documentation la plus récente lorsqu'il en a besoin. Notez que GitHub n'est qu'un exemple. Si vous conservez votre documentation dans GitLab, Confluence, etc., il y a probablement un serveur MCP pour cela aussi.

Vous pourriez être tenté de supprimer le fichier de steering maintenant que Kiro a un accès direct à la documentation dans GitHub. Cependant, en pratique, j'ai constaté que j'ai besoin des deux. Imaginez que j'ai demandé à Kiro de create a function to add two numbers. Il n'y a rien dans cette requête pour indiquer que je veux que Kiro utilise MathJSON, ni que la documentation de MathJSON est stockée dans GitHub. Kiro est susceptible d'écrire la fonction en Python plutôt qu'en MathJSON. Le fichier de steering aide Kiro à faire le lien.

Dans l'exemple suivant, vous pouvez voir que j'ai mis à jour mon fichier de steering pour indiquer à Kiro que nous utilisons MathJSON et que la documentation est disponible dans GitHub. De plus, j'ai indiqué à Kiro d'utiliser le serveur MCP GitHub pour accéder à la documentation.

Notez que je fournis des références à des fichiers précis. C'est une optimisation de performance. Si j'avais simplement fourni une référence au dépôt, Kiro passerait trop de temps à explorer le dépôt et à lire les fichiers. Je tiens également à noter que GitHub n'est pas un dépôt de documentation idéal. Kiro bénéficierait de découper la documentation en sujets et de stocker ces morceaux dans une base de données vectorielle. Cela permettrait à Kiro d'accéder uniquement à la portion de la documentation dont il a besoin. Cependant, cet article devient un peu long, donc je garderai ce sujet pour un autre article.

À ce stade, mon fichier de steering sert principalement de pointeur vers la documentation. Cependant, j'ai encore une partie de la documentation de haut niveau directement dans mon fichier de steering, ainsi que la section des bonnes pratiques. Plus important encore, je demande à Kiro de mettre à jour le fichier de steering périodiquement. Chaque fois que Kiro fait une erreur, ou rencontre un problème, je demande à Kiro d'apporter des mises à jour pendant que le problème est encore dans le contexte.

Dans l'exemple suivant, vous pouvez voir Kiro résoudre un problème de formatage de variable d'environnement. Lorsque le linter identifie un problème, Kiro utilise le serveur MCP pour lire la documentation et corriger l'erreur.

Au fur et à mesure que Kiro résout ces problèmes, il apprend de nouvelles compétences. Cependant, ces nouvelles connaissances ne sont conservées que pour la durée de la conversation. Par conséquent, Kiro est susceptible de commettre la même erreur dans une future session. C'est une excellente occasion de demander à Kiro de mettre à jour les fichiers de steering, comme le montre l'image suivante.

Après avoir appris la syntaxe de MathJSON pour les variables d'environnement, Kiro a ajouté la section suivante au fichier de steering.

Au fil du temps, Kiro continuera à peaufiner les directives et à élargir sa connaissance de mon DSL et à améliorer le code qu'il écrit.

Après quelques itérations, Kiro est prêt à rédiger du MathJSON. Je vais demander à Kiro de créer une fonction pour modéliser un surpaiement hypothécaire.

Kiro est maintenant prêt à générer du MathJSON pour moi. Voici le MathJSON qu'il a généré pour le calcul du surpaiement hypothécaire.

Et bien sûr, Kiro suivra les bonnes pratiques définies dans le fichier de steering pour vérifier et tester le code qu'il a écrit, validant que le code est syntaxiquement correct.

Enseigner à Kiro à comprendre et à travailler avec des bibliothèques personnalisées comme MathJSON démontre la puissance de la combinaison des fichiers de steering avec le Model Context Protocol. En suivant l'approche décrite dans cet article - peaufiner la documentation, établir des bonnes pratiques claires et exploiter le MCP pour des connaissances à jour - vous pouvez enseigner à Kiro à travailler avec vos bibliothèques, langages et outils personnalisés. Commencez avec Kiro.