La Era Dorada del Programador: ¿Estás Aprovechándola?

Llevo dos años escuchando que los programadores nos vamos a quedar sin trabajo. Lo he escuchado de consultores, de inversores, de periodistas que nunca han compilado un programa en su vida, y de vez en cuando de compañeros del sector con un mal día. Yo lo he pensado alguna vez. Hoy creo que todos se equivocan. Y creo que la historia es suficientemente elocuente al respecto como para no andarme con rodeos: estamos entrando en la era más interesante de la historia para dedicarse a programar. No lo digo para tranquilizar a nadie. Lo digo porque los datos, durante setenta años, siempre han apuntado en la misma dirección.

El miedo de siempre

La pregunta que todo el mundo se hace es “¿me va a sustituir la IA?” Pero esa no es la pregunta correcta.

La pregunta correcta es: ¿qué pasa cuando construir software cuesta la mitad?

La respuesta histórica es siempre la misma. Se construye el doble. O el triple. O se construyen cosas que antes no existían porque no eran económicamente viables. El número de personas que se dedican a construirlas no baja: sube. El miedo al reemplazo tecnológico no es nuevo, y hasta ahora no ha acertado ni una sola vez en este sector. Puede que esta vez sea diferente. Pero necesito más evidencia antes de creerlo.

Esto ya pasó antes — tres veces

No estamos ante algo sin precedentes. Hemos vivido versiones de este mismo momento al menos tres veces en la historia del software, y en las tres el resultado fue idéntico.

Los años 50 y 60: de las tarjetas perforadas a FORTRAN y COBOL

Antes de FORTRAN en 1957, programar requería entender la arquitectura física de la máquina. Era carísimo, especializado, exclusivo. No era para todo el mundo: era para una élite técnica muy específica, y el software resultante reflejaba ese coste. FORTRAN permitió que científicos e ingenieros escribieran fórmulas matemáticas directamente, sin pasar por ensamblador. COBOL, en 1959, fue diseñado de forma explícita para que más personas pudieran programar, incluidas personas de negocio que no eran ingenieros de hardware.

El objetivo era bajar la barrera. Lo consiguieron.

¿El resultado? En los años 60, los periódicos publicaban reportajes sobre la escasez brutal de programadores. La demanda en banca, gobierno e industria se había disparado. Según reportajes de la época recogidos por Click Americana, en Denver en 1967, un programador freelance decía que podría dar trabajo a cien programadores más solo en el sector financiero de la ciudad.

La herramienta se hizo más accesible, el número de problemas que se podía resolver con software aumentó, y la demanda de personas capaces de resolverlos se disparó con él.

Los años 90 y 2000: frameworks, web y el developer de fin de semana

Con Rails, Django, jQuery, PHP… montar una aplicación web pasó de requerir un equipo de expertos a ser alcanzable para una persona sola. La barrera bajó de nuevo.

Resultado: la comunidad de JavaScript pasó de unos 10,7 millones de desarrolladores en 2018 a más de 20 millones en pocos años, según datos de SlashData. La comunidad global de developers prácticamente se duplicó en una década. De repente, una startup de pocas personas podía construir un producto para millones de usuarios. Cosas que antes eran económicamente imposibles se volvieron viables. Y eso requería gente que las construyera.

Los años 2010: mobile, cloud e infraestructura invisible

App stores, AWS, infraestructura como servicio. Lanzar un producto global sin levantar un servidor físico. Otra vez el coste cayó. Otra vez apareció más gente construyendo más cosas. No menos roles especializados: más. Surgieron cloud architects, DevOps, SREs — perfiles que no existían antes y que hoy son altamente demandados.

El patrón lleva setenta años siendo consistente. A estas alturas, me parece difícil ignorarlo.

Lo que los números dicen

El contexto histórico en una sola tabla:

Era	Qué bajó la barrera	El miedo de entonces	Lo que pasó
Años 50-60	FORTRAN, COBOL	”No harán falta especialistas en hardware”	Escasez masiva de programadores; demanda disparada en banca, gobierno e industria
Años 90-2000	Rails, Django, PHP, jQuery	”Cualquiera puede hacer webs, los devs perderán valor”	La comunidad JS pasó de ~11M a +20M; los developers se multiplicaron en toda la industria
Años 2010	AWS, App Stores, SaaS	”La infraestructura se vuelve commodity, los sysadmins desaparecen”	Surgieron cloud architects, DevOps, SRE — roles nuevos con demanda aún mayor
Años 2020-hoy	Copilot, Cursor, agentes IA	”La IA va a programar por nosotros”	Por confirmar, pero el patrón histórico sugiere: más programadores, problemas diferentes

