Idea principale

Convertire un JSON in CSV, rinumerare un indice, ricopiare un frontmatter, ordinare un elenco: sono operazioni con un risultato unico, deducibile dai loro input. Affidate al modello, escono dal canale più caro — quello della generazione — e in più introducono una variabilità di cui nessuno aveva bisogno. Affidate a uno script, costano zero token e girano in pochi millisecondi.

Su competitor_analyze, due fasi spostate su Python — la scrittura dei frontmatter e il calcolo del delta dell'indice — hanno tolto 111 000 unità dal consumo, senza cambiare nulla nei risultati prodotti.

Il criterio di ripartizione non è la difficoltà del compito ma la presenza di un giudizio: se il risultato si deduce dagli input, non c'è nulla da far decidere.

Perché è importante

Offre una regola di scomposizione per progettare uno skill: ogni fase si chiede che cosa si aspetta dal modello, e una fase che non richiede alcuna decisione non ha motivo di essergli affidata.

Il guadagno, del resto, non è solo economico: ciò che produce uno script è riproducibile, ciò che produce un modello lo è solo in modo approssimativo.

Sfumature e limiti

Scrivere e mantenere lo script ha un costo, invisibile in un report di token. Per una trasformazione occasionale che non verrà mai rieseguita, passare dal modello resta meno caro che sviluppare.

E certe trasformazioni sembrano deterministiche fino al primo dato malformato — il modello assorbe l'irregolarità là dove lo script si ferma.

Domande aperte

• Chi si accorge che un giudizio si è infilato in una fase classificata come meccanica, visto che il risultato ne conserva la forma?