Hay una idea que llevamos años dando por hecha: la IA va a hacer que programar sea cada vez más barato.
Yo también lo creo. Pero después del último OpenAI DevDay me quedé pensando en una cifra que, para mí, cuenta una historia distinta: 500 dólares al mes.
Entre anuncios de modelos, Codex y más velocidad, OpenAI llevó su oferta profesional hasta ese nivel para quienes quieren trabajar con mayores límites y capacidades. Mi primera reacción fue bastante simple: esto empieza a ser mucho dinero por una herramienta de programación.
La segunda fue más incómoda: ¿y si 500 dólares no son caros?
¿Y si estamos mirando mal el precio? ¿Y si programar se está abaratando al mismo tiempo que trabajar permanentemente con la mejor inteligencia disponible se convierte en un lujo profesional?
La contradicción solo es aparente
Los datos apuntan en las dos direcciones a la vez. Stanford mostró que obtener un nivel de rendimiento comparable al de GPT-3.5 se abarató de forma brutal entre 2022 y 2024. Los modelos pequeños también son cada vez más capaces.
Por eso no creo que la IA se esté encareciendo. Creo algo más concreto: se está encareciendo la última milla.
Claude Pro empezó en 2023 en 20 dólares al mes. Después llegaron niveles de uso intensivo de 100 y 200 dólares. Ahora OpenAI ha llevado la parte alta hasta 500 dólares al mes.
No es una comparación perfecta entre productos ni proveedores. Sí es una señal: existe un mercado dispuesto a pagar cada vez más por no quedarse un escalón por debajo de la frontera.
Entonces entendí por qué puede funcionar
Hace unos años me habría parecido absurdo pagar 500 euros al mes por una herramienta para escribir código. Hoy trabajo con agentes de programación y la pregunta ya no me parece esa.
La pregunta es: ¿cuánto cuesta no tenerla?
Si una tarea que ocupaba dos días termina en dos horas, discutir unos cientos de euros de suscripción empieza a perder sentido. Si un desarrollador puede producir varias veces más, el coste relevante deja de ser el token y pasa a ser el resultado.
Y ahí está el incentivo para que la frontera sea cara. El mejor modelo no necesita ser barato si consigue devolver mucho más valor del que cuesta.
Por eso creo que veremos planes todavía más caros. No porque la inteligencia sea más escasa, sino porque la ventaja de tener la mejor inteligencia disponible puede valer cada vez más.
Mientras tanto, por detrás ocurre algo todavía más interesante
La frontera corre. Pero todo lo que deja atrás se abarata.
Los modelos abiertos avanzan rápido. Familias como Qwen muestran capacidades de programación, razonamiento y uso de herramientas que hace poco asociábamos a sistemas mucho más grandes y caros.
No necesito que un modelo abierto de hoy sea idéntico al mejor Claude u OpenAI. Esa discusión me parece secundaria.
La pregunta que me interesa es otra: ¿cuánto tarda lo extraordinario en convertirse en suficiente?
Imaginemos que hoy la frontera está en 100 y un modelo abierto está en 75. Dentro de seis meses la frontera puede estar en 140 y el abierto en 100. El abierto seguirá perdiendo contra lo mejor del momento. Pero habrá alcanzado exactamente la capacidad que hoy nos parece espectacular.
Por eso no me sorprendería que dentro de unos meses podamos ejecutar, por muy poco dinero o incluso en infraestructura propia, una calidad de programación parecida a la que hoy pagamos como premium. Es una predicción, no una certeza. Pero es una posibilidad demasiado importante como para ignorarla.
Dos maneras de programar
Creo que ahí se separarán dos mundos.
Uno será el frontier coding: el mejor modelo del momento, contextos enormes, agentes trabajando durante horas, máxima velocidad, muchos tokens y capacidad para atacar los problemas realmente difíciles. Será caro. Y muchas veces compensará pagarlo.
El otro será el desarrollo convertido en commodity: modelos abiertos, modelos locales, sistemas especializados y una inferencia cada vez más barata.
Porque quizá utilizar el modelo más inteligente del planeta para generar un CRUD, actualizar documentación o escribir un test termine pareciéndonos tan absurdo como usar un Ferrari para repartir paquetes.
La pregunta dejará de ser «¿cuál es el mejor modelo para programar?» y será mucho más útil: ¿qué parte de este trabajo necesita realmente la frontera?
Aquí es donde me preocupa equivocarme
Ante un cambio así es fácil cometer uno de dos errores.
El primero sería lanzarnos ahora a construir nuestra propia alternativa a Claude Code. Probablemente quemaríamos tiempo y dinero intentando anticipar un escenario que todavía no ha llegado.
El segundo sería más cómodo: no hacer nada. Dar por hecho que Claude Code, Codex o la herramienta que hoy nos funciona seguirá siendo siempre nuestra forma de programar.
No me convence ninguno.
No quiero construir hoy para un futuro incierto. Pero tampoco quiero tomar decisiones que nos impidan llegar a él.
El activo no es el modelo
Cuanto más utilizamos agentes de programación, más claro veo que alrededor del modelo estamos construyendo algo quizá más valioso que el propio modelo.
Le enseñamos cómo están organizados nuestros repositorios. Cómo ejecutamos tests. Cómo desplegamos. Cómo accede a una base de datos. Qué convenciones respetamos. Qué puede tocar y qué no. Cómo documenta. Cuándo una tarea está terminada. Cuándo debe pedir ayuda.
Todo eso es el arnés.
Y el arnés sí puede pertenecernos.
Ahí aparece el escenario más extremo que contemplo: que una empresa de desarrollo termine teniendo su propio entorno de programación agéntica. No su propio LLM. Su propio agente.
Un agente nuestro, muchos cerebros
Imagino un agente que conozca cómo trabaja la empresa, pueda entrar en los repositorios, levantar entornos, ejecutar tests, consultar documentación, investigar incidencias, generar commits y llevar una tarea hasta preproducción.
Pero con una condición: que el cerebro sea intercambiable.
Hoy podría utilizar Claude. Mañana OpenAI. Después Gemini. Para una tarea sencilla, un modelo local. Para una complicada, el modelo frontera aunque cueste mucho más.
El agente, las herramientas, las reglas, las evaluaciones y el conocimiento seguirían siendo nuestros. Cambiaría el modelo, no nuestra forma de trabajar.
Esa idea me parece mucho más importante que construir «nuestro Claude Code». La independencia no consiste en dejar de usar Claude. Consiste en poder dejar de usarlo.
No lo construiría mañana
Y precisamente por eso no dedicaría ahora un gran equipo a construirlo.
Prefiero comprar opcionalidad poco a poco: mantener instrucciones y skills fuera de un proveedor, estandarizar herramientas, registrar qué hacen los agentes, abstraer el acceso a modelos y empezar a medir qué modelo resuelve mejor cada tipo de tarea.
Y, sobre todo, probar.
Cada tres o seis meses cogería los mejores modelos abiertos y les pondría delante trabajo real de nuestros desarrolladores. No benchmarks bonitos. Nuestros repositorios. Nuestros bugs. Nuestras migraciones.
Quizá hoy resuelvan un 40 %. Dentro de seis meses, un 65 %. Después, un 80 %. No sé dónde estará el punto de inflexión.
Lo que sí sé es que cuando llegue no quiero empezar desde cero.
La lección que me dejó el DevDay
Volvamos a los 500 dólares.
Quizá dentro de un año nos parezcan baratos. Quizá aparezcan planes de 1.000. Quizá la competencia haga caer los precios. Nadie sabe exactamente cómo se moverá esa curva.
Pero el DevDay me dejó una idea que sí quiero conservar: el suelo y el techo pueden moverse en direcciones distintas.
Programar software razonablemente bueno puede ser cada vez más barato. Y, al mismo tiempo, programar siempre con la mejor inteligencia disponible puede ser cada vez más caro.
No quiero elegir entre esos dos mundos. Quiero poder movernos entre ellos.
Pagar por la frontera cuando realmente marque la diferencia. Utilizar inteligencia barata cuando sea suficiente. Y construir nuestra tecnología de forma que ningún proveedor se convierta en una jaula.
Porque quizá la ventaja no sea tener siempre el mejor modelo.
Quizá la ventaja sea poder cambiar de inteligencia sin cambiar la empresa.