Idea principal

Convertir un JSON en CSV, renumerar un índice, copiar un frontmatter, ordenar una lista: estas operaciones tienen un resultado único, deducible de sus entradas. Encargadas al modelo, salen por el canal más caro — el de la generación — y encima aportan una variabilidad que nadie necesitaba. Encargadas a un script, cuestan cero tokens y se ejecutan en milisegundos.

En competitor_analyze, dos pasos trasladados a Python — la escritura de los frontmatter y el cálculo del delta del índice — quitaron 111 000 unidades del consumo, sin cambiar nada en los entregables producidos.

El criterio de reparto no es la dificultad de la tarea sino la presencia de un juicio: si el resultado se deduce de las entradas, no hay nada que decidir.

Por qué es importante

Esto da una regla de corte para el diseño de un skill: cada paso se pregunta qué espera del modelo, y un paso que no espera ningún arbitraje no tiene por qué dirigirse a él.

La ganancia, por lo demás, no es solo económica: lo que produce un script es reproducible, lo que produce un modelo solo lo es de forma aproximada.

Matices y límites

Escribir y mantener el script tiene un coste, invisible en un informe de tokens. Para una transformación puntual que nunca se volverá a ejecutar, pasar por el modelo sigue saliendo más barato que pasar por el desarrollo.

Y algunas transformaciones parecen deterministas hasta el primer dato mal formado — el modelo absorbe la irregularidad allí donde el script se detiene.

Preguntas abiertas

• ¿Dónde situar la frontera cuando una transformación es mecánica en un noventa por ciento y ambigua en el resto?