Seguimos midiendo a los ingenieros por la parte que se automatizó.

Hay una frase que los ingenieros con veinte años de experiencia dicen ahora en voz baja, como quien confiesa algo: ya no escribo código.

Suele venir con una pequeña disculpa pegada. No debería. Lo interesante de esa frase no es lo que dice sobre quien la pronuncia. Es lo que dice sobre los instrumentos que usamos para decidir si esa persona es buena en lo suyo.

El marcador se tiró, y casi nadie se dio cuenta

Durante cerca de una década, la industria clasificó la entrega en cuatro números y ordenó a los equipos en low, medium, high y elite. Esos niveles se citaban en presentaciones de consejo por gente que nunca había leído el informe de origen, que suele ser la señal de que una medición ha pasado a ser realmente estructural.

En 2025 DORA los abandonó. Los niveles desaparecieron y fueron sustituidos por siete arquetipos de equipo, descritos sobre ocho medidas: throughput, estabilidad, desempeño del equipo, desempeño del producto, eficacia individual, tiempo dedicado a trabajo con valor, fricción y agotamiento. Los arquetipos tienen nombres en lugar de posiciones, del tipo que no se pone en una diapositiva fingiendo que es una nota.

Se puede discutir con razón que esto es más difícil de aplicar que cuatro números y una escalera. Lo es. Pero el motivo del cambio es la parte que merece asentarse: la mitad de esas ocho medidas no va de producción en absoluto. Fricción, agotamiento, tiempo en trabajo con valor y eficacia individual miden si una organización está desperdiciando el criterio que emplea.

Es una admisión muy concreta. Dice que el instrumento antiguo medía el volumen de trabajo y perdía el interés en saber si el trabajo era el correcto, y que esa distinción dejó de ser asumible.

Qué dicen los números, y por qué incomodan

Los datos de 2025 explican la urgencia. Alrededor del 90% de los encuestados declararon usar IA en su trabajo, con una mediana en torno a dos horas al día, cuando el año anterior eran el 75%. Comparando personas con características y entornos iguales en todo lo demás, más adopción de IA aparece asociada a mayor eficacia individual, mayor throughput, mejor desempeño organizativo y mejor calidad declarada de código y producto.

Y a mayor inestabilidad en la entrega de software.

Vale la pena leer ese par despacio, porque su forma es el argumento. La IA movió casi todas las métricas en la dirección correcta, salvo la que dice si el sistema se mantiene en pie. Las medidas que mejoraron son las que cuentan producción. La medida que empeoró es la que cuenta consecuencias.

Si su idea de un ingeniero se construye con las primeras cinco filas, los últimos dos años parecen un triunfo. Si se construye con la última, parecen un aviso. Ambas lecturas salen del mismo conjunto de datos, y es exactamente por eso que el marcador tuvo que cambiar.

Esto ya ocurrió antes, y sabemos cómo acaba

Hace veinte años, un buen administrador de sistemas era alguien que configuraba bien un servidor. La competencia era real y era escasa, y se medía por una especie de throughput: cuántas máquinas, con qué rapidez, con qué pocos errores.

Después llegó la gestión de configuración, y a continuación la infraestructura como código. El ingeniero dejó de escribir la configuración y pasó a describir el estado deseado. Hoy nadie cree que un ingeniero que usa Terraform sea menos capaz que uno que configura máquinas a mano. Al contrario: consideramos la configuración a mano un riesgo, porque no se revisa, no se reproduce y no se revierte.

El trabajo no desapareció. Subió un nivel. Lo que era un acto de producción pasó a ser un acto de especificación, y la dificultad cambió de sitio: dejó de estar en ejecutar bien y pasó a estar en decidir bien, porque un error en un módulo llega ahora a cuatrocientas máquinas en lugar de a una.

Nunca llamamos a eso una caída. Lo llamamos madurez, y subimos los salarios en consecuencia.

La misma escalera, en tres peldaños:

El software de aplicación está subiendo ahora los mismos peldaños, y quien lo está viviendo lo describe en el lenguaje de la pérdida. Fíjese en qué peldaño tomó la automatización cada vez. Tomó el de la izquierda, y dejó el de la derecha exactamente donde estaba.

Qué subió de verdad de nivel

Conviene ser preciso sobre qué parte del trabajo cambió, porque la respuesta es más pequeña de lo que sugiere el entusiasmo y mayor de lo que admiten los escépticos.

Lo que se abarató fue la transcripción. Pasar a sintaxis que una máquina acepta una decisión que ya estaba tomada. Siempre fue la parte menos interesante, y consumía una porción enorme del día.

Lo que no se abarató es todo lo que viene antes de la primera línea: si aquello debe ser un servicio o una función, cuál es el modo de fallo cuando el tercero está caído, cuál de estos dos modelos de datos va a doler dentro de dieciocho meses, si aquella integración crea una dependencia de la que el negocio no puede salir. Escribimos sobre el lado de la calidad del código en la IA resolvió la sintaxis, no resolvió el criterio. Esto es la versión organizativa de la misma frontera.

