SDLC con IA: cómo cambian las 6 etapas con agentes

Casi todo el ritual que rodea a tu código existe por una razón muy concreta: escribir ese código era la parte cara. Los PRD, las estimaciones, los comités de arquitectura, la revisión de seguridad previa… todo eso se inventó para forzar alineación antes de gastar semanas de desarrollo. Si equivocarte cuesta un trimestre, invertir un mes en no equivocarte sale barato.

¿Y si implementar pasa a costar horas?

La aritmética se rompe. No porque los controles sobren, sino porque estaban calibrados para otro precio. Anthropic ha publicado un playbook del SDLC nativo de IA que reordena las seis etapas de siempre alrededor de esa idea. Es un documento con intención comercial, así que aquí lo vas a leer con lupa: qué propone, qué se sostiene, qué aplica a tu escala y dónde puede reventar.

Lo que cubre este artículo:

• Por qué el ciclo de vida clásico está optimizado para un cuello de botella que se ha movido de sitio
• Las seis etapas del SDLC tradicional con su artefacto, su control y su coste real
• Cómo quedan esas mismas etapas cuando cada una escribe un fichero versionado que la siguiente lee
• Qué sobrevive de todo esto si trabajas solo, en un equipo de cinco o en una empresa regulada
• El orden de adopción, las métricas que salen del git log y los cinco puntos donde el modelo puede fallar

¿Por qué el SDLC tradicional se diseñó para un cuello de botella que ya no existe? ¶

Porque durante cuarenta años la etapa lenta fue construir, y todo el proceso se montó alrededor de esa lentitud.

Seis etapas, cada una con su dueño, y el trabajo viajando entre ellas mediante documentos, tickets y firmas. Planificar, diseñar, construir, probar, desplegar, mantener. El diseño es correcto para su época: cuando cada línea la escribe una persona a mano, tiene todo el sentido del mundo revisar cada línea a mano.

Los datos dicen que la época ha cambiado. El informe DORA 2025 de Google Cloud recoge que el 90% de los profesionales encuestados ya usan IA en el trabajo y más del 80% cree que le ha subido la productividad. Y en la encuesta de Stack Overflow de 2025 el 84% usa o planea usar herramientas de IA.

Aquí viene la parte incómoda. En esa misma encuesta solo el 29% confía en que la salida sea correcta, un 46% desconfía, y la frustración número uno (66%) son las soluciones “casi correctas, pero no del todo”. DORA lo dice con otras palabras: la adopción de IA ya correlaciona con más throughput, pero sigue correlacionando con más inestabilidad. Pasar de un 5% a un 6% de tasa de fallo en los cambios le costó a las organizaciones del estudio unos 344.000 dólares estimados en caídas.

Más volumen por delante, el mismo embudo por detrás.

Tres consecuencias que se notan enseguida:

1. El cuello de botella se desplaza. Lo que hay a izquierda y derecha del build (planificar, revisar, desplegar) sigue funcionando a velocidad humana. Si el build se comprime y lo demás no, el ciclo total apenas mejora. Es la ley de Amdahl aplicada a tu tablero de Jira.

2. Los controles dejan de encajar. Revisar línea a línea tenía sentido cuando una persona había escrito cada línea. Con diez veces más diffs entrando, la misma persona hace la misma revisión con la décima parte de atención por línea.

3. La gobernanza se encarece. Las excepciones siguen pasando por comités que se reúnen los martes. El coste de esperar al martes no ha cambiado; lo que ha cambiado es cuánto trabajo se acumula esperando.

¿Qué hace cada etapa del SDLC tradicional y qué te cuesta de verdad? ¶

Antes de proponer el cambio conviene mirar bien lo que hay. Cada etapa tiene un artefacto que produce, un control que protege y un coste que casi nunca aparece en la presentación de PowerPoint.

Planificar. Alguien detecta un problema. Ese alguien casi nunca es quien lo va a escribir. La idea entra en un backlog, se convierte en historia de usuario, se refina en una reunión, se le asignan puntos. Artefacto: un ticket. Control: que no se construya lo que nadie ha pedido. Coste real: la propiedad de la idea cambia de manos tres o cuatro veces, y lo que llega a ingeniería es una traducción de una traducción. La persona de soporte que reportó el problema ya no reconoce su propio problema.

