La mayoría de los comités de dirección que revisan hoy su inversión en asistentes de programación con IA se apoyan en dos fuentes: el gasto en licencias y lo que los propios equipos dicen sobre su experiencia. La segunda fuente es la que más pesa en la decisión de renovar o ampliar, y es también la menos fiable. Existe evidencia experimental de que la percepción de velocidad de un desarrollador puede ir en dirección contraria a su rendimiento real.
El experimento que invirtió el signo
En 2025, la organización de investigación METR publicó un ensayo controlado aleatorizado con 16 desarrolladores de código abierto experimentados sobre 246 tareas reales en repositorios que ellos mismos mantenían: proyectos maduros, de gran tamaño, en los que llevaban años trabajando. Cada tarea se asignaba al azar a una de dos condiciones: con acceso a asistentes de IA o sin él.
Antes de empezar, los participantes estimaron que la IA les haría un 24% más rápidos. Al terminar, y ya habiendo trabajado en ambas condiciones, seguían creyendo que habían ganado en torno a un 20% de velocidad. La medición de los tiempos reales mostró lo contrario: tardaron un 19% más en las tareas con asistente que en las tareas sin él.
El detalle relevante para un directivo no es el signo del resultado, sino la magnitud del error de percepción. Hablamos de casi cuarenta puntos de diferencia entre lo que la gente creía que estaba pasando y lo que estaba pasando. Si su organización está evaluando el impacto de la IA mediante encuestas internas de satisfacción o percepción de productividad —que es lo habitual—, está midiendo con un instrumento que en este experimento apuntó al lado equivocado.
Por qué otros estudios sí encuentran ganancias
Sería un error leer el trabajo de METR como una refutación general de los asistentes de código. Existen experimentos de campo con resultados positivos y sólidos. El más citado es el estudio aleatorizado sobre GitHub Copilot realizado en Microsoft, Accenture y una gran empresa industrial, que midió un aumento cercano al 26% en tareas completadas por semana, con un efecto notablemente mayor entre los desarrolladores con menos antigüedad.
Las dos conclusiones no se contradicen porque no miden lo mismo. Las condiciones son distintas en tres ejes:
- Familiaridad con el código. En METR los participantes conocían el repositorio a fondo. Un experto que ya sabe dónde tocar compite contra una herramienta que tiene que reconstruir ese contexto desde cero, y luego dedica tiempo a revisar y corregir la propuesta.
- Tipo de tarea. Escribir código nuevo en un dominio conocido y estandarizado no se parece a modificar un sistema grande con dependencias implícitas, convenciones no escritas y requisitos de calidad altos.
- Perfil del desarrollador. El beneficio marginal es mayor cuando la alternativa es buscar en documentación durante media hora. Ese es el caso de un perfil junior, no el de quien mantiene el módulo desde hace cinco años.
El informe DORA de 2024 apunta en una dirección compatible: a medida que aumentaba la adopción de IA en los equipos, subía la productividad percibida, pero se deterioraban indicadores de entrega como el rendimiento del flujo y la estabilidad de los despliegues. La sensación de ir rápido y la capacidad de poner cambios en producción sin romper nada son dos cosas que pueden moverse en sentidos opuestos.
Qué implica para la medición interna
Recomendamos a nuestros clientes retirar tres métricas del cuadro de mando de IA en ingeniería, porque generan lecturas falsamente positivas:
- Líneas de código o volumen de sugerencias aceptadas. Miden actividad de la herramienta, no valor entregado. Un asistente que produce más código puede estar generando más superficie que revisar y mantener.
- Encuestas de percepción de velocidad. Sirven para medir adopción y satisfacción, que son cosas legítimas de medir. No sirven como evidencia de rendimiento.
- Número de commits o de pull requests. Se inflan con facilidad y no capturan el coste posterior.
En su lugar, proponemos tres indicadores que sí resisten:
- Tiempo de ciclo de extremo a extremo, desde que la tarea entra en curso hasta que el cambio está en producción. Incluye la revisión, que es donde suele reaparecer el tiempo que la generación de código ahorró.
- Retrabajo. Porcentaje de cambios que hay que revertir, corregir o volver a tocar en un plazo corto. Es el indicador que más rápido delata una ganancia aparente.
- Estabilidad del servicio tras el despliegue: incidencias y fallos atribuibles a cambios recientes.
Cómo diseñar una evaluación que dé una respuesta útil
La consecuencia operativa del desfase entre percepción y realidad es que la evaluación tiene que segmentarse. Un dato agregado del conjunto del departamento mezcla poblaciones que responden de forma distinta a la herramienta y produce una media sin significado.
Un diseño razonable separa al menos por familiaridad con la base de código (equipos que mantienen sistemas antiguos frente a equipos que arrancan productos nuevos), por tipo de trabajo (evolutivo sobre sistema legado, desarrollo nuevo, corrección de incidencias, pruebas) y por antigüedad del perfil. Cada segmento se mide con las mismas tres métricas durante un periodo suficiente para acumular volumen, y se compara con su propia línea base anterior a la herramienta, no con la de otro equipo.
Con esa segmentación, la decisión deja de ser binaria. La pregunta pertinente no es si la organización adopta IA en ingeniería, sino en qué segmentos concentra las licencias, en cuáles conviene acompañar la adopción con cambios en el proceso de revisión, y en cuáles el retorno todavía no aparece en los números. Esa es una conversación de asignación de recursos, y admite una respuesta con datos propios.