En el año 2000 había unos 680.000 ingenieros de software en Estados Unidos, según el Bureau of Labor Statistics. Hoy hay más de 47 millones de developers en todo el mundo, según estimaciones de SlashData. En setenta años, con cada nueva abstracción, el número no se contrajo. Se multiplicó.

Puede que ahora sea diferente. Puede que me equivoque. Pero necesito ver evidencia en contra del patrón antes de aceptar el relato del reemplazo.

Lo que cambia ahora, en el buen sentido

Hay algo que sí es diferente esta vez: el ritmo. Las abstracciones anteriores tardaban años en democratizarse. Rails tardó varios años en ser adoptado masivamente. AWS necesitó casi una década para convertirse en la infraestructura por defecto. Con la IA, el ciclo es mucho más corto. Copilot lleva en producción desde 2021; en 2025, la mayoría de los developers en proyectos activos tienen alguna herramienta de IA a mano.

Pero lo más interesante no es la velocidad. Es lo que cambia en el trabajo diario.

Peleamos menos con la sintaxis. Más con lo que importa: diseñar soluciones, tomar decisiones de arquitectura, validar que lo que se construye tiene sentido, asumir responsabilidad sobre los resultados. Parte de lo que antes hacíamos se automatiza. Y eso es bueno, igual que fue bueno que FORTRAN automatizara el ensamblador.

Un developer con IA no produce el mismo software más rápido. Produce software diferente que antes no era económicamente posible construir. Esa es la distinción que más me importa, y la que menos se menciona en el debate sobre el futuro del sector.

El fin del SaaS generalista

Hay una consecuencia del abaratamiento del software que creo que todavía no está suficientemente bien entendida: el fin del SaaS generalista tal como lo conocemos.

Los SaaS actuales son generalistas por necesidad económica. Nunca fue viable construir y mantener software específico para un nicho de doscientas empresas. El coste de desarrollo solo tenía sentido sirviendo a mercados grandes con un producto único, poco personalizable. Software para todos y optimizado para ninguno en particular.

Cuando ese coste cae, el argumento se rompe.

Algunas empresas optarán por soluciones completamente a medida. En lugar de pagar licencias mensuales por software que cubre el 70% de sus necesidades, tendrán su propia herramienta que cubre el 95%. Otras seguirán usando SaaS, pero micro-SaaS muy específicos que antes no existían porque no eran rentables de construir: mercados que nadie atendía porque el tamaño no justificaba la inversión.

En ninguno de los dos casos el resultado es menos programadores. Donde antes un equipo de diez personas daba soporte a miles de clientes con el mismo producto, ahora pueden existir decenas de equipos distintos construyendo productos diferentes para mercados que antes nadie veía. Los costes para el cliente final son similares. La calidad, adaptación y diferencia competitiva, mucho mayor.

Las economías de escala de los grandes SaaS generalistas se erosionan. No desaparecen: dejan de ser el único modelo viable. Y eso crea espacio para más equipos, más productos, más problemas que resolver.

Cuando “programar” deja de ser la palabra correcta

Hay una reflexión que llevo tiempo dando vueltas y que creo que merece decirse directamente: puede que “programar” como término deje de tener sentido antes de lo que pensamos. Y eso no me preocupa.

“Mecanógrafo” dejó de ser una profesión cuando llegaron los procesadores de texto. Pero la habilidad de escribir con rapidez y precisión no desapareció. Se redistribuyó: todo el mundo empezó a escribir en teclados. La profesión se disolvió porque la habilidad se volvió universal.

Algo parecido puede pasar con “programar” en el sentido estricto. Si cualquier persona puede generar código funcional a partir de una descripción en lenguaje natural, la barrera de “saber programar” se desvanece. Pero lo que no desaparece es la necesidad de alguien que sepa qué construir, por qué, y cómo validar que lo construido realmente resuelve el problema.

