Productividad de desarrolladores y agentes. Medida, no estimada.

La organización había democratizado el acceso a asistentes y agentes de IA para sus más de 500 desarrolladores, con una bolsa de tokens idéntica para todos (40 € por desarrollador al mes, 259K€ al año entre licencias y consumo). El gasto crecía un 9% cada trimestre y nadie sabía responder a la pregunta del comité: ¿quién está sacando partido a la IA y quién solo la está consumiendo?

Foreworth atribuyó a cada desarrollador los Achieved Days incrementales generados con apoyo de IA y los cruzó con su consumo real de tokens. El resultado fue un ranking de retorno por persona, comparable entre equipos, que sirvió de base para reasignar los créditos cada mes.

• El coste por Achieved Day incremental bajó un 27% (84 → 61 €) con el mismo gasto y un 37% más de producción atribuible a IA; el ROI ajustado a IA pasó de 5,0x a 6,8x. Los 95 Achieved Days adicionales al mes, sumados en toda la organización, equivalen a ≈480K€ al año de capacidad.
• El 21% de los desarrolladores (114 personas) concentraba el 66% de los Achieved Days incrementales atribuibles a IA. Tras la reasignación, ese grupo pasa de recibir el 21% a recibir el 45% de los créditos y concentra el 81% de los Achieved Days incrementales.
• El 27% del gasto en tokens (5,8K€ al mes) se destinaba a perfiles cuyo Net Achieved Days apenas variaba con el uso de IA. Tras la reasignación, ese gasto baja al 6% (1,3K€ al mes), con un mínimo garantizado para los perfiles en onboarding.
• En los perfiles de mayor consumo y menor retorno, el Code Churn llegaba al 31%, el doble del benchmark de Foreworth (15%).
• El 38% de los perfiles de mayor retorno tenía menos de 3 años de experiencia: el rendimiento de la IA no dependía de la seniority.
• Próximo paso: automatizar la asignación mensual de créditos con un tope por equipo y alertas de gasto sin retorno.

Tres herramientas de IA y tres opiniones. Los equipos defendían la que más usaban y cada herramienta presumía de sus propios informes de adopción. Dirección tenía un trimestre para decidir cuál se desplegaba a más de 5.000 desarrolladores, con un contrato plurianual difícil de revertir.

Piloto de 4 meses con 612 desarrolladores: tres grupos equivalentes de 153 (por seniority y tecnología), uno por herramienta, más un grupo de control sin IA de otros 153. Foreworth midió las tres herramientas con el mismo método: Achieved Days por desarrollador, Code Churn del código generado y coste por Achieved Day incremental (coste total mensual por desarrollador, licencia y consumo, ÷ Achieved Days adicionales frente al grupo de control).

• Achieved Days medios por desarrollador: 8,1 sin IA; 8,4 con la herramienta A (+3,7%); 8,7 con la C (+7,4%); 9,1 con la B (+12,3%).
• Coste total por desarrollador y mes (licencia y consumo): 38 € con A, 34 € con B y 26 € con C. Coste por Achieved Day incremental: 127 €, 34 € y 43 € respectivamente: la más cara era la que menos rendía.
• ROI ajustado a IA (Achieved Day valorado a 420 €): 12,4x con B, 9,7x con C y 3,3x con A.
• Code Churn del código generado: 22% con A, 16% con C y 12% con B, frente al 15% del benchmark de Foreworth. La Review Load con A subió de 13,1 a 16,8 días por desarrollador (+28%); con B se mantuvo en 13,4.
• La herramienta A tenía la mayor tasa de uso diario (82%) y el menor retorno: adopción no equivale a valor. Desplegar B en lugar de A, además, ahorra 0,24M€ al año (4 € menos por desarrollador y mes).
• Próximo paso: despliegue progresivo de la herramienta B a 5.000+ desarrolladores en tres oleadas, con revisión trimestral de coste por Achieved Day y Code Churn.

Más de 1.500 desarrolladores repartidos en decenas de equipos y la sensación generalizada de que no todo el mundo produce igual. Sin un dato objetivo, cualquier decisión sobre personas sonaba a arbitrariedad y los mandos intermedios no se atrevían a señalarla.

Achieved Days por desarrollador sobre 6 meses de histórico de repositorios, contextualizados con partes de horas, roles, incorporaciones y bajas. La contextualización fue clave: separamos el «no produce» del «no produce código por una razón legítima» (gestión, QA, bajas largas, onboarding) antes de que ningún nombre llegara a Dirección.

• Tras contextualizar con partes de horas y roles, el 15,3% inicial (≈230 desarrolladores) quedó en un 9,3% (≈140) sin justificación.
• De esos ≈140 perfiles, 65 (4,3% de la plantilla) salieron o no se renovaron; el resto pasó a un plan de mejora con seguimiento mensual.
• La distribución de Ownership mostraba alta concentración: el 40% de los módulos críticos dependía de un único desarrollador, y solo 60 personas (el 4% de la plantilla) sostenían ese 40%.
• El Achieved Days medio por desarrollador estaba un 35% por debajo del benchmark de Foreworth (10 días/mes): 6,5.
• Próximo paso: extender el análisis a los proveedores externos del programa de outsourcing.

Doce proveedores, más de 500 desarrolladores externos y 31M€ al año facturados por horas. La VMO no tenía forma de saber quién producía qué: los partes de horas los redactaba cada proveedor y los informes de entrega, también.

Achieved Days por proveedor y por desarrollador individual, cruzados con las horas facturadas en cada parte. Un ranking de proveedores por Achieved Days por euro facturado y una lista nominal de desarrolladores facturados sin commits equivalentes, lista para el comité de proveedores.

• 48 desarrolladores (9,2% de los externos) facturados sin actividad de código detectable en 6 meses: desarrolladores fantasma, 2,9M€ al año.
• El coste por Achieved Day medio de la cartera era de ≈630 €, 1,6x el del mejor proveedor (≈395 €); el peor llegaba a ≈1.190 € (3,0x): cobraba el triple por cada día entregado. Alinear el pago con la entrega real ahorra 1,6M€ al año.
• Los 2 proveedores con peor ratio concentraban el 41% de la facturación. La concentración de la cartera suma 0,9M€ adicionales.
• Los 5 mejores proveedores entregaban 11,4 Achieved Days por desarrollador al mes frente a 5,9 de los 5 peores.
• Próximo paso: modelo de pago variable ligado a Achieved Days en la renovación de contratos de 2027.