IA en ingeniería: qué premias al medir su uso

Un responsable de ingeniería abre el panel de adopción de IA. Un equipo consume más tokens, genera más cambios y aparece arriba. Otro ha eliminado una integración innecesaria y apenas ha usado el asistente esta semana. Si ese panel decide quién progresa profesionalmente, la organización acaba de expresar qué trabajo quiere, aunque su estrategia diga otra cosa.

La pregunta no es si debemos aprender a trabajar con IA. Es qué evidencia permite exigir ese aprendizaje sin convertir el consumo en una obligación de producir actividad visible. Una métrica puede servir para investigar una diferencia entre equipos y ser inadecuada para evaluar a una persona. Cambiar su uso cambia también los incentivos de quienes aparecen en ella.

La tensión que deja abierta Amazon

En su comunicado del 27 de octubre de 2026, Amazon revisa el papel del ingeniero de software y centra la evaluación en resultados duraderos y pide aprender a utilizar IA. Reconoce los defectos de medir tokens, cambios de código o revisiones, pero considera útiles las señales de adopción para investigar equipos con uso bajo o alto. También reconoce como criterio profesional explicar dónde las herramientas actuales no ayudan.

El texto afirma que observa correlación entre adopción y resultados. No publica allí una muestra, una estimación del efecto ni un diseño que permita aislar causalidad. Es una posición de dirección de ingeniería, no un experimento que demuestre cuánto mejorará otro equipo.

La tensión me parece más interesante que un titular a favor o en contra de la IA. Si la señal de adopción entra en una conversación sobre carrera profesional, ¿qué impide que termine funcionando como objetivo informal? No hace falta fijar una cuota escrita. Basta con que cada persona aprenda qué gráfico tiene que justificar.

Del diagnóstico al incentivo hay un cambio de sistema

Supongamos que los equipos con mayor adopción entregan más. Puede existir un efecto real de las herramientas. También puede influir que esos equipos tengan mejor plataforma, tareas más compatibles con la generación, más tiempo para experimentar o una dirección que elimina bloqueos. Incluso puede invertirse parte de la explicación: disponer de margen permite adoptar mejor.

Comparar consumidores intensivos con consumidores ocasionales mezcla esas diferencias. Y evaluar después a todos por consumo introduce otra: quienes quieren mejorar su posición pueden elegir tareas fáciles de generar, fragmentar cambios o mantener conversaciones innecesarias. La relación observada antes del incentivo no garantiza la misma relación después.

El error difícil de detectar aparece cuando el panel mejora de verdad. Los registros son correctos, el uso crece y nadie ha falsificado nada. Lo que ha cambiado es la distribución del trabajo. El equipo resuelve más tareas contables porque ahora compensa convertir el trabajo en tareas contables.

Por eso separaría dos decisiones: localizar dónde conviene investigar y decidir a quién recompensar. Un percentil bajo puede abrir una conversación sobre acceso, restricciones o adecuación de la herramienta. No identifica por sí mismo resistencia al cambio. Uno alto puede señalar una práctica que merece compartirse o un coste de iteración que nadie ha relacionado con su resultado.

Los estudios no miden una única productividad

Hay evidencia experimental de beneficios. El resumen de Cui y colaboradores publicado por Microsoft Research en junio de 2025 reúne tres experimentos aleatorizados en Microsoft, Accenture y una empresa Fortune 100: 4.867 desarrolladores y un aumento estimado del 26,08 % en tareas completadas, con error estándar de 10,3 puntos porcentuales. El acceso al asistente se asignó aleatoriamente; los autores señalan mayor adopción y ganancias entre desarrolladores con menos experiencia.

Esa cifra mide tareas completadas en aquellos entornos. No es un porcentaje de beneficio empresarial ni una mejora garantizada para cualquier ingeniero. La incertidumbre importa: el error estándar no es un intervalo de confianza, y una estimación conjunta no describe necesariamente cada empresa.

En otro contexto, el ensayo de METR con herramientas de principios de 2025 estudió a 16 desarrolladores experimentados y 246 tareas en repositorios que conocían. Permitir IA aumentó el tiempo de realización un 19 %. Los participantes creyeron después que habían trabajado más rápido. El resultado corresponde a esa población, esas tareas y aquellas herramientas; no mide el efecto de los modelos de octubre de 2026.

Además, METR explicó en febrero de 2026 que su siguiente experimento daba una señal poco fiable sobre el efecto actual: algunos desarrolladores no querían participar sin IA y otros evitaban presentar tareas que preferían realizar con ella. También había dificultades para medir tiempo cuando se trabajaba con agentes en paralelo. La selección estaba cambiando precisamente porque cambiaba la utilidad percibida de las herramientas.

No resolvería estas diferencias haciendo una media entre porcentajes. Un estudio mide volumen de tareas; otro, tiempo de ejecución. Las poblaciones, herramientas y condiciones tampoco coinciden. Son evidencias para formular hipótesis locales, no dos votos que permitan declarar ganadora una posición general.

Una encuesta posterior de METR, publicada en mayo de 2026, separó velocidad y valor percibido entre 349 trabajadores técnicos. Las medianas declaradas de aumento de valor variaban entre 1,4 y 2 veces según la pregunta; la de velocidad era 3 veces. Era una muestra de conveniencia y una estimación de los participantes, no una medición causal de valor entregado. Sirve para mostrar qué preguntas creen poder responder, con sus sesgos; no para convertir percepción en ahorro presupuestario.

