Imagina la planificación del lunes. Tu equipo estima una historia en cinco días. El martes, el agente ya ha escrito el código y las pruebas. El viernes la historia sigue abierta: nadie había decidido qué pasa cuando un cliente no tiene dirección de facturación, y la respuesta tardó tres días en llegar.
Cuando programar deja de ser lo caro, el ciclo de vida del software no desaparece: cambia de cuello de botella. El tiempo que el agente ahorra escribiendo código se pierde en las suposiciones que nadie dijo en voz alta antes de empezar.
Qué pasa cuando planifica la IA sola
Adriana Caraeni, Alexander Shick y Andrew Lan compararon tres formas de planificar un sprint sobre un encargo real de una agencia digital mediana: solo con IA, solo con personas y con las dos a la vez. Planificar solo con IA fue lo más rápido y lo más barato, pero «significantly degrades risk capture rates»: captó menos riesgos y dejó más retrabajo por suposiciones que nadie había dicho.
Su conclusión cuestiona algo que muchos equipos dan por hecho: «that efficiency equates to effectiveness». Proponen dejar a las herramientas la estimación y el formato del backlog, y reservar a las personas la conversación sobre riesgos y ambigüedades.
Límite Es un preprint de siete páginas, en revisión, hecho en una sola agencia, y su resumen no da el tamaño de la muestra. Sirve como señal de dónde mirar en tu equipo.
Dónde se va ahora el tiempo
Si el código sale en horas, el ritmo del ciclo lo marca lo que tarda tu equipo en contestar una pregunta. ¿Qué pasa con este caso límite? ¿Quién decide si cambia el contrato de la API? Antes, esas preguntas aparecían a mitad de la implementación y se resolvían por el camino, porque programar daba tiempo para pensar. Con un agente aparecen en minutos. Y entonces se quedan esperando a alguien, como en el metatrabajo con agentes, o el agente las contesta solo con lo que le parece razonable.
Algo parecido pasaba en un cliente del sector público. Los proveedores externos programaban con IA sin integrarse en el flujo ni en el contexto del equipo. Cada vez, las pull requests, las propuestas de cambio que se revisan antes de incorporarlas al código, eran más complejas de hacer.
La fase que más crece es la de antes del código: escribir lo que el equipo da por supuesto. Una issue de dos líneas no basta, por las razones de por qué una issue no es una especificación. Basta con una línea por suposición, con la forma de comprobar que se cumple: ya cambia la semana.
Una pregunta para tu próxima planificación
Mira la última historia que se retrasó en tu equipo. ¿Se retrasó escribiendo código o esperando una respuesta? Si fue lo segundo, el atajo está en la planificación: sentar en ella a quien puede contestar y salir con las suposiciones escritas.
Si quieres mirarlo con alguien de fuera, el diagnóstico es gratuito. Antes, puedes ver cómo trabajamos con equipos de desarrollo en AI-Accelerated Development.
Preguntas frecuentes
¿Cómo cambia el ciclo de vida del software con IA?
Las fases siguen siendo las mismas: entender el problema, especificar, construir, probar, desplegar y operar. Cambia dónde se va el tiempo. Escribir el código puede pasar a durar horas, y el ritmo lo marca lo que tarda el equipo en decidir lo que el agente no puede deducir por su cuenta.
¿Hay que cambiar de metodología, por ejemplo a AIDLC?
No necesariamente. AIDLC (AI-Driven Development Life Cycle) es la metodología que AWS presentó en julio de 2025 para un ciclo de desarrollo dirigido por IA, y hay otras propuestas. Antes de cambiar el nombre del proceso, conviene mirar dónde espera hoy el trabajo de tu equipo: si espera respuestas, el cambio está en cuándo y con quién decide el equipo.
¿Puede la IA planificar el sprint sola?
Puede ayudar a estimar y a ordenar el backlog. En un experimento publicado en abril de 2026 sobre un encargo real de una agencia digital, planificar solo con IA fue más rápido y más barato, pero captó menos riesgos y generó más retrabajo por suposiciones que nadie había dicho. Los autores proponen dejar a las personas la conversación sobre riesgos y ambigüedades.
¿Sirve ese experimento para mi empresa?
Sirve como señal de dónde mirar. Es un preprint en revisión, de siete páginas, hecho en una sola agencia, y su resumen no da el tamaño de la muestra. Lo útil es mirar en tu equipo dónde se retrasan las historias: escribiendo código o esperando una respuesta.
¿Qué es una suposición sin escribir?
Cualquier decisión que el equipo da por hecha y que nadie ha dejado por escrito antes de empezar: qué pasa si un cliente no tiene dirección de facturación, quién puede cambiar el contrato de una API, qué tiempo de respuesta se acepta. Si nadie la escribe, el agente la rellena con lo que le parece razonable.
¿Escribir las suposiciones obliga a hacer documentos largos?
No hace falta. Basta con una línea por suposición, con la forma de comprobar que se cumple. Es la base del Spec-Driven Development (SDD), el desarrollo guiado por especificaciones: dejar escrito qué tiene que hacer el cambio y con qué criterios se acepta antes de que nadie, persona o agente, escriba el código.
Fuentes
- Adriana Caraeni, Alexander Shick y Andrew Lan, «Cognitive Offloading in Agile Teams: How Artificial Intelligence Reshapes Risk Assessment and Planning Quality», arXiv:2604.13814, 15 de abril de 2026 (en revisión).
- Raja SP, «AI-Driven Development Life Cycle: Reimagining Software Engineering», AWS DevOps & Developer Productivity Blog, 31 de julio de 2025.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →