Saltar al contenido
Todos los artículos

De 7 años a 7 días con la IA agéntica

por Ghazi Triki · 12 min de lectura

De siete años a siete días
En este artículo

Si alguna vez ha visto cómo una hoja de cálculo COCOMO II predecía 33 meses de calendario para un proyecto que su equipo entregó en dos sprints, ya conoce el problema: todos los modelos de estimación que se usan hoy en producción se calibraron en un mundo en el que los desarrolladores escriben cada línea, cada cambio de contexto tiene un coste y el calendario se detiene a las 17:00. Ese mundo ya no existe. Hace poco desarrollamos desde cero una aplicación de 286 KLOC, 672 archivos y varios subsistemas (capa de protocolo, capa de datos, motor de renderizado, integración con la plataforma) y alcanzamos una versión alfa lista para pruebas en 7 días. El panel completo de modelos (COCOMO Basic/Intermediate/Post-Architecture, puntos de función, referencia SLOC, Putnam/SLIM) arrojó una predicción mediana de 30.3 meses de calendario. El multiplicador de productividad mediano: 4240×. Incluso la referencia más conservadora (25 SLOC por día-desarrollador para sistemas complejos) se equivocaba en un factor de 1433×. Los modelos no están mal. Están mal aplicados. A continuación encontrará el desglose modelo por modelo, la calibración empírica con un mismo autor y lo que dice realmente la literatura de ensayos controlados aleatorizados de 2024 a 2026 sobre dónde comprime los plazos la IA agéntica, y dónde no.

El proyecto que hizo saltar las estimaciones

En RIADVICE desarrollamos recientemente una aplicación compleja y rica en funciones, de las que coordinan varios subsistemas en una arquitectura distribuida, como entorno nativo multiplataforma para móvil y escritorio a partir de una única base de código, impulsada por requisitos del mercado que exigían una nueva implementación. La base de código da cuenta de la escala:

  • 286 662 SLOC (unos 286 KLOC) repartidas en 672 archivos fuente
  • 1 329 399 líneas de churn total: 862 488 inserciones y 466 911 eliminaciones
  • 700 commits en 7 días de desarrollo activo para alcanzar la primera versión alfa lista para pruebas
  • Internacionalización completa en decenas de idiomas
  • Varios subsistemas sin ninguna relación entre sí (gestión de protocolos, gestión de datos, renderizado e integración con la plataforma), todos construidos desde cero para el entorno de destino

No se trataba de un envoltorio ni de un simple cambio de apariencia. Era una implementación nativa construida desde la base para satisfacer requisitos del mercado que las soluciones existentes no cubrían. Antes de escribir una sola línea, conecté al proyecto una herramienta de análisis propia que aplica a la base de código, a medida que crece, el panel completo de modelos estándar del sector para la estimación del esfuerzo de software. El objetivo era honesto: medir la distancia entre lo que predicen los modelos clásicos y lo que produce realmente una entrega asistida por IA. Los resultados no son un error de redondeo. Son una ruptura de categoría.

Lo que predijeron los modelos de estimación frente a lo que ocurrió

La herramienta aplica todos los grandes modelos de estimación de la literatura de ingeniería de software: COCOMO Basic (Organic, Semi-Detached, Embedded), COCOMO Intermediate (Semi-Detached y Embedded, ajustados), COCOMO II Post-Architecture (ajustado), puntos de función, la referencia de productividad SLOC y Putnam/SLIM, calibrados según el tipo de proyecto con las constantes publicadas en la literatura original.

Modelo de estimaciónEsfuerzo previstoCalendario previstoAceleración frente a lo real
COCOMO Basic (Organic)913 meses-persona33.3 meses2282×
COCOMO Basic (Semi-Detached)1696 meses-persona33.7 meses4240×
COCOMO Basic (Embedded)3200 meses-persona33.1 meses8000×
COCOMO Intermediate (Semi-Det., ajustado)1259 meses-persona30.4 meses3148×
COCOMO Intermediate (Embedded, ajustado)2376 meses-persona30.1 meses5940×
COCOMO II Post-Architecture (ajustado)1703 meses-persona30.3 meses4257×
Puntos de función (cálculo aproximado)17.9 meses-persona7.5 meses45×
Referencia de productividad SLOC (25 SLOC/día-desarr.)573 meses-persona573.3 meses1433×
Putnam/SLIMomitido (duración inferior a 30 días; T 4/3 diverge)n. a.n. a.

El multiplicador de productividad mediano del conjunto de modelos es de 4240×. Incluso el modelo más conservador predice un plazo de entrega unas 1400 veces más largo que el real. El más optimista, el de puntos de función, seguía prediciendo 7.5 meses de calendario, 45 veces más que los 7 días reales. Según los modelos, este proyecto debería haber llevado entre 7 meses y 47 años. Una versión alfa estuvo lista para pruebas en 7 días.