La unidad útil es el cambio aceptado y sus consecuencias

Para una decisión de inversión, observaría un recorrido completo: necesidad seleccionada, trabajo producido, revisión, aceptación y comportamiento posterior. El tiempo hasta la primera propuesta puede mejorar mientras la carga del revisor crece. También puede aumentar la calidad sin reducir el tiempo. Ambas situaciones desaparecen si solo contamos generación.

El marco SPACE, publicado en 2021, ya planteaba que la productividad del desarrollador no se reduce a actividad individual ni a una sola dimensión. La llegada de mejores herramientas no elimina ese problema de medida.

Mi propuesta sería definir una familia de cambios suficientemente comparable y una condición de aceptación estable. En mantenimiento de una API, por ejemplo, no contaría igual corregir un mensaje y modificar compatibilidad con consumidores. Registraría tiempo de trabajo del autor, tiempo de revisión, espera y correcciones posteriores por separado. Las horas que transcurren y las horas de personas no son intercambiables: dos agentes concurrentes pueden reducir calendario sin reducir supervisión humana.

También fijaría una ventana de observación posterior adecuada al servicio. Si solo contabilizamos aceptación inicial, dejamos fuera defectos que aparecen con tráfico real. Si esperamos indefinidamente, nunca decidimos. La ventana debe responder al mecanismo de fallo y conservar explícitamente qué consecuencias todavía no ha podido observar.

Esto conecta con la capacidad real de revisión humana, pero aquí la decisión es otra: dónde atribuir una mejora y qué comportamiento reforzar. Acelerar la producción mientras se transfiere trabajo a otro equipo puede ser una mejora local y un empeoramiento del servicio.

Un contrato de uso para cada métrica

Propongo este contrato como herramienta propia de gobierno de la medición. Antes de incorporar un indicador a una evaluación profesional, dejaría escrito qué decisión puede sostener, qué evidencia falta y qué uso queda fuera de su alcance.

Adopción de la herramienta

Permite investigar acceso, aprendizaje y adecuación por tipo de trabajo. Necesita contexto de tareas y restricciones. No demuestra rendimiento individual.

Consumo y coste

Permite presupuestar y localizar iteraciones costosas. Necesita resultado aceptado, costes de revisión y casos fallidos. No convierte más gasto en más contribución ni menos gasto en mejor trabajo.

Trabajo aceptado por familia

Permite comparar capacidad de entrega bajo una definición estable. Necesita complejidad, retrabajo, calidad y demanda. No permite comparar personas asignadas a trabajos distintos.

Efecto en el servicio

Permite decidir si ampliar una práctica: fiabilidad, plazo útil, satisfacción o coste operativo según el objetivo. Necesita una ventana suficiente y considerar otros cambios simultáneos. No atribuye por sí solo todo el efecto a la IA.

Este contrato cambia una reunión concreta. Ante un equipo de poco uso, la pregunta deja de ser «¿por qué estás abajo?» y pasa a ser «¿qué parte de tu trabajo merece una prueba y qué impediría aprovecharla?». Ante uno de uso alto, pide identificar qué entrega adicional o mejora de calidad justifica el consumo. Ambos tienen que aportar evidencia; ninguno recibe una conclusión automática.

Exigir aprendizaje sin premiar consumo

Una organización puede exigir competencia con herramientas relevantes sin exigir utilizarlas en cada tarea. Evaluaría si la persona sabe seleccionar un uso, comprobarlo, explicar sus límites y compartir una práctica reproducible. La decisión fundamentada de prescindir del asistente también puede demostrar competencia, pero debería poder revisarse cuando cambien la herramienta o las condiciones.

Para comprobar una mejora local, un despliegue escalonado entre grupos comparables puede aportar más que un ranking de usuarios voluntarios. Conviene registrar las tareas elegibles antes de conocer los resultados, mantener las reglas de aceptación y observar a quienes reciben acceso aunque apenas lo utilicen. Excluirlos después contesta otra pregunta: qué ocurre entre quienes decidieron adoptar, con la selección que eso implica.

La aleatorización tampoco borra todo. Los equipos comparten prácticas, un revisor puede atender ambos grupos y el aprendizaje continúa. Hay que describir esas interferencias y considerar el equipo como unidad cuando la intervención se transmite entre personas. Si no es viable experimentar, una comparación observacional sigue siendo útil para decidir un piloto acotado, siempre que no se presente como demostración causal.

¿Cuándo dejaría de aplicar una comparación? Si cambia sustancialmente el tipo de tarea, el modelo, la revisión o la condición de aceptación, revisaría su alcance. Si el beneficio consiste en hacer posible un trabajo antes inviable, medir solo minutos ahorrados ya no responde a la inversión: habrá que justificar por qué merece hacerse ese trabajo y qué alternativa desplaza.

La responsabilidad de dirección consiste en mantener conectadas herramienta, trabajo y resultado. Un equipo debería poder mejorar su evaluación eliminando complejidad, compartiendo conocimiento o descartando una generación innecesaria. Si el sistema de métricas castiga esas decisiones porque reducen el uso de IA, tenemos un problema de evaluación que ninguna herramienta más potente resolverá por nosotros.