Le tue skills IA hanno bisogno del controllo di versione

Blog · 6 min di lettura

Prima dei gestori di pacchetti, «usare il codice di qualcun altro» voleva dire copiare un file nel proprio progetto. Funzionava, fino al giorno in cui l'originale riceveva una correzione e la tua copia no, oppure la tua copia era divergita quel tanto che bastava perché reintegrare la correzione non fosse più un copia-e-incolla. Per il codice l'abbiamo risolto decenni fa. Le skills stanno vivendo esattamente lo stesso problema adesso, e per lo più senza la soluzione.

Chiedi in giro e troverai ovunque lo stesso schema: un buon prompt per la revisione delle pull request viene incollato nel progetto A, poi di nuovo nel progetto B perché lì funzionava bene, poi una terza volta con due righe cambiate per un altro linguaggio. Non è più una skill. Sono tre prompt con un antenato comune e nessun modo di capire, sei mesi dopo, quale sia «quello vero» o se le correzioni fatte su A siano mai arrivate a C.

Quanto ti costa davvero il copia-e-incolla

• Le correzioni non si propagano. Find a mistake in the shared logic and you have to remember every place you pasted it, then go fix each one by hand.
• Non c'è un diff. When two copies disagree, you can't tell what changed on purpose versus what someone forgot to update.
• Non c'è un ritorno indietro. A change that turns out to be wrong has already overwritten the version that worked.

Niente di tutto questo è un motivo per smettere di comporre skills a partire da altre: condividere una filosofia di test tra cinque skills specifiche per linguaggio, o una guida di stile tra una dozzina di skills più mirate, è proprio il tipo di riuso che vale la pena. È un motivo perché quei pezzi condivisi ricevano la stessa disciplina delle dipendenze di codice: una versione vera, un vincolo dichiarato e un posto in cui «attuale» significhi qualcosa.

Il modello dei gestori di pacchetti, applicato alle istruzioni

Tratta una skill come un pacchetto anziché come un blocco di testo e l'intera classe di problemi svanisce, esattamente come è successo per il codice:

• Una skill ha una versione. Se la modifichi, la versione cambia con essa.
• Un'altra skill può dipenderne con un vincolo (>=1.0.0), invece di incorporarne il contenuto.
• Pubblicare un aggiornamento della dipendenza aggiorna ogni skill dipendente che la risolve: niente caccia alle copie.
• Una versione può essere deprecata senza rompere ciò che vi resta ancorato.
• Divergere di proposito è un fork, registrato come tale, non un copia-e-incolla senza tracciabilità.

È la stessa forma di npm, pip o cargo: non perché le skills siano codice, ma perché «molte cose dipendono da una cosa condivisa che cambia nel tempo» è lo stesso problema a prescindere da cosa ci sia nel file.

Una skill che esiste solo come testo incollato non ha genealogia. Una skill versionata e componibile ha una storia su cui si può davvero ragionare.

Provalo

Il tutorial Compose and version skills like code mostra come dichiarare una dipendenza, pubblicare un aggiornamento che tutte le skills dipendenti raccolgono, e forkare una skill senza perdere traccia della sua provenienza.