Cómo medir la adopción de IA en equipos de ingeniería de software

Alguien de la dirección pregunta cuántos ingenieros usan las herramientas de IA que paga la empresa, y la respuesta que llega es el número de licencias. Las licencias dicen qué se compró. No dicen si el equipo de frontend abre Cursor todos los días mientras la mitad del equipo de backend lo probó una vez en marzo y volvió a su forma de trabajar de siempre.

¿Por qué el número de licencias no mide la adopción de IA?

El número de licencias mide gasto, no adopción, porque una licencia queda asignada aunque nadie la use. Los inicios de sesión son apenas un poco mejores. DX, que publica uno de los marcos de medición de IA más conocidos, advierte que el total de inicios de sesión engaña porque el uso de una sola vez y el uso habitual se ven iguales en ese número.

La adopción es un comportamiento: personas que recurren a una herramienta de IA como parte de su trabajo, semana tras semana, en tareas reales. Un comportamiento se mide con actividad a lo largo del tiempo, y hace falta más de un número para ver su forma.

¿Qué dice la investigación sobre la adopción de IA hoy?

Las encuestas de la industria muestran una adopción casi total, y justo por eso un equipo necesita sus propios números. El informe DORA 2025, con respuestas de casi 5.000 profesionales de tecnología, encontró que el 90 % usa IA en el trabajo, con una mediana de dos horas diarias. La encuesta de desarrolladores de Stack Overflow 2025, con unas 49.000 respuestas, encontró que el 84 % usa o planea usar herramientas de IA y que el 51 % de los desarrolladores profesionales las usa a diario.

Las mismas encuestas muestran el problema. En los datos de Stack Overflow, el 46 % desconfía de la precisión de lo que produce la IA y solo el 33 % confía. En los de DORA, el 30 % declara poca o ninguna confianza. Un equipo puede figurar como “adoptado” y aun así usar la IA solo para código repetitivo porque nadie le confía nada más. Los promedios de la industria esconden eso. Tus propios números de alcance, frecuencia y profundidad no.

¿Qué métricas de adopción de IA debería seguir un equipo de ingeniería?

Sigue cuatro dimensiones, cada una con una métrica principal, y agrega una quinta para las capacidades que el equipo distribuyó a propósito.

Dimensión	Métrica	La pregunta que responde	Cuidado con
Alcance	Parte de los miembros activos con IA en el periodo	¿Cuántas personas la usan?	“Activo” debe significar uso real, no un inicio de sesión
Frecuencia	Días activos o sesiones por persona	¿Es un hábito o un experimento?	Unos pocos usuarios intensivos inflan el promedio; mira la mediana
Profundidad	Parte de los commits y pull requests con evidencia de IA	¿Cuánto de lo que se entrega tocó la IA?	La detección es una heurística, no una prueba
Concentración	Parte del uso que viene del 10 % más activo	¿La adopción está repartida o la sostienen unos pocos?	Una concentración alta es normal al inicio
Uso de capacidades	Invocaciones de las skills y los servidores MCP compartidos	¿Se usa la configuración que el equipo acordó?	Solo funciona si se registran por nombre

Dos notas prácticas. Elige una sola definición de “activo” y mantenla: “usó una herramienta de IA al menos un día de la semana” es simple y difícil de discutir. Y deja fijo el periodo (siete días, treinta días) para que cada número se compare con el periodo anterior de la misma duración.

¿Cómo se implementa la medición de adopción de IA, paso a paso?

1. Escribe qué cuenta como activo. Una frase en la documentación del equipo. Desde ahí, todos leen el tablero de la misma forma.
2. Lista cada herramienta de IA en uso, incluidas las no oficiales. Pregúntale al equipo. Una herramienta sin telemetría aparece como “no adoptada” cuando en realidad es la favorita.
3. Conecta las fuentes que ya tienes. El tablero y la API de métricas de uso de Copilot de GitHub reportan usuarios activos diarios y semanales, adopción de agentes y líneas agregadas. Claude Code exporta métricas de OpenTelemetry como claude_code.session.count, claude_code.commit.count y claude_code.pull_request.count. Git aporta commits y pull requests.
4. Toma una línea base de 30 días antes de cambiar nada. Un despliegue, una capacitación o una configuración compartida nueva solo se puede medir contra un antes.
5. Separa por herramienta y por repositorio. Un único número de adopción para una organización de 200 personas promedia y borra al equipo que nunca empezó.
6. Agrega una pregunta corta de encuesta cada trimestre. “¿Cuánto tiempo te ahorraron las herramientas de IA la semana pasada?” es la única forma de ver el lado del valor que la telemetría no capta. El marco de DX combina telemetría justo con este tipo de ahorro de tiempo declarado.
7. Revisa cada mes, con el periodo anterior junto al actual. La dirección importa más que el nivel.

En Claude Code, activar la telemetría son unas pocas variables de entorno, que un admin también puede fijar para todos con la configuración administrada:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4317

Eso lleva una herramienta a un colector. Un equipo que usa Claude Code, Cursor y Copilot al mismo tiempo todavía tiene que unir tres fuentes, y ahí es donde se estancan la mayoría de los tableros de adopción hechos en casa.

¿Cómo mide HubBound la adopción de IA?

HubBound Métricas mide la adopción con dos fuentes: la telemetría de agentes que el Runtime y la CLI de HubBound reportan desde la máquina de cada desarrollador, y el GitHub de la organización. La sección Sesiones muestra Sesiones en el tiempo, Activos con IA (las personas que usaron IA al menos una vez en el periodo), Calendario de actividad y Sesiones por herramienta. La sección Skills y MCP muestra Skills más usadas y Servidores MCP más usados, que es la fila de uso de capacidades de la tabla anterior.

La pestaña Hallazgos lee el periodo y redacta hallazgos como Tasa de adopción, Miembros inactivos y Concentración de adopción, cada uno comparado con el periodo anterior de la misma duración. Un Admin de org ve toda la organización y puede acotarla a un miembro; el resto ve solo su propia actividad. Las métricas no se dividen por equipo, así que un desglose por equipo todavía necesita filtrar por miembro o una segunda herramienta.

¿Cuándo engañan los números de adopción de IA?

Los números de adopción engañan en cuanto alguien los lee como productividad. Un equipo donde todos usan IA cada día puede entregar al mismo ritmo que antes: la adopción mide cuánto se usan las herramientas, no qué cambió ese uso más adelante. Reporta la adopción como adopción, y pon números de entrega al lado cuando la conversación sea sobre resultados.

También engañan cuando se convierten en un ranking de personas. Publicar “los usuarios menos activos” convierte una medición en vigilancia, y la gente responde abriendo la herramienta sin usarla. Usa los datos por persona para encontrar, en privado, a quién le falta ayuda para empezar, y reporta hacia arriba el número del equipo.

Por último, los huecos de cobertura parecen falta de adopción. Si una herramienta no está instrumentada, sus usuarios aparecen inactivos. Antes de actuar sobre un número bajo, confirma que la herramienta que esas personas usan de verdad está reportando.

¿Qué debería medir primero un equipo?

Empieza por el alcance y la concentración, no por la profundidad. La profundidad (cuánto código tiene evidencia de IA) es el número que todos quieren, pero tiene ruido y es fácil de discutir. El alcance y la concentración son difíciles de discutir, y juntos responden la pregunta que decide el siguiente paso: ¿el uso de IA está repartido en el equipo o lo sostienen tres entusiastas?

La lista más útil no suele ser la de las personas más activas, sino la de quienes estuvieron activos una vez y luego dejaron de usarla. Alguien que nunca empezó quizá no necesite IA para su trabajo. Alguien que probó y abandonó se topó con algo: una configuración que no funcionaba, un archivo de reglas que peleaba con su código, una herramienta que no llegaba a sus sistemas. Eso es un problema de habilitación, y es la mejora de adopción más barata que un equipo va a encontrar.