La IA no va a eliminar al ingeniero de software. Va a eliminar al que solo escribía código.

Llevo meses con esto en la cabeza.

En enero, Dario Amodei subió al escenario de Davos y dijo que estamos a 6-12 meses de que la IA haga "la mayoría, quizá todo" lo que hace un ingeniero de software. Jensen Huang lleva desde 2024 repitiendo que los niños no deberían aprender a programar. Zuckerberg predice que la IA escribirá la mayor parte del código de Meta antes de que acabe el año. Y la semana pasada leí un post de Sean Goedecke, Staff Engineer, diciendo sin rodeos: "no sé si mi trabajo existirá en diez años".

Me leí ese post entero y me reconocí en muchas cosas. Pero al terminar me di cuenta de que mi conclusión es diferente. No porque yo tenga razón y él no, sino porque creo que estamos mirando cosas distintas.

Sean mira su trabajo y ve código. Código que la IA ya escribe mejor que muchos ingenieros. Y tiene razón: si tu trabajo es convertir user stories en líneas de código, la IA se lo va a comer. Eso ya está pasando.

Yo miro mi trabajo y no veo código. Veo contexto, fricción entre equipos, decisiones que nadie quiere tomar, principios que hay que hacer explícitos para que siete equipos no se pisen unos a otros. Y eso no sé cómo lo automatizas. Al menos no todavía.

No voy a fingir que tengo la respuesta completa. Pero sí tengo una postura, y quiero compartirla.

El delineante y el arquitecto

Tengo una analogía que me funciona muy bien para explicar lo que pienso. La uso en conversaciones con otros ingenieros y siempre genera debate, así que la comparto.

Durante décadas, los estudios de arquitectura empleaban delineantes: profesionales que convertían los bocetos del arquitecto en planos técnicos precisos. Era un trabajo cualificado, lento y esencial. Cada línea, cada cota, cada detalle de un edificio pasaba por sus manos.

Cuando llegó el CAD en los 80, los delineantes desaparecieron. Pero los arquitectos no. Porque el trabajo del arquitecto nunca fue dibujar planos. Era decidir cómo debe funcionar un edificio, cómo se vive, cómo envejece, cómo resiste. El plano era el artefacto. La decisión era el trabajo.

Escribir código es delinear. La función técnica en una empresa es arquitectura.

Coordino siete equipos de ingeniería en Mercadona Tech. Te digo una cosa que puede sonar exagerada pero es literal: ninguna de las conversaciones importantes que tengo tiene que ver con código. Ni una. Tienen que ver con contexto. ¿Por qué este equipo está bloqueado? ¿Qué principio de diseño debería guiar esta decisión inter-equipos? ¿Cómo evitamos que esta fricción se repita? ¿Dónde está el cuello de botella real, en la implementación o en la indefinición del problema?

El plano lo puede generar un agente. Estas preguntas, no.

Y alguien dirá: "claro, es que tú eres Staff Engineer, tu caso es diferente". Y tiene razón. Mi caso es diferente. Pero la dirección en la que se mueve toda la profesión es esta. Lo que yo hago hoy es lo que más ingenieros harán mañana: menos delinear, más decidir.

Los datos: ni tan apocalípticos ni tan tranquilos

No quiero hacer cherry-picking con los datos, así que voy a poner los que me parecen más relevantes y que cada uno saque sus conclusiones.

Lo que está pasando con los juniors es preocupante. Un estudio de Stanford encontró que el empleo de desarrolladores de 22 a 25 años ha caído casi un 20% desde su pico en 2022. Y un estudio de Harvard sobre 62 millones de trabajadores mostró que cuando las empresas adoptan IA generativa, el empleo junior cae un 9-10% en seis trimestres, mientras que el empleo senior apenas se mueve.

Pero no estamos viendo una destrucción masiva de empleo senior. Lo que estamos viendo es un reequilibrio. Las empresas están moviendo presupuesto de formación junior a contratación senior. De velocidad a calidad. De escalar personas a construir sistemas que escalan.

Mientras tanto, un estudio de GitHub demostró que los desarrolladores con Copilot terminan tareas un 55% más rápido. ¿Y qué hacen las empresas con esa ganancia? Lanzan más proyectos, no despiden gente. Al menos, por ahora. Esto puede cambiar, y sería deshonesto no decirlo.

Sobre el efecto Jevons: un argumento con trampa

Muchos se agarran a la paradoja de Jevons como fuente de optimismo. La idea: cuando algo se vuelve más eficiente, la demanda total aumenta en vez de disminuir. Pasó con el carbón, con los coches, con el almacenamiento de datos. Si producir software se abarata, produciremos más software y necesitaremos más ingenieros.

Históricamente esto ha funcionado con el software. Internet, GitHub, la nube, cada salto de productividad ha creado más empleos de ingeniería, no menos. Hay más ingenieros que nunca.

Pero la paradoja de Jevons tiene un contraejemplo que nadie suele mencionar. La productividad agrícola se disparó en el siglo XX y el empleo agrícola cayó del 33% al 1,3%. ¿La diferencia? La demanda de comida tiene un techo. La pregunta es: ¿tiene techo la demanda de software?

Sean Goedecke argumenta que los agentes de IA pueden mantener código tan bien como escribirlo, así que la meseta necesaria para que Jevons funcione probablemente no existe. Yo creo que tiene razón si hablamos solo de código. Pero el software no es solo código. Es contexto, decisiones, trade-offs, operaciones, personas. Y la demanda de eso no tiene techo visible.

Dicho esto, no me fío del efecto Jevons como argumento para la tranquilidad. Es un patrón histórico, no una garantía.

La abstracción sube. Siempre ha subido.

Esto es lo que me da más perspectiva. Porque no es nuevo.

