# denisov-blanch-stanford-quantify-ai-roi-software-engineering-2025-11-23

## Veille

Stanford Research - Medición del ROI de la IA - Productividad de los Desarrolladores - Marco de Métricas - Brecha de Adopción de IA

## Titre Article

How to Quantify AI ROI in Software Engineering (Stanford Study / 120k Devs)

## Date

2025-11-23

## URL

https://www.youtube.com/live/cMSprbJ95jg?si=4HnxK8w1ELvSr4tz&t=9705

## Keywords

Stanford, ROI de la IA, Productividad de los Desarrolladores, Métricas, Calidad del Código, Deuda Técnica, Adopción de la IA, Engineering Output, Rework

## Authors

Yegor Denisov-Blanch (Researcher, Stanford)

## Ton

**Perfil:** Académico-Investigación | Basado en Datos | Analítico | Objetivo

El tono es el de una investigación académica rigurosa aplicada a la industria. El enfoque se fundamenta en evidencia cuantitativa (estudios longitudinales y transversales sobre 120.000 desarrolladores). El discurso busca desmitificar el "hype" mediante datos sólidos, proponiendo marcos de medición sofisticados (modelos de ML para evaluar el output, índices de limpieza del código). Es un llamado al rigor métrico dirigido a los líderes técnicos.

## Pense-betes

- **Brecha creciente**: Los equipos que rinden bien con la IA mejoran aún más ("el rico se hace más rico"), mientras que los equipos con dificultades se quedan aún más atrás. Saber a qué cohorte se pertenece es crítico.
- **Calidad de uso > Cantidad**: La correlación entre el número de tokens utilizados y la productividad es débil. Lo que importa es *cómo* se utiliza la IA (patrones de ingeniería).
- **Higiene del código (Cleanliness Index)**: Un código limpio, modular y probado amplifica las ganancias de la IA. Por el contrario, la IA utilizada sobre código desordenado acelera la entropía y la deuda técnica.
- **Medición del ROI**:
- No basarse en los resultados de negocio (demasiado ruido/factores de confusión).
- No basarse en métricas simplistas (líneas de código, número de PR). Un aumento de los PR puede ocultar una caída de calidad y un aumento del "rework" (retrabajo).
- **Marco de métricas propuesto**:
- **Métrica principal**: Engineering Output (evaluado por un modelo de ML que simula un panel de expertos, no solo el volumen).
- **Métricas "Guardrail"**: Calidad, Rework/Refactorización, Salud del equipo (métricas DevOps). El objetivo es maximizar el output manteniendo saludables los guardrails.
- **Caso de estudio (Advertencia)**: Una empresa registró +14% de PR con IA, pero una caída del 9% en calidad y una explosión de 2,5 veces en el rework. Sin una medición de grano fino, esto parecía un éxito cuando el ROI era probablemente negativo.

## RésuméDe400mots

Yegor Denisov-Blanch, investigador en Stanford, presenta los resultados de un estudio a gran escala sobre el impacto de la IA en la productividad de más de 100.000 desarrolladores. El objetivo es ir más allá del "hype" y cuantificar el retorno de la inversión (ROI) real.

El estudio revela una **brecha creciente**: la diferencia de rendimiento entre los equipos que tienen éxito con la IA y los que fracasan aumenta. Contrariamente a la creencia popular, la cantidad de IA utilizada (número de tokens) se correlaciona poco con la productividad. El factor determinante es la **calidad del entorno de código** ("Codebase Hygiene"). Un código limpio, bien probado y bien documentado permite que la IA rinda bien. Por el contrario, sobre una base de código degradada, la IA corre el riesgo de acelerar la entropía y la deuda técnica, exigiendo más esfuerzo humano para corregir errores.

Denisov-Blanch advierte contra métricas simplistas como el número de Pull Requests (PR). Cita el ejemplo de una empresa que observó un aumento del 14% en los PR, interpretado inicialmente como un éxito. Un análisis más detallado reveló una caída del 9% en la calidad del código y un aumento de 2,5 veces en el "rework" (retrabajo sobre código escrito recientemente). La ganancia en volumen se vio compensada por la caída en calidad, haciendo que el ROI fuera potencialmente negativo.

Para medir correctamente el ROI, Stanford propone un marco:
1.  **Medir el Uso**: Distinguir el acceso teórico del uso real (mediante telemetría de grano fino) e identificar los "patrones" de uso (uso personal vs. orquestación agéntica).
2.  **Medir los "Resultados de Ingeniería"**: Utilizar una métrica principal de **"Engineering Output"** (basada en un modelo de ML entrenado para replicar la evaluación de expertos humanos, en lugar del volumen de líneas de código) junto con **métricas "Guardrail"** (calidad, tasa de rework, salud del equipo) que deben mantenerse en un nivel saludable.

La conclusión es que la IA es un amplificador: acelera tanto las buenas como las malas prácticas. Los líderes deben medir el impacto con precisión para corregir el rumbo e invertir en la higiene del código para liberar el potencial de la IA.

## GrapheDeConnaissance

- Yegor Denisov-Blanch —a_créé→ étude ROI IA développement (EVENEMENT, 0.95)
- Stanford —emploie→ Yegor Denisov-Blanch (PERSONNE, 0.95)
- étude Stanford —mesure→ 120 000 développeurs analysés (MESURE, 0.95)
- hygiène du code —améliore→ gains IA (CONCEPT, 0.92)
- code sale —permet→ dette technique avec IA (CONCEPT, 0.9)
- métriques simplistes —permet→ masquage de la baisse qualité réelle (CONCEPT, 0.88)
- Engineering Output —remplace→ métriques volume (lignes, PRs) (CONCEPT, 0.85)
- IA développement —permet→ creusement écart équipes performantes/faibles (CONCEPT, 0.9)
- étude Stanford —affirme_que→ la quantité de tokens corrèle faiblement avec la productivité développeur (AFFIRMATION, 0.88)
- Yegor Denisov-Blanch —recommande→ framework métriques guardrails (METHODOLOGIE, 0.88)

---
Canonical: https://www.thekb.eu/es/fiches/denisov-blanch-stanford-quantify-ai-roi-software-engineering-2025-11-23/