Diseñar. Analistas formalizan el ticket en requisitos. Diseñadores interpretan esos requisitos. Arquitectura opina. Seguridad opina más tarde, casi siempre demasiado tarde. Artefacto: un documento de requisitos y unos mockups, normalmente en herramientas distintas que no se hablan entre sí. Coste real: es un proceso con pérdidas, y las políticas (seguridad, marca, accesibilidad) se descubren en una revisión semanas después, cuando cambiar de rumbo ya duele.

Construir. El desarrollador lee el diseño y empieza a escribir. El cómo (qué ficheros toca, en qué orden, qué puede romper) vive en su cabeza o, con suerte, en un comentario del ticket. Artefacto: el diff. Control: ninguno, en realidad. El primer control llega después, cuando lo primero que ve un revisor es el resultado terminado y discutir el enfoque significa tirar trabajo.

Probar. QA como puerta al final de la etapa. La señal de que algo funciona llega tarde: CI en minutos, un tester en días, producción en semanas. Coste real: alguien tiene que validar todo lo que sale del build, y esa persona se convierte en el nuevo cuello de botella.

Desplegar. Revisión humana línea a línea, aprobaciones, ventana de despliegue, comité de cambios si la organización es lo bastante grande. Control: separación de funciones, quien escribe no aprueba. Coste real: la capacidad de revisión está dimensionada para producción humana, y la calidad de cada revisión depende de cuánta carga tenga el revisor ese día.

Mantener. Fase reactiva. Una alerta salta de madrugada. Un ticket espera en el backlog. Las acciones del post-mortem se escriben y no llegan al código porque empieza el siguiente incendio. Coste real: el aprendizaje no vuelve al sistema y el mismo fallo se repite con otro nombre.

🔑 Ninguna de esas seis etapas es tonta. Todas resuelven un problema real. Lo que ha cambiado es el precio de la etapa que todas estaban protegiendo.

Curso gratis · paso a paso

Antes de rediseñar tu ciclo entero, mira uno funcionando

Todo lo que viene ahora se apoya en la misma idea: artefactos que el agente escribe y tú apruebas. En el curso recorres el ciclo completo de SDD con OpenSpec sobre un proyecto de juguete (proposal, spec, diseño, tareas, apply y archivar) para verlo entero antes de coger tú el volante.

Entra en el curso gratis →

¿Cuál es la idea que reordena el ciclo entero? ¶

No es “meter IA en cada etapa”. Es una sola frase, y conviene separarla del ruido de marketing:

💡 Cada etapa termina escribiendo un artefacto en control de versiones, y la siguiente etapa empieza leyéndolo.

De ahí salen dos propiedades que el proceso tradicional nunca tuvo.

La primera: los artefactos son legibles por una persona y ejecutables por una máquina a la vez. Un .md sirve para las dos cosas. Un ticket en una herramienta propietaria, no: tu agente no lo lee sin una integración, y cuando la tiene lo lee peor.

La segunda: la cadena de commits es la pista de auditoría. Quién pidió qué, qué produjo el agente, quién lo aprobó. No hay que fabricar evidencia aparte porque la evidencia es un efecto secundario de trabajar.

Y el proceso deja de ser una línea recta. Se convierte en un bucle: lo que aparece en producción vuelve a entrar como intención nueva.

Si esto te suena a Spec Driven Development, vas bien encaminado. La diferencia es de alcance: el SDD ordena la fase de construir, y este modelo intenta ordenar las seis.

¿Cómo se captura la intención sin pasar por el backlog? ¶

Con una conversación y un fichero. El originador del problema habla con un agente hasta que la idea es concreta, y el resultado se escribe como intent.md en sus propios términos.

Lo que hace el agente ahí es elicitación pura: preguntar lo que preguntaría un analista. Alcance, usuarios afectados, restricciones, qué significa “esto ya está bien”. Ni más ni menos.

El patrón ya tiene nombre en otros sitios. Matt Pocock lo llama alineamiento y lo empaqueta en una skill de diez líneas, /grill-me, que interroga hasta llegar a un entendimiento compartido antes de escribir nada. Es exactamente la misma pieza con otra etiqueta, y merece la pena mirarla porque su workflow completo resuelve bien la parte que el playbook despacha en un párrafo: cuántas preguntas son suficientes.

Un intent.md mínimo honesto se ve así:

# Intent: estado del pedido en autoservicio
Autor: soporte. Estado: borrador.

