Un estudio sobre el SDLC agentic desplaza el foco desde generar código hasta demostrar que merece llegar a producción

Un trabajo publicado en arXiv por Happy Bhati propone cambiar la pregunta con la que se evalúan los agentes de programación. En lugar de preguntar cuánto código pueden producir, plantea medir cuánto valor apto para producción entrega el sistema por dólar, por hora de revisión y por unidad de riesgo operativo. El estudio no presenta un experimento nuevo: sintetiza investigaciones de ingeniería de software, estudios universitarios, auditorías de benchmarks, informes de empresas y evidencias de costes publicadas principalmente entre 2024 y septiembre de 2026.

La tesis parte de una observación sencilla. Los agentes actuales pueden inspeccionar repositorios, editar varios archivos, ejecutar herramientas, escribir pruebas y abrir pull requests con una supervisión limitada. Esa capacidad hace más barata la producción de cambios plausibles, pero no elimina las etapas que convierten un cambio en software confiable. Revisión, integración, pruebas, seguridad, despliegue y operación siguen siendo restricciones, y pueden convertirse en el nuevo cuello de botella cuando aumenta el número de cambios generados.

El autor denomina a esta tensión “Agentic SDLC Throughput Paradox”: más actividad de programación no implica necesariamente más software fiable entregado. El concepto de “Production-Qualified Change” intenta fijar un criterio más útil. Un cambio no cuenta plenamente por estar escrito o por pasar una prueba aislada; debe atravesar las comprobaciones que la organización exige antes de producción, incluyendo integración, seguridad, observabilidad y capacidad de recuperación cuando corresponda.

El trabajo también introduce la “Verification Tax”, el coste adicional de revisar, probar y corregir la salida de los agentes. Ese coste no se limita a una licencia por usuario. Incluye tokens, llamadas a herramientas, entornos aislados, ejecución de CI, reintentos y trabajo humano de revalidación. Por eso, una métrica que solo mida líneas de código, tareas cerradas o velocidad de generación puede ofrecer una imagen optimista y económicamente incompleta.

La propuesta más operativa es un “control plane” del SDLC agentic. No se trata necesariamente de una plataforma concreta, sino de una capa de políticas que asigna autonomía según el coste, la fiabilidad esperada y la atención humana disponible. Un cambio pequeño y bien acotado podría avanzar con controles automáticos. Una migración de datos, una modificación de permisos o una alteración de un componente crítico debería exigir más pruebas, revisores y límites de ejecución.

Para los equipos, la lección es diseñar el flujo antes de ampliar la autonomía. Conviene definir qué significa “listo”, qué evidencias debe adjuntar un agente, qué comandos puede ejecutar, qué rutas requieren aprobación y cómo se mide el retrabajo posterior. Las pruebas siguen siendo necesarias, pero no bastan si no cubren integración y operación. También hace falta observar el coste por cambio y el tiempo de revisión, porque una aceleración local puede trasladar trabajo a QA, seguridad o soporte.

El artículo debe leerse como una síntesis y una agenda de investigación, no como una demostración definitiva. Su utilidad está en situar el debate en el punto donde normalmente fallan las promesas de automatización: el límite entre generar código y demostrar que el sistema puede mantenerlo con seguridad.