Primero fueron unos y ceros. Luego ensamblador. Después lenguajes de alto nivel. JVM, .NET, el navegador. Cada capa de abstracción hizo irrelevante algo que antes era crítico. ¿Cuándo fue la última vez que optimizaste instrucciones de ensamblador a mano?

Ahora la IA es la siguiente capa. Como dice un artículo de InfoWorld: la programación agéntica es la compilación de lenguaje hablado a lenguaje de programación. El código se está convirtiendo en lo que el código máquina es hoy. Una sopa de instrucciones que no lees, generada por un proceso automático.

Y aquí es donde creo que Amodei se confunde, o al menos simplifica demasiado. Cuando dice "mis ingenieros ya no escriben código", está describiendo una realidad. Pero confunde "escribir código" con "hacer ingeniería de software". No son lo mismo. Como bien señala Ivan Turkovic en su respuesta al post de Amodei: el trabajo de ingeniería se está moviendo hacia arriba en la pila de abstracción. Arquitectura, seguridad, escalabilidad, conocimiento organizacional, alineamiento con producto. Esas preguntas se vuelven centrales al rol, no periféricas.

En Mercadona Tech ya lo hemos vivido. Las discusiones sobre si una clase debería ser genérica, si deberías inyectar un use case de una forma u otra, esas conversaciones prácticamente han desaparecido. Lo que queda son debates sobre contexto, decisiones de diseño a nivel de sistema, fricción entre equipos, principios transversales. El código es un detalle de implementación. Y lo digo como alguien al que le encantaba escribir código. Pero es lo que es.

Lo que me preocupa de verdad: la paradoja de la automatización

No me preocupa que la IA me quite el trabajo. Me preocupa que nos quite la competencia sin que nos demos cuenta.

En 1983, Lisanne Bainbridge publicó "Ironies of Automation". La ironía central: automatizar una tarea no elimina la necesidad de experiencia humana. La transforma y la incrementa. El operador sigue siendo responsable, pero pierde el contacto continuo con el trabajo que construyó su comprensión. Cuando la automatización falla (y siempre falla) el operador enfrenta el momento más exigente precisamente cuando está menos preparado.

El ejemplo más trágico es Air France 447. El avión cayó al Atlántico en 2009 después de que el piloto automático se desconectara por un fallo conocido y recuperable. La tripulación, con 20.000 horas de vuelo combinadas, no pudo diagnosticar el problema. No porque fueran malos pilotos, sino porque la automatización les había robado la práctica.

El paralelo con nuestra profesión es directo. Si dejas que la IA escriba todo el código y te limitas a aprobar PRs, ¿qué pasa cuando el sistema falla de una forma que la IA no puede diagnosticar? ¿Qué pasa cuando necesitas entender un sistema en profundidad para tomar una decisión crítica a las 3 de la mañana?

Como dice Addy Osmani: si todos tienen acceso a agentes de IA, lo que distingue a los grandes ingenieros es saber cuándo la IA está equivocada. Y para saber eso, necesitas el criterio que solo se construye resolviendo problemas difíciles. No aprobando lo que la IA te da.

En mi artículo sobre heurísticas invisibles hablé de cómo los seniors tienen una biblioteca interna de patrones que no pueden articular pero que les permiten resolver incidentes en minutos. Eso es exactamente lo que la IA no puede replicar. Porque la IA genera código, pero no tiene la experiencia de miles de horas de producción real.

Un dato que pone las cosas en perspectiva

El informe MIT NANDA de 2025 encontró que el 95% de los pilotos de IA enterprise no generan retorno medible. Deja bastante mal a las IAs, hasta que miras la tasa base: los proyectos IT enterprise en general fallan un 84% de las veces. McKinsey sitúa solo 1 de cada 200 a tiempo y en presupuesto.

La IA no falla más que cualquier otra transformación tecnológica. Falla diferente: las empresas intentan meter IA genérica en procesos existentes sin adaptación. Los proyectos que funcionan son los que integran la IA profundamente en flujos de trabajo específicos. El problema nunca fue tecnológico. Es de contexto, de entender el sistema completo (negocio, personas, tecnología) y de tomar decisiones con criterio.

Exactamente lo que hace un buen ingeniero senior. Y exactamente lo que ningún modelo sabe hacer todavía.

Lo que pienso, con toda la incertidumbre que eso implica

A medio plazo estoy convencido de que los perfiles técnicos siguen existiendo. Con más abstracción, con más herramientas, pero siguen existiendo. Pensar que el rol desaparece porque la máquina escribe código es como pensar que el diseñador desaparece porque Figma tiene autocompletado. La máquina la tiene que usar alguien. Y ese alguien necesita criterio.

A largo plazo, no sé qué pasará. Te digo la verdad: no lo sé. Y te lo digo como alguien que no le preocupa reconocerlo.

Lo que sí tengo claro es esto: la IA amplifica cualquier juicio que se le dé. Con juicio débil, produce caos rápido y seguro. Con juicio fuerte, es un multiplicador de fuerza. La diferencia entre un equipo que usa IA para entregar mejor y un equipo que usa IA para generar deuda técnica más rápido es la misma de siempre: la calidad del pensamiento detrás de las decisiones.

Programar en el futuro será programar contexto. Qué quieres que pase, en qué condiciones, con qué restricciones. No cómo se implementa.

La IA no va a eliminar al ingeniero de software. Va a eliminar al que solo escribía código. Y si eso te preocupa, la pregunta no es si tu trabajo desaparece. La pregunta es en cuál de las dos mitades estás.

Pregunta para ti: ¿Tu día a día se parece más al del delineante o al del arquitecto? No lo digo con juicio. Lo pregunto porque creo que la respuesta marca la diferencia entre preocuparse y prepararse.