Un telar mecánico del siglo XIX, con sus engranajes, sus palancas, su ritmo implacable. Y al lado, un tejedor. No operando el telar —eso ya lo hace la máquina— sino mirándolo.
Hay una imagen que me persigue desde hace meses.
Un telar mecánico del siglo XIX, con sus engranajes, sus palancas, su ritmo implacable. Y al lado, un tejedor. No operando el telar —eso ya lo hace la máquina— sino mirándolo. Con una expresión que no es exactamente miedo, pero tampoco es tranquilidad. Es la expresión de alguien que acaba de entender que las reglas del juego han cambiado y que nadie le avisó a tiempo.
Esa imagen me persigue porque creo que estoy viendo su equivalente exacto en los equipos de desarrollo de software de 2025. Y creo que la mayoría no se ha dado cuenta todavía.
Cuando las máquinas llegaron a las fábricas
Para entender lo que está pasando en el software hoy, hay que hacer un ejercicio que parece innecesario: retroceder dos siglos.
Entre 1760 y 1840, la Revolución Industrial transformó la manufactura europea de una manera que, vista desde dentro, debió de parecer simultáneamente extraordinaria y devastadora. El artesano que durante generaciones había dominado su oficio de principio a fin —que compraba la materia prima, diseñaba el producto, lo fabricaba, lo vendía, y transmitía ese conocimiento a sus hijos— se encontró de repente compitiendo con máquinas que producían diez veces más, a un décimo del coste.
Lo que ocurrió a continuación no fue la eliminación del humano de la ecuación. Fue algo más sutil y, en cierto modo, más brutal:su fragmentación.
El artesano que antes era un agente completo —con criterio, con visión, con autonomía— se convirtió en un operario especializado en una sola etapa del proceso. Uno alimentaba la máquina. Otro la vigilaba. Otro transportaba el material. Otro reparaba los engranajes. El conocimiento que antes residía en una sola persona se distribuyó, se atomizó, se hizo dependiente del sistema.
La productividad se multiplicó. La autonomía del individuo, no.
Y aquí está el punto que la narrativa habitual omite:esa transición no fue igual para todos. Una minoría —los ingenieros que diseñaban las máquinas, los capataces que entendían el proceso completo, los dueños que veían el sistema desde arriba— no solo sobrevivió al cambio. Lo capitalizó. El resto quedó atrapado en la especialización: imprescindible mientras la máquina los necesitara, prescindible en el momento en que la máquina pudiera hacer también su parte.
Lo que siguió durante décadas fue una guerra silenciosa entre dos tipos de trabajadores: los que sabían operar dentro del sistema, y los que sabían entender el sistema.
El software como artesanía
Durante décadas, el desarrollo de software fue una de las pocas profesiones que logró preservar algo de aquella artesanía original.
Un buen desarrollador era, en esencia, un artesano digital. Entendía el problema desde su raíz, diseñaba la solución, la implementaba, la depuraba, la explicaba. Había algo de orgullo legítimo en eso —en la capacidad de ir de la idea al producto con las manos propias, con el control de cada pieza.
Y no es nostalgia vacía. La historia del software está construida sobre esa artesanía individual de una manera que hoy cuesta creer.
En 1991, Linus Torvalds tenía 21 años y una sola máquina. Escribió el núcleo de Linux como proyecto personal, casi por el placer de entenderlo todo desde abajo. Ese kernel hoy corre en el 97% de los servidores del mundo, en todos los teléfonos Android, en los superordenadores que modelan el clima y entrenan los modelos de IA que estamos discutiendo en este artículo. Una sola mente, con visión completa del sistema, construyendo algo que el mundo entero terminó necesitando.
Richard Stallman escribió GCC —el compilador que durante décadas fue la base sobre la que se construyó prácticamente todo el software open source— casi en solitario. John Carmack diseñó los motores gráficos de Doom y Quake con una comprensión tan profunda del hardware que sus optimizaciones se estudiaron en universidades. Ward Cunningham inventó la wiki —la estructura que sostiene Wikipedia y miles de sistemas de conocimiento— con unas pocas líneas de Perl en 1995. Rasmus Lerdorf creó PHP para gestionar su propia página personal; hoy el 77% de los sitios web con servidor conocido lo usa.
Lo que une a todos ellos no es el genio aislado —la mayoría colaboró, publicó, recibió contribuciones. Lo que los une es lavisión de sistema completo: entendían el problema de principio a fin, tomaban decisiones de arquitectura con plena conciencia de sus implicaciones, y podían rastrear cualquier fallo hasta su raíz porque habían construido cada capa.
Eso era el artesano digital en su forma más pura. Y ese es exactamente el perfil que la industria fue fragmentando, especialización a especialización, hasta convertirlo en algo irreconocible.
Y durante mucho tiempo, el mercado lo reconoció. En la primera y segunda décadas del siglo XXI, el desarrollador de software se convirtió en el perfil profesional más valorado del mercado occidental. Los bootcamps prometían reconversiones en seis meses. Las universidades lanzaban grados a toda velocidad. Los sueldos escalaban. Se hablaba del "trabajo del futuro" con una convicción que rozaba la fe religiosa.
Era comprensible. En un mundo donde cada empresa se estaba convirtiendo en una empresa de software, quien sabía construir software tenía el poder.
Lo que nadie dijo entonces —o lo que se dijo muy bajo— es que ese poder estaba ligado a una escasez específica. No era el conocimiento lo que valía; era la dificultad de adquirirlo y ejecutarlo. El valor del desarrollador era, en parte, el valor de la barrera de entrada.
Y las barreras de entrada tienen una tendencia histórica muy clara:desaparecer.
La IA no es una herramienta más. Es el telar.
Aquí es donde la mayoría de las narrativas sobre IA y desarrollo de software cometen el mismo error: presentar la IA como una herramienta más en el cinturón del desarrollador. Como el IDE, como el compilador, como el gestor de dependencias. Algo que te hace más rápido, pero que no cambia fundamentalmente lo que eres.
No lo creo. Y la historia tampoco lo sostiene.
El telar mecánico no era una herramienta más en manos del tejedor. Era la externalización de su habilidad central. La máquina no ayudaba al artesano a tejer mejor; tejía en su lugar, con mayor velocidad y menor variabilidad. Lo que quedaba del artesano en el proceso era secundario a la máquina, no el centro del proceso.
Los modelos de lenguaje de gran escala —y las herramientas de generación de código que se construyen sobre ellos— están haciendo exactamente eso con la parte del desarrollo de software que durante años fue su núcleo:la traducción de intención a instrucción.
Escribir código, en su nivel más operacional, es el acto de traducir lo que quieres que haga un sistema al lenguaje que ese sistema entiende. Durante décadas, esa capacidad de traducción fue el cuello de botella. Era lo que tardaba años en adquirirse, lo que requería práctica constante, lo que justificaba los sueldos.
La IA ha atacado directamente ese cuello de botella. No lo ha eliminado todavía —hay matices, contextos, decisiones de arquitectura que todavía requieren un humano que entienda lo que está haciendo. Pero lo ha comprimido de una manera que hace irreconocible el trabajo de hace apenas dos años.
Un desarrollador con herramientas de IA puede producir hoy en un día lo que antes requería una semana. Eso suena bien hasta que haces la pregunta obvia:¿qué pasa con los otros cuatro días de trabajo que el mercado ya no necesita pagar?
El ferrocarril del software: cuando el delivery se volvió invisible
La Revolución Industrial tiene una segunda historia que suele pasar desapercibida. No es la historia de la máquina que produce. Es la historia de cómo llega lo producido al mundo.
No bastó con fabricar diez veces más. El cuello de botella se desplazó: si los canales de distribución seguían siendo los de antes —carros de madera, caminos de tierra, semanas de viaje entre ciudad y ciudad— la fábrica producía para un mercado local. El ferrocarril fue lo que convirtió la producción industrial en economía de escala real. El vapor no solo movía los telares; movía los productos terminados a cientos de kilómetros, en horas, con una fiabilidad que antes era imposible.
Y hay algo más que el ferrocarril hizo, que es lo que más me interesa:estandarizó el mundo. Cuando las compañías ferroviarias acordaron el ancho de vía, no solo conectaron ciudades — homogeneizaron la infraestructura. A partir de ese momento, cualquier tren podía circular por cualquier vía. El transporte se volvió predecible, intercambiable, commodity.
La historia del software es una sucesión de ese mismo patrón. TCP/IP estandarizó cómo viajan los datos entre máquinas. HTTP estandarizó cómo se comunican los sistemas en la web. REST estandarizó cómo se diseñan las interfaces entre servicios. Cada vez que una capa se estandarizó, el conocimiento operativo de quien sabía navegar el caos anterior perdió valor — y se abrió espacio para construir cosas más complejas encima.
Ahora estamos en el umbral de la siguiente estandarización, y esta vez no afecta a cómo se mueven los datos sino a cómo se comunican los agentes de IA entre sí. El protocolo MCP —Model Context Protocol, impulsado por Anthropic— define una interfaz común para que los modelos de lenguaje accedan a herramientas y contexto externo de forma estructurada. El protocolo A2A de Google va un paso más allá: establece cómo un agente de IA puede delegar tareas a otro agente, coordinarse, transferir contexto.
Para el comercio electrónico, las implicaciones son concretas y próximas. Un agente que gestiona el catálogo de productos puede hablar con un agente que gestiona el inventario, que a su vez coordina con un agente de logística, que notifica a un agente de atención al cliente — todo sin intervención humana en el flujo, con cada pieza construida sobre el mismo ancho de vía. Las plataformas como VTEX o Shopify ya están posicionando sus APIs para ser consumidas por agentes, no solo por desarrolladores humanos.
Lo que el ancho de vía ferroviario fue para el transporte físico, MCP y A2A van a ser para la economía agéntica. Y como siempre que se estandariza una capa: quienes entiendan el sistema que hay debajo capturarán el valor. Quienes solo sepan operar las herramientas de encima, quedarán a merced de quien las construyó.
En el software, ese momento ya ocurrió. Y la mayoría no lo vio porque fue gradual.
Hace veinte años, desplegar software en producción era una operación de riesgo mayor. Servidores físicos que había que configurar a mano, procesos de release con ceremonial de lanzamiento de cohete, entornos que "funcionaban en local" y fallaban misteriosamente en producción, rollbacks que podían significar horas de trabajo manual. El deploy era un evento. Requería coordinación, valentía, y frecuentemente un viernes por la tarde que nadie quería vivir.
Hoy un git push puede desplegar código a producción en minutos, con tests automatizados, zero downtime, rollback en un click, y métricas en tiempo real. Docker estandarizó los entornos. GitHub Actions automatizó los pipelines. Vercel, Railway,Fly.iohicieron que el deploy de una aplicación compleja fuera comparable a enviar un email.
El ferrocarril llegó al software. Y como el ferrocarril original, hizo dos cosas simultáneamente:aceleró todo y eliminó el conocimiento diferencial de quien sabía hacer la ruta a mano.
El desarrollador que en 2005 sabía configurar un servidor Nginx, gestionar certificados SSL manualmente, orquestar un deployment sin herramientas modernas —ese conocimiento era oro. Era escaso. Era años de experiencia destilados en capacidad operativa. Hoy ese mismo conocimiento está encapsulado en plataformas que cualquier junior puede usar el primer día.
No es una crítica. Es un patrón. El mismo que vivieron los maquinistas de diligencias cuando llegó el tren, los telegrafistas cuando llegó el teléfono, los linotipos cuando llegó la fotocomposición. El conocimiento operativo que tomó años construir se volvió irrelevante no porque fuera malo, sino porque la infraestructura que lo hacía necesario desapareció.
Y aquí está la clave que conecta el transporte con todo lo demás:cuando el delivery se vuelve invisible, lo que queda visible es la calidad de lo que se entrega. El ferrocarril no hacía mejores productos —hacía que los productos malos llegaran más rápido al mercado donde eran rechazados, y que los buenos llegaran más rápido al mercado donde triunfaban.
El CI/CD perfecto desplegando código mediocre sigue siendo código mediocre, ahora en producción en cinco minutos en lugar de en tres semanas. La velocidad de entrega ya no es ventaja competitiva. Es la línea de base. Lo que diferencia ahora es qué se decide entregar, y por qué.
Londres no fue casualidad. Y la IA tampoco.
Inglaterra no se convirtió en la cuna de la Revolución Industrial por accidente. Tenía carbón bajo sus colinas. Tenía hierro. Tenía ríos navegables y puertos abiertos al Atlántico. Tenía una clase comerciante hambrienta de ganancias y dispuesta a apostar por ideas que parecían locas. Y tenía un problema concreto que resolver: la demanda textil crecía más rápido de lo que los métodos tradicionales podían responder.
La revolución no nació de la genialidad abstracta. Nació de la confluencia de recursos físicos, presión de mercado y capital dispuesto a arriesgar. Cuando James Hargreaves vio girar una rueca volcada en el suelo y pensó "¿y si pudieran girar ocho a la vez?", no estaba inventando en el vacío. Estaba respondiendo a una urgencia que todo el sistema económico llevaba años acumulando.
Pero Londres fue el origen, no el destino. La Revolución Industrial no se quedó donde nació. Alemania la sistematizó — convirtió la intuición inglesa en ingeniería rigurosa, en química industrial, en formación técnica institucionalizada. Francia aportó la organización burocrática del Estado al servicio de la producción. Estados Unidos la escaló de una manera que Europa no había imaginado: líneas de montaje, estandarización de piezas, producción masiva para un mercado continental. Y en el siglo XX, Japón la reinventó desde dentro con la manufactura lean, reduciendo el desperdicio hasta convertir la eficiencia en filosofía.
Cada geografía aportó lo que tenía: recursos naturales, cultura de trabajo, estructura política, escala de mercado. La revolución fue un proyecto colectivo que nadie coordinó y que nadie pudo detener.
La revolución de la IA sigue exactamente ese patrón. Y también tiene sus Londres.
El equivalente moderno del carbón y el hierro no son materiales que se extraen del suelo. Son recursos que se construyen, pero que tienen las mismas restricciones físicas que los de hace dos siglos: energía, refrigeración, conectividad, y la ingeniería capaz de combinarlos a escala.
Un centro de datos de última generación para entrenar modelos de IA de frontera consume entre 100 y 500 megavatios de electricidad — más que muchas ciudades medianas. Necesita refrigeración constante que en climas cálidos puede requerir tanta energía como el propio cómputo. Y necesita conectividad de fibra de baja latencia para que las operaciones distribuidas sean viables.
Estados Unidos fue el primer Londres de esta revolución. Silicon Valley tenía el capital, la densidad de talento, la cultura de riesgo y —durante décadas— la infraestructura energética. OpenAI, Anthropic, Google DeepMind, Meta AI: todos nacieron o crecieron dentro de ese ecosistema. El equivalente de Hargreaves pensando delante de una rueca volcada ocurrió en garajes de Palo Alto y oficinas de San Francisco.
China tomó el rol que Alemania jugó en el siglo XIX: sistematizó, escaló, y añadió una dimensión que Occidente subestimó. No solo construyó sus propios modelos —construyó la cadena de suministro del hardware. TSMC en Taiwán, las fábricas de semiconductores, la producción de los chips sobre los que corre toda esta inteligencia. Quien controla la fabricación del chip controla el cuello de botella físico de la revolución, igual que quien controlaba las minas de carbón controlaba el cuello de botella de la industrial.
Y ahora emergen los nuevos candidatos a ser los próximos nodos de esta geografía.
Los países nórdicos —Islandia, Noruega, Suecia— llevan años posicionándose como destino preferente para centros de datos porque resuelven los dos problemas simultáneamente: energía renovable abundante y refrigeración natural gratuita. El frío del Ártico hace el trabajo que en Texas requiere torres de refrigeración que consumen otro 30% de energía. Microsoft, Google y Meta ya tienen instalaciones masivas en Suecia y Finlandia por esa razón exacta.
España aparece en este mapa de una manera que pocas veces se analiza con la seriedad que merece. La irradiación solar en la Península Ibérica es de las más altas de Europa occidental. La capacidad instalada de energía renovable crece a ritmo récord. Y geográficamente, España es el nodo natural entre Europa, África y América Latina — tres mercados con demanda creciente de infraestructura de IA. Google ya anunció inversiones en centros de datos en España. Microsoft también. No es filantropía tecnológica; es posicionamiento sobre un recurso físico escaso.
Pero hay una pregunta que vale la pena formular, porque también tiene su paralelo histórico:¿estos cuellos de botella físicos tienen los días contados?
El motor de vapor, que parecía inamovible e imprescindible durante un siglo, fue eventualmente miniaturizado, electrificado y distribuido hasta hacerse invisible en cada dispositivo. La computación siguió el mismo arco: de mainframes del tamaño de habitaciones a chips en el bolsillo. ¿Hará la IA el mismo viaje? ¿Llegará un momento en que los modelos que hoy requieren centros de datos del tamaño de estadios corran en dispositivos portátiles, en el edge, incluso — como se especula — en plataformas orbitales de baja latencia global?
La respuesta honesta es: probablemente sí, pero no pronto, y no para los modelos de frontera. Los modelos pequeños ya corren en local — llama, Mistral, Phi. Pero los modelos que mueven el mercado, los que definen el estado del arte, seguirán siendo dependientes de infraestructura masiva durante años. La física no negocia: más parámetros requieren más cómputo, más cómputo requiere más energía, más energía requiere más infraestructura.
Lo que sí puede cambiar —y aquí está la oportunidad real para geografías como España o los países nórdicos— es quién controla esa infraestructura y en qué condiciones. La soberanía energética sobre la IA puede convertirse en la ventaja competitiva más duradera de esta década, igual que el acceso al carbón lo fue durante el siglo XIX.
Londres no fue casualidad. Tampoco lo será el próximo nodo que domine esta revolución.
El engranaje que no sabía que era un engranaje
La Revolución Industrial enseñó algo que tardamos generaciones en digerir: la especialización extrema protege en el corto plazo y vulnerabiliza en el largo.
Pero antes del problema económico estaba el problema humano.
Por primera vez en la historia, la producción se concentraba en enormes edificios donde el trabajo se dividía en tareas repetidas con precisión mecánica. Un trabajador ya no hacía un producto completo de principio a fin. En su lugar, realizaba una sola operación, una y otra vez, sin ver el antes ni el después. El artesano que antes tenía una historia que contar sobre su trabajo —"hice esto, de principio a fin, con mis manos, con mi criterio"— se convirtió en alguien que no podía explicar qué hacía sin nombrar la máquina que lo definía.
Era más eficiente. Y era profundamente deshumanizante.
No porque el trabajo fuera más duro —muchas veces no lo era. Sino porque había desaparecido la narrativa. El sentido de autoría. La capacidad de señalar algo terminado y decir:esto lo hice yo.
Aunque hay que matizarlo: esa autoría no desapareció del proceso. Se desplazó. El empresario que diseñó la fábrica, el ingeniero que construyó la máquina, el capataz que organizó el flujo — ellos sí tenían una historia que contar. Pero ya no era "lo hice". Era algo diferente y, en el fondo, más poderoso:lo pensé. Vi el problema y diseñé la respuesta.
Ahí está el desplazamiento real de valor que la Revolución Industrial introdujo y que pocas veces se nombra con claridad:el mérito migró de la ejecución al criterio. De las manos a la cabeza. De quien construía la solución a quien conectaba el problema con ella.
El obrero perdió la narrativa. El ingeniero la conservó, pero transformada. Ya no era autoría sobre un objeto —era autoría sobre una idea, sobre un sistema, sobre una decisión. Y esa forma de autoría resultó ser mucho más resistente a la automatización que cualquier habilidad manual.
Ahora bien —y aquí está el giro incómodo que la industria del software no quiere verse obligada a hacer—:esa deshumanización no llegó con la IA. Llegó antes. Y la aceptamos voluntariamente.
El mercado nos ofreció una trampa disfrazada de oportunidad. Especializarse pagaba bien. "Frontend developer", "DevOps engineer", "data pipeline specialist", "QA automation engineer". Roles cada vez más acotados, cada vez más optimizados para encajar en un proceso mayor que ninguno de ellos entendía completamente. Nos convertimos en engranajes antes de que llegara la máquina que podía reemplazarnos. Y mientras los sueldos fueron buenos, nadie hizo demasiadas preguntas.
El operario que en el siglo XIX aprendió a operar una máquina específica tenía trabajo mientras esa máquina era necesaria. Cuando la máquina cambió, él no podía cambiar con ella. Su especialización, que era su valor, era también su límite.
En el ecosistema de software, estamos viendo ese patrón repetirse con décadas de aceleración. Gente que aprendió a escribir componentes React, a hacer consultas SQL, a configurar pipelines de CI/CD, a maquetar con Tailwind. Habilidades reales, valiosas —y ahora parcialmente automatizables con un prompt bien construido.
No es que esas habilidades no importen. Es que, por sí solas, ya no diferencian. Y quien construyó su identidad profesional enteramente sobre ellas está descubriendo ahora, con desconcierto, que la IA no le quitó la visión de conjunto. Es que nunca la tuvo.
Lo que diferencia ahora —y aquí es donde la analogía histórica se vuelve verdaderamente incómoda— es lo mismo que diferenciaba entonces:la capacidad de entender el sistema completo. No solo operar dentro de él, sino razonar sobre él. Saber por qué una arquitectura tiene sentido, no solo cómo implementarla. Entender las implicaciones de una decisión técnica en el negocio, no solo en el código.
El ingeniero que diseñaba las máquinas de la Revolución Industrial no fue desplazado por ellas. El artesano que solo las operaba, sí.
El desarrollador que va a sobrevivir (y los que no)
Voy a ser directo, porque creo que la honestidad vale más aquí que el optimismo de consumo.
No hay espacio para todos en la nueva configuración. La idea de que "la IA creará más trabajo del que destruye" es estadísticamente posible a nivel macroeconómico y completamente irrelevante a nivel individual si no eres de los que hacen la transición correcta.
El desarrollador que va a sobrevivir —y a prosperar— en el siguiente ciclo tiene un perfil que, curiosamente, se parece más al artesano del siglo XVIII que al programador del siglo XXI. Es alguien con visión completa del proceso. Que entiende el negocio detrás del código, la arquitectura detrás del componente, el dato detrás de la interfaz. Que puede leer lo que genera la IA y saber, con criterio propio, si está bien o mal y por qué.
En el ecosistema de e-commerce donde trabajo, lo veo cada semana. Los perfiles que están ganando terreno no son los que escriben más código por hora —la IA ya los iguala en velocidad. Son los que pueden pararse delante de un cliente, entender qué problema real tiene su negocio, y traducir eso en una arquitectura que tenga sentido técnico, comercial y operativamente. Eso no se automatiza. Todavía no.
Pero hay otro perfil que está desapareciendo más rápido de lo que la industria reconoce: el desarrollador que sabe ejecutar bien tareas definidas por otros. El que implementa el diseño que le pasan, el que integra la API según la documentación, el que resuelve tickets sin preguntarse por qué existen. Ese perfil no va a desaparecer de golpe. Va a vaciarse lentamente de valor, como ocurrió con los oficios de la Revolución Industrial, hasta que un día el mercado deje de pagar lo que antes pagaba.
Y para entonces, la brecha con los otros será demasiado grande para cruzarla rápido.
La ilusión del "trabajo del futuro"
Quiero hablar de algo que me parece importante y que rara vez se dice en los círculos técnicos: el daño que hizo la narrativa del "desarrollador como trabajo del futuro".
Durante la última década, esa narrativa fue real. El mercado la sostuviera. Los datos la confirmaban. Era razonable aconsejar a alguien que aprendiera a programar como inversión de vida.
El problema es que esa narrativa tenía una condición implícita que nadie verbalizó:era cierta en un contexto donde la capacidad de escribir código era escasa. En ese contexto, quien tenía la habilidad tenía el poder.
Lo que la IA está haciendo no es solo automatizar tareas —es atacar esa escasez directamente. Está democratizando la capacidad de traducir intención a código de una manera que comprime el valor de esa habilidad en sí misma.
Esto no significa que aprender a programar fue un error. Significa que el valor de hacerlo ya no está donde estaba. Ya no está en la sintaxis ni en conocer las APIs. Está en lo que siempre estuvo en las profesiones más resistentes al cambio tecnológico: en el criterio, en el contexto, en la capacidad de hacer las preguntas correctas.
Un arquitecto no vale por saber dibujar planos —los ordenadores llevan décadas haciendo eso mejor que él. Vale porque sabe qué planos hacer y por qué. Esa distinción, que en arquitectura llevaba clara desde los años 80, acaba de llegar al software.
Lo que la historia nos pide recordar
La Revolución Industrial no fue solo una historia de progreso. Fue también una historia de quiénes capturan el valor de ese progreso y quiénes quedan atrapados en la transición.
Los historiadores económicos calculan que tardó entre 50 y 70 años en materializarse el beneficio amplio de la Revolución Industrial para la clase trabajadora. Décadas en las que la productividad crecía mientras los salarios reales de los obreros se estancaban o caían. El progreso existía; el beneficio era asimétrico.
No tenemos 70 años esta vez. Los ciclos se han comprimido radicalmente. Lo que en el siglo XIX tardó décadas en remodelarse, en el software se está remodelando en años.
Eso tiene una implicación que incomoda pero que creo que hay que nombrar:la ventana para hacer la transición correcta es estrecha, y ya está cerrándose.
Los que estén construyendo ahora capacidad de razonamiento sobre sistemas —no solo habilidad de construirlos—, los que estén aprendiendo a usar la IA como amplificador de criterio y no como sustituto de pensar, los que estén desarrollando la capacidad de hablar de tecnología con vocabulario de negocio y de hablar de negocio con vocabulario de tecnología... esos son los que van a estar en el lado correcto de esa asimetría.
El resto no va a desaparecer de golpe. Va a ir perdiendo terreno, poco a poco, hasta que la distancia sea insalvable.
Una nota final sobre nosotros mismos
Escribo esto también como reflexión propia, no solo como observación externa.
Yo también crecí profesionalmente en el contexto en que "saber programar" era suficiente distinción. Aprendí a valorar el código bien escrito, la arquitectura limpia, la solución técnicamente elegante. Hay orgullo legítimo en eso.
Pero si algo me ha enseñado trabajar en la intersección de tecnología, negocio y estrategia en los últimos años es que el código elegante que resuelve el problema equivocado no vale nada. Y que la IA puede escribir código elegante más rápido que yo.
Lo que no puede hacer —todavía— es decidir qué problema merece ser resuelto. No puede sentar en una sala con un cliente y entender qué hay debajo de lo que pide. No puede mirar una arquitectura propuesta y saber, desde la experiencia, dónde va a fallar en producción.
Ese es el territorio que tenemos que reclamar. No como reacción defensiva, sino como evolución honesta.
La Revolución Industrial creó, al final, más riqueza y más oportunidades de las que destruyó. Pero no para todos, y no al mismo tiempo. Quienes entendieron antes qué estaba cambiando —y cambiaron con ello antes de que fuera urgente— fueron los que capturaron esa riqueza.
La pregunta no es si el software va a cambiar. Ya está cambiando.
La pregunta es si vamos a ser de los que entienden el sistema, o de los que lo operan.