La IA barata e ilimitada se está acabando: toca aprender a orquestar

Hace no tanto, gastarte la cuota de tu suscripción de IA era casi imposible: con OpenAI, hace un tiempo, simplemente no ocurría. Hoy pago suscripciones de 100 y 200 dólares al mes y me encuentro con los rate limits una semana sí y otra también. Y no hace falta un uso superintensivo para llegar a ellos.

No es casualidad. Se están juntando varias cosas: los modelos nuevos cuestan mucho más de servir, la computación se ha convertido en el cuello de botella, los laboratorios necesitan beneficios ahora que miran a bolsa, y los propios modelos, al ser más capaces, trabajan durante más tiempo y queman más tokens por tarea. Todo empuja en la misma dirección: los límites llegan antes.

Y ese cambio en cómo consumimos la IA pide una habilidad nueva que todavía casi nadie está practicando.

Ya no pagamos por respuestas, pagamos por trabajo

Hace un par de años, usar un modelo era esto:

Pregunta → respuesta.

Ahora, cuando le pido a un agente que implemente una feature, lo que pasa por detrás se parece más a esto:

Objetivo → planificación → leer archivos → ejecutar → fallar → corregir → más herramientas → verificar → resultado.

Hace un año, una tarea de agente que durase 20 minutos me parecía una barbaridad. Hoy lanzo loops de horas: le defino un objetivo y el agente lo persigue sin descanso, planificando, equivocándose, corrigiéndose y verificando hasta cumplirlo. Y ojo, no lo digo como crítica: si quiero resultados de verdad, el modelo necesita tiempo y pasos.

Pero eso tiene una consecuencia directa: la unidad de consumo ya no es "una conversación". Es una sesión de trabajo. Y una sesión de trabajo quema muchísimo más compute que una pregunta.

Y la tendencia va a más: cada nueva generación de modelos piensa durante más tiempo, le da más vueltas a las cosas y hace más por su cuenta. Más consumo, sí. Pero es que la salida, habitualmente, es mucho más rica.

Las suscripciones estaban escondiendo el coste real

Durante un tiempo, los 20, 100 o 200 dólares al mes de las suscripciones han estado subvencionando un uso cuyo coste real por API era bastante mayor. Las empresas absorbían la diferencia para captar usuarios y crear hábito.

Esa etapa se está terminando, y es pura aritmética: los modelos frontier son caros de servir, el uso agentic consume muchísimo, y los planes ilimitados aguantan mal a usuarios que lanzan sesiones largas todos los días. De hecho, el mercado ya se está moviendo a "cuota incluida + pago por uso". Y no descarto el siguiente paso: modelos que solo se puedan usar pagando por uso, fuera de cualquier suscripción.

Y aquí está lo que me ronda de verdad la cabeza: la inteligencia de primera se está convirtiendo en un recurso que se paga por consumo, como la luz. Las empresas grandes la pagarán sin pestañear. La duda es qué pasa con el freelancer, con el indie hacker, con el equipo pequeño, cuando usar lo mejor cueste lo que de verdad cuesta.

No creo que el acceso desaparezca. Pero sí puede cambiar mucho la diferencia entre uso ocasional y uso intensivo. Y esa diferencia es productividad.

La respuesta no es pagar más

Aquí está el matiz que me parece importante: no todas las tareas necesitan un modelo frontier.

Muchas cosas que hoy le pido al modelo más caro las puede hacer un modelo pequeño, uno local, uno barato por API... o directamente un script. Tests, linters, herramientas deterministas, pipelines bien montados. No es glamuroso, pero funciona.

La pregunta deja de ser "¿qué modelo es el mejor?" y pasa a ser "¿qué necesita esta tarea concreta?". Eso convierte la preocupación por el precio en una estrategia.

Cuanto peor el modelo, mejor tiene que ser el sistema

Llevo un tiempo dándole vueltas a una idea que resume todo esto:

Cuando baja la inteligencia bruta del modelo, sube la importancia del sistema que lo rodea.

Con un modelo frontier puedes pedir algo impreciso y probablemente salga algo decente. Con un modelo pequeño, no: necesitas mejor contexto, mejores instrucciones, ejemplos, tests que verifiquen el resultado, límites claros, una forma de escalar a un modelo mayor cuando haga falta.

A esa capa que rodea al modelo la llamo, todavía de forma un poco difusa (lo reconozco), un harness: las plantillas, el contexto del repo, las herramientas que le dejo usar, los scripts de verificación, los prompts reutilizables, las reglas de cuándo usar qué modelo. Un buen harness multiplica el valor de los modelos baratos y reduce la dependencia de los caros.

Por eso los modelos locales han pasado, al menos para mí, de curiosidad a algo más serio: no van a sustituir al frontier, pero pueden absorber una parte grande del trabajo repetible y verificable. Eso es independencia operativa.

La habilidad que viene

Si tuviera que apostar (y aviso de que mis apuestas sobre IA tienen un historial regulero) diría que la siguiente habilidad valiosa no es prompting, ni siquiera "usar agentes". Es orquestar: saber descomponer el trabajo, darle a cada tarea el modelo justo, poner verificación donde hace falta, y gastar el modelo caro solo donde de verdad marca la diferencia.

De hecho, esto ya tiene nombre ahí fuera: harness engineering. Primero fue el prompt engineering, luego el context engineering, y ahora toca diseñar el arnés entero: el sistema que envuelve al modelo y decide qué ve, qué puede hacer y cómo se verifica lo que produce.

Yo no puedo controlar el precio de los modelos frontier. Lo que sí puedo controlar es cómo diseño mis workflows para depender menos de ellos. En eso estoy ahora mismo: aprendiendo a montar mi propia capa de trabajo con IA, equivocándome bastante por el camino, y anotándolo aquí.

La frase con la que me quedo, por si solo te llevas una:

La próxima brecha no será entre quienes tienen acceso a IA y quienes no. Será entre quienes saben orquestarla y quienes solo saben consumirla.

No sé si llegará en uno, dos o cinco años. Pero por si acaso, yo ya estoy practicando.