Tus skills de IA necesitan control de versiones

Blog · 6 min de lectura

Antes de los gestores de paquetes, «usar el código de otra persona» significaba copiar un archivo a tu proyecto. Funcionaba, hasta que el archivo original recibía un arreglo y el tuyo no, o tu copia había divergido lo justo para que reintegrar el arreglo ya no fuese un copiar y pegar. Esto lo resolvimos hace décadas para el código. Los skills están viviendo exactamente el mismo problema ahora, y en general sin la solución.

Pregunta por ahí y encontrarás el mismo patrón en todas partes: un buen prompt para revisar pull requests se pega en el proyecto A, luego otra vez en el B porque allí también funcionaba bien, y una tercera vez con dos líneas cambiadas para otro lenguaje. Eso ya no es un skill. Son tres prompts con un antepasado común y sin forma de saber, seis meses después, cuál es «el de verdad» ni si los arreglos hechos en A llegaron alguna vez a C.

Lo que te cuesta realmente copiar y pegar

• Los arreglos no se propagan. Find a mistake in the shared logic and you have to remember every place you pasted it, then go fix each one by hand.
• No hay diff. When two copies disagree, you can't tell what changed on purpose versus what someone forgot to update.
• No hay vuelta atrás. A change that turns out to be wrong has already overwritten the version that worked.

Nada de esto es motivo para dejar de componer skills a partir de otras: compartir una filosofía de pruebas entre cinco skills específicos de cada lenguaje, o una guía de estilo entre una docena de skills más concretas, es justo el tipo de reutilización que merece la pena. Es motivo para que esas piezas compartidas reciban la misma disciplina que las dependencias de código: una versión real, una restricción declarada y un sitio donde «actual» signifique algo.

El modelo de los gestores de paquetes, aplicado a las instrucciones

Trata un skill como un paquete en lugar de como un bloque de texto y toda esta clase de problemas desaparece igual que desapareció para el código:

• Un skill tiene versión. Si lo cambias, la versión cambia con él.
• Otro skill puede depender de él con una restricción (>=1.0.0), en vez de incrustar su contenido.
• Publicar una actualización de la dependencia actualiza a todos los skills que la resuelven: nada de buscar copias.
• Una versión puede marcarse obsoleta sin romper lo que siga fijado a ella.
• Divergir a propósito es un fork, registrado como tal, y no un copiar y pegar sin rastro.

Es la misma forma que npm, pip o cargo: no porque los skills sean código, sino porque «muchas cosas dependen de una cosa compartida que cambia con el tiempo» es el mismo problema sea cual sea el contenido del archivo.

Un skill que solo existe como texto pegado no tiene linaje. Un skill versionado y componible tiene un historial sobre el que de verdad se puede razonar.

Pruébalo

El tutorial Compose and version skills like code explica cómo declarar una dependencia, publicar una actualización que todos los skills dependientes recogen, y bifurcar un skill sin perder de vista de dónde venía.