La paradoja de Jevons aplicada al software: cuanto más fácil es crearlo, más queremos

Andrej Karpathy publicó el 9 de junio un hilo en X que Simon Willison recogió en su blog con una observación que merece más atención de la que suele recibir este tipo de posts cortos: a medida que el software sale "del grifo", la demanda no se estabiliza ni baja. Ocurre exactamente lo contrario.

El propio Karpathy lo enuncia sin rodeos: "I feel my own demand for software growing substantially". Visualizadores, dashboards, apps de un solo uso hiper-específicas para un proyecto concreto, suites de tests multiplicadas por diez, código auto-optimizado, proyectos de investigación con HTML personalizado para los resultados. La lista no es prospectiva; describe lo que ya hace hoy.

La paradoja de Jevons no es nueva, pero sí su aplicación al software

La paradoja de Jevons viene del siglo XIX: cuando la eficiencia en el uso de un recurso mejora, el consumo total de ese recurso tiende a crecer, no a disminuir. Se formuló primero para el carbón y las máquinas de vapor, y desde entonces ha reaparecido en casi todos los sectores donde la tecnología abarata el acceso a algo escaso.

En el caso del software, el recurso escaso siempre fue el tiempo de desarrollo. Una app "bespoke" —hecha a medida para un único propósito y descartada después— era inviable económicamente para la mayoría de proyectos. Nadie encargaba un panel de control personalizado para analizar los resultados de un experimento puntual. El coste de oportunidad era demasiado alto.

Ahora ese coste ha caído de forma apreciable. Y el efecto, como predice Jevons, no es que los desarrolladores descansen más, sino que abren la vía a decenas de herramientas que antes descartaban mentalmente antes incluso de planteárselas.

Por qué importa para quienes trabajan con Claude

Esto tiene implicaciones prácticas para equipos que ya usan Claude Code o integran Claude vía API. La utilidad de contar con skills reutilizables, subagentes o workflows automatizados no reside solo en ejecutar las mismas tareas más rápido. Reside en que la fricción reducida hace aflorar una demanda latente que antes no se expresaba.

Dicho de otro modo: el valor no está únicamente en sustituir trabajo que ya se hacía, sino en habilitar trabajo que directamente no ocurría. Una suite de tests ampliada, un visualizador ad hoc para datos de un sprint, un pequeño dashboard para compartir con un cliente durante una reunión y no volver a abrir. Casos de uso que el equipo descartaba en el momento de la idea porque el esfuerzo de implementación no compensaba.

Eso cambia cómo tiene sentido planificar la capacidad técnica de un equipo. No se trata solo de "hacer lo mismo con menos personas". Se trata de que la superficie de lo que se considera factible se expande, y con ella la lista de lo que acaba en el backlog.

Una nota sobre la fuente

El post de Willison cita el tweet de Karpathy mencionando "Claude Fable 5". No existe ningún modelo con ese nombre en el catálogo público de Anthropic a fecha de hoy —los modelos vigentes son Claude Opus 4.8, Sonnet 4.6 y Haiku 4.5—, por lo que reproducimos el nombre tal como aparece en la fuente original sin interpretarlo ni corregirlo. Puede tratarse de un nombre interno, un alias no oficial o simplemente un error en el tweet original.

Lo que queda sin resolver

Karpathy habla desde la perspectiva de alguien con contexto técnico profundo y criterio para evaluar qué merece construirse. La paradoja de Jevons también tiene una cara menos cómoda: más consumo no equivale automáticamente a más valor. El riesgo simétrico es la proliferación de software descartable que nadie mantiene, que nadie documenta y que genera deuda técnica invisible porque «total, fue fácil de hacer».

La observación de Karpathy es válida y refleja algo que en ElephantPink llevamos meses viendo en proyectos de clientes. Pero conviene acompañarla de una segunda pregunta: de toda esa demanda nueva que el grifo libera, ¿cuánta se convierte en infraestructura sostenible y cuánta en ruido acumulado?