Desde la irrupción de ChatGPT, el número de desarrolladores ha crecido entre un 18% y un 50% dependiendo de la métrica. Más automatización, más empleo. La paradoja es evidente, y tiene una explicación, aunque no sea la que muchos esperaban. Porque lo que está ocurriendo no es una desaparición, sino algo bastante más interesante: una redefinición profunda de lo que significa «ser programador».
Porque, en efecto, si hay un ámbito en el que los modelos de lenguaje tienen una ventaja estructural evidente es precisamente en la escritura de código. A diferencia del lenguaje natural, lleno de ambigüedades, excepciones, ironías y contextos, los lenguajes de programación son sistemas formales, consistentes y con reglas estrictas. Son, en cierto modo, el terreno ideal para una inteligencia estadística entrenada con millones de ejemplos, que además pueden ser tomados de los enormes repositorios de código abierto a los que muchos desarrolladores suben su mejor código para «hacer curriculum». En ese contexto, que las máquinas se vuelvan extraordinariamente competentes en escribir código no debería sorprender a nadie.
Y, sin embargo, esa constatación aparentemente devastadora no está produciendo, al menos por ahora, el efecto que muchos anticipaban. Según datos recogidos por Boston University, el número de desarrolladores no ha disminuido, sino que ha crecido de manera notable desde la irrupción de ChatGPT: entre un 18% y un 50% dependiendo de la métrica utilizada. En Estados Unidos, el aumento ronda el 19%, con cientos de miles de nuevos profesionales incorporados al mercado. A escala global, algunas estimaciones sitúan el crecimiento en decenas de millones de desarrolladores adicionales en apenas tres años.
La paradoja es evidente: más automatización, pero también más empleo. Y la explicación, lejos de ser misteriosa, responde a un patrón clásico en economía de la tecnología. Cuando una herramienta aumenta la productividad de forma significativa, y en este caso hablamos de incrementos del 30% al 50% o más, no sólo reduce el coste de producir software, sino que expande radicalmente la demanda del mismo. Más software, más barato, más ubicuo… y, por tanto, más necesidad de personas que lo diseñen, lo supervisen, lo integren y lo mantengan.
Lo que sí está cambiando, y aquí es donde conviene mirar con más atención, no es tanto la cantidad de desarrolladores como la naturaleza de su trabajo. Los datos de GitHub son elocuentes: el 92% de los programadores ya utilizan herramientas de inteligencia artificial en su flujo de trabajo. No estamos hablando del futuro, sino del presente. La programación asistida por inteligencia artificial se ha convertido en la norma, no en la excepción.
Pero ese mismo estudio introduce una tensión interesante: los desarrolladores no quieren ser evaluados por la cantidad de código que producen, sino por su capacidad para diseñar soluciones, comunicarse, entender problemas complejos y gestionar la calidad del software. Es decir, justo aquello que las máquinas todavía no hacen bien. El código, progresivamente, deja de ser el producto principal del trabajo del programador para convertirse en un subproducto.
Esto encaja con una intuición que llevamos tiempo viendo desarrollarse: la programación como actividad manual, el teclear líneas de código, está siendo desplazada por la programación como actividad conceptual. Los ingenieros pasan menos tiempo escribiendo «boilerplate« y más tiempo definiendo arquitecturas, supervisando agentes autónomos y tomando decisiones de diseño. En otras palabras, dejan de ser operarios del código para convertirse en orquestadores de sistemas.
En ese contexto, las narrativas más alarmistas resultan, como mínimo, incompletas. Incluso en textos que anticipan el «fin de la programación tal y como la conocemos», como el artículo de Farhad Manjoo en The New York Times, «It’s the end of computer programming as we know it (and I feel fine)«, la conclusión real es más matizada: la programación no desaparece, sino que se democratiza y cambia de forma. Las máquinas empiezan a entendernos a nosotros, en lugar de obligarnos a aprender sus lenguajes. Y eso, lejos de eliminar la necesidad de expertos, la desplaza hacia niveles superiores de abstracción.
Sin embargo, sería ingenuo no tener en cuenta el otro lado de la ecuación: mientras el número total de desarrolladores crece, asistimos simultáneamente a despidos masivos en grandes empresas tecnológicas y a una creciente polarización salarial. Algunos perfiles, especialmente los más cercanos a la comprensión profunda de sistemas de inteligencia artificial, arquitectura distribuida o seguridad, alcanzan niveles de remuneración sin precedentes, mientras que otros ven cómo su trabajo se devalúa o desaparece.
Lo que estamos presenciando no es una destrucción homogénea de empleo, sino una reconfiguración jerárquica de la profesión. Una especie de «elevador» que empuja hacia arriba a quienes logran adaptarse y deja atrás a quienes permanecen en tareas fácilmente automatizables. El programador que se limita a escribir código rutinario compite ahora con una máquina que lo hace más rápido, más barato y, en muchos casos, suficientemente bien. El que entiende problemas, contextos, sistemas y trade-offs, en cambio, se vuelve más valioso que nunca.
Esto plantea una pregunta incómoda, especialmente en el ámbito educativo: ¿qué significa hoy «aprender a programar»? Durante años, se ha defendido como una habilidad fundamental, casi como una alfabetización del siglo XXI. Pero si escribir código deja de ser el núcleo de la actividad, tal vez lo que deberíamos enseñar no es sintaxis, sino pensamiento computacional, modelado de problemas, capacidad crítica y comprensión de sistemas complejos. Porque, en el fondo, el verdadero cambio no está en quién escribe el código, sino en qué papel juega el código en la creación de valor. Y ahí es donde la narrativa del «vibe coding», esa idea de que basta con pedirle cosas a un chatbot y dejarse llevar, resulta especialmente peligrosa. Generar software sin entenderlo puede funcionar en contextos triviales, pero se convierte en una bomba de relojería cuando hablamos de sistemas críticos, seguridad o escalabilidad. Como señalaban algunos desarrolladores en la encuesta de GitHub, el código generado por inteligencia artificial puede ser simplemente basura si quien lo utiliza no es capaz de evaluarlo.
Por tanto, no, no estamos ante el fin de los programadores. Pero tampoco estamos ante su continuidad tal y como la conocíamos. Estamos ante una mutación, una de esas que redefinen una profesión desde dentro. Una mutación que convierte al programador en algo más cercano a un ingeniero de sistemas complejos, a un diseñador de soluciones o incluso a un gestor de inteligencias artificiales.
Y, como ocurre siempre en estos procesos, la diferencia no la marcará la tecnología, sino la capacidad de adaptación. Porque, en última instancia, el problema nunca ha sido que las máquinas aprendan a programar. El problema es qué hacemos nosotros cuando dejan de necesitarnos para hacerlo.
Esto lo he vivido en mis carnes en un repositorio de Github donde un «usuario» se puso a producir como loco. Luego al revisarlo tuve que echar para atrás todos los cambios. Un desastre sin paliativos.
Supongo que irán mejorando las herramientas y hay lenguajes como PHP o Javascript donde realmente es bueno (mucha documentación online, Substacks, etc.) pero otros donde anda confundido (NabSic, Go…)
Y por experiencia hay una cosa mala que es buena. Si le pones un problema complejo lo fastidia totalmente. Pero si se lo subdivides en tareas pequeñas, es capaz de hacer cada una bien y la lo terminas de montar tú
Pero, ¿aumentan los programadores o aumentan los ‘ya sé programar’?
Porque ni de lejos es lo mismo. Porque las Store de Apple y Google se están llenando literalmente de basura generada por no-informáticos que se creen programadores y generan aplicaciones basura con código basura que ellos ni entienden ni serán capaces de mantener y que no resisten un análisis serio, como dice Benji.
Que un programador con IA es más que sólo un programador, sin duda, pero ¿ahora todos somos programadores? ¿De repente hay millones de desarrolladores que antes estaban escondidos? No, ¡ni de coña!
Esta es la madre del cordero. Pero el fenómeno no es nuevo: hoy en día cualquiera puede «venir aquí a hablar de su libro» (publicar escritos en web, blogs y compañía; publicar fotos en el gramo instantáneo; publicar vídeos en el tubo; etc) con el resultado previsible de que, como dice la ley de Sturgeon, «el 90% de todo es basura». La parte positiva es que ese 10% restante es aún más numeroso que todo lo que se publicaba cuando las únicas opciones eran las editoriales o los estudios de cine o TV.
Hace eones yo impartía formación en Edición Digital, ósea, QuarkXPress.
Dominaba la herramienta, incluso llegué a maquetar, y cobrar por ello, dos libros pero, ¿me convertía eso en maquetador? En mi opinión, NO.
Dominaba la herramienta pero no conocía el mundo del diseño que rodea a la maquetación. Mis maquetaciones podrían pasar por buenas, pero seguro que un maquetador de verdad sacaría mil y un fallos que el resto del mundo ni vería. Ni yo.
Claro, pero por algún sitio tenías que empezar, y tú sabes mejor que yo, que hay gente que empezó así y luego hizo un carrerón con eso porque fueron aprendiendo lo que no estaba en los Escritos…
Vivimos tiempos interesantes. Hace un rato me he pasado dos horas discutiendo y refinando con Claude las especificaciones de un proyecto, y después, mientras lo implementaba, he salido a dar un paseo (ahora me toca revisar el resultado y hacer u ordenar correcciones, claro; pero aún así sale a cuenta -en tiempo y en calidad del resultado- con respecto a hacerlo todo a mano).
Desde mi punto de vista, incluso si mañana las IAs desaraparecieran y tuviéramos que volver a programar a mano, aún así lo haríamos mejor que antes de la era IA, porque ya nos hemos acostumbrado a pensar y escribir una maldita especificación antes de ponernos a tirar código como posesos. Que es algo que antes ya sabíamos que había que hacer, pero no lo hacíamos tanto como debíamos por las prisas o por una falsa sensación de seguridad.
El domingo estuve escuchando en Radio 3 Fallo de Sistema: Ejercicio para moldear nuestro cerebro
¿Necesita Claude salir a pasear virtualmente, aclarar sus ideas y obtener mejores resultados como nos pasa a los humanos? XD
La reflexión es interesante pero creo le falta algo. Como en muchas profesiones, hay diferentes niveles dentro de la profesión. Creo que es importante diferenciar entre desarrolladores e ingenieros de software. Los primeros no suelen tener una formación más allá de aprender una serie de tecnologías y lenguajes de programación, mientras que los segundos han (o deberían) haber estudiado la base teórica de la computación, sistematización y a pensar soluciones a problemas. Para los ingenieros, la tecnología específica es/debería ser secundario. Y es ahí donde parece que los LLMs son más útiles, en hacer el trabajo de implementación y de traducción de requisitos y diseño a código.
Sin denostar a los desarrolladores ni a otros trabajos, es, quizás, el equivalente a sustituir operarios de maquinaria en una fábrica por una máquina en sí. Pero los ingenieros de montaje, los ingenieros mecánicos no pueden ser reemplazados. Al menos por ahora…
Voy a compartir mi experiencia porque creo que aterriza bien lo que plantea Enrique.
En mi caso, el “Vibe Coding” me ha permitido abordar proyectos que antes eran directamente inabordables por ambiciosos. En la mayoría prácticamente ya no escribo código, pero eso no significa que programe menos: significa que programo en otro nivel.
Lo que se vuelve crítico no es la sintaxis, sino:
1. Entender el problema y descomponerlo en fases evolutivas.
2. Elegir un stack no solo adecuado técnicamente, sino también “compatible” con la IA para iterar rápido.
3. Definir funcionalidades con precisión creciente.
4. Anticipar efectos colaterales entre componentes.
5. Diagnosticar errores lo suficiente como para guiar a la IA.
6. Diseñar interfaces coherentes y utilizables.
Es decir: el foco se desplaza de escribir código a dirigir sistemas que lo generan.
Pero hay un matiz importante: esto funciona solo si mantienes capacidad real de entender lo que está pasando. Si no, entras en una falsa sensación de control bastante peligrosa.
En mi caso, este enfoque es el que hay detrás de herramientas como Live Aula, donde pasamos de documentos complejos a sistemas interactivos y pedagógicamente optimizados en tiempos que antes eran impensables.
Off topic ¿para un futuro post?
El Pentágono ha llegado a un acuerdo con la plana mayor de la industria de la IA, incluyendo a SpaceX, OpenAI, Google, Nvidia, Microsoft, Amazon y Oracle, para implementar esta tecnología en “cualquier uso operacional amparado por la ley”. En el caso de EEUU, este concepto incluye extremos como la vigilancia masiva, habilitada a través de leyes posteriores al 11S como la Patriot Act o la Ley de Vigilancia Extranjera. Juassss!!!
https://www.eldiario.es/tecnologia/elites-silicon-valley-acatan-orden-trump-abren-ia-militar-proposito-legal_1_13192543.html
Internet vuelve a donde nació. Ni más, ni menos. (Y quizás de donde NUNCA salió…).
Programar tiene cierto parecido con la construcción, Hay que poner ladrillos enteros o partidos unos al lado del otro, Eso es lo que hacen los programadores poner los comandos adecuados uno detrás de otros. Pero primero hay que decidir por donde van las paredes y si irán enyesadas o alicatadas y por donde hay que hacer rozas par colocar cables,
Eso a veces lo hacen los mismos albañiles, interpretando los planos, o lo indican otros albañiles más capacitados, que hacen de capataces, Incluso, raras veces los propios albañiles hicieron los planos.
Algo parecido ocurre en programacion, alguien decide que es lo que van a hacer los programas y lo especifica en cuadernos de carga y a veces lo hacen los mismo programadores o lo dejan para los llamados analistas.
Herramientas generadoras de código, las hay desde muy antiguo, yo las he conocido que generaban lenguaje de COBOL Bastaba que el programador escribiera un pseudocódigo y para que la herramienta generara el código en el lenguaje de programación. Lo que pasa es que prácticamente era tan pesado escribir el pseudocódigo como el lenguaje de programación y no compensaba.
Lo que la IA ha facilitado es pasar de pseudocódigo, que ahora llamamos «prompt», al lenguaje de programación, pero queda todo lo de mas , decidir que es lo que ha de hacer el programa y cómo hacerlo. Se han reducido los albañiles necesarios, pero no los capataces.
Me alegro por la profesiön , «tirar código» era la parte menos creativa y peor pagada del trabajo.
«aquello que las máquinas todavía no hacen bien. El código, progresivamente, deja de ser el producto principal del trabajo del programador para convertirse en un subproducto.» (EDans).
En una serie de TV he conocido como una máquina podía hacer líneas de código alucinante, como si no hubiera un mañana, simplemente para desorientar a los que la infectaron con un virus. Parecía querer ganar tiempo (o dárselo al humano, que hacía aún de administrador).
Esa máquina ya pensaba por sí misma, como se supone deben hacer las IH. Pero el problema es que las IH no suelen saber como ganar tiempo en situación de peligro. Realmente no suelen saber captar las señales de peligro. Y mucho es por falta de entrenamiento.
Los humanos somos muy precarios como IH, y subidos a la montaña, nos negamos a interactuar positivamente (para nosotros) con los peligros que nos esperan en el valle… porque la dificultad extrema nunca está en la subida, siempre está en la bajada.
Lo comenté hace dos años en el blog. Puede estar bien revisar el artículo para ver cómo han cambiado las cosas y la opinión y sentimiento de los comentaristas (¿os acordáis de Menestro? :)