Vos skills IA ont besoin d'un contrôle de version

Blog · 6 min de lecture

Avant les gestionnaires de paquets, « utiliser le code de quelqu'un d'autre » signifiait copier un fichier dans son projet. Cela fonctionnait, jusqu'au jour où l'original recevait un correctif que votre copie n'avait pas, ou bien votre copie avait suffisamment divergé pour que réintégrer le correctif ne soit plus un simple copier-coller. Nous avons résolu cela il y a des décennies pour le code. Les skills vivent exactement le même problème aujourd'hui, et le plus souvent sans la solution.

Renseignez-vous autour de vous et vous retrouverez partout le même schéma : un bon prompt de revue de pull requests est collé dans le projet A, puis dans le projet B parce qu'il y fonctionnait bien aussi, puis une troisième fois avec deux lignes modifiées pour un autre langage. Ce n'est plus un skill. Ce sont trois prompts au même ancêtre, sans moyen de savoir, six mois plus tard, lequel est « le vrai » ni si les correctifs apportés à A ont jamais atteint C.

Ce que le copier-coller vous coûte réellement

• Les correctifs ne se propagent pas. Find a mistake in the shared logic and you have to remember every place you pasted it, then go fix each one by hand.
• Il n'y a pas de diff. When two copies disagree, you can't tell what changed on purpose versus what someone forgot to update.
• Il n'y a pas de retour arrière. A change that turns out to be wrong has already overwritten the version that worked.

Rien de tout cela n'est une raison de cesser de composer des skills à partir d'autres skills — partager une philosophie de test entre cinq skills propres à un langage, ou une charte maison entre une douzaine de skills plus spécifiques, est exactement le genre de réutilisation qui vaut la peine. C'est une raison pour que ces pièces partagées reçoivent la même rigueur que les dépendances de code : une vraie version, une contrainte déclarée, et un endroit où « la version courante » veut dire quelque chose.

Le modèle des gestionnaires de paquets, appliqué aux instructions

Traitez un skill comme un paquet plutôt que comme un bloc de texte, et toute cette classe de problèmes disparaît, exactement comme pour le code :

• Un skill a une version. Modifiez-le, et la version change avec lui.
• Un autre skill peut en dépendre avec une contrainte (>=1.0.0), au lieu d'en intégrer le contenu.
• Publier une mise à jour de la dépendance met à jour toutes les skills qui la résolvent — plus besoin de traquer les copies.
• Une version peut être dépréciée sans casser ce qui y reste épinglé.
• Diverger volontairement devient un fork, enregistré comme tel, et non un copier-coller sans traçabilité.

C'est la même forme que npm, pip ou cargo — non parce que les skills seraient du code, mais parce que « beaucoup de choses dépendent d'une chose partagée qui évolue » est le même problème quel que soit le contenu du fichier.

Un skill qui n'existe que sous forme de texte collé n'a pas de filiation. Un skill versionné et composable a un historique sur lequel on peut vraiment raisonner.

Essayez

Le tutoriel Compose and version skills like code montre comment déclarer une dépendance, publier une mise à jour que toutes les skills dépendants récupèrent, et forker un skill sans perdre la trace de son origine.