//El valor del token
El fin de la IA subvencionada y el pago por token
El foco del desarrollo con IA estaba en garantizar la corrección y calidad de lo que generaba. Su rendimiento y rentabilidad no se cuestionaban. Incluso se temía como una amenaza al mercado laboral. El fin de las tarifas planas subvencionadas pone sobre la mesa la cuestión del coste-beneficio.|Éramos ricos y no lo sabíamos, o quizá no lo queríamos saber. El caso es que, desde que la IA irrumpió en nuestro sector hace la friolera de 5 años, nunca se planteó su coste como una debilidad. Nos preocupaban las alucinaciones, la falta de control o incluso la amenaza al mercado laboral.
Pero era porque vivíamos en un mundo de Narnia subvencionado por los inversores, que nos ofrecían servicios con suscripción de tarifa plana, que con el tiempo y la mejora de sus propios modelos hizo que los consumos se disparasen. Eso, unido a la coyuntura internacional, el precio de las memorias y la energía, ha hecho que los proveedores hayan decidido repercutir esos costes sobre los usuarios. Y nos hemos dado cuenta de que ahora somos clientes de un producto caro.
Así que toca echar cuentas y apretarse el cinturón. Porque no se trata de no usar una tecnología que nos hace mucho más productivos, y que, si renunciamos a ella, nos veremos fuera del mercado en mucho menos tiempo del que la IA lleva con nosotros.
Coste cero
Para ahorrar, lo mejor es no gastar. Apuntadme para el Nobel de Economía. Con esta sabiduría popular podemos identificar qué procesos debemos seguir haciendo manualmente o dejando de hacer con IA.
-
Procesos deterministas con herramientas (por cierto, cada vez hay más y mejores) para análisis de código. Hablo de formateadores, linters, revisiones de seguridad, mutación de pruebas… todo esto puede y debe lanzarse en procesos out of the loop.
-
Comodidades del primer mundo que podemos recuperar como habilidades cotidianas antes de que se nos evaporen. Me refiero al trabajo con git y la generación de mensajes de commit. Recuerda que, para detallar un buen mensaje de commit, el modelo debe leer el diff completo, y eso son tokens.
-
Boilerplates e instalación de dependencias. Las puedes pedir en el chat… pero también las puedes instalar desde la terminal. Este es otro caso más del pecado capital de la pereza aprendida en estos últimos años, de la que me declaro culpable.
-
Compactaciones. Es sabido que la ventana de contexto de los modelos es algo crítico, sobre todo para tareas largas que incluyan varios loops entre humano, agente y modelo. El caso es que, independientemente de su tamaño, los modelos no aprovechan igual cada token de espacio de dicha ventana. Llega un momento en que se vuelven literalmente torpes y perezosos, empezando a dilapidar tokens. Para volver a su zona inteligente nos ofrecen soluciones de compactación que resumen la conversación de la sesión. Pero esto conlleva dos peligros. El evidente es que se pueden perder detalles que a la larga resulten en un mayor gasto. Y el segundo es que el propio proceso de compactación consume una gran cantidad de tokens. Es como pagar a un fisio y a un psicólogo para devolverte la plenitud de las mañanas a última hora de la tarde. Mejor usar sesiones cortas o delegar entre agentes.
Uso de modelos baratos
No todo lo que hacemos con la IA requiere el mismo grado de esfuerzo. Y este es un concepto que debemos tener en cuenta. El token no cuesta lo mismo en todos los casos. Cada modelo lo cobra en función de los recursos que consume para procesar la entrada y producir la salida. De esta forma, verás que hay enormes diferencias en el precio por token que te factura un mismo proveedor según el modelo o el nivel de razonamiento requerido. Ojo, que en algunos casos un modelo más inteligente puede producir una mejor salida consumiendo menos tokens y, por tanto, resultar más barato, aunque su precio unitario sea mayor.
-
La propia codificación puede caer en esta franja de uso. Dirás: ¿pero cómo dices eso? Si programar es justamente lo que hacemos y lo que más cuesta. Déjame explicar aquello que ya nos decían en la universidad en el milenio pasado. Si analizas bien un problema y diseñas completamente su solución, la programación es prácticamente una traducción rutinaria a un lenguaje compilable o interpretable. Y hoy estamos cerca de ese Nirvana. Buenas especificaciones, reglas y planes hacen que codificar sea la tarea que menos esfuerzo requiere a un modelo. Y de las que más tokens consume.
-
Si, por cualquier razón, decides no hacerme caso en los consejos de la sección de Coste cero, al menos haz esas cosicas con modelos de mínimo esfuerzo, que habitualmente van en la capa gratuita de cualquier suscripción.
Inversiones rentables
Como la inteligencia artificial afecta a todo trabajo intelectual, tenemos tareas y más tareas de todo tipo y condición. Algunas requieren un nivel de esfuerzo alto. Todo lo que tenga que ver con análisis, bien sea de documentación, logs o código, es muy costoso. También lo es la planificación detallada y la elección de herramientas y arquitecturas. Lo bueno es que algunas de esas tareas no son para nada rutinarias.
-
Puede que tengas que hacer una costosa exploración de un código legacy, pero tampoco la vas a repetir todos los días. Solamente debes guardar el resultado de forma reaprovechable para no volver a invertir en ella.
-
La planificación detallada de una intervención requiere esfuerzo y gran consumo de tokens, pero, a cambio, reduce el coste del desarrollo y mejora la calidad del código. Esto hace que el coste completo de desarrollo verificado disminuya.
Reduce el consumo de tokens
En los anteriores puntos he hablado del precio por token. Pero claro, cuantos menos dichosos tokens consumas, mejor. Y eso nos lleva al siguiente conflicto conceptual: ¿qué demonios es un token?
Pues es la unidad mínima de medida de la entrada o salida de un modelo. Equivale a una palabra corta, o a un trozo de una larga. Pero también a un símbolo, un carácter, un byte… todo depende del modelo y del contexto. Y, por si fuera poco, depende también del idioma humano que usemos. Sí, quizás sea por sesgo o por su propia simplicidad, pero el inglés es el idioma preferido por los modelos de lenguaje.
Y estamos hablando de texto plano, o con marcas. Si nos vamos a imágenes o a PDFs la cosa cambia. A peor. Esta es una de las razones por las que el markdown se ha erigido como el formato preferido para maximizar la relación señal/ruido.
Pero ¿en qué se gastan los tokens? Intuitivamente pensamos que el tamaño de la petición y de la respuesta es el meollo del gasto. Pero no. En realidad, a esto debes sumar todo lo que el arnés (sí, lo que llamábamos agente hasta hace nada) envía por ti. Las reglas generales tipo AGENTS.md se incorporan a cada sesión. La lista de herramientas y skills para que el modelo escoja también se le envían sin preguntar. Y, por supuesto, los ficheros que acompañen al prompt como contexto.
¿Y eso es todo? Pues no. También hay que tener en cuenta la conversación interna entre agente y modelo. Una petición humana requiere de numerosas idas y venidas con sus correspondientes costes. Y en una sesión, lo que llamaríamos un chat, se producen numerosas interacciones entre el usuario y el modelo que necesitan un histórico para que la conversación tenga sentido. Así que multiplica.
Por todo ello, te sugiero que recortes lo que está en tu mano. El tamaño y número de skills. Ajusta el conjunto de tools disponibles para cada tarea. Evita si puedes los MCPs. Y procura detallar lo mejor posible tus peticiones, de forma que no sea necesario corregir o completar en futuras interacciones.
Seguir una metodología que te permita resolver tareas por fases o que ataque problemas grandes dividiéndolos en otros más manejables siempre es una buena idea. Cuanto más sencilla y de menor contexto es la tarea, más acierta por trabajar en su zona de altas capacidades. Cuanto menos se equivoque, menos gastamos.
La opción local
Hasta hace poco lo de tener una IA en local quedaba reservado para entusiastas del metal y para organizaciones muy reguladas o preocupadas por la confidencialidad de su código. Pero ni los modelos instalables eran muy buenos ni los equipos muy potentes. Y todo esto en un contexto de modelos remotos baratos, no te urgía a comprar versus alquilar.
Pero todo esto está cambiando. Los modelos de pesos abiertos van unos meses por detrás de los mejores modelos frontera. Pero eso, a día de hoy, ya los hace muy capaces. Los equipos con GPUs potentes y, sobre todo, con memoria compartida facilitan su ejecución local con caudales de respuesta aceptables.
Solo queda echar cuentas. Porque lo que no ha ocurrido es que esos equipos potentes se abaraten. Al contrario, el mercado de equipos para devs está por encima del luxury que representaban los gamers y diseñadores de vídeo y 3D. Seguro que aparecen ejecutadores más sencillos y modelos optimizados para el gran público. Pero, si quieres mirar de cerca la frontera, tienes que sacar la billetera.
Conclusión
Esta revolución industrial que estamos viviendo en tiempo real es astronómicamente veloz. Los paradigmas cambian de un mes para otro. Lo que ayer era barato hoy es prohibitivo y tienes que medir y reducir consumos para mantenerte en el juego. Pero es lo que nos ha tocado vivir, y más vale aceptarlo y adaptarse.
He tratado de incluir todas estas consideraciones en el catálogo de skills de AIDDbot y en mis últimos cursos para AI Native Engineers.