## Problema
Los clientes escriben para preguntar dónde está su pedido.
Se va un tercio del tiempo de soporte en consultas de estado.

## Resultado esperado
El cliente ve estado, siguiente paso y fecha estimada en su panel.

## Afecta a
Soporte, equipo de frontend, API de pedidos.

## Restricciones
Sin datos personales nuevos en la sesión. Autenticación actual.

## Preguntas abiertas
¿Los transportistas externos necesitan acceso?

Cinco encabezados. Nada más.

Lo que cambia de verdad no es el formato, es quién escribe. La persona que tiene el problema escribe el problema. Se elimina la traducción con pérdidas, no la reunión.

Y ese originador no tiene que ser del equipo técnico. Puede ser quien atiende soporte, una responsable de producto con una idea, un cliente reportando un fallo o tú mismo capturando una mejora de proceso a media tarde. Los ficheros viven en el repositorio, en una carpeta intent/, con un prefijo en el nombre que te deje ordenarlos y buscarlos después (2026-09-06-estado-pedido.md funciona perfectamente).

¿Dónde está el riesgo? En que intent.md se convierta en un formulario. Si nadie rechaza nunca uno, no es una puerta, es un trámite con extensión .md.

¿Qué pasa con el backlog si cualquiera puede escribir una intención? ¶

Que sigue existiendo. Cambia de formato, no desaparece, y este es el punto donde el modelo se cae si no lo miras.

Si el originador puede ser cualquiera, en tres semanas tienes cuarenta ficheros en la carpeta intent/ escritos por ocho personas distintas con criterios distintos. Eso es un backlog. Uno mejor que el de antes, porque cada entrada la escribió quien tenía el problema y no una traducción a tercera mano, pero un backlog al fin y al cabo. Y un backlog sin priorizar es un cementerio ordenado.

Hacen falta dos cosas, y solo la segunda es nueva.

Alguien decide el orden. Product owner, tech lead, tú un viernes por la mañana. La captura de intención democratiza quién plantea el problema, no quién decide qué se construye. Confundir esas dos cosas es la vía rápida a un equipo trabajando en lo que gritó más fuerte.

El triaje se puede delegar en un agente. Aquí sí hay ganancia real. Un agente lee la cola de intenciones y les pone etiquetas: si es fallo o mejora, qué área toca, tamaño estimado, prioridad propuesta, y qué intenciones son la misma cosa contada de dos maneras. Lo que llega a la persona que prioriza ya viene agrupado y comparable. La decisión sigue siendo suya; lo que se ahorra es la hora de leer cuarenta ficheros para poder tomarla.

Y una vez la intención está aprobada, el paso a la spec puede dispararse solo. Un hook sobre el commit que marca la intención como aceptada arranca la sesión que produce el spec.md. Ahí es donde el proceso empieza a parecerse a una tubería en vez de a una carpeta compartida.

¿Se pueden juntar requisitos y diseño en una sola sesión? ¶

Sí, y es donde el modelo se pone más interesante. En vez de dos fases con dos equipos y dos traducciones, una sesión lee el intent.md aprobado y produce spec.md, con las políticas de la organización cargadas como contexto ejecutable en lugar de como un PDF en una wiki que nadie abre.

El cambio de fondo: la política se aplica mientras se escribe la spec, no se descubre en una revisión tres semanas después.

Y hay una petición que marca la diferencia entre una spec útil y una spec decorativa: exigirle al agente que marque los conflictos. Algo tan simple como “señala explícitamente dónde no puedes satisfacer políticas contradictorias”. Esos puntos son exactamente los que un analista habría escalado, y son los primeros que hay que resolver con quien tenga la autoridad para resolverlos.

¿Quién revisa la spec? Quien escribió la intención. Revisa, no redacta. Y con una sola pregunta en la cabeza: ¿esta spec resuelve el problema que planteé?

¿Por qué no se implementa nada sin un plan aceptado? ¶

Porque el plan es el último punto donde cambiar de opinión sigue siendo barato.

En el modelo tradicional el plan vive en la cabeza del desarrollador y nadie puede revisarlo. Aquí la sesión arranca en modo planificación, con lectura del código pero sin escritura. El agente propone un plan, la persona lo interroga, y el plan aprobado se commitea como plan.md.

El criterio para saber si un plan está terminado es sencillo: sirve cuando alguien que no ha visto la conversación puede implementar el cambio solo con él. Antes de eso, no está.

