En este artículo
¿Vuelve el desarrollo en cascada con la IA? ¿Cuánto debes planificar?
Apruebas un plan detallado. Pasan meses antes de que alguien pueda usar el resultado. Las prioridades cambian. Si la IA acorta ese intervalo, conviene revisar los argumentos contra la planificación previa.
La IA da motivos para dedicar más atención a la planificación previa del software. Una implementación más rápida deja menos tiempo para que un buen plan quede obsoleto y permite aplicar antes las decisiones acordadas. Antes de un cambio importante, acordaríamos resultados, restricciones y criterios de aceptación, con los supuestos abiertos a revisión.
Planificar de antemano significa resolver decisiones antes de implementar. El desarrollo en cascada organiza el trabajo en fases secuenciales. Puedes adoptar la planificación previa sin dejar todos los requisitos congelados hasta el lanzamiento final.
Investigación revisada: 10 de noviembre de 2026. Este argumento se apoya en fuentes primarias y un cálculo hipotético. No hemos realizado un experimento de Wavect que compare el desarrollo en cascada con Agile. La programación 100 veces más rápida del ejemplo es un supuesto, no un resultado medido en el sector.
¿Por qué merece la pena reconsiderar la planificación previa con IA?
Planificar antes cobra más valor cuando la implementación se acelera tanto que las decisiones pendientes pasan a condicionar la entrega. Un agente puede actuar de inmediato sobre un requisito acordado. Si nadie ha definido qué resultado es correcto, la rapidez puede producir trabajo que otra persona tendrá que rechazar o rehacer.
En una función para exportar datos de clientes, dos agentes podrían desarrollar la interfaz y la API en paralelo. Acordar el aislamiento entre organizaciones, el esquema de datos y el tratamiento de errores les permite trabajar hacia el mismo resultado. Si la instrucción se limita a «crear la exportación», cada uno tendrá que suponer esas decisiones.
Un cambio que puedes mostrar a los usuarios esta semana está expuesto durante menos tiempo a nuevas circunstancias que otro cuya implementación tarda un año, si ambos parten de la misma incertidumbre. Acortar la implementación puede hacer más rentable la planificación sin volver infalible la predicción.
Nuestro ensayo sobre IA, especificaciones y el regreso de la fábrica de software aborda ese cambio general en el trabajo de ingeniería. Aquí la decisión es cuánto conviene resolver antes de la siguiente implementación.
¿El único problema del desarrollo en cascada era la lentitud al programar?
Una implementación lenta podía dejar obsoleto el plan. Descubrir un error demasiado tarde era otro problema. Incluso una implementación instantánea puede cumplir el requisito equivocado. La planificación necesita mecanismos para detectar supuestos erróneos antes de comprometer demasiado trabajo y revisar las decisiones cuando cambien las evidencias.
El artículo de Royce de 1970 ya advertía del riesgo de descubrir restricciones del sistema durante las pruebas finales y describía la retroalimentación entre etapas. No es una buena base para defender un proceso rígido que solo avanza en una dirección. Puedes comprobarlo en el artículo original sobre el desarrollo de grandes sistemas.
El Manifiesto Ágil también reconoce el valor de los planes, aunque da prioridad a responder al cambio. Seguir un plan cuando ya tienes evidencias en contra puede desperdiciar incluso una implementación rápida.
¿La IA ya permite implementar software 100 veces más rápido?
Los estudios revisados no demuestran una aceleración general de 100 veces en la implementación de software. Los resultados dependen de la tarea, la persona, la herramienta y la medida elegida. El tiempo necesario para superar una tarea de programación, la actividad del código, los lanzamientos y el valor para el cliente responden a preguntas distintas.
| Evidencia | Resultado publicado | Límite |
|---|---|---|
| Experimento controlado de Copilot, realizado en 2022 | 95 programadores participantes; quienes completaron la tarea con Copilot tardaron un 55,8 % menos. | Una tarea de servidor HTTP en JavaScript, no la entrega de un producto completo. |
| Experimento de METR de principios de 2025 | 16 responsables de mantenimiento experimentados, 246 tareas; el acceso a IA aumentó el tiempo de finalización un 19 %. | Un entorno de repositorios y una generación de herramientas concretos, no una ralentización universal vigente hoy. |
| Writing Code vs. Shipping Code, revisión de septiembre de 2026 | Con datos de más de 500.000 desarrolladores de GitHub, el estudio observacional estimó un aumento mucho mayor de la actividad del código que de los lanzamientos. | Contar resultados no equivale a medir el tiempo ahorrado ni el valor para el cliente. |
La actualización de METR de febrero de 2026 explica que los efectos de selección y la medición del tiempo con agentes simultáneos impiden obtener una estimación fiable de la productividad en ese seguimiento. El resultado anterior no debe tratarse como un veredicto sobre las herramientas actuales.
Podemos estudiar el factor 100 como hipótesis: si una implementación concreta se acelera tanto, ¿cuánto mejora el proyecto completo?
¿Qué cambiaría en el proyecto si programaras 100 veces más rápido?
En un proyecto secuencial hipotético, programar 100 veces más rápido puede aumentar el peso relativo de la planificación sin acercar la aceleración total a ese factor. El resultado depende de cuánto tiempo ocupaba la implementación y de si el resto del trabajo también se acelera. El cálculo no determina el presupuesto óptimo de planificación.
Supongamos el mismo alcance y los mismos criterios de aceptación: 10 días de planificación, 80 de implementación y 10 de verificación y lanzamiento. Solo se acelera la implementación. Las fases no se solapan y no cambian las esperas ni el trabajo que hay que rehacer. Son datos ilustrativos, no mediciones de Wavect ni promedios del sector.
Días totales = 10 + 80 / factor de aceleración de la implementación + 10
| Factor de implementación | Días de implementación | Días totales | Aceleración del proyecto completo | Proporción de planificación |
|---|---|---|---|---|
| 1× | 80 | 100 | 1× | 10 % |
| 10× | 8 | 28 | 3,57× | 35,7 % |
| 100× | 0,8 | 20,8 | 4,81× | 48,1 % |
| Implementación instantánea, caso límite | 0 | 20 | 5× | 50 % |
La planificación ocupa casi la mitad del escenario de 100× sin haberle dedicado un día adicional. Su proporción aumenta porque la implementación se acorta. Eso no demuestra que duplicar la fase de planificación ayudara.
Para evaluar tu proceso de entrega, mide la ruta crítica. No sumes duraciones que se solapan. Si la IA también cambia las pruebas, la revisión o el trabajo repetido, estima esos efectos por separado. Lo que interesa es el tiempo transcurrido hasta obtener un cambio aceptado y utilizable.
¿Qué debes planificar antes de encargar el trabajo a un agente?
Define las decisiones que harían costoso deshacer una implementación rápida: el resultado para el usuario, las responsabilidades, los límites de acceso a datos, las interfaces, el comportamiento ante fallos y los criterios de aceptación. Dales el detalle necesario para delimitar el siguiente cambio. No hace falta fijar elecciones técnicas sin consecuencias relevantes solo porque un agente pueda redactar un documento largo sobre ellas.
Para un cambio importante, pide al responsable que aclare:
- Resultado y alcance: qué problema de quién se resuelve, cómo observarás el éxito y qué peticiones relacionadas quedan fuera.
- Restricciones: a qué datos y acciones puede acceder el sistema, qué debe conservar y qué compromisos de compatibilidad existen.
- Interfaces: qué recibe, devuelve y registra cada componente cuando algo falla.
- Aceptación y recuperación: qué evidencias permiten lanzar, quién las evalúa y cómo detener o recuperar un despliegue que no funciona.
Los resultados de MirrorCode de abril de 2026, de Epoch AI y METR, muestran una reimplementación autónoma de alcance considerable con un comportamiento de referencia ejecutable y pruebas detalladas. Ese benchmark acotado respalda la utilidad de especificaciones verificables. No demuestra que el desarrollo en cascada sea superior ni aporta un factor de velocidad medido frente a personas.
«Gestionar bien los fallos» da poco que comprobar a quien revisa. «Tras una respuesta incierta del proveedor, conserva el identificador de la operación y comprueba su estado antes de volver a intentarlo» describe un comportamiento que se puede poner a prueba.
¿Cuánta planificación previa necesita cada cambio?
Elige el nivel de detalle según la incertidumbre y el coste de revertir una decisión. Los requisitos claros con consecuencias costosas justifican una preparación detallada. Ante un comportamiento todavía incierto que puedas cambiar a bajo coste, experimenta pronto. Si ambos factores son altos, diseña primero una forma segura de aprender sin comprometer el sistema completo.
| Incertidumbre de los requisitos | Coste de revertir | Siguiente acción más útil | Ejemplo |
|---|---|---|---|
| Baja | Bajo | Escribe unas condiciones de aceptación breves e implementa. | Un cambio visual con un ejemplo acordado que no modifica datos guardados. |
| Baja | Alto | Resuelve las dependencias, los fallos posibles y la recuperación antes de ejecutar. | Una migración que debe conservar los registros y las integraciones existentes. |
| Alta | Bajo | Formula la pregunta que necesitas resolver y prueba una versión desechable. | Dos recorridos de incorporación probados con usuarios representativos. |
| Alta | Alto | Reduce la incertidumbre con una simulación o prueba aislada antes de comprometerte. | Una nueva regla de asignación evaluada con datos sintéticos antes de afectar a cuentas reales. |
Si un agente puede crear pronto un prototipo seguro, dedicar otra semana a debatir una interfaz hipotética puede aportar poco. Implementar más rápido puede aumentar el valor de planificar restricciones conocidas y reducir el de predecir preferencias que puedes observar directamente.
Entiende el coste de revertir en sentido amplio: personas afectadas, datos perdidos, compromisos asumidos, interrupciones operativas y trabajo de ingeniería. Que generar código sea barato no abarata todas sus consecuencias. Los requisitos de seguridad obligatorios siguen siendo límites aunque una hoja de cálculo presente un experimento arriesgado como rentable.
¿Cuándo está el plan lo bastante claro para empezar?
Deja de planificar cuando el siguiente cambio tenga un resultado acordado, restricciones explícitas, un responsable, criterios de aceptación observables y una vía de recuperación. Registra las dudas pendientes y cómo las probarás. Sigue aclarando decisiones solo cuando sea razonable esperar que eviten un perjuicio mayor que el coste del tiempo dedicado a resolverlas.
Considera este ejemplo ficticio: un agente de soporte necesita solicitar un reembolso completo a través de un proveedor de pagos. Supongamos que las condiciones para concederlo y la política de aprobación ya están acordadas. Si entran en conflicto, consulta primero la guía para resolver reglas de negocio contradictorias antes de especificar.
| Decisión previa a la implementación | Requisito verificable |
|---|---|
| Autoridad | Solo un rol de soporte autorizado puede solicitar el reembolso aprobado dentro de su propia organización. |
| Identidad de la operación | Guarda una clave de idempotencia estable para el reembolso autorizado y utiliza un proveedor que la admita en los distintos intentos. |
| Concurrencia | Los clics simultáneos y las solicitudes recibidas por duplicado no pueden crear operaciones de reembolso distintas para la misma petición aprobada. |
| Respuesta incierta del proveedor | Si se agota el tiempo de espera, la operación queda pendiente de conciliar su estado. No crees otra operación solo porque se haya perdido la respuesta. |
| Aceptación y recuperación | Demuestra en un entorno de prueba cómo se gestionan la denegación de autorización, las solicitudes duplicadas y las respuestas perdidas. Documenta cómo el personal confirma un resultado todavía incierto. |
Esas condiciones bastan para investigar el comportamiento del proveedor y crear una integración de prueba acotada. No constituyen un sistema de reembolsos implementado o verificado. El agente puede elegir nombres de funciones auxiliares; no puede decidir reglas de negocio en silencio ni suponer que no se movió dinero porque se agotó el tiempo de espera.
¿Qué resolvería otra sesión de planificación que esta implementación segura no pudiera enseñarnos a menor coste? Si solo queda pulir el documento, empieza el trabajo acotado.
¿Cómo debería funcionar un ciclo de desarrollo con IA que empiece por el plan?
Mantén cada implementación lo bastante pequeña para revisarla y la especificación fácil de corregir. Acuerda un cambio acotado, impleméntalo y compruébalo con criterios de aceptación revisados de forma independiente. Antes del siguiente cambio, examina el resultado con sus usuarios o con la persona responsable.
- Elige un resultado. Identifica al usuario, el cambio observable y a quien puede aceptarlo.
- Resuelve la ambigüedad costosa. Revisa las restricciones y los fallos posibles que señala la matriz de planificación.
- Genera una implementación revisable. Divide el trabajo en partes cuyo comportamiento puedas verificar y registra cualquier desviación de las condiciones acordadas.
- Comprueba la implementación y los supuestos. Prueba su corrección, inspecciona los cambios de código y busca evidencias de que el comportamiento ayuda al usuario previsto.
- Actualiza la especificación. Deja visibles el comportamiento aceptado, los supuestos descartados y la siguiente pregunta antes de iniciar otro cambio.
La presentación de Spec Kit de GitHub describe especificaciones que evolucionan y tareas pequeñas y revisables. Nuestra guía de Spec Kit para producción aborda la herramienta. Una especificación estructurada sigue necesitando una evaluación independiente de sus supuestos.
La guía de DORA sobre lotes pequeños también destaca la importancia de obtener información pronto durante el desarrollo asistido por IA. Limita cada lote a lo que puedes verificar, aunque el agente pueda generar más.
¿Cómo sabes si dedicar más tiempo a planificar compensa?
Evalúa la planificación adicional por las entregas aceptadas, el trabajo que se rehace y los defectos que llegan a producción. Mide desde que empiezas a aclarar el cambio hasta que se acepta el lanzamiento, incluidas la revisión de la especificación y las esperas. Acortar la programación solo ayuda si el trabajo restante no anula la mejora ni rebaja la aceptación.
Como piloto propuesto, compara cambios similares: unos con una descripción breve de la tarea y otros con condiciones previas más explícitas. Registra el tamaño, la incertidumbre, el coste de revertir, la familiaridad del equipo y las versiones de las herramientas. Asigna al azar tareas comparables a cada método cuando sea viable; si no, considera la comparación descriptiva y deja visibles las diferencias entre tareas.
Registra el tiempo transcurrido hasta la entrega y el esfuerzo humano de planificación, implementación y revisión. Anota el trabajo reabierto, los defectos detectados después del lanzamiento y si el cambio produjo el resultado previsto para el usuario. Son mediciones propuestas, no resultados de un piloto que hayamos ejecutado.
Mantén el mismo alcance y los mismos criterios de calidad: contar más líneas generadas premia el volumen, y más lanzamientos pueden reflejar entregas de menor tamaño. Nuestra guía de costes de un MVP de IA trata el presupuesto del proyecto. Aquí debes decidir si aclarar más requisitos justifica el tiempo que ocupa en la entrega.
¿Conviene recuperar el desarrollo en cascada?
Recupera una planificación previa rigurosa cuando los requisitos puedan aclararse y los errores resulten caros de revertir. La IA hace que merezca la pena probar ese enfoque: una implementación bien definida puede llegar mientras sus supuestos siguen siendo útiles. Acota el alcance y revisa el plan según la evidencia. Amplía la planificación solo si mejora la entrega aceptada.
Para un proceso conocido, prepararíamos una especificación precisa antes de encargarlo a agentes. Para un producto cuyos usuarios o propuesta de valor aún sean inciertos, planificaríamos el experimento y buscaríamos evidencias pronto.
Si tu equipo todavía no acuerda el resultado, las restricciones o quién acepta el cambio, el servicio de descubrimiento y definición de requisitos de software de Wavect aborda esas decisiones. La guía de la fase de descubrimiento de software explica su alcance. El caso de entrega y migración del protocolo Quivr aporta contexto de ingeniería relacionado; no demuestra una aceleración de la IA ni una comparación entre metodologías.
Cuéntanos qué cambio concreto quieres implementar. Decide qué debe quedar resuelto antes de programar y qué evidencias permitirán lanzarlo.