Un agente ya escribe el código, genera las pruebas, abre el pull request y actualiza la documentación. Son tareas de producción y se están automatizando en ese orden. Lo que ningún agente hace hoy es decir que aquello que acaba de construir con todo el cuidado no debería existir.

La columna de la derecha no es una lista de cosas que los modelos nunca harán. Es una lista de cosas que exigen conocer la organización, su historia, sus contratos y su apetito de riesgo. Eso no son capacidades de un modelo. Es contexto que en su mayor parte no está escrito en ningún sitio, y por eso quien lo tiene pasó a valer más, y no menos.

Las decisiones que no tienen autocompletado

En la práctica, las decisiones que determinan si un sistema sobrevive se toman antes de escribir nada, y son menos de las que se supone. En un proyecto normal contamos quizá una docena que importen.

• Dónde cae la frontera entre dos sistemas, porque esa frontera se convierte en contrato y los contratos son caros de mover.
• Qué ocurre cuando una dependencia no está disponible, que es una decisión de negocio disfrazada de técnica.
• Qué datos son el sistema de registro, porque todo aguas abajo hereda esa elección.
• Qué puede hacer el sistema sin una persona, que pasó de pregunta teórica a pregunta real.
• Qué se decide deliberadamente no construir, que es la decisión menos escrita y más lamentada.

Cada una cabe en una frase y ninguna se delega en algo que no ha leído los últimos cuatro años de decisiones de su organización. Acertando en ellas, el código mediocre sobrevive. Fallando, el código excelente, generado deprisa, llega más deprisa a un sitio donde no quería estar.

Un ejemplo reciente, y a propósito sin ningún brillo. Un equipo necesitaba un paso de aprobación de documentos. La implementación obvia era un flujo en la plataforma donde los documentos ya vivían, y un asistente produce eso en una tarde, correctamente. La pregunta que nadie hizo primero fue si la aprobación era una propiedad del documento o un hecho de negocio. Era un hecho de negocio: la misma aprobación tenía que ser visible para un sistema que nunca tendría acceso a la biblioteca de documentos. La tarde de código correcto se habría tirado dentro del año, y el coste no habría sido la tarde. Habrían sido los seis meses en que dos sistemas discrepaban sobre qué se había aprobado.

Aquella decisión llevó veinte minutos y ninguna línea de código. Es también la razón entera por la que el proyecto no tuvo que rehacerse, y no aparecería en ninguna medición de la producción de aquel ingeniero esa semana.

La frase no es una confesión

Así que, cuando un ingeniero experimentado dice que ya no escribe mucho código, la lectura honesta suele ser lo contrario de la lectura avergonzada.

Es la misma frase que un administrador de sistemas habría dicho en 2012 sobre configurar servidores a mano, y hoy nadie oye aquello como una caída. Significa que la persona pasó de producir artefactos a decidir cuáles deben ser los artefactos, que es la dirección hacia la que fueron todas las disciplinas de ingeniería a medida que sus herramientas maduraron. Los ingenieros de estructuras dejaron de dibujar cada línea a mano. Eso no los convirtió en delineantes con menos competencias.

El riesgo de la frase es otro, y conviene nombrarlo. Un ingeniero que deja de escribir código por completo acaba por no poder evaluar el código que está aprobando, y el criterio sin contacto con el material se vuelve opinión. Quien hace esto bien no está escribiendo nada. Está escribiendo menos, a propósito, y leyendo muchísimo más.

Qué medir en su lugar

Si el throughput mejoró mientras la estabilidad empeoraba, entonces el throughput dejó de funcionar como aproximación al valor, y seguir premiándolo no es neutral. Selecciona activamente el comportamiento que produjo la inestabilidad.

Las medidas que vale la pena discutir son las que sobreviven a la automatización de la producción:

Todas las filas de la derecha son más difíciles de recoger que las de la izquierda, y eso no es casualidad. Lo que predice si un sistema sobrevive siempre fue más caro de medir que lo que predice cuán ocupado parecía todo el mundo. Automatizar el paso de producción quitó la última excusa para usar las baratas.

La parte que envejece bien

Las herramientas seguirán moviéndose. El modelo que hoy está en producción será sustituido dos veces antes de que esto envejezca, y el agente que este año abre pull requests hará el año que viene algo más ambicioso.

Lo que no se moverá es el sitio donde vive la dificultad. Ha subido la escalera de la abstracción en todas las disciplinas de ingeniería que alguna vez se automatizaron, y nunca ha vuelto a bajar. Cada vez ocurrieron las mismas tres cosas: el paso de producción se abarató, el coste de una decisión equivocada creció porque se propagaba más lejos, y la profesión pasó unos años incómodos midiendo lo que no era hasta que los instrumentos se pusieron al día.

Estamos en los años incómodos. DORA cambió su instrumento en 2025; la mayoría de las organizaciones aún no ha cambiado el suyo.

El valor de un ingeniero nunca fue de hecho el teclado. Solo era medible así, que es una afirmación distinta, y esa acaba de caducar.