La paradoja de Jevons del software a medida
Si la IA reduce el coste de crear software específico, quizá no gastemos menos en software. Quizá construyamos muchas más soluciones para problemas que antes no superaban el umbral económico de un proyecto.
En el siglo XIX, William Stanley Jevons observó que mejorar la eficiencia con la que se utilizaba el carbón no garantizaba una reducción de su consumo. Al abaratar los usos posibles, la eficiencia podía ampliar la demanda total.
Aplicar esa idea al software no demuestra una ley económica. Es una hipótesis útil para pensar qué ocurre cuando la IA reduce el coste marginal de diseñar, construir y mantener soluciones específicas.
El umbral de lo que merece software
Hasta ahora muchas necesidades se quedaban en una hoja de cálculo, una cadena de correos o una tarea manual. No porque fueran irrelevantes, sino porque el coste de analizarlas, desarrollar una aplicación, integrarla y mantenerla superaba el beneficio esperado.
Si ese coste baja, el catálogo de problemas que merece una solución digital crece. Una herramienta para encontrar una frase exacta en horas de audio, una interfaz para una operación interna muy concreta o una automatización utilizada por tres personas pueden empezar a tener sentido.
No sustituirán necesariamente a un gran sistema corporativo. Ocuparán el espacio que nunca justificó uno.
De proyectos grandes a capacidades pequeñas
El modelo tradicional de software a medida tiende a concentrar requisitos en proyectos grandes para amortizar costes iniciales. Eso crea esperas, dependencias y soluciones que intentan satisfacer muchos problemas a la vez.
Cuando construir una pieza pequeña es viable, podemos componer capacidades: resolver una necesidad, observar su valor, conectarla con otras y decidir si merece evolucionar. La cartera se parece menos a una sucesión de grandes implantaciones y más a un ecosistema de herramientas mantenidas con intención.
Más software también significa más responsabilidad
La paradoja tiene un lado incómodo. Si multiplicamos aplicaciones sin arquitectura, propietarios ni criterios de retirada, también multiplicamos superficie de ataque, datos duplicados, dependencias y coste cognitivo.
Que algo sea barato de crear no significa que sea gratis de poseer. Cada solución necesita una respuesta para autenticación, permisos, operación, soporte, evolución y cierre. La nueva economía del software exige una disciplina de cartera, no una fiesta permanente de prototipos.
Cambia la pregunta de compra
La comparación ya no es únicamente software estándar frente a gran desarrollo a medida. Aparece una tercera opción: componer una solución pequeña con plataformas, APIs, agentes y código específico.
Para una pyme esto puede ser especialmente relevante. Muchos de sus procesos diferenciales son demasiado particulares para una herramienta estándar y demasiado pequeños para un proyecto clásico. Si el umbral baja, ese espacio se abre.
Una hipótesis que debemos medir
No sabemos que todo ahorro se convertirá en más demanda. Puede haber límites de atención, confianza, integración o regulación. Por eso la paradoja debe presentarse como una lente, no como una predicción inevitable.
La señal a observar es sencilla: cuántos problemas descartados por coste vuelven a la conversación y qué parte del valor total procede de soluciones que antes nunca habríamos construido.
Fuentes y referencias
- Texto de The Coal Question, de William Stanley Jevons.
- Fuente primaria: observación de Victor sobre prototipos y pequeñas herramientas viables con IA.