Los modelos discrepan entre sí, en un factor de 50× a 8000×

Estos modelos no coinciden entre sí. Sobre esta misma base de código, las predicciones van de 17.9 a 3200 meses-persona: una dispersión de 178×. La evaluación comparativa SEAA 2013 de COCOMO II, SEER-SEM, SLIM y TruePlanning sobre 51 proyectos reales obtuvo un MMRE del 50 al 100 %. Una evaluación de 2023 sobre el conjunto de datos COCOMO de la NASA obtuvo un MMRE cercano a 1.0 y un PRED(0.25) = 0.0: ni un solo proyecto estimado dentro del margen de error del 25 %. Estos modelos nunca se diseñaron para un proyecto asistido por IA. Pero la magnitud de la diferencia, incluso teniendo en cuenta la imprecisión de los modelos, indica que algo ha cambiado estructuralmente.

Lo que dice realmente la investigación sobre la IA agéntica y la productividad de los desarrolladores

La cifra de 4240× es extrema, y no quiero exagerar su alcance. El andamiaje de un proyecto nuevo infla el churn, y las SLOC son un indicador débil del valor. Veamos, pues, la literatura revisada por pares. Los asistentes de tipo Copilot aportan mejoras modestas pero reales. Peng et al. (2023) constataron que los desarrolladores que trabajaban con un programador de IA en pareja completaban una tarea un 55.8 % más rápido (IC del 95 %: del 21 al 89 %). El ensayo controlado aleatorizado de Microsoft, Accenture y una empresa de la lista Fortune 100 (2025), el mayor estudio hasta la fecha con n = 4867, halló un aumento del 26 % en las tareas completadas. El ensayo interno de Google (2024) midió una reducción de aproximadamente el 21 % del tiempo dedicado a la tarea. El experimento de campo de BIS y Ant Group (2024) midió un aumento del 55 % en la producción de código entre el personal júnior. El resumen honesto: de 1.26× a 1.56× en las tareas adecuadas. Real, pero no transformador. La IA agéntica opera en otro régimen. La revisión de 2025 de Devin publicada por Cognition recogía resultados de clientes de 10× en migraciones ETL, 14× en migraciones de versión de Java y 20× en correcciones de seguridad. Nubank informó de una mejora de eficiencia de 12× y un ahorro de costes de 20× en una refactorización de varios millones de líneas que se había estimado en un esfuerzo de varios años y mil ingenieros. Nuestro desarrollo se sitúa de lleno en ese rango: el histograma de commits muestra ráfagas densas a las 22:00, a las 00:00 y a la 01:00, la firma de las sesiones dirigidas por agentes. Las pruebas en contra son reales. El ensayo controlado aleatorizado de Metr.org en 2025 (16 desarrolladores experimentados, 246 tareas en proyectos maduros) halló que la IA aumentaba el tiempo de realización en un 19 %: ralentizó a desarrolladores experimentados en bases de código que conocían. Un estudio de diferencias en diferencias de 2026 sobre 807 repositorios de GitHub que adoptaron herramientas de IA (He et al., MSR ’26) observó un aumento “transitorio” de la velocidad y un incremento “persistente” de la complejidad del código que provocó una ralentización a largo plazo. El título lo dice todo: Speed at the Cost of Quality. El consenso: la IA ayuda mucho en proyectos nuevos y en el desarrollo estructurado, ayuda de forma modesta en las tareas de autocompletado y puede perjudicar la velocidad en bases de código maduras. La deuda de calidad es real.

Por qué fallan los modelos: tres cambios estructurales

Ninguno de los factores de coste de los modelos clásicos contempla el caso de que “el desarrollador dispone de un agente autónomo que nunca duerme y tiene toda la base de código en su contexto”. Tres cambios hunden la curva de duración:

  1. El cuello de botella de la escritura ha desaparecido.

Los modelos suponen que una parte importante del esfuerzo es mecánica: código repetitivo, andamiaje, refactorizaciones repetitivas, recursos de localización y otros datos estructurados. En este desarrollo, buena parte del volumen es texto muy regular y código de conexión que un agente puede generar o transformar en bloque. El propio código artesanal (andamiaje, constructores, código de unión con la plataforma) se genera ahora en ráfagas, no línea a línea.

  1. El coste del cambio de contexto se desploma.

Una persona que pasa de la capa de protocolo a la capa de datos y al motor de renderizado paga cada vez un peaje de carga de contexto. Un agente que ha leído todo el repositorio de 672 archivos lo paga una sola vez. Esa asimetría se acumula rápidamente en una base de código de este tamaño.

  1. El calendario ya no es el cuello de botella.