Eso siempre ha sido lo valioso. El lenguaje, el framework, la herramienta: eso es el medio, no el fin.

Y si llegara el día en que no quedan problemas que resolver… ese sería un mundo maravilloso. Probablemente muy aburrido. Esperemos que tarde en llegar.

Cargando ejercicio...

Tres malentendidos que vale la pena desmontar

Confundir la automatización de la herramienta con la desaparición del oficio

El error más extendido: pensar que porque la IA puede generar código, ya no hace falta quien lo entienda, lo valide y tome decisiones sobre él. Un carpintero que usa una sierra eléctrica no tiene menos trabajo que uno que usaba una sierra manual. Tiene más, y puede abordar proyectos que antes eran inviables. La herramienta más potente no elimina al artesano: expande lo que el artesano puede construir.

Tratar la demanda actual de developers como si fuera un techo

El razonamiento implícito es este: “si la IA puede hacer X, habrá menos trabajo para developers.” Ese argumento asume que la cantidad de software que el mundo quiere construir es fija. No lo es. En cuanto el coste de construir software cae, aparecen nuevas categorías de problemas que resolver, nuevas empresas que antes no existían, nuevos productos que antes no eran rentables. La demanda no es un techo. Es un suelo que, históricamente, siempre ha subido cuando la barrera baja.

Olvidar que la IA también genera complejidad nueva

Este es el que menos se menciona, y es el que más me interesa. Los agentes de IA necesitan orquestación, verificación, gestión de contexto, integración con sistemas existentes. Ninguno de esos problemas es trivial. Alguien los tiene que resolver. Y ese alguien es, hoy por hoy, un developer.

Si quieres sacar partido de este momento

Esto no es un plan de carrera. Son las cosas que, en mi caso, han resultado útiles para no perder el hilo en medio del ruido:

• Practica delegar la implementación rutinaria a herramientas IA, sin perder la capacidad de leer y validar lo que generan

• Desarrolla criterio para saber qué problema merece ser resuelto con software. Eso la IA no lo hace por ti

• Aprende los patrones que permiten construir con agentes IA: orquestación, verificación, gestión de contexto

• Identifica un dominio donde puedas construir algo que antes no era rentable construir

• Sigue escribiendo código propio. El que solo delega pierde la intuición de qué es posible y qué no

Por ejemplo, la validación y orquestación de agentes IA requiere que alguien estructure el flujo:

Este es exactamente el tipo de trabajo que la IA genera, no que elimina: alguien tiene que pensar cómo validar, cómo orquestar, qué pedir y por qué.

Hace unos años no me habría planteado que compartir lo que sé y cómo pienso fuese viable como proyecto. Hoy lo es. No porque la IA escriba por mí, sino porque me ayuda a construir esto: a no perder las ideas en el camino, a darles la forma que merecen, a llegar a un nivel de calidad que solo no tendría ni el tiempo ni la paciencia de alcanzar.

La IA no me sustituyó. Me desbloqueó.

¿La IA va a reducir el número de empleos de programación?

Puede que sí en ciertos perfiles específicos y en algunas empresas en el corto plazo. No hay que ignorar que la IA ya se usa para justificar recortes. Pero el patrón histórico sugiere que el efecto neto a largo plazo es más programadores, no menos, porque aparecen nuevas categorías de problemas que resolver. El corto plazo puede ser turbulento. La tendencia de fondo, según setenta años de historia, apunta en otra dirección.

¿Qué tipo de programador tiene más futuro en la era de la IA?

El que sabe qué construir y por qué, más que el que ejecuta instrucciones precisas en un lenguaje específico. La capacidad de diseñar sistemas, tomar decisiones de arquitectura, validar resultados y entender el dominio del problema: eso es lo que la IA no sustituye todavía. La sintaxis y la implementación rutinaria se automatizan. El criterio, no.

¿Esto significa que cualquiera puede ser programador?

La barrera de sintaxis se está aplanando, sí. Pero la barrera de criterio, saber qué construir, cómo estructurarlo para que sea mantenible y cómo validar que funciona en condiciones reales, esa no desaparece. Si acaso, se vuelve más importante. El developer que solo sabía escribir código correcto tiene menos ventaja diferencial que antes. El que sabe pensar cómo resolver problemas tiene más.