Anthropic publica su manual del SDLC con IA y admite que un solo proceso no basta

Anthropic ha publicado su AI-Native SDLC Playbook, un manual sobre cómo organizar el ciclo de vida del software cuando los agentes escriben el código. La tesis central es que el código ha dejado de ser el cuello de botella: si un agente produce una implementación en minutos, el límite se traslada a la planificación, la revisión, la verificación, el despliegue y el gobierno.

El riesgo que señala es concreto. Si multiplicas por diez los cambios manteniendo la calidad por cambio, o algo peor, ya no hay manera humana de identificar cuáles son los malos. Y la respuesta tradicional, que una persona mire cada propuesta, es justo la que deja de funcionar a ese volumen.

La ola del desarrollo guiado por especificación

El playbook se suma a una corriente más amplia: Spec Kit de GitHub, Kiro de Amazon y herramientas parecidas. Todas comparten una forma reconocible. Los artefactos escritos dirigen el trabajo: un documento de intención se convierte en spec, en plan, en diff y en hallazgos de revisión, todo versionado. Las políticas se aplican con mecanismos deterministas como hooks, no con instrucciones dentro de un prompt. Los agentes comprueban su propio trabajo antes de que lo vea una persona. Y las aprobaciones siguen siendo humanas.

El problema es que cada herramienta trae su propio proceso: una secuencia fija de etapas que producen artefactos fijos, y por la que pasa todo cambio. Adoptar la herramienta significa adoptar su proceso.

Muchos procesos, no uno

Ninguna organización real corre un único proceso. Un arreglo de documentación, una subida de dependencia y una migración de esquema en un servicio de pagos no deberían recorrer el mismo camino: exigen niveles de verificación, aprobadores y registros distintos. En dominios regulados el proceso forma parte de la obligación de cumplimiento, porque el auditor quiere saber quién aprobó cada cambio y con qué evidencia.

Cuando una herramienta impone un solo flujo, los equipos lo sortean para los cambios que no encajan, y eso es lo peor: el proceso real se vuelve invisible. La otra salida es que el proveedor acumule configuración hasta convertir la herramienta en un motor de workflow que nadie entiende del todo.

La propuesta es definir cada proceso como una máquina de estados. Los estados son hechos sobre un cambio —revisado, validado contra sus dependencias, aprobado para producción— y viven en sistemas que ninguna herramienta posee en exclusiva: el repositorio, el CI, el clúster, el gestor de incidencias. El proceso no es un programa que ejecuta pasos, sino un conjunto de reglas guardado como datos y revisado como código. Cada regla declara qué hechos necesita, si dispara sola o espera aprobación humana, y qué permiso concede al hacerlo, como hacer merge o desplegar. El proceso avanza cuando aparece un hecho, no cuando alguien anota que va por el paso cuatro, así que los eventos duplicados, tardíos o posteriores a un reinicio se tratan igual que cualquier otro.

La ruta depende de cómo se clasifique el cambio, no de que el autor elija camino: rutas tocadas, repositorio, etiqueta en la incidencia. Y como la definición es datos, editarla es a su vez un cambio con su propio proceso: relajar una aprobación del proceso de release se revisa como una migración de esquema, no se toca como un fichero de configuración. La pieza que falta es quién hace cumplir la puerta: si está implementada como instrucción en un prompt, depende de que el modelo la obedezca.

Queda por ver si las herramientas de terceros adoptan este modelo o siguen vendiendo su secuencia fija. Lo que plantea es una decisión de arquitectura para quien opera pipelines: dónde vive la puerta y quién la hace cumplir cuando ya no cabe una persona por cambio.