El software se construye en bucles, no en cascada: cómo funciona de verdad el desarrollo moderno con IA

En resumen. Los proyectos de software clásicos planifican todo de principio a fin y entregan al final. El software de IA moderno se construye de otra manera: en bucles cortos donde, después de cada ciclo, hay algo funcional que se puede ver, probar y corregir. La diferencia no es cosmética. Determina si un proyecto de IA llega a producción o acaba como un piloto caro. Y esa es precisamente la forma más habitual en que fracasan los proyectos de IA.

Por qué la cascada funciona especialmente mal con la IA

El enfoque clásico en el desarrollo de software se suele llamar cascada: primero el plan completo, luego la ejecución, al final la entrega. En problemas bien conocidos puede funcionar. Con la IA, casi nunca.

La razón es sencilla. Con la IA, al principio no sabes qué va a funcionar realmente lo bastante bien. Si un modelo lee tus documentos con la fiabilidad necesaria, si un agente asume de verdad el proceso de principio a fin, si la calidad aguanta en la práctica: todo eso solo se ve cuando algo está funcionando. Un gran plan que fija doce meses antes qué se va a construir choca con una tecnología cuyo resultado no se conoce de antemano. Por eso tantos proyectos de IA producen una demo impresionante y después nada que llegue a producción.

Lo extendido que está este patrón lo muestra un estudio del MIT (proyecto NANDA, "The GenAI Divide", 2025): alrededor del 95% de los pilotos de IA generativa estudiados no lograron un retorno medible ni llegaron a producción. Importante para contextualizar: esto es una afirmación sobre pilotos de IA generativa, no sobre la IA en general, y no sobre el uso de herramientas ya hechas. Pero de esos pilotos se trata precisamente cuando una empresa encarga construir algo propio. La causa principal que señala el MIT no es técnica, sino estructural: los sistemas no aprenden durante el uso ni se ajustan. Ese es un problema de cascada.

El bucle de construcción

La alternativa es un bucle corto y repetido. Un ciclo se ve así:

1. Construir una pieza pequeña. No el sistema entero, sino el siguiente paso con sentido.
2. Revisar de inmediato. ¿Funciona? ¿Resuelve el problema con datos reales? Pruebas automatizadas más una mirada humana.
3. Aprender del resultado. ¿Qué funciona, qué no, y qué implica eso para el siguiente paso?
4. Repetir. El siguiente ciclo se construye sobre lo aprendido.

Cada ciclo termina con algo funcional, no con un informe de avance. Suena a detalle menor, pero lo cambia todo: el riesgo se hace visible pronto en vez de al final, corregir el rumbo cuesta días en vez de meses, y nadie construye durante doce meses sobre una suposición que resulta ser falsa.

Esta forma de trabajar no es nueva: el desarrollo ágil de software sigue desde hace tiempo un principio parecido. Lo nuevo es que los agentes de codificación de IA aceleran el bucle de forma drástica. Un ciclo que antes duraba un sprint hoy puede caber en horas. Con eso, el desarrollo iterativo con IA deja de ser solo razonable y pasa a ser la única opción honesta.

Cascada frente a bucle de construcción

Lo que esto significa en la práctica, con cifras reales

Una advertencia antes de nada, porque si no, este texto cometería exactamente el error que critica: las siguientes cifras son de nuestro propio trabajo en nuestra propia plataforma, no cifras de cliente ni un estudio general. Muestran cómo entrega un equipo pequeño con esta forma de trabajar, y se pueden verificar en nuestro propio historial de Git.

En un periodo de unas 36 horas, pusimos en producción unas 30 funcionalidades independientes, cada una como un paso propio, revisado e integrado: en conjunto, 244 archivos modificados y algo más de 32.000 líneas de código. La base de pruebas detrás cubre 660 casos de prueba repartidos en 76 archivos de test. Esta velocidad no viene de teclear más rápido. Viene de que cada paso es pequeño, se revisa al momento y queda cubierto por pruebas: viene del bucle en sí.

Y a la honestidad le corresponde también la otra cara. La velocidad sin control es peligrosa. Un ejemplo de nuestra propia operativa: dos agentes trabajando en paralelo llegaron a tocar el mismo archivo, porque una lista de responsabilidades no había recogido una dependencia, y se pisaron el uno al otro. Estas cosas pasan cuando se avanza rápido. La cuestión no es que nada salga mal. La cuestión es que el bucle hace visibles esos errores pronto, cuando cuestan minutos, en lugar de tarde, cuando cuestan un lanzamiento. Por eso incorporamos los puntos de control antes de empezar, no después de que algo se rompa.

Cómo reconocer con quién estás tratando

Si vas a encargar la construcción de software con IA, la forma de trabajar de tu proveedor es una de las pocas cosas que puedes comprobar de antemano. Algunas preguntas que aclaran rápido el panorama:

• ¿Cuándo veo la primera pieza funcional? Si la respuesta es "al final", es cascada.
• ¿Con qué frecuencia entregáis? Semanas está bien, trimestres es una señal de alarma.
• ¿Qué pasa si, durante la construcción, resulta que una suposición era falsa? Si eso es una solicitud de cambio con sobrecoste en vez del siguiente ciclo, eso delata el modelo que hay detrás.
• ¿Probáis con datos reales o solo en la demo? Una demo no demuestra nada sobre el funcionamiento en producción.

Construimos software de IA en producción, todos los días, exactamente en estos bucles. Si quieres saber cómo se traduce esto a un proyecto concreto en tu empresa, ese es el tema para una primera conversación.