Praveen Rajamani encontró la forma más clara que he leído de explicar lo que la IA le hizo a nuestro trabajo. En un artículo en DEV divide la ingeniería de software en dos partes. Cerca del 80% era ejecución: escribir código repetitivo, arreglar bugs recurrentes, montar configuraciones, escribir tests de un comportamiento que ya entendías. El otro 20% era pensar: entender el problema real, diseñar bajo restricciones, depurar los casos límite que nadie previó, decidir con información incompleta, saber qué no construir.
Su resumen en una frase: "La IA se comió el 80%. Ahora el 20% es todo el trabajo."
Suena a victoria hasta que ves lo que le hace a una jornada. La ejecución era tediosa, pero el cerebro descansaba mientras la hacías. Era la parte del día sin presión, donde recuperabas el aliento entre una decisión difícil y la siguiente. Quítala y no obtienes una jornada más corta. Obtienes una jornada hecha por completo de las partes que siempre fueron difíciles.
Lo que la IA absorbió y lo que no
El 80% es justo donde las herramientas brillan. Claude Code y Copilot te generan un endpoint CRUD, una migración, un conjunto de tests o un archivo de configuración más rápido de lo que tardas en describirlos. El 20% es donde flojean, porque plantear un problema y decidir qué no construir no son autocompletado. Son criterio.
Así que la forma del trabajo se invirtió. La parte barata, esa de la que te recuperabas, se fue. La parte cara y agotadora se quedó y creció, porque ahora la haces sin pausas.
Cada hora que ahorras en ejecución vuelve directa a pensar más
El tiempo que la IA libera no se convierte en holgura. Se reinvierte en trabajo más denso: revisar el código generado, decidir si está bien, sostener más arquitectura en la cabeza a la vez. Y la evidencia de que esto acelera de verdad a los ingenieros con experiencia es mucho más endeble de lo que sugiere el marketing.
METR hizo un ensayo controlado aleatorizado con 16 desarrolladores de código abierto con experiencia, sobre 246 tareas reales en repositorios en los que llevaban años trabajando. Con permiso para usar IA, tardaron un 19% más. Antes de empezar esperaban acelerar un 24%, y al terminar seguían creyendo que la IA les había acelerado un 20%. La sensación de ir más rápido y el hecho de ir más rápido se separaron por completo.
A nivel de equipo, el informe State of DevOps 2024 de DORA encontró que, a medida que subía la adopción de IA, el rendimiento de entrega de software y su estabilidad bajaban, no subían (el resumen de InfoQ trae las cifras: alrededor de un 1,5% menos de rendimiento y un 7,2% menos de estabilidad por cada 25% de aumento en la adopción). En ese mismo informe, el 39,2% de los desarrolladores dijo confiar poco o nada en el código generado por IA.
El propio código muestra la tensión. El análisis de GitClear sobre 211 millones de líneas modificadas encontró que el código copiado y pegado subió del 8,3% al 12,3% y, por primera vez registrada, superó al código reutilizado (el que se "mueve"). La refactorización cayó del 25% de los cambios a menos del 10%. La reescritura inmediata casi se duplicó. La IA es muy buena añadiendo código y bastante mala convenciéndote de reutilizar lo que ya existe.
Y quienes hacen el trabajo lo notan. En la encuesta de 2025 de Stack Overflow, la confianza en la precisión de la IA cayó al 33%, desde el 43% del año anterior. La mayor frustración, señalada por el 66% de los desarrolladores, fueron las "soluciones de IA que son casi correctas, pero no del todo". Lo casi correcto es el tipo de error más caro, porque hace falta alguien con experiencia que lo lea con la atención suficiente para detectar dónde falla.
El argumento contrario, dicho con honestidad
Nada de esto significa que los estudios sobre la aceleración sean falsos. No lo son, e ignorarlos sería deshonesto.
El experimento de la propia GitHub puso a 95 desarrolladores a escribir un servidor HTTP en JavaScript; el grupo con Copilot terminó un 55% más rápido. Un conjunto mayor de experimentos de campo en Microsoft, Accenture y una empresa del Fortune 100, 4.867 desarrolladores en total, encontró un 26% más de tareas completadas. McKinsey midió documentación y código nuevo escritos en aproximadamente la mitad de tiempo.
Fíjate en lo que tienen en común esas ganancias. Un servidor HTTP desde cero. Documentación. Tareas que se cuentan. Eso es el 80%. La IA es más rápida justo donde el trabajo ya era fácil y estaba bien especificado, y ahí es donde se concentran las cifras de productividad. También se concentran en la gente con menos experiencia: MIT Sloan informó de que los desarrolladores júnior ganaban entre un 27% y un 39%, mientras que los sénior ganaban entre un 8% y un 13%. Cuanto más se acerca el trabajo al 20% difícil, más flacas son las ganancias, hasta que los ingenieros con experiencia de METR cruzan a terreno negativo.
Así que ambas cosas son ciertas. La IA hizo la parte fácil más rápida y la parte difícil más difícil, y ahora casi todo el trabajo es la parte difícil.
Nadie habla de la ventana de contexto humana
Cada nuevo modelo presume de una ventana de contexto más grande. Nadie menciona la que no cambió. La ventana de contexto del ingeniero es el mismo cerebro de siempre, al que ahora se le pide sostener más complejidad arquitectónica por hora porque el trabajo de descanso que marcaba el ritmo del día ya no está.
Ahí es donde se acumula la deuda de comprensión. Rajamani cuenta que mandó a producción código generado por IA que no entendía del todo, y lo pagó después con un problema de depuración de tres semanas. El código llega más rápido que tu comprensión de él, y esa distancia no desaparece. Se traslada a las fases siguientes y se va sumando.
Los ingenieros que se lo toman en serio tratan la verificación como innegociable. La regla de Simon Willison es tajante: "Si no lo has visto funcionar, no es un sistema que funcione." Martin Fowler recomienda tratar cada cambio de la IA como un pull request de "un colaborador bastante dudoso, muy productivo en el sentido de líneas de código", pero en cuyo trabajo no puedes confiar a primera vista. Leer y juzgar ese resultado es trabajo cognitivo real, y recae por completo en la persona.
Las habilidades que desaparecen sin hacer ruido
El criterio no es innato. Es el poso de haber hecho el 80% a mano, las veces suficientes como para notar que algo no encaja antes incluso de poder explicar por qué. Quita la práctica y debilitas aquello que la práctica producía.
Unos investigadores de Microsoft y Carnegie Mellon encuestaron a trabajadores del conocimiento y encontraron que cuanto más confiaba alguien en la IA, menos pensamiento crítico aplicaba. Delega el esfuerzo y el músculo que lo producía se va atrofiando.
La cantera que convierte júniors en perfiles sénior es la parte más expuesta. El estudio "Canaries in the Coal Mine" de Stanford, con datos de nómina de millones de trabajadores en EE. UU., encontró que los trabajadores de entre 22 y 25 años en las ocupaciones más expuestas a la IA, el desarrollo de software entre ellas, sufrieron una caída relativa del 16% en el empleo. Los trabajadores con experiencia en esos mismos campos, no. Si el trabajo de entrada que antes formaba a la gente es justo el que ahora hace la IA, la pregunta evidente es de dónde saldrá la siguiente generación de perfiles sénior.
Addy Osmani pone nombre a lo que sobrevive: "El trabajo de un ingeniero sénior es, sobre todo, las partes que no aparecen en el diff. Especificaciones. Tests. Revisiones. Disciplina sobre el alcance. Negarse a enviar lo que no se puede verificar." Esas son las habilidades que cuestan años y unos cimientos del tamaño de una carrera, y son justo las que la IA no te puede regalar.
Por qué la tarifa sube, no baja
Esta es la parte que debería cambiar cómo le pones precio al trabajo de ingeniería. No puedes obtener más producto por el mismo dinero cuando el trabajo que queda es más difícil.
Un ingeniero sénior que lleva tres proyectos con IA a la vez produce más que antes. Pero pilotar la IA, revisar lo que escribe, cazar las respuestas casi correctas, mantener la arquitectura en pie, decidir qué no se construye, es un trabajo más duro que la ejecución que sustituyó. Más producto con mayor carga cognitiva por hora no es un argumento para una tarifa más baja. Lo es para una más alta.
La escasez apunta en la misma dirección. La habilidad que ahora abunda es la ejecución, y lo que abunda se abarata. La que ahora escasea es el criterio para dirigir toda esa ejecución, y los datos de Stanford muestran que el mercado ya la está protegiendo: la gente con experiencia conservó su empleo mientras los júniors perdían terreno. Cuando el 20% difícil se convierte en todo el trabajo y hay menos gente formándose para hacerlo, quienes saben hacerlo bien no se abaratan. Se convierten en el cuello de botella que todos pagan por sortear.
Ahora el arquitecto es el bien escaso
El trabajo que la IA volvió escaso es el de un arquitecto de software con experiencia: plantear el problema real, diseñar bajo restricciones reales, decidir qué no construir y dar la cara por el resultado. La IA convirtió teclear en una mercancía corriente. Volvió escaso el criterio, y la escasez es lo que da valor a las cosas.
Esa es la persona sobre la que se construye IBERANT: ingenieros sénior que apuntan la IA hacia la ejecución y mantienen el criterio en manos humanas, porque esa parte nunca fue el 80% barato. Si estás intentando averiguar cómo organizar un equipo en torno a herramientas cuyo precio y capacidades no paran de moverse, hablemos.