Durante años dimos por sentado que el software era algo sólido. Algo que se diseñaba, se construía, se empaquetaba y se vendía. Un artefacto relativamente estable, pensado para durar, escalar y servir a miles —o millones— de usuarios con el menor número posible de variaciones. El ideal industrial aplicado al mundo digital.
El software era una promesa de estabilidad en un mundo cambiante. Por eso hablábamos de roadmaps, de versiones, de mantenibilidad, de escalabilidad. Por eso medíamos el éxito en número de clientes, en adopción, en permanencia. El ideal era claro: construir una vez y servir muchas veces, escalar los sistemas y las operaciones, pasar el break even y volverse rico, muy rico.
Este ideal empieza a resquebrajarse. No de forma abrupta. No con una gran ruptura visible, más bien, como se agrietan los edificios antiguos: pequeñas fisuras que aparecen donde antes nadie miraba.
Empieza a emerger otra cosa, todavía sin nombre oficial, todavía incómoda para los manuales, para los frameworks mentales heredados, para la industria que se construyó alrededor de la idea de software como producto.
Yo la llamo «software on the fly«.
No como etiqueta técnica.
No como tendencia de mercado.
Sino como síntoma cultural.
On the fly, me aporta la ligereza que necesito para explicar la volatilidad del concepto.
Del software como producto al software como acción
El software on the fly no nace para durar. Nace para resolver. No se piensa como producto. Se piensa como una extensión momentánea de quien lo crea. No busca escalar. Busca encajar en un momento determinado. Aparece, cumple su función… y desaparece sin despedirse; incluso si intentas buscarlo luego, probablemente no sepas ni dónde está. Es escurridizo.
Durante años nos educaron para pensar que un software que no escala es un fracaso. Que un código que no se reutiliza es un desperdicio. Que una herramienta que no puede venderse a otros es, en el fondo, irrelevante. El software on the fly cuestiona esa moral desde lo más profundo.
No porque sea mejor, sino porque responde a otro tipo de problema.
Problemas pequeños.
Contextuales.
Efímeros.
Problemas que no justifican una solución industrial, pero que tampoco deberían resolverse a mano una y otra vez. Y aquí ocurre algo interesante: la IA reduce el coste de crear software hasta hacerlo trivial. Cuando el coste baja tanto, el valor se desplaza.
La caída del muro técnico
Durante mucho tiempo, el muro técnico actuó como filtro cultural. No todo el mundo podía crear software, y eso no era solo una cuestión de conocimiento: era una cuestión de poder. Saber programar era tener acceso a un lenguaje privilegiado. Era poder hablarles a las máquinas sin intermediarios.
La IA generativa derriba ese muro con una facilidad inquietante. Ya no necesitas dominar un lenguaje, sino formular una intención. Experesar una voluntad, et voilà, se concederá tu deseo. Cuando la fricción entre intención y ejecución desaparece, aparece una sensación nueva. Una sensación profundamente humana y peligrosa: la sensación de poder.
“Puedo hacerlo.”
“Puedo construirlo.”
“Puedo resolverlo ahora.”
«Dale zapatilla»
La IA convierte el software en algo maleable, casi blando. Algo que se adapta a ti, y no al revés.
Durante un tiempo, esa sensación es eufórica; superas retos que antes parecían inaccesibles.
Saltas obstáculos técnicos que durante años fueron infranqueables. Y sin darte cuenta, empiezas a confundir el poder con la omnipotencia.
No es vibe coding (aunque lo parezca)
Conviene aclarar el punto, el software on the fly no es vibe coding, aunque desde fuera se le parezca.
El vibe coding es una técnica: una forma de programar desde la intuición, desde el flujo, desde la iteración rápida, sin demasiada reflexión estructural ni una arquitectura de conocimiento bien asentada.
El software on the fly es otra cosa. Es una actitud rebelde frente al software:
Una renuncia explícita a la idea de permanencia.
Una aceptación de que no todo merece convertirse en sistema.
Una comprensión intuitiva de que hay problemas que solo existen ahora.
El software on the fly no quiere ser bonito. Quiere ser útil. No quiere ser robusto. Quiere ser suficiente. Y eso, para una industria obsesionada con la excelencia técnica, suena casi a herejía.
Hiperpersonalización radical: cuando el usuario deja de adaptarse
El software tradicional siempre pedía al usuario lo mismo: adaptación.
Adáptate al flujo.
Adáptate a la interfaz.
Adáptate al modelo mental del producto.
La promesa de la hiperpersonalización llevaba años en el discurso, pero rara vez se materializaba de verdad. Personalizar significaba cambiar colores, activar opciones y configurar alguna preferencia.
El software on the fly empuja esa idea hasta el límite.
Si puedo crear herramientas a mi medida,
¿por qué adaptarme yo a ellas?
Si puedo moldear el sistema,
¿por qué aceptar sus fricciones?
Aquí ocurre un desplazamiento silencioso pero profundo: el usuario deja de ser usuario y se convierte en autor. No en el sentido romántico del término, sino en uno mucho más práctico: el software empieza a reflejar directamente la forma de pensar de quien lo crea.
Mil softwares para mil personas.
Durante décadas repetimos una lógica casi industrial: un buen software es el que sirve a muchos. Cuantos más clientes, mejor. Cuanta más estandarización, más eficiencia. El software on the fly invierte esa lógica sin pedir permiso. Antes, un software servía a mil clientes. Ahora, mil softwares sirven a mil clientes.
Cada uno distinto.
Cada uno contextual.
Cada uno profundamente idiosincrático.
Esto no es necesariamente más eficiente. Tampoco más elegante. Pero es más cercano.
Y ahí aparece un nuevo tipo de ventaja competitiva, difícil de ver desde fuera: la ventaja invisible de quien se rodea de microherramientas que solo él entiende, scripts, bots, flujos… Pequeños artefactos cognitivos que nadie más usa, pero que encajan perfectamente en una forma concreta de trabajar.
Productividad asimétrica.
Ventajas silenciosas.
Conocimiento encapsulado.
Imaginad la que se puede montar en una empresa de 1000 trabajadores, creando una media de 2 a 3 microherramientas por trabajador al año. Intenta gobernar esto con las diez o veinte vulnerabilidades de seguridad en cada microherramienta.
El problema: lo que es fácil de crear no siempre es fácil de sostener
Aquí aparece el primer límite serio del software on the fly. El hecho de que algo sea rápido de construir no significa que sea trivial de mantener. El hecho de que funcione hoy no implica que funcione mañana.
El hecho de que encaje contigo no garantiza que encaje con otros. El riesgo no es técnico, es cognitivo.
Creer que porque algo ha sido fácil de crear, también será fácil de sostener.
Estas microherramientas funcionan bien cuando:
- el contexto es claro,
- el impacto es local,
- el error es reversible.
Empiezan a ser problemáticas cuando:
- se usan para decisiones estructurales,
- se convierten en piezas críticas,
- se estiran más allá de su intención original.
El software on the fly no escala bien. No envejece bien. No tolera malentendidos.
Y eso no es un bug. Es una feature.
El software como Kleenex
Durante años pensamos en el software como un artefacto estable. Ahora empieza a parecerse más a un Kleenex. Lo usas, cumple su función y lo tiras. No porque sea malo, sino porque ya no lo necesitas.
Esta idea resulta profundamente incómoda para una industria que se ha construido en torno a la permanencia: suscripciones, licencias, contratos, mantenimientos, dependencias a largo plazo.
Pero quizá el error esté en exigirle al software algo que no siempre tiene sentido exigir.
No todo debe durar.
No todo debe escalar.
No todo debe convertirse en infraestructura.
Hay herramientas que solo necesitan existir durante un rato.
El canibalismo del software
Durante años repetimos una frase con cierta satisfacción: el software se comió al mundo. Era una forma elegante de decir que todo acabaría siendo mediado por sistemas digitales. Que cualquier industria terminaría siendo, en el fondo, una industria de software. Esto ya pasó; nos pasamos esa pantalla.
Lo que empieza ahora es otra fase: el software empieza a comerse a sí mismo. Cuando una web puede clonarse en minutos, una app es replicable en horas y el “cómo” deja de ser diferencial. El valor se desplaza, el software pierde su aura y se convierte en commodity cognitivo.
Donde ya no está el valor
Cuando el software se vuelve banal, el valor ya no está en el código, ni en la interfaz, ni siquiera en la funcionalidad, porque todo eso puede replicarse, clonarse o generarse en minutos. El valor empieza a desplazarse hacia lo que no admite copia ni automatización: el contexto desde el que se construye, el criterio que decide qué hacer y qué no, la intención que guía cada elección, la relación —siempre asimétrica— con el usuario, el tiempo acumulado que no se puede acelerar y la confianza que solo se gana con repetición y coherencia.
El software on the fly no compite por ser único ni memorable; compite por ser adecuado en un instante concreto. Y ese pequeño matiz altera por completo la conversación sobre qué importa realmente.
El verdadero cuello de botella sigue siendo humano
Paradójicamente, cuanto más fácil es crear software, menos importante se vuelve el software. El cuello de botella vuelve a ser humano, formular bien el problema, entender qué merece ser automatizado y qué no, saber cuándo una solución efímera es suficiente… y cuándo es peligrosa.
El software on the fly no sustituye al pensamiento; lo deja al descubierto, porque cuando todo se puede construir rápido, lo único que no se puede acelerar sin romperlo es el criterio.
Una transición, no un destino
El software on the fly no es el futuro final del software, es una fase. Una transición entre el software como producto industrial y algo que todavía no sabemos nombrar del todo. Un recordatorio incómodo de que la tecnología, cuando se banaliza, deja al descubierto lo único que no puede automatizarse.
La pregunta ya no es qué software usas. Ni siquiera qué puedes construir. La pregunta es otra, más incómoda y más interesante:
¿qué sabes hacer cuando el software deja de importar?