Los modelos convierten los meses-persona en meses de calendario mediante una ecuación de dotación de personal que presupone una jornada laboral humana. Las sesiones de los agentes continúan durante la noche. El histograma de commits muestra una producción sostenida desde las 07:00 hasta la 01:00: 18 horas activas, no 8.

La calibración empírica con un mismo autor

Como los modelos paramétricos discrepan en varios órdenes de magnitud, realicé también una calibración empírica entre proyectos, comparando mi propio churn de código por día-persona antes y después de adoptar una herramienta de IA agéntica en otros tres repositorios de producción del mismo ecosistema:

ProyectoChurn/día-desarr. antes de la IAChurn/día-desarr. con IAMultiplicador
Proyecto A (equilibrador de carga)67320563.1×
Proyecto B (servicio de informes)23921278.9×
Proyecto C (servicio de procesamiento)13229820.7×
Conjunto (media / mediana)n. a.n. a.4.2× / 3.1×

Mismo autor, mismo dominio, trabajo de mantenimiento real. El multiplicador empírico es de 3 a 9×, mucho más conservador que la cifra de 4240× de un proyecto nuevo, y coherente con la parte alta de la investigación publicada sobre la IA agéntica. Un proyecto llegó incluso a ir más lento: las mejoras dependen de la tarea, no son universales.

Qué significa para la planificación de proyectos

Si sigue estimando proyectos de software con modelos sin calibrar y una referencia de 25 SLOC al día, se equivocará en uno a tres órdenes de magnitud en el trabajo asistido por IA. Esto es lo que hacemos en RIADVICE:

  1. Calibre con su propio historial. Compare su propia producción de código por día-persona con y sin IA. Es más barato, más honesto y ofrece un rango de 3 a 9× que puede defender en un plan de proyecto.
  2. Distinga los proyectos nuevos del mantenimiento. El multiplicador de la IA agéntica es máximo en los proyectos nuevos y el desarrollo estructurado, y mínimo (a veces negativo) en el mantenimiento de bases de código maduras. No aplique una misma cifra a ambos.
  3. Presupueste la deuda de calidad. La velocidad que aporta la IA conlleva aumentos persistentes de la complejidad. Planifique una fase de consolidación e instruméntela: mida la complejidad ciclomática y ejecute la detección de código duplicado en cada versión.
  4. Estime toda la curva, no solo su inicio. Una mejora de velocidad de 10× que duplica la densidad de defectos no es una mejora de 10×: es un calendario adelantado a costa de una fase de estabilización más larga.

En resumen

Un proyecto que, según todos los modelos de estimación, debería haber llevado entre 7 meses y 47 años alcanzó una versión alfa lista para pruebas en 7 días. El multiplicador mediano de 4240× no debería convertirse en el plan de proyecto de nadie. Pero es una señal clara de que la duración del desarrollo de software complejo se está comprimiendo por la misma fuerza que está comprimiendo el esfuerzo. La investigación publicada muestra que la IA aporta desde un ligero impulso de 1.26× hasta un salto de 20×, con un riesgo real de rendimientos negativos en bases de código maduras y un coste medible en calidad. Los modelos que nos decían que este proyecto llevaría décadas son los mismos que siguen funcionando hoy en las hojas de cálculo de estimación de las empresas. La cuestión no es si la IA agéntica modifica la duración de los proyectos: la investigación ya ha respondido. La cuestión es si sus prácticas de estimación se han puesto al día con la evidencia. Si sus cifras siguen procediendo de un modelo de 1981 calibrado con COBOL y ensamblador, es hora de recalibrar, o al menos de dejar de creer el calendario que imprime.

“Sigue habiendo un margen de mejora considerable para abordar mejor los retos de predicción que se plantean en la práctica.”

Accuracy of Contemporary Parametric Software Estimation Models, SEAA 2013

🏆 Ingeniería y experiencia en la nube de confianza

RIADVICE: su socio de confianza en ingeniería de software

Diseñamos, construimos y desplegamos sistemas de software complejos con la disciplina de ingeniería y las herramientas necesarias para cumplir en la era de la IA: en plazo, dentro del presupuesto y con calidad.

Descubra nuestros servicios →

📚 Fuentes y lecturas complementarias

Este artículo se basa en investigaciones revisadas por pares, ensayos controlados aleatorizados e informes de campo del sector sobre la productividad del desarrollo de software asistido por IA y la estimación del esfuerzo de software:

⚡ RIADVICE.com ofrece ingeniería de confianza, experiencia en la nube y soluciones de software de nivel empresarial: en plazo, dentro del presupuesto y con calidad.

Compartir este artículo

Artículos relacionados