Y ese “alguien” casi nunca es una persona. Aquí está la parte que se entiende tarde: ninguna de las seis etapas la ejecuta el mismo agente. Cada una arranca en una ventana de contexto distinta, y los subagentes que trocean la implementación arrancan con la suya propia y vacía. El plan.md no es documentación para el equipo, es el traspaso entre agentes que no comparten memoria. Si el plan solo se entiende habiendo leído la conversación que lo produjo, el siguiente agente va a improvisar la mitad.

Tres preguntas valen más que veinte iteraciones:

• ¿Qué puede romper este cambio?
• ¿Cuál es el paso más arriesgado?
• ¿Qué alternativas has descartado y por qué?

Con el plan aprobado, la ejecución puede ir mucho más deprisa, pero el orden importa: primero afinas los permisos, después sueltas al agente. Trabajar aceptando acciones una a una durante unos días es lo que te dice qué herramientas, qué rutas y qué dependencias son de uso legítimo en tu repositorio. Cuando eso está escrito en la configuración, el modo automático deja de ser una apuesta y pasa a ser un radio de acción acotado. Al revés (auto mode primero, permisos después de un susto) también funciona, pero es más caro.

Ahí es donde los hooks dejan de ser teoría. Tres ejemplos concretos de esta etapa:

• Actualizar el plan.md de forma automática cuando la implementación de un paso termina, para que el artefacto no se quede viejo.
• Bloquear la escritura en carpetas que el cambio no debería tocar.
• Impedir que el agente añada o actualice una dependencia que nadie ha aprobado.

Y si el plan se trocea en tareas independientes, cada una puede irse a su propio worktree de Git y ejecutarse en paralelo. Es el mecanismo que hace posible lo de las sesiones simultáneas, con el límite que ya viste: no cuántas puedes lanzar, cuántas puedes revisar.

Aquí entran dos piezas que sostienen todo lo demás, y que merecen su propio párrafo.

El fichero de contexto del repositorio. CLAUDE.md, AGENTS.md, el que use tu herramienta. Es el onboarding que le darías a alguien nuevo el primer día: comandos de build y test, convenciones que importan, y las cosas que el agente se empeña en hacer mal. La regla de trabajo es una: cuando el agente comete el mismo error dos veces, la corrección se escribe ahí. Y se mantiene corto (el playbook sugiere no pasar de una página) porque todo lo que contiene ocupa contexto en cada sesión. Si quieres el detalle de qué va en el fichero, qué va en el prompt y qué va en una regla por ruta, lo desmenuzamos en el post sobre AGENTS.md y dónde vive cada regla.

El conocimiento institucional como instrucción versionada. Una política que hoy se aplica de forma desigual (un estándar de seguridad de APIs, una convención de diseño, una regla de marca) se escribe una vez, se versiona y se actualiza en un sitio. La distinción práctica es limpia: lo que debe aplicarse siempre y en todas partes es conocimiento institucional; lo que solo aplica a este repositorio va en el fichero de contexto; lo que solo aplica a esta tarea va en el prompt.

⚠️ Una instrucción es un control blando. Hace probable que la política se aplique; no la garantiza. Lo que debe cumplirse sin excepción necesita algo determinista detrás: un hook que bloquee la acción o una comprobación en CI. La instrucción hace raro el incumplimiento. El hook lo hace imposible.

Esa frontera es la que más gente se salta, y es la que separa un proceso de una intención de proceso.

¿Cómo se verifica el trabajo del agente antes de que lo veas tú? ¶

Con un bucle cerrado que el agente pueda ejecutar solo. Esta es, de todo el playbook, la pieza con mejor relación coste-beneficio.

La regla, entera, en una frase: siempre hay que darle al agente una forma de comprobar su propio trabajo antes de que lo vea una persona. Tests, build, una captura comparada con el mockup. Si el agente no puede verificarse, tú eres su suite de tests, y eso no escala más allá de un par de sesiones.

Cuatro reglas que funcionan en la práctica:

Un solo comando que devuelva error si algo falla. Si comprobar el trabajo requiere cinco comandos y conocimiento del entorno, envuélvelo en un script. El agente no va a adivinar tu setup.

Para lo visual, dale ojos. Los tests y el build cubren la lógica, no cubren que el botón esté donde tiene que estar. Con automatización de navegador el agente levanta la aplicación, recorre el flujo y compara la captura con el mockup. Cambia por completo lo que llega a la revisión: en vez de “he implementado el modo oscuro”, llega el modo oscuro con la pantalla al lado.

Objetivos cuantificables. “Pasan los tests de test_estado.py”, “el endpoint devuelve 200 con el campo nuevo”. Nunca “que funcione bien”.

Para bugs, primero el test que falla. Reproduce el fallo como test, confirma que falla por la razón esperada, commitea el test, y solo entonces pide el arreglo sin tocar el test. Un test que existía antes del arreglo y que el agente no pudo reescribir es la única prueba real de que el bug se ha ido.

Protege el bucle. Un agente que arregla código no puede tener permiso para debilitar la comprobación de ese código. Suena obvio hasta que ves un commit que “arregla” el test en vez del bug.

Y hay una segunda capa: evaluar la configuración como se evalúa el código. Cuando cambias el fichero de contexto, una instrucción o el modelo, estás cambiando el sistema que produce tu software. El playbook propone un conjunto de 20 a 50 tareas reales con su resultado esperado, que te dice si el agente sigue trabajando al mismo nivel. Cada incidente de producción se convierte en un caso nuevo y se queda ahí como test de regresión.

Aquí es donde el dato de Stack Overflow cobra sentido: si el 45% de los desarrolladores dice que depurar código generado por IA lleva más tiempo, el problema no es que la IA escriba mal. Es que llega hasta ti sin haber pasado por ningún filtro automático.

Tu IA puede mentirte

Cuando el bucle de verificación deja de ser una teoría

Montar el bucle es la parte fácil de contar y la difícil de ejecutar. En esta masterclass se ve funcionando: ciclo anticaos, pruebas de navegador con Playwright, casos Gherkin, evaluación de skills y revisión adversarial entre modelos. Con las manos en el teclado, no en diapositivas.

Ver la masterclass entera →

Masterclass en directo · Acceso con Web Reactiva Premium

¿Qué revisa una persona cuando el código lo escribe un agente? ¶

Dos cosas que conviene no mezclar: la revisión automática y la puerta de aprobación.

La revisión automática. Todos los PR reciben el mismo conjunto de pasadas: errores lógicos, seguridad, y cumplimiento contra la spec y el plan. Los hallazgos vienen con severidad. La atención humana sube un nivel y responde a una pregunta distinta: ¿el cambio hace lo que el plan decía, y el riesgo es aceptable?

Hay un matiz de montaje que importa: la instancia que revisa no es la que escribió, y la que responde a los comentarios de la revisión tampoco es la misma. Son procesos separados, con su propio contexto y sus propias políticas cargadas. No es paranoia, es la única forma de que la revisión no herede los mismos puntos ciegos que produjeron el código. Encima de eso va una segunda pasada específica de seguridad, que puede ser determinista (linters, análisis estático, comprobaciones de dependencias) o de agente.

Un detalle pequeño que cambia el resultado: definir por escrito qué cuenta como importante y qué es un detalle menor, y ponerle tope a los detalles menores. El playbook propone cinco por revisión. Una revisión automática con cuarenta comentarios de estilo se ignora entera, y con ella se van los tres hallazgos que sí importaban. Si quieres arrancar por aquí, tenemos un repaso a las mejores Agent Skills para revisar código y seguridad.

Las puertas de aprobación. Un hook puede permitir, preguntar o bloquear. Y la regla de fondo cabe en una línea: el agente puede llegar hasta la puerta de producción y no puede cruzarla.

Protección de rama, sin ruta directa a main, y despliegue a producción condicionado a una autorización con nombre y apellidos. La separación de funciones se mantiene intacta por una razón mecánica, no por confianza: quien escribió el código no tiene forma de aprobarlo.

¿Cómo se cierra el bucle en mantenimiento? ¶

Con un disparador que no espera a que una persona reaccione. Una métrica fuera de banda, un ticket, un mensaje en un canal, un cron. El agente diagnostica, actúa solo por rutas autorizadas, y escribe lo que encuentra como un intent.md nuevo.

Ahí es donde el círculo se cierra de verdad: la salida del mantenimiento es la entrada de la planificación.

El propio modelo asume dos cautelas que conviene subrayar porque son las que evitan el desastre.

La primera: la detección se mantiene determinista. El script que vigila la métrica no lleva modelo dentro. El modelo entra cuando ya hay algo que investigar. Un detector probabilístico te despierta a las tres de la mañana por nada.

La segunda: la autonomía se escalona. Ante una desviación pequeña, solo se registra. Ante una mayor, el agente diagnostica en modo lectura. Ante la mayor de todas, el agente puede proponer, y proponer significa abrir un PR o lanzar un runbook aprobado de antemano. Nunca actuar directamente sobre producción.

¿En qué se diferencian los dos ciclos, etapa por etapa? ¶

Fíjate en que la columna de la derecha no elimina ni un solo control de la izquierda. Los mueve de sitio y les cambia el formato. Eso es lo que hace que el modelo sea defendible delante de un auditor y no solo delante de un CTO con prisa.

¿Qué parte de esto aplica si trabajas solo o en un equipo de cinco? ¶

Aquí es donde hay que traducir, porque el playbook está escrito para organizaciones grandes y decir que aplica todo sería venderte humo.

Persona sola o freelance ¶

Se queda:

• El artefacto versionado. No por auditoría, sino por memoria. Dentro de tres meses no vas a recordar por qué descartaste la alternativa B, y el plan.md sí.
• El modo planificación como norma. Es la mejora con mejor relación coste-beneficio de toda la lista.
• El bucle de verificación. Un comando, un objetivo medible.
• El fichero de contexto del repositorio, corto y mantenido.

Se cae o se reduce:

• La separación intención / spec / plan en tres ficheros para un cambio de dos horas. Colapsa a uno. La ceremonia debe ser proporcional al tamaño del cambio o la abandonas en dos semanas.
• Las evaluaciones continuas en CI con presupuesto de API. Aquí basta con un puñado de casos que ejecutas a mano cuando cambias de modelo o reescribes una instrucción.
• Los hooks de aprobación. No hay a quién pedirle aprobación.

El riesgo específico de esta escala tiene nombre: eres a la vez quien escribe y quien aprueba. La única salvaguarda barata es temporal. Revisar en una sesión distinta, con el contexto limpio, leyendo el diff contra el plan. No es separación de funciones, pero es algo.

Equipo pequeño, de 3 a 10 personas ¶

Aquí es donde el modelo rinde mejor, porque hay suficiente gente para que la coordinación duela y suficiente poca como para cambiar el proceso en una tarde.

Prioridades, en este orden:

1. Fichero de contexto compartido en el repo, revisado como código.
2. Bucle de verificación, con la regla de “no se reporta hecho sin pegar la salida de los tests”.
3. Modo planificación por defecto, con el plan commiteado.
4. Revisión automática en el PR con política escrita, incluyendo el tope de comentarios menores.
5. Conocimiento institucional versionado, empezando por una sola política que hoy se aplica de forma desigual.
6. Hooks para lo que no puede fallar nunca.

Lo que hay que vigilar son las sesiones en paralelo. El techo real no es cuántos agentes puedes lanzar, es cuántos flujos puede revisar bien una persona. El playbook sugiere dos o tres como punto de partida, y solo se añade uno más mientras la revisión aguante. Si empiezas a aprobar sin leer, ya has perdido lo que ganabas.

Organización grande o regulada ¶

Aquí el modelo se aplica casi entero, pero con un problema previo: ya existen sistemas que guardan estos artefactos. Jira, herramientas de requisitos con trazabilidad regulatoria, comités de cambio. Y los auditores ya los aceptan.

Tres configuraciones posibles, y hay que elegir una por artefacto:

• El repositorio manda y el sistema heredado referencia commits. Es la más limpia si el equipo es de ingeniería.
• El sistema heredado manda y los markdown son copias de trabajo que se sincronizan.
• Enlace mínimo: cada artefacto anota el ID del registro y cada registro guarda el SHA del commit. Se aceptan dos fuentes de verdad, y es el punto de partida realista.

Lo importante es que haya una designada. Dos fuentes de verdad sin enlace no son un proceso, son un problema de reconciliación esperando a explotar.

¿En qué orden se adopta todo esto? ¶

Nada de esto se adopta a la vez. Y el orden importa porque hay dependencias reales entre las piezas:

1. Fichero de contexto del repo. Sin prerrequisitos. Todo lo demás lo lee.
2. Bucle de verificación. Sin prerrequisitos. Es lo que permite bajar la supervisión.
3. Modo planificación. Mejora mucho con los dos anteriores.
4. Captura de intención. Sin prerrequisitos técnicos, pero necesita a alguien no técnico con acceso y con ganas.
5. Revisión automática en el PR. Necesita el 1 y el 3, porque revisa contra ellos.
6. Hooks como puertas. Necesita saber qué aprobaciones deben sobrevivir.
7. Cierre del bucle. Necesita todo lo anterior. Es lo último, no lo primero.

Si alguien empieza por el 7 sin el 1, lo que ha construido es un generador automático de trabajo no revisado. Y de esos ya hay bastantes.

¿Cómo medir si esto funciona sin montar un observatorio? ¶

Con lo que ya tienes. Estas métricas salen del git log y de los metadatos de los PR, sin instrumentación extra:

• Tiempo entre la intención y la spec para el mismo cambio. Dos timestamps de commit, una resta.
• Reproceso de requisitos: commits de spec fechados después del primer commit de plan. Si son muchos, la spec no estaba lista cuando dijisteis que lo estaba.
• Deriva del plan: cuántas veces el diff final sigue pareciéndose al plan.md aprobado.
• Errores repetidos que el fichero de contexto debería haber evitado. Si se repiten, o no se está leyendo o está desactualizado.
• Hallazgos de revisión que citan una política ya escrita. Deberían tender a cero. Si no lo hacen, la instrucción no se está activando o ha derivado del texto oficial.
• Tiempo hasta el primer PR mergeado de alguien nuevo. El mejor indicador agregado de que el contexto del repositorio funciona.

Ninguna de las seis necesita una herramienta nueva. Esa es justo la gracia.

¿Dónde puede fallar este modelo? ¶

El documento original es una propuesta comercial y no se detiene mucho aquí, así que vamos a detenernos nosotros. Cinco puntos de fallo, por orden de probabilidad.

La burocracia de markdown. Tres ficheros por cambio es un proceso pesado disfrazado de ligero. Si intent.md, spec.md y plan.md se escriben para cambios de una hora, has reinventado el waterfall con mejor tipografía. El criterio: la ceremonia escala con el radio de impacto, no con la costumbre. Lo mismo pasa con las specs, y por eso recopilamos los errores comunes al hacer Spec-Driven Development antes de que te los encuentres tú.

El aprobador de goma. El modelo depende de que un humano revise en la puerta. Si el volumen sube diez veces y la persona sigue siendo una, la aprobación se convierte en un clic. El control existe en el organigrama y no en la realidad. Esto no lo arregla ninguna herramienta: se arregla limitando el paralelismo a lo que la revisión aguanta.

Artefactos que nadie lee. Un plan commiteado solo vale si la revisión lo compara con el diff. Si nadie hace esa comparación, el plan.md es teatro de auditoría.

La instrucción confundida con el control. Merece repetirse porque es el error más caro: lo probabilístico no garantiza. Todo lo que deba cumplirse siempre necesita un hook o una comprobación determinista detrás.

El acoplamiento a un proveedor. El patrón (artefacto versionado, plan antes que código, verificación propia, puerta humana) es agnóstico. Las piezas concretas no lo son. Si escribes el proceso contra los ficheros y comandos de un producto específico, migrar a otro agente es reescribir el proceso. Conviene separar desde el principio el patrón de la implementación, y escribir los artefactos en un formato que cualquier agente pueda leer.

El proceso que cambias cada dos semanas. Este no sale en el playbook y es el que más he visto de cerca. Un flujo mediocre que todo el equipo conoce rinde más que uno excelente que cambia cada sprint, porque las skills, los hooks, los ficheros de contexto y las costumbres de la gente se calibran contra un proceso concreto. Elige una forma de hacerlo, escríbela, y aguanta unos meses antes de tocarla.

Corolario para quien ya tiene algo montado: si trabajas con BMAD, con superpowers, con OpenSpec o con un flujo propio que funciona, no lo tires para adoptar esto entero. Coge las piezas que te falten (el bucle de verificación, la puerta determinista, el triaje de intenciones) y déjalas encajar en lo que ya tienes. No hay una talla única aquí, y quien te diga lo contrario te está vendiendo su talla.

🛡️ Si tu proceso no sobrevive a cambiar de agente, no tienes un proceso: tienes una configuración.

TL;DR ¶

• 🔁 Cada etapa termina escribiendo un artefacto versionado (intent.md, spec.md, plan.md) y la siguiente empieza leyéndolo. Legible por personas, ejecutable por máquinas.
• 📝 Nada se implementa sin un plan escrito y aceptado. El plan es el último punto donde cambiar de opinión sale barato.
• ✅ El agente siempre tiene que poder comprobar su propio trabajo con un solo comando antes de que lo veas tú. Si no puede, tú eres su suite de tests.
• 🚪 El agente llega hasta la puerta de producción y no la cruza. La separación de funciones se mantiene por mecánica, no por confianza.
• ⚖️ Una instrucción hace probable el cumplimiento; un hook lo hace obligatorio. No los confundas.

Preguntas frecuentes sobre el SDLC con agentes de IA ¶

¿Qué es el SDLC nativo de IA?
Es un ciclo de vida del desarrollo de software en el que cada etapa produce un artefacto versionado en markdown que la siguiente etapa lee, y en el que los agentes ejecutan el trabajo mientras las personas revisan intención, riesgo y aprobación. Mantiene las seis etapas clásicas y cambia dónde se aplica el control humano.

¿En qué se diferencia del SDLC tradicional?
En que el plan deja de vivir en la cabeza del desarrollador y pasa a ser un fichero revisable, la verificación ocurre dentro de cada sesión en lugar de en una puerta de QA al final, y la revisión humana se concentra en el riesgo en vez de repartirse por igual sobre cada línea.

¿Esto sustituye al Spec Driven Development?
No, lo extiende. El SDD ordena la fase de construir alrededor de una especificación. Este modelo aplica la misma idea a las seis etapas del ciclo, desde la captura de la intención hasta el mantenimiento.

¿Necesito escribir tres ficheros para cada cambio?
No. La ceremonia debe escalar con el radio de impacto del cambio. Para un arreglo de dos horas, un solo fichero de plan es suficiente. Los tres artefactos separados tienen sentido cuando hay varias personas implicadas o el cambio toca sistemas críticos.

¿Quién prioriza si cualquiera puede escribir una intención?
Sigue haciéndolo una persona con responsabilidad de producto. La captura de intención democratiza quién plantea el problema, no quién decide qué se construye. Lo que sí se puede delegar en un agente es el triaje previo: agrupar duplicados y proponer tipo, área, tamaño y prioridad para que la decisión humana llegue con la cola ya ordenada.

¿Qué diferencia hay entre una instrucción y un hook?
Una instrucción es un control blando: hace probable que el agente aplique la política, pero no lo garantiza porque el modelo es probabilístico. Un hook es determinista: bloquea la acción antes de que ocurra. Todo lo que deba cumplirse sin excepción necesita un hook o una comprobación en CI.

¿Cuántas sesiones de agente puedo llevar en paralelo?
El límite no es técnico, es de revisión. Dos o tres sesiones simultáneas es un punto de partida razonable, y solo conviene añadir una más mientras puedas seguir revisando cada flujo con atención real.

¿Qué pongo en el fichero de contexto del repositorio?
Comandos de build y test, convenciones que el agente no puede deducir leyendo el código, y los errores que comete de forma repetida. Mantenlo corto (una página es una buena referencia) porque ocupa contexto en cada sesión.

¿Cómo se verifica que un bug está arreglado de verdad?
Escribiendo primero el test que reproduce el fallo, confirmando que falla por la razón esperada y commiteándolo antes de pedir el arreglo. Si el agente no puede modificar ese test, que pase después del arreglo es prueba real de que el bug se ha ido.

¿Sirve esto si trabajo solo?
Sí, con recortes. Se quedan el artefacto versionado, el modo planificación, el bucle de verificación y el fichero de contexto. Se caen los hooks de aprobación y las evaluaciones continuas en CI. El riesgo propio de esta escala es aprobar tu propio trabajo, y se mitiga revisando en una sesión distinta con el contexto limpio.

¿Cómo encaja esto con un proceso auditado o regulado?
Eligiendo por artefacto quién es la fuente de verdad: el repositorio, el sistema heredado, o un enlace mínimo en el que cada artefacto anota el ID del registro y cada registro guarda el SHA del commit. Lo que no funciona es tener dos fuentes de verdad sin enlace entre ellas.

Fuentes ¶

• The AI-native SDLC playbook — Anthropic
• Announcing the 2025 DORA Report — Google Cloud
• 2025 Stack Overflow Developer Survey: AI — Stack Overflow

🧨 Última oportunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter