En resumen. Toda automatización es un préstamo. Recuperas tiempo hoy y pagas intereses después: revisando resultados, gestionando excepciones, arreglando averías y manteniendo a alguien capaz de hacer el trabajo a mano. Al saldo pendiente lo llamamos deuda de automatización. La evidencia de que esos intereses son reales es sólida: en un ensayo aleatorizado, desarrolladores experimentados de código abierto pronosticaron que las herramientas de IA reducirían el tiempo de sus tareas un 24% y en realidad tardaron un 19% más; el informe DORA 2024 de Google estima que cada aumento del 25% en la adopción de IA va acompañado de una caída del 1,5% en el rendimiento de entrega y del 7,2% en la estabilidad de las entregas; y el 66% de los desarrolladores de la encuesta de Stack Overflow 2025 señala como su principal frustración los resultados de IA que son “casi correctos, pero no del todo”. Nuestro modelo de punto de equilibrio de cinco automatizaciones habituales muestra que, una vez contabilizados la verificación, las excepciones y el mantenimiento, dos de ellas nunca se amortizan y una tercera necesita más de tres años. La solución no es automatizar menos. Es el criterio propio de un dueño sobre qué automatizar, sumado a la disciplina del estudiante: aprender un proceso a mano antes de entregárselo a una máquina.
El préstamo que nadie anota
Ward Cunningham introdujo la metáfora de la deuda en su informe de experiencia de OOPSLA de 1992 sobre el sistema de cartera WyCash. Publicar código por primera vez, escribió, es como endeudarse: un poco de deuda acelera el desarrollo siempre que se devuelva pronto, pero cada minuto dedicado a código que no es del todo correcto cuenta como interés, y una organización puede quedar paralizada bajo esa carga. Veintitrés años después, un equipo de Google dirigido por D. Sculley aplicó la misma lente al aprendizaje automático en el artículo de NeurIPS “Hidden Technical Debt in Machine Learning Systems”. Su advertencia inicial sirve para cualquier proyecto de automatización: es peligroso pensar que las victorias rápidas salen gratis, porque los sistemas del mundo real suelen incurrir en “enormes costes de mantenimiento continuos”. Añaden que no toda deuda es mala, pero toda deuda debe atenderse, y la deuda oculta es peligrosa porque se acumula en silencio.
La deuda de automatización es el mismo fenómeno a escala del flujo de trabajo de una persona o de un equipo. Un Zap, un script, un agente de IA, una regla de correo o una macro de hoja de cálculo eliminan una tarea visible y crean otras menos visibles:
- alguien tiene que comprobar que el resultado es correcto;
- alguien tiene que atender los casos que la automatización no puede resolver;
- alguien tiene que repararla cuando cambia una API, un formulario, el nombre de una columna o un modelo;
- alguien tiene que recordar cómo funciona el proceso para el día en que la automatización falle.
Cuando esos cuatro trabajos no tienen dueño, la automatización parece beneficio puro el día en que se lanza y se convierte después en una fuga lenta. Lo peligroso es que la fuga rara vez aparece en el mismo lugar que el ahorro. Quien construyó el flujo informa de las horas ahorradas; quien limpia sus errores no informa de nada, porque nadie se lo preguntó.
Lo que dice la evidencia sobre los intereses ocultos
Tres conjuntos de datos independientes, procedentes de un ensayo aleatorizado, una gran encuesta del sector y una encuesta muy amplia a desarrolladores, apuntan en la misma dirección. La Tabla 1 recoge solo cifras que hemos confirmado en los documentos originales.
Tabla 1. Evidencia de que la automatización conlleva costes ocultos (datos verificados)
| Fuente | Muestra | Hallazgo |
|---|---|---|
| Ensayo controlado aleatorizado de METR (Becker et al., 2025) | 16 desarrolladores experimentados, 246 tareas reales en proyectos maduros de código abierto | Los desarrolladores pronosticaron que la IA reduciría el tiempo de finalización un 24%; después estimaron una reducción del 20%; el efecto medido fue un aumento del 19% en el tiempo de finalización |
| Mismo estudio, análisis de fiabilidad (Apéndice C.1.4) | Grabaciones de pantalla de 44 incidencias con etiquetas válidas | Los desarrolladores aceptaron menos del 44% de las generaciones de IA y dedicaron cerca del 9% del tiempo con IA permitida a revisar y limpiar sus resultados; el 75% afirmó leer cada línea del código de IA |
| Google DORA, Accelerate State of DevOps 2024 | Casi 3.000 profesionales encuestados en 2024 | Por cada aumento del 25% en la adopción de IA: rendimiento de entrega estimado -1,5%, estabilidad de entrega -7,2%, tiempo en trabajo valioso -2,6%, tiempo en trabajo tedioso +0,4% |
| Google DORA 2024, confianza | Misma encuesta | El 39,2% declaró poca (27,3%) o ninguna (11,9%) confianza en la calidad del código generado por IA |
| Stack Overflow Developer Survey 2025 | Decenas de miles de desarrolladores (33.244 respondieron a la pregunta sobre confianza) | El 46% desconfía de la precisión de las herramientas de IA frente al 33% que confía; el 66% cita lo “casi correcto, pero no del todo” como frustración y el 45,2% dice que depurar código generado por IA lleva más tiempo; el 20% afirma haber perdido confianza en su propia capacidad para resolver problemas |
Leídas en conjunto, las cifras describen la anatomía de la deuda de automatización.
La brecha de percepción es el primer pago de intereses. En el ensayo de METR los desarrolladores no eran novatos: llevaban una media de cinco años en los repositorios en los que trabajaban y, aun así, después del estudio seguían creyendo que la IA los había hecho más rápidos. Si los expertos se equivocan en el signo del efecto sobre su propio trabajo, una estimación informal de “horas ahorradas” por una nueva automatización es una prueba débil. Los autores subrayan que su resultado se aplica a un contexto concreto (desarrolladores experimentados, bases de código grandes y maduras, herramientas de principios de 2025) y que no debe leerse como “la IA ralentiza a todo el mundo”. La lección trasladable es más estrecha y más útil: la velocidad percibida no es la velocidad medida.
La verificación es un coste recurrente, no puntual. Aceptar menos de la mitad de las generaciones, dedicar alrededor de una décima parte del tiempo a revisar y limpiar, y leer cada línea: así es la comprobación cuando el responsable tiene estándares altos. Los datos de Stack Overflow muestran el mismo patrón en decenas de miles de desarrolladores: un resultado casi correcto sale caro, porque hay que encontrarlo, entenderlo y corregirlo.
La velocidad local puede perjudicar los resultados del sistema. El hallazgo de DORA es el más contraintuitivo. La adopción de IA se asoció con mejor calidad de la documentación, mejor calidad del código y mayor productividad individual, pero también con peor rendimiento y estabilidad de las entregas. La hipótesis del informe es que la generación más rápida tentó a los equipos a olvidar uno de los principios más básicos de DORA, los lotes pequeños: si la IA permite producir más código en el mismo tiempo, los conjuntos de cambios probablemente crecen, y DORA ha comprobado de forma sistemática que los cambios más grandes son más lentos y más propensos a la inestabilidad. También observó que el tiempo dedicado al trabajo valioso disminuyó mientras el tiempo en tareas tediosas no cambió, justo lo contrario de lo que promete la automatización. Para cualquiera que automatice un flujo de trabajo, esa es la advertencia: pasos más rápidos no garantizan un sistema más rápido.
Estos hallazgos proceden del software, donde la medición es inusualmente buena. Los usamos como el caso mejor medido de un patrón que la literatura sobre factores humanos describió décadas antes para la automatización en general, y al que volveremos más abajo.
Las cuentas del ROI real: un modelo de punto de equilibrio
La mayoría de las decisiones de automatización se toman con un cálculo ingenuo: minutos ahorrados por ejecución, multiplicados por las ejecuciones al año, menos el tiempo de construcción. La Tabla 2 recalcula cinco automatizaciones habituales del trabajo intelectual con tres términos adicionales: minutos de verificación por ejecución, una tasa de excepciones con su tiempo de gestión manual y horas de mantenimiento al mes. Los datos de entrada son supuestos ilustrativos elegidos para ser realistas en un equipo pequeño, no mediciones; lo importante es la forma del resultado, y puedes repetir el cálculo con tus propias cifras.
Tabla 2. Cálculo de CEOtudent: rendimiento ingenuo frente a real en el primer año de cinco automatizaciones (horas)
| Automatización | Minutos ahorrados por ejecución | Ejecuciones al año | Horas de construcción | Ahorro bruto ingenuo | Neto ingenuo año 1 | Costes ocultos (parte del bruto) | Neto real año 1 | Punto de equilibrio ingenuo (semanas) | Punto de equilibrio real (semanas) |
|---|---|---|---|---|---|---|---|---|---|
| Elaboración del informe semanal | 45 | 52 | 6 | 39,0 | +33,0 | 23,3 (60%) | +9,7 | 8,0 | 19,8 |
| Clasificación diaria de la bandeja de entrada | 10 | 260 | 8 | 43,3 | +35,3 | 51,1 (118%) | -15,8 | 9,6 | nunca |
| Conciliación mensual de facturas | 120 | 12 | 12 | 24,0 | +12,0 | 20,4 (85%) | -8,4 | 26,0 | 173,3 |
| Enriquecimiento del CRM por cada lead | 3 | 2.080 | 10 | 104,0 | +94,0 | 88,0 (85%) | +6,0 | 5,0 | 32,5 |
| Formato del dosier trimestral del consejo | 90 | 4 | 10 | 6,0 | -4,0 | 8,3 (139%) | -12,3 | 86,7 | nunca |
Supuestos (minutos de verificación por ejecución / tasa de excepciones x minutos manuales por excepción / horas de mantenimiento al mes): informe semanal 10 / 10% x 30 / 1; clasificación de la bandeja 4 / 15% x 15 / 2; conciliación de facturas 30 / 20% x 60 / 1; enriquecimiento del CRM 1 / 5% x 10 / 3; dosier del consejo 20 / 25% x 60 / 0,5. Costes ocultos = verificación + excepciones + mantenimiento al año. Punto de equilibrio real = horas de construcción divididas entre el ahorro neto recurrente anual, multiplicado por 52; “nunca” significa que el ahorro neto recurrente es cero o negativo.
Destacan cuatro patrones.
- Todos los cálculos ingenuos parecían una victoria salvo uno. Cuatro de las cinco muestran un neto positivo en el primer año con el método ingenuo. Con el método real, solo dos siguen en positivo, y ambas se reducen bruscamente: el informe semanal cae de +33,0 a +9,7 horas y el enriquecimiento del CRM de +94,0 a +6,0.
- La alta frecuencia no salva una tarea ruidosa. La clasificación de la bandeja de entrada se ejecuta 260 veces al año y ahorra 10 minutos cada vez, pero cuatro minutos de revisión por ejecución, una tasa de excepciones del 15% y dos horas al mes de ajuste de reglas consumen el 118% del ahorro bruto. Nunca se amortiza.
- Baja frecuencia más alto coste de construcción es la trampa clásica. El dosier trimestral del consejo no se amortiza ni siquiera con el método ingenuo, y cada ejecución tiene una posibilidad entre cuatro de necesitar una hora de rescate manual.
- El mantenimiento es el término decisivo. La automatización de facturas pasa de una amortización ingenua de seis meses a más de tres años, sobre todo por 12 horas de mantenimiento al año frente a solo 24 horas de ahorro bruto.
La Tabla 3 muestra lo sensible que es incluso una automatización sólida a los dos términos ocultos que más a menudo se omiten.
Tabla 3. Cálculo de CEOtudent: horas netas reales del primer año de la automatización del informe semanal, según la carga de mantenimiento y de verificación
| Horas de mantenimiento al mes | 0 min de revisión por ejecución | 10 min | 20 min | 30 min |
|---|---|---|---|---|
| 0 | +30,4 | +21,7 | +13,1 | +4,4 |
| 0,5 | +24,4 | +15,7 | +7,1 | -1,6 |
| 1 | +18,4 | +9,7 | +1,1 | -7,6 |
| 2 | +6,4 | -2,3 | -10,9 | -19,6 |
| 3 | -5,6 | -14,3 | -22,9 | -31,6 |
Se mantienen constantes 45 minutos ahorrados por ejecución, 52 ejecuciones al año, 6 horas de construcción y una tasa de excepciones del 10% a 30 minutos cada una.
La misma automatización oscila entre una ganancia de 30 horas y una pérdida de 32 horas en función de dos cifras que rara vez aparecen en un caso de negocio. Si todavía no puedes estimarlas, no conoces el proceso lo suficiente como para automatizarlo. Ese es el núcleo del argumento que sigue.
Los seis componentes de la deuda de automatización
La deuda tiene más de un origen. La Tabla 4 nombra los componentes que utilizamos, cómo se manifiesta cada uno en el trabajo diario y la investigación con la que conecta.
Tabla 4. Marco editorial de CEOtudent: los seis componentes de la deuda de automatización
| Componente | Qué se acumula | Señal de alerta temprana | Eco en la investigación |
|---|---|---|---|
| 1. Deuda de mantenimiento | Reparaciones cuando cambian entradas, herramientas, API, prompts o modelos | “Se ha vuelto a romper” aparece en el chat más de una vez por trimestre | Sculley et al.: código de pegamento y “Changing Anything Changes Everything” |
| 2. Deuda de excepciones | Gestión manual de los casos que la automatización no puede procesar | Una carpeta de “pendiente de revisión” cada vez más grande que nadie vacía | Bainbridge: al operador le quedan las tareas que el diseñador no pudo automatizar |
| 3. Deuda de verificación | Tiempo dedicado a revisar resultados casi correctos | Relees cada resultado “por si acaso” | METR: menos del 44% de las generaciones aceptadas, cerca del 9% del tiempo revisando |
| 4. Deuda de dependencia | Acoplamiento oculto: otros flujos o personas empiezan a depender del resultado | Alguien que no esperabas se queja cuando deja de funcionar | Sculley et al.: consumidores no declarados y bucles de retroalimentación ocultos |
| 5. Deuda de habilidad | Erosión de la capacidad de hacer, juzgar o rescatar la tarea a mano | Nadie sabe hacer la tarea manualmente cuando la automatización falla | Bainbridge: las habilidades se deterioran cuando no se usan; Stack Overflow 2025: un 20% con menos confianza en su propia capacidad para resolver problemas |
| 6. Deuda de propiedad | Sin responsable designado, sin presupuesto, sin fecha de retirada | No sabes decir quién notaría si fallara en silencio | Parasuraman y Riley: el “abuso” de la automatización por parte de diseñadores y directivos |
Dos de ellos merecen más atención porque son los menos visibles.
La deuda de habilidad es la ironía que está en el corazón de la automatización. El artículo de Lisanne Bainbridge de 1983 “Ironies of Automation”, publicado en Automatica, planteó el argumento cuatro décadas antes de la IA generativa. Automatizar un proceso suele dejar a la persona dos trabajos: vigilar que el sistema automático funciona y tomar el control cuando no lo hace. Pero tomar el control exige precisamente las habilidades que se desvanecen cuando una persona solo vigila: las habilidades físicas se deterioran si no se usan, y el conocimiento necesario para situaciones inusuales solo se desarrolla con el uso y la retroalimentación. También señaló, citando la investigación sobre vigilancia, que ni siquiera una persona muy motivada puede mantener una atención eficaz durante más de una media hora sobre una fuente en la que ocurre muy poco. Su ironía es que cuanto más avanzada es la automatización, más crucial puede volverse la contribución humana, justo cuando esa persona ha tenido menos práctica.
La deuda de propiedad es donde la dirección se equivoca. En su artículo de 1997 en Human Factors, Raja Parasuraman y Victor Riley distinguieron cuatro formas en que las personas se relacionan con la automatización. Como resume su abstract, el mal uso es la dependencia excesiva, que provoca fallos de supervisión y sesgos en las decisiones; el desuso es el abandono, a menudo causado por falsas alarmas; y el abuso es automatizar funciones “sin tener debidamente en cuenta las consecuencias para el desempeño humano”, lo que define los roles de las personas como subproductos de la automatización. Para un directivo o un profesional independiente, el abuso es el más relevante: automatizar porque una herramienta lo permite y dar por hecho que quien quede absorberá las excepciones y las revisiones.
La tarjeta de puntuación Automatizar ahora / Esperar / Nunca
La regla de decisión siguiente convierte los seis componentes en una lista de comprobación puntuable. Puntúa cada pregunta con 0, 1 o 2 antes de construir nada.
Tabla 5. Marco editorial de CEOtudent: tarjeta de puntuación de la deuda de automatización
| Pregunta | 0 puntos | 1 punto | 2 puntos |
|---|---|---|---|
| Frecuencia: ¿con qué frecuencia se ejecuta la tarea? | Menos de una vez al mes | De 1 a 8 veces al mes | Más de 8 veces al mes |
| Estabilidad: ¿ha cambiado el proceso en los últimos 3 meses? | Ha cambiado y no está documentado | Estable pero sin documentar | Estable y redactado como procedimiento operativo estándar |
| Verificación: ¿cuánto se tarda en revisar un resultado en comparación con hacer la tarea a mano? | Más del 30% | Del 10% al 30% | Menos del 10% |
| Excepciones: ¿qué proporción de ejecuciones necesita a una persona? | Más del 20% | Del 5% al 20% | Menos del 5% |
| Coste del error: si el resultado es erróneo sin que nadie lo note, ¿qué ocurre? | Llega a un cliente, a un regulador o a un pago | Se detecta más adelante con algún coste | Se detecta de forma barata e inofensiva |
| Propiedad: ¿hay un responsable designado con tiempo para el mantenimiento? | Nadie | Hay responsable, pero sin tiempo asignado | Responsable designado, tiempo asignado y fecha de revisión fijada |
| Habilidad: ¿alguien puede todavía hacer y juzgar la tarea a mano? | Nadie podría | Una persona, sin práctica reciente | Sí, y la habilidad se mantiene en uso |
Regla de decisión (máximo 14 puntos):
- Automatizar ahora: 10 puntos o más, y ningún cero en Coste del error ni en Propiedad.
- Esperar y aprender: de 6 a 9 puntos, o cualquier cero en Estabilidad o Propiedad. Ejecuta la tarea manualmente unas cuantas veces más, documenta el procedimiento, mide el tiempo de verificación y la tasa de excepciones, designa un responsable y vuelve a puntuar.
- Nunca (por ahora): 5 puntos o menos, o un cero tanto en Coste del error como en Verificación. Son tareas en las que los errores salen caros y cuestan de detectar: mantén a una persona haciendo el trabajo y usa las herramientas solo como apoyo.
Hay dos decisiones de diseño deliberadas. Primera, Propiedad y Coste del error funcionan como vetos, porque un total alto no compensa una automatización que nadie mantiene ni errores silenciosos que llegan a un cliente. Segunda, Estabilidad puntúa más cuando el proceso está documentado, porque un proceso que no puedes describir es un proceso que no puedes verificar. Si todavía no has mapeado el trabajo, empieza por la auditoría de flujo de trabajo en 7 pasos y convierte el resultado en un procedimiento escrito con el enfoque de el renacimiento de los procedimientos operativos estándar. La tarjeta de puntuación complementa, y no sustituye, a un método de priorización como la regla 80/20 para decidir qué tareas del trabajo intelectual automatizar primero: la lente 80/20 te dice dónde está el valor, y la tarjeta de la deuda te dice si podrás cobrarlo.
La lente CEO+Student: aprende el proceso antes de automatizarlo
Un CEO no aprueba una inversión sin preguntar cuánto costará mantenerla en marcha. La automatización es una inversión con costes de funcionamiento, y el trabajo del dueño es verlos todos: las horas de construcción que figuran en la propuesta, las horas de revisión y reparación que acaban en la mesa de otra persona y la capacidad que pierde la organización si nadie vuelve a practicar la tarea. El criterio de dueño consiste en plantear tres preguntas que toda propuesta de automatización debería responder:
- ¿Quién lo revisa, cómo y cuánto tiempo lleva? Si la respuesta es “nadie” o “ya veremos”, la deuda de verificación no tiene precio. Situar puntos de control deliberados es una tarea de diseño, tratada en supervisión humana por diseño.
- ¿Quién es responsable cuando se rompe y cuándo revisaremos si la mantenemos? Una automatización sin fecha de revisión es una suscripción sin botón de cancelar.
- ¿Qué pasa con nuestra habilidad? Si se trata de una tarea en la que el criterio es el producto, como fijar precios, contratar, asesorar a clientes o editar, automatizar la tarea completa consume la experiencia necesaria para juzgar el resultado.
La mitad estudiante de la tesis es la defensa práctica. La forma más fiable de evitar la deuda de automatización es entender un proceso a mano antes de automatizarlo: hacerlo las veces suficientes para conocer sus excepciones, cronometrar el paso de revisión, documentar el procedimiento y solo entonces decidir. Los desarrolladores de METR tenían años de experiencia en sus repositorios y aun así se llevaron una sorpresa; quien automatiza un proceso que ha ejecutado dos veces tiene mucho menos en qué apoyarse. Aprender primero también protege frente a la ironía de Bainbridge. Si has hecho el trabajo tú mismo y lo sigues haciendo de vez en cuando, todavía puedes juzgar lo que produce la automatización y rescatarla cuando falla. Desarrollar ese criterio es una habilidad en sí misma, descrita en la habilidad de evaluación para juzgar resultados de IA.
La oportunidad es real: en la Tabla 2, dos de las cinco automatizaciones siguen amortizándose en menos de un año. Las tareas estables, frecuentes y baratas de revisar son aquellas en las que la automatización se gana el sueldo. Las ganadoras se eligen, no se dan por supuestas.
Cómo saldar la deuda de automatización que ya tienes
La mayoría de quienes leen esto ya tienen automatizaciones en marcha. Una revisión trimestral de cuatro pasos mantiene el saldo bajo control:
- Inventario. Enumera todas las automatizaciones, incluidas las reglas de correo, los scripts programados, los agentes de IA y los flujos sin código. Junto a cada una, anota el responsable y la última fecha en que alguien comprobó que funcionaba. Las celdas vacías son deuda de propiedad.
- Mide los intereses. Durante una semana típica, registra los minutos dedicados a revisar resultados, gestionar excepciones y arreglar averías de cada automatización. Introduce esas cifras en la fórmula de la Tabla 2.
- Refinancia o retira. Las automatizaciones que ya no se amortizan tienen tres opciones: simplificarlas (menos pasos, menos dependencias), limitarlas a los casos que funcionan de forma fiable y derivar el resto a una persona, o apagarlas. Desactivar una automatización que cuesta más de lo que ahorra es una ganancia, no un fracaso.
- Mantén viva la habilidad. Para todo lo crítico, haz que el responsable ejecute la tarea manualmente de vez en cuando, para que la alternativa exista cuando haga falta.
Esta revisión encaja de forma natural en la capa de mantenimiento de una jornada estructurada; consulta el flujo de trabajo de IA en 5 capas para ver dónde encaja.
Preguntas frecuentes
¿Qué es la deuda de automatización?
La deuda de automatización es el trabajo futuro acumulado que genera automatizar una tarea: revisar resultados, gestionar excepciones, mantener la automatización cuando cambian las cosas, gestionar lo que depende de ella y preservar la habilidad humana necesaria cuando falla. Es un marco de CEOtudent que extiende la metáfora de la deuda técnica de Ward Cunningham del código a los flujos de trabajo.
¿La deuda de automatización es siempre mala?
No. Igual que la deuda financiera, puede ser una decisión acertada si el rendimiento supera los intereses y alguien la atiende. En nuestro modelo de punto de equilibrio, la automatización del informe semanal sigue devolviendo 9,7 horas netas en su primer año tras todos los costes ocultos. El problema es la deuda sin precio y sin dueño.
¿La automatización con IA empeora el problema?
Puede hacerlo, porque los resultados de la IA suelen ser “casi correctos”, lo que aumenta la carga de verificación. En la encuesta de Stack Overflow 2025, el 66% de los desarrolladores lo señaló como una frustración, y en el ensayo de METR los desarrolladores aceptaron menos del 44% de las generaciones de IA. La IA también acelera la construcción de automatizaciones, lo que facilita endeudarse sin darse cuenta.
¿Cómo sé si una automatización cuesta más de lo que ahorra?
Registra durante una semana el tiempo de revisión, gestión de excepciones y reparación, anualízalo y réstalo del tiempo bruto ahorrado. Si el neto recurrente es cero o negativo, la automatización nunca amortizará su tiempo de construcción, como ocurre con dos de los cinco ejemplos de la Tabla 2.
¿Debo dejar de automatizar hasta dominar todos los procesos?
No. Usa la tarjeta de puntuación: las tareas estables, frecuentes y baratas de revisar que tienen un responsable designado pueden automatizarse ya. La categoría “esperar” solo significa aprender el proceso a mano, documentarlo y medirlo antes de construir.
Fuentes
- Becker, J., Rush, N., Barnes, B., and Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. arXiv:2507.09089v2.
- Google Cloud DORA (2024). Accelerate State of DevOps Report 2024 (v. 2024.3).
- Stack Overflow (2025). 2025 Developer Survey, sección de IA.
- Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., and Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015).
- Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775-779.
- Parasuraman, R., and Riley, V. (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2), 230-253 (abstract).
- Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ‘92 Experience Report.
La Tabla 1 recoge cifras verificadas del ensayo de METR, el informe DORA 2024 y la encuesta de Stack Overflow 2025. Las Tablas 2 y 3 son cálculos de CEOtudent basados en los supuestos ilustrativos indicados bajo cada tabla; cada celda se calculó mediante script y se volvió a comprobar de forma independiente. Las Tablas 4 y 5 son el marco editorial de CEOtudent; los ecos de investigación de la Tabla 4 señalan hallazgos relacionados, no una validación del marco.
Este contenido fue recopilado con el apoyo de la IA tras una investigación exhaustiva, y luego redactado y preparado para su publicación por el equipo editorial de CEOtudent.
This post is also available in:
