TL;DR
- Tu intuición va en la dirección correcta: en un entorno asistido por IA, el tiempo de implementación es un indicador cada vez menos fiable de la complejidad.
- Pero la versión más sólida de la afirmación es más precisa: el tiempo nunca fue lo mismo que la complejidad, y la IA está dejando esa diferencia mucho más en evidencia.
- La IA reduce el tiempo necesario para crear una primera versión de código en tareas acotadas. No reduce al mismo ritmo la ambigüedad, la gestión de dependencias, la verificación, la coordinación entre equipos, los riesgos de despliegue ni la preparación operativa.
- Para los equipos Scrum, esto significa que las conversaciones sobre las historias deben centrarse menos en «¿cuánto tardaremos en programar?» y más en «¿qué tipo de complejidad de entrega estamos asumiendo?».
- El error de planificación de la era de la IA no es subestimar la velocidad de generación de código. Es confundir la creación rápida de código con una entrega de baja complejidad.
El resto de este artículo utiliza fuentes vigentes hasta el April 22, 2026.
La idea principal
Esta es la intuición detrás de la hipótesis:
Si la IA puede generar en minutos el esqueleto de una funcionalidad, un borrador de pruebas, una sugerencia de refactorización, una herramienta auxiliar para una migración o una implementación de interfaz, el viejo atajo mental empieza a fallar:
«Esto tomará más tiempo, por lo tanto debe ser más complejo».
Ese atajo siempre fue imperfecto, pero a menudo era suficientemente útil. En muchos equipos, escribir y reescribir código consumía una parte tan grande del trabajo que el tiempo de desarrollo transcurrido parecía un indicador razonable de la complejidad.
Ahora eso es mucho menos cierto.
Cuando generar código se vuelve mucho más barato, resulta más fácil ver qué es lo difícil del trabajo de software. No era solo escribir código. Era la incertidumbre que rodeaba esa actividad.
Por eso la hipótesis es útil, pero necesita afinarse.
Una versión más sólida de la hipótesis
Yo la reformularía así:
En la era de la IA, el tiempo de programación es un indicador cada vez menos fiable de la complejidad del software, por lo que los equipos de ingeniería necesitan un mejor lenguaje para hablar de complejidad y una mejor manera de pronosticar las entregas que depender solo del esfuerzo de implementación.
Esa formulación importa porque «la complejidad ya no se puede medir en tiempo» refleja bien la sensación, pero, tomada literalmente, es demasiado absoluta.
El tiempo sigue importando. Si algo toma seis semanas, obviamente es un problema para la planificación.
Lo que cambió es esto:
- el tiempo de programación ya no es el costo dominante en tantas tareas como antes
- la variabilidad que introduce la IA depende mucho del contexto
- el trabajo restante suele ser sociotécnico más que puramente sintáctico
- el tiempo transcurrido ahora oculta varios tipos de complejidad que no cambian al mismo ritmo
En otras palabras, la IA no elimina la complejidad. Redistribuye dónde se encuentra.
Lo que realmente dice la evidencia
Lo más interesante de este debate es que la evidencia no está claramente a favor ni en contra de la IA. Es más útil que eso. Muestra dónde aparecen las mejoras y dónde las absorben otras formas de trabajo.
1. La IA claramente acelera algunas tareas de programación
El experimento controlado de GitHub sobre Copilot encontró que los desarrolladores terminaron una tarea de creación de un servidor JavaScript aproximadamente 55% más rápido con Copilot que sin él. En una investigación empresarial posterior con Accenture, GitHub también reportó una mayor satisfacción de los desarrolladores, menos esfuerzo mental en tareas repetitivas y mayor facilidad para entrar en un estado de flujo.
Esto importa porque confirma la premisa básica: la IA puede reducir considerablemente el costo de generar código funcional en entornos acotados.
Si tu modelo mental de complejidad se basaba principalmente en «cuánto código hay que escribir», la IA lo rompe rápidamente.
2. La IA también puede ralentizar a desarrolladores experimentados en trabajo real sobre sistemas existentes
El ensayo controlado aleatorizado de METR de 2025 encontró algo que casi todos consideraron sorprendente: los desarrolladores experimentados de código abierto que trabajaban en sus propios repositorios, que conocían bien, tardaron 19% más al usar herramientas de IA de principios de 2025.
Ese resultado es sumamente importante para quienes gestionan equipos.
No significa que la IA sea inútil. Significa que el cuello de botella en sistemas maduros a menudo no es la generación inicial de código. Es:
- cargar el contexto del repositorio
- respetar las convenciones locales
- validar resultados que son casi correctos
- revisar y limpiar los cambios generados
- tomar decisiones seguras dentro de las restricciones existentes
Esto ya cuestiona seriamente la forma de pensar basada en el tiempo. El mismo «tipo de tarea» puede parecer fácil en un benchmark greenfield y complicado en un sistema de producción real.
3. La IA mejora algunas métricas locales de proceso sin mejorar automáticamente la entrega
El informe de IA de DORA de 2025 añade otra dimensión crítica.
DORA encontró que una mayor adopción de IA estaba asociada con una mejor calidad de la documentación y del código, mayor velocidad de revisión y aprobación, y una menor complejidad percibida del código. Pero el mismo informe encontró un peor desempeño de entrega, incluida una probable reducción del volumen de entrega y una reducción aún mayor de su estabilidad.
Su hipótesis es muy plausible: si la IA permite que los equipos produzcan mucho más código en el mismo tiempo, podrían empezar a entregar conjuntos de cambios más grandes. DORA ha demostrado repetidamente que los lotes grandes son más lentos y generan más inestabilidad.
Esta es una de las evidencias más claras que respaldan tu hipótesis.
La complejidad no desapareció. Se desplazó a etapas posteriores, hacia:
- la facilidad de revisión
- el tamaño de los lotes
- la seguridad de la integración
- la inestabilidad en producción
4. La investigación sobre productividad ya nos advertía que no usáramos una sola métrica
Antes de la actual ola de IA, el framework SPACE sostenía que la productividad de los desarrolladores no puede reducirse a una sola métrica. La productividad abarca satisfacción, desempeño, actividad, comunicación y colaboración, y eficiencia y flujo.
Esto importa aquí porque los equipos suelen caer en una visión muy limitada de la productividad con IA:
«El modelo escribió más código más rápido, así que el trabajo debe ser más sencillo».
Pero producir código más rápido es principalmente una señal de actividad y eficiencia. Dice mucho menos sobre el esfuerzo de colaboración, la carga de verificación, la salud del servicio o si se resolvió el problema correcto.
5. Scrum ya estaba diseñado para el trabajo complejo
La Guía de Scrum define Scrum como un framework para generar valor mediante soluciones adaptativas para problemas complejos. También plantea el refinamiento del backlog en torno a aumentar la transparencia y dimensionar el trabajo que el equipo realmente puede completar dentro de un Sprint.
Es un recordatorio útil: los story points nunca debieron ser una traducción directa de las horas de desarrollo.
En la práctica, muchos equipos terminaron usándolos así de todos modos, sin darse cuenta. Ahora la IA hace que esa deriva sea mucho más peligrosa.
Si un equipo estima principalmente según el esfuerzo de programación, la IA hará que muchas historias parezcan artificialmente más pequeñas, incluso cuando la verdadera incertidumbre esté en otra parte.
Entonces, ¿qué es la complejidad ahora?
Este es el núcleo del artículo.
En un entorno de ingeniería asistido por IA, es mejor hablar de la complejidad como una superficie de entrega, no solo como esfuerzo de implementación.
Me resulta útil dividir esa superficie en seis dimensiones.
1. Complejidad de la ambigüedad
¿Qué tan poco claro está el problema en sí?
Ejemplos:
- los requisitos están incompletos
- las partes interesadas no están de acuerdo sobre el comportamiento esperado
- aún se están descubriendo casos límite
- los criterios de éxito todavía no se pueden probar
La IA puede ayudar a generar opciones, pero no elimina la ambigüedad. En algunos casos la aumenta, al hacer que muchas implementaciones posibles parezcan igualmente viables.
2. Complejidad de integración
¿Cuántos sistemas existentes, servicios, restricciones y convenciones debe respetar el cambio?
Ejemplos:
- esquemas heredados
- API de terceros
- modelos de autenticación y permisos
- capas de caché
- cambios en los contratos entre frontend y backend
- secuencia de las migraciones
Aquí es donde el trabajo sobre sistemas existentes a menudo deja de ser «solo código».
3. Complejidad de verificación
¿Qué tan difícil es demostrar que el cambio es correcto?
Ejemplos:
- errores difíciles de reproducir
- harnesses de pruebas insuficientes
- entornos frágiles
- código sensible al rendimiento
- comportamiento crítico para la seguridad
- regresiones sutiles que solo aparecen bajo carga o con datos de producción
La IA suele desplazar el esfuerzo hacia aquí. El borrador aparece más rápido. Demostrar que es correcto sigue siendo costoso.
4. Complejidad de coordinación
¿Cuántas personas, equipos, aprobaciones o puntos de contacto entre áreas de la organización deben alinearse?
Ejemplos:
- dependencias del equipo de plataforma
- revisión de diseño
- revisión legal o de cumplimiento
- coordinación con QA
- ventanas de lanzamiento
- comunicación con clientes
Esta es una de las razones por las que una misma funcionalidad puede ser «pequeña» para un equipo y «grande» para otro.
5. Complejidad de las consecuencias
¿Qué pasa si esto sale mal?
Ejemplos:
- fallas en pagos
- exposición a riesgos de seguridad
- corrupción de datos
- interrupciones visibles para los clientes
- reversiones costosas
- implicaciones regulatorias
Un bajo esfuerzo de programación y consecuencias graves pueden coexistir. La IA hace que esa discrepancia sea más común, no menos visible.
6. Complejidad de preparación para producción
¿Cuánto trabajo se necesita después de tener la primera versión funcional?
Ejemplos:
- limpieza y refactorización
- observabilidad
- documentación
- compatibilidad hacia atrás
- controles de despliegue
- monitoreo y alertas
- preparación del equipo de soporte
Esta es la clásica trampa de «funcionó en la demo». El prototipo llega rápido y todos subestiman el costo de hacerlo seguro, mantenible y operable.
La nueva regla
Esta es la forma más concisa de decirlo:
La IA reduce la fricción de implementación más rápido de lo que reduce la complejidad de entrega.
No necesitas una gran teoría para ver el patrón actual:
- la IA es excepcionalmente buena para reducir la fricción al crear borradores, traducir, generar estructuras iniciales y explorar opciones de implementación
- la IA es mucho menos fiable como sustituto del criterio al definir problemas, evaluar compromisos, entender el contexto organizacional, medir el alcance del impacto y verificar resultados
Así que cuando los equipos dicen «la IA hizo esto más rápido», la siguiente pregunta correcta es:
¿Qué parte se hizo más rápido?
Porque esa respuesta determina si el trabajo en conjunto realmente se volvió menos complejo o si la complejidad simplemente se desplazó.
Preguntas frecuentes que se hacen los equipos hoy
Estas son las preguntas que aparecen una y otra vez en conversaciones de ingeniería, revisiones de entrega y debates sobre Scrum.
«Si la IA puede construirlo en una tarde, ¿por qué esto sigue siendo un 8?»
Porque el borrador de la implementación no es lo mismo que el riesgo de entrega.
La historia aún puede implicar migración de datos, brechas de verificación, secuenciación del lanzamiento, planificación de la reversión, alineación de las partes interesadas o casos límite que no son evidentes.
En la era de la IA, los equipos deben dejar de permitir que la velocidad de la demo pese más que la realidad de la entrega.
«¿Deberíamos dejar de usar story points?»
No necesariamente.
Pero los equipos deben dejar de fingir que los story points representan horas de programación. Si siguen siendo útiles, deberían reflejar una evaluación conjunta de la incertidumbre, la integración, la verificación y las consecuencias, no solo el esfuerzo de implementación.
Si tu equipo no puede mantener estable ese significado, los pronósticos basados en flujo, con rangos históricos de tiempo de ciclo, podrían ser una mejor opción.
«¿Por qué los tickets que parecen fáciles todavía se complican durante el Sprint?»
Porque la IA abarata la parte visible del ticket.
Eso hace que los equipos descubran tarde que la parte difícil nunca fue la estructura inicial. Era la discrepancia entre el cambio local de código y el sistema en su conjunto.
«¿Por qué los PR son más grandes y las revisiones más difíciles si programar es más rápido?»
Porque una generación más rápida favorece lotes más grandes, a menos que los equipos contrarresten esa tendencia activamente.
Los hallazgos de DORA son una advertencia: la velocidad local de programación puede coexistir con una menor estabilidad de entrega cuando los cambios generados por IA se vuelven demasiado grandes para revisarlos y validarlos de forma segura.
«¿Esto significa que los ingenieros sénior importan menos?»
Casi todo lo contrario.
El valor que aportan los ingenieros sénior se desplaza de la cantidad de código producido hacia:
- definir el problema correctamente
- dividir el trabajo en lotes seguros
- decidir qué se debe verificar
- detectar dependencias ocultas
- proteger la integridad del sistema
La IA reduce el esfuerzo de implementación que pueden abordar los perfiles júnior. No elimina el valor del criterio.
Cómo se ve esto en la planificación real
La mejor manera de concretarlo es mediante algunos escenarios comunes.
Escenario 1: La funcionalidad CRUD «simple»
El asistente genera el formulario, la validación, el endpoint y las pruebas en una hora.
Todos sienten que la historia es muy pequeña.
Pero el trabajo real incluye:
- conciliar las reglas de acceso basadas en roles
- actualizar los registros de auditoría
- hacer cumplir las reglas de retención de datos
- manejar estados de falla parcial
- integrar el nuevo comportamiento en los reportes existentes
El tiempo de programación se redujo drásticamente. La complejidad del negocio y del sistema no.
Escenario 2: Un error en un sistema maduro
El cambio en sí puede ser de tres líneas.
Pero el error solo aparece bajo condiciones específicas de concurrencia en producción, el autor original se fue hace años, el harness de pruebas es insuficiente y el equipo no tiene plena confianza en la estrategia de despliegue.
Esto es baja complejidad de implementación y alta complejidad de verificación.
Los equipos que dimensionan solo por «cantidad de código» lo subestimarán cada vez.
Escenario 3: Un cambio de plataforma entre equipos
La IA puede generar rápidamente adaptadores, scripts de migración y borradores de documentación.
Pero el trabajo sigue dependiendo de:
- la coordinación con otro equipo
- la negociación de contratos
- el momento del despliegue
- la compatibilidad hacia atrás
- los consumidores posteriores
Aquí es donde quienes gestionan equipos de ingeniería necesitan especialmente un lenguaje más amplio que «rápido» o «lento».
Escenario 4: Un prototipo llamativo se convierte en un compromiso del roadmap
Alguien usa IA para construir una demo interna convincente en dos días.
Ahora la dirección supone que la funcionalidad de producción está cerca.
Pero aún queda:
- revisión de seguridad
- observabilidad
- refinamiento de UX
- responsabilidad operativa
- preparación del equipo de soporte
- pruebas de rendimiento
- gestión del cambio
El prototipo era real. La complejidad también era real. Estaban en distintas partes del ciclo de vida.
Qué falla en la planificación de Scrum
Este cambio afecta a Scrum de una manera muy práctica.
1. Los equipos vuelven a anclar las estimaciones al tiempo de programación sin darse cuenta
Esta es la trampa más grande.
En cuanto la IA acelera la implementación visible, los equipos empiezan a reducir las estimaciones sin reevaluar el resto del trabajo. El resultado es predecible:
- hacia el final del Sprint, queda claro que se comprometió más trabajo del que se puede completar
- se acumulan historias «casi terminadas»
- la revisión y las pruebas se convierten en el cuello de botella oculto
- la confianza en las estimaciones empeora en vez de mejorar
2. Los story points se vuelven inestables entre distintos tipos de trabajo
Un valor en puntos que parecía bien calibrado para el desarrollo de funcionalidades antes de la IA puede dejar de corresponder bien entre:
- trabajo greenfield frente a brownfield
- componentes aislados frente a cambios que afectan a todo el sistema
- herramientas internas frente a flujos regulados de cara al cliente
- trabajo de prototipo frente a preparación para producción
Cuanto más rápida se vuelve la IA, más se manifiesta esta inconsistencia.
3. Los planes de Sprint ignoran la carga de revisión inducida por la IA
Los equipos suelen celebrar que la IA ayudó a producir más código y luego, sin darse cuenta, sobrecargan a quienes revisan, a QA o a los responsables del lanzamiento.
Si la capacidad de revisión no forma parte de la planificación, la IA puede aumentar la producción local mientras reduce el flujo del sistema en su conjunto.
4. Quienes gestionan equipos confunden una reducción del esfuerzo con una reducción de la incertidumbre
No son lo mismo.
Una tarea puede parecer más fácil porque la IA se encarga de una mayor parte de la creación del borrador, pero seguir siendo muy incierta porque:
- los requisitos son inestables
- las dependencias no están resueltas
- los modos de falla no se comprenden bien
Esta es una de las razones por las que la IA puede hacer que el trabajo parezca más fluido mientras los pronósticos siguen siendo imprecisos.
Una mejor forma de estimar en la era de la IA
Los equipos de ingeniería no necesitan tanto un nuevo framework mágico como una mejor conversación.
Este es el cambio práctico que recomendaría.
1. Estimen la dificultad de entrega, no el esfuerzo de escribir código
Durante el refinamiento o la planificación, pregunten:
- ¿Qué no está claro?
- ¿Qué debe integrarse?
- ¿Qué es difícil de verificar?
- ¿Quién más debe estar alineado?
- ¿Qué pasa si esto falla?
- ¿Qué hay que preparar para producción después de la primera versión funcional?
Esto pone rápidamente en evidencia la complejidad real que la IA no elimina.
2. Dividan las historias según el tipo de complejidad
Una historia que mezcla descubrimiento, implementación, verificación y despliegue es más difícil de estimar que una historia que aísla un tipo de trabajo.
Posible división:
- parte de descubrimiento
- parte de implementación
- parte de preparación para producción
- parte de despliegue
Esto suele ser mucho más útil que intentar producir un único número «inteligente».
3. Hagan pronósticos con rangos, no con falsa precisión
Si un equipo usa Scrum, la decisión más saludable al planificar suele ser reducir la simulación de certeza.
Digan:
- «Es probable que la IA reduzca el tiempo de implementación aquí»
- «la integración y la revisión siguen siendo el riesgo»
- «deberíamos pronosticar esto como un rango, no como una promesa determinista»
El objetivo no es sonar menos seguros. Es ser más precisos.
4. Recalibren las estimaciones según la clase de trabajo
Ahora muchos equipos necesitan desarrollar una intuición distinta para cada categoría:
- desarrollo de funcionalidades greenfield
- cambios en sistemas existentes
- correcciones de incidentes
- migraciones
- trabajo de plataforma entre equipos
- preparación para producción
La IA afecta cada categoría de forma diferente. Tratarlas como un único ámbito de estimación hace que las cifras sean más variables de lo necesario.
5. Protejan rigurosamente los tamaños pequeños de los lotes
Si la IA aumenta la producción, los equipos necesitan más disciplina para mantener:
- pull requests más acotados
- revisiones más tempranas
- criterios de aceptación más precisos
- controles de pruebas más rigurosos
De lo contrario, la IA amplifica el tamaño de los lotes y el sistema de entrega absorbe las mejoras en forma de inestabilidad.
Qué deben cambiar los ingenieros y quienes gestionan equipos de ingeniería
Para los ingenieros:
- dejar de usar «puedo generar esto rápido» como prueba de que el trabajo es sencillo
- distinguir entre un primer borrador y un cambio verificado
- priorizar partes más pequeñas y fáciles de revisar
- hacer explícitos antes los costos ocultos de integración y verificación
Para quienes gestionan equipos de ingeniería:
- dejar de tratar la velocidad de programación con IA, por sí sola, como un dato directo para el pronóstico
- preguntar dónde se encuentra la incertidumbre restante
- monitorear las colas de revisión, el tamaño de los lotes, los defectos que llegan a producción y el retrabajo, no solo el volumen de producción
- separar la velocidad de creación de prototipos de la preparación para producción en las conversaciones sobre el roadmap
Aquí es donde el impacto en la gestión es más fuerte.
La intuición anterior para planificar era:
más velocidad de programación -> menos esfuerzo -> estimación más pequeña
Una mejor intuición para la era de la IA es:
más velocidad de programación -> comprobar dónde se desplazó la complejidad antes de reducir la estimación
Posición final sobre la hipótesis
Entonces, ¿es correcta la hipótesis?
Sí, con una corrección importante.
No es que la complejidad ya no pueda relacionarse en absoluto con el tiempo. Es que el tiempo ya no es un atajo fiable para medir la complejidad cuando la IA cambia solo algunas partes del trabajo.
Esto importa porque la planificación de Scrum, los pronósticos de ingeniería y las conversaciones sobre entregas se distorsionan cuando los equipos siguen tratando la velocidad de implementación como la señal principal.
El nuevo lenguaje de planificación debería sonar más así:
- esto requiere poco esfuerzo de programación, pero tiene un alto riesgo de verificación
- esto es fácil de estructurar, pero difícil de integrar
- esto es rápido de convertir en prototipo, pero costoso de preparar para producción
- esto implica poco código, pero tiene un gran alcance de impacto
- esto es sencillo para un equipo, pero requiere mucha coordinación entre tres
Esa es la conversación que la IA nos está obligando a tener.
Y, honestamente, de todos modos es una conversación más sana. Se acerca más a cómo ha funcionado siempre la complejidad del software.
Fuentes
- Investigación: cuantificación del impacto de GitHub Copilot en la productividad y la satisfacción de los desarrolladores — GitHub, 2022
- Investigación: cuantificación del impacto de GitHub Copilot en el entorno empresarial con Accenture — GitHub, 2024
- Medición del impacto de la IA de principios de 2025 en la productividad de desarrolladores experimentados de código abierto — METR, 2025
- Estamos cambiando el diseño de nuestro experimento sobre productividad de desarrolladores — METR, 2026
- Impacto de la IA generativa en el desarrollo de software: el imperativo de la IA y el enfoque de DORA — DORA, 2025
- Equilibrar las tensiones de la IA: de la adopción de IA a su uso eficaz en el SDLC — DORA, 2026
- El SPACE de la productividad de los desarrolladores — ACM Queue, 2021
- La Guía de Scrum (November 2020) — Scrum Guides