Ideia principal

Converter um JSON em CSV, renumerar um índice, copiar um frontmatter, ordenar uma lista: essas operações têm um resultado único, dedutível a partir das suas entradas. Confiadas ao modelo, elas saem pelo canal mais caro — o da geração — e ainda trazem de brinde uma variabilidade de que ninguém precisava. Confiadas a um script, custam zero token e rodam em milissegundos.

No competitor_analyze, duas etapas passadas para Python — a escrita dos frontmatter e o cálculo do delta do índice — tiraram 111 000 unidades do consumo, sem mudar nada nos entregáveis produzidos.

O critério de divisão não é a dificuldade da tarefa, mas a presença de um julgamento: se o resultado se deduz das entradas, não há nada a decidir.

Por que isso importa

Isso dá uma regra de recorte para o desenho de um skill: cada etapa se pergunta o que espera do modelo, e uma etapa que não espera nenhuma arbitragem não precisa ser endereçada a ele.

Aliás, o ganho não é só econômico: o que um script produz é reproduzível, o que um modelo produz só é aproximadamente.

Nuances e limites

Escrever e manter o script tem um custo, invisível num relatório de tokens. Para uma transformação pontual que nunca será repetida, passar pelo modelo continua saindo mais barato que pelo desenvolvimento.

E certas transformações parecem determinísticas até o primeiro dado mal formatado — o modelo absorve a irregularidade onde o script para.

Questões em aberto

• Onde colocar a fronteira quando uma transformação é mecânica em noventa por cento e ambígua no resto?