Blog
El SDLC en la era agéntica: cómo cambia el ciclo de vida del software
En 2026 los agentes de IA ya no solo sugieren líneas de código: abren incidencias, escriben cambios completos, ejecutan pruebas y proponen pull requests. El ciclo de vida del software (SDLC) no ha desaparecido, pero se ha desplazado: el trabajo humano se mueve de escribir código a definir la intención, revisar y decidir. Este artículo repasa cómo cambia cada fase, qué dicen los datos y dónde están los riesgos.
El ciclo, redibujado
Las fases siguen siendo las de siempre, pero cambia quién las ejecuta: el agente hace el trabajo del centro y las personas se quedan con la intención de partida y la decisión final. La revisión es hoy el punto donde se acumula el trabajo.
Fase a fase: qué cambia
El patrón se repite en cada fase: el agente produce más y más rápido, y la persona pasa a especificar y a verificar.
Fase | Qué hace el agente | Qué hace la persona |
|---|---|---|
Requisitos y planificación | Convierte una incidencia en un plan o una especificación técnica | Define el objetivo, los límites y los criterios de aceptación |
Implementación | Escribe cambios que tocan varios archivos y abre el pull request | Elige qué tareas delegar y en qué orden |
Pruebas | Genera tests, los ejecuta e itera hasta que pasan | Comprueba que los tests prueban lo que importa |
Revisión | Hace una primera revisión automática del código | Lee, cuestiona y aprueba; asume la responsabilidad del cambio |
Despliegue | Prepara la configuración y lanza el pipeline | Da la aprobación final a producción |
Operación | Vigila alertas, diagnostica incidencias y propone arreglos | Decide si aplicar el arreglo o revertir |
La consecuencia es que la especificación vuelve a ser un documento de primera clase. Un agente solo es tan bueno como la instrucción y el contexto que recibe: tickets vagos producen código que compila pero no resuelve el problema.
Lo que dicen los datos
La adopción se ha duplicado en un año, pero los agentes siguen trabajando con correa y la ganancia de productividad depende mucho del tipo de código.
Dato | Valor | Fuente |
|---|---|---|
Profesionales que usan agentes en el trabajo | 59% (31% en 2025) | |
Uso diario de agentes | 37% (14% en 2025) | |
Rara vez o nunca dejan al agente en piloto automático | 63% | |
Usan un solo agente frente a sistemas multiagente | 69% frente a 16% | |
Ganancia de productividad en tareas sencillas y proyectos nuevos | 35–40% | |
Ganancia en código heredado complejo | 10% o menos | |
Parte del código que ya escribe la IA en empresas que la han adoptado | Cerca de la mitad |
Medir la productividad real sigue siendo difícil. En 2025, METR vio que desarrolladores expertos tardaban un 19% más con IA aunque creían ir un 20% más rápido. Su repetición de 2026 ya apunta a mejoras, pero con intervalos muy amplios, y METR ha tenido que rediseñar el estudio: entre el 30% y el 50% de los participantes no quería hacer algunas tareas sin IA.
DORA resume el patrón como una curva en J: primero hay una caída de productividad por el aprendizaje y el coste de verificar código ajeno, y después llega la ganancia. Su conclusión es que la IA amplifica lo que ya existe: los equipos con buenas bases de ingeniería ganan más y los desordenados se desordenan más rápido.
Los riesgos: seguridad, revisión y deuda
El código que escriben los agentes compila casi siempre, pero no es seguro por defecto. Según el informe 2026 de Veracode, el 44% de las tareas de generación introdujo vulnerabilidades de riesgo y la tasa media de aprobación en seguridad sigue estancada en el 56%. Los modelos fallan especialmente en cross-site scripting (15% de aprobados) e inyección en logs (12%).
El segundo riesgo es la propia revisión. Si los agentes multiplican los pull requests pero el número de revisores no cambia, la cola crece y la tentación es aprobar sin leer. DORA lo llama el "impuesto de verificación": revisar código que no has escrito cuesta más que revisar el tuyo.
El tercero es la cadena de herramientas que rodea al agente. Esta misma semana se publicó un fallo en el SDK oficial de MCP para Python que permitía a un servidor malicioso robar credenciales OAuth. Cada conector que se le da a un agente es también una superficie de ataque.
Qué pueden hacer los equipos ahora
Escribir mejores especificaciones. Criterios de aceptación claros y contexto del repositorio (convenciones, arquitectura) valen más que cambiar de modelo.
Automatizar la verificación antes de la revisión humana. Tests, análisis estático y escaneo de seguridad en cada PR del agente, para que la persona revise decisiones y no errores triviales.
Limitar lo que el agente puede tocar. Permisos mínimos, sin cambios en producción sin aprobación y conectores auditados y actualizados.
Empezar por donde la ganancia es mayor. Tareas acotadas y código nuevo primero; el código heredado complejo, después.
Medir resultados, no volumen. Tasa de fallos en cambios, tiempo de revisión e incidencias, además de PRs abiertos o líneas escritas.
En resumen, el SDLC agéntico no elimina a los desarrolladores: los convierte en quienes definen el problema y responden del resultado. Los equipos que antes tenían buenas prácticas son los que más están ganando con los agentes.
Fuentes
¡Contáctanos!
¡Contáctanos!