# claxton-anthropic-ai-native-sdlc-playbook-2026-08-21

## Veille

Guía extensa de **Anthropic** firmada por **Louis Claxton** (equipo Applied AI), publicada el **21 de agosto de 2026** en el blog de claude.com: una lectura estimada en **40 minutos**, de unos **64.000 caracteres**, presentada como una colección de *plays* extraídos del trabajo del equipo con sus clientes. (A) El diagnóstico: al dejar de ser el código el cuello de botella, este se desplaza hacia las etapas situadas a ambos lados de la construcción (planificación, revisión/pruebas, despliegue), los controles línea por línea dejan de sostenerse en cuanto el agente escribe la mayor parte del diff, y el coste de la gobernanza aumenta porque las excepciones siguen pasando por comités periódicos. (B) La respuesta: seis etapas (Plan, Design, Build, Test, Deploy, Maintain) organizadas como un **loop** en lugar de una cadena, cada una terminando en un **artefacto versionado** que la siguiente etapa lee — `intent.md`, `spec.md`, `plan.md`, el diff y sus pruebas, la PR y sus hallazgos, el registro del incidente. (1) El conocimiento institucional se convierte en archivos versionados: `CLAUDE.md`, skills, `REVIEW.md`, `bands.yaml`. (2) La gobernanza se divide en dos capas, con la skill situada como control consultivo y el hook como capa determinista detrás de ella. La separación de funciones se fija como invariante — el agente que escribe el código no puede aprobarlo — y la pieza se cierra con *"El loop sigue corriendo. El juicio humano permanece por encima de él."* El corpus ya cuenta con [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sobre la vertiente de seguridad del mismo ciclo, y con [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sobre el mismo desglose en seis etapas visto por un competidor.

## Titre Article

The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage

## Date

2026-08-21

## URL

https://claude.com/blog/the-ai-native-sdlc-playbook

## Keywords

SDLC nativo de IA, ciclo de vida de desarrollo de software, plays, intent.md, spec.md, plan.md, CLAUDE.md, REVIEW.md, bands.yaml, artefacto versionado, rastro de auditoría, plan mode, auto mode, hooks, skills, subagentes, sesiones paralelas, git worktrees, bucle de feedback, evals continuos, revisión agéntica de PR, separación de funciones, managed settings, sandbox, MCP, claude-code-action, Agent SDK, bandas de control, reglas de Western Electric, OpenTelemetry, DORA, Claude Tag, indicadores adelantados, indicadores retrasados, gobernanza como código

## Authors

Louis Claxton (Anthropic, équipe Applied AI), sur le blog claude.com ; contributions créditées à Jim Blackhurst, Will Steuk et Jamal Arif.

## Ton

Perfil: guía extensa de tipo corporativo con finalidad operativa, voz «nosotros» de un equipo Applied AI de un proveedor que describe el uso de sus propios productos, registro prescriptivo y procedimental, nivel técnico alto, dirigida a platform leads, tech leads y equipos de cumplimiento/seguridad de grandes organizaciones, incluidas las reguladas. La estructura es la de un **manual** más que la de un ensayo: cada *play* sigue la misma cuadrícula — qué cambia, requisitos previos, infraestructura, pasos de ejecución, consideraciones de gobernanza, un indicador adelantado y un indicador retrasado — y casi todos vienen acompañados de un artefacto mostrado tal cual (`intent.md`, `plan.md`, `CLAUDE.md`, `SKILL.md`, `settings.json`, `bands.yaml`, un workflow de GitHub Actions). El vocabulario está tomado del control interno — *control objectives*, *separation of duties*, *approval gates*, *audit trail*, *blast radius* — y sirve para traducir las prácticas de los agentes a las categorías de un auditor. La retórica avanza mediante una oposición binaria sistemática, cada play se abre con un par *Traditional* / *AI-native*. El texto asume su papel comercial sin disimularlo: los productos nombrados (Claude Code, Claude Design en beta, Claude Tag en beta pública, Code Review en *research preview*, Cowork) son propios, y la sección final enlaza a quince páginas de documentación. Con todo, sigue matizando sus propios límites — se dice que la skill no obliga a nada, y los managed settings se ofrecen como punto de partida para ajustar, no como una recomendación para copiar literalmente.

## Pense-betes

- **Tres consecuencias cuando la construcción deja de ser la restricción**: (1) el cuello de botella se desplaza hacia las etapas que aún funcionan a velocidad humana (planificación, revisión/pruebas, despliegue); (2) los controles se vuelven inaplicables — leer cada línea tenía sentido cuando la había escrito un humano; (3) el coste de la gobernanza aumenta, porque las excepciones pasan por comités periódicos. Ejemplo aportado: un equipo de seguridad dimensionado para un caudal humano, frente al cual la cola de revisión crece o el código se despliega con revisión insuficiente.
- **El hilo conductor es el artefacto versionado**, no la herramienta: cada etapa termina escribiendo en el control de versiones, la siguiente empieza leyéndolo, y la cadena de commits **es** el rastro de auditoría. El `.md` domina en las etapas iniciales porque el product owner y el agente leen el mismo archivo; a partir de la etapa de construcción, el artefacto es el código y sus trazas.
- **Disparadores en cascada**: un `intent.md` aceptado desencadena la pasada de requisitos/diseño, un `spec.md` aprobado desencadena el plan mode, una PR fusionada desencadena el pipeline, una banda cruzada en producción escribe el siguiente `intent.md`. Los equipos empiezan indicando cada etapa a mano; el estado objetivo es el loop en el que cada artefacto aceptado arma la siguiente puerta.
- **Skill frente a hook — la distinción sostiene todo el edificio de control**: la skill hace probable el cumplimiento de la política sin obligar a una sesión a cumplirla; el hook es determinista y bloquea la acción. Una política que debe cumplirse siempre necesita un hook o una pasada de revisión detrás de la skill. Corolario: un hook que *solicita* aprobación humana pertenece al despliegue, no a la construcción, donde volvería a poner a una persona en la ruta crítica de cada sesión paralela.
- **Sistemas legados**: para cada artefacto, se designa **un único** sistema como fuente de verdad (el repositorio, o Jira/ServiceNow con los archivos `.md` como copias de trabajo), y todo lo demás conserva solo un enlace. Un **encadenamiento** simple — el artefacto lleva el ID del registro, el registro lleva el SHA del commit — se propone como listón mínimo de partida.
- **Test**: el bucle de feedback (tests, build, diff de capturas) se ejecuta a lo largo de toda la tarea; el subagente verificador es una pasada final con contexto nuevo, de modo que el veredicto no queda coloreado por los supuestos que produjeron el código. Para una corrección, se escribe primero el test que falla, se confirma, y luego se impide mediante un hook que el agente lo edite. Los evals son el equivalente nativo de IA a las puertas de QA: **de 20 a 50 tareas reales** se repiten en cada cambio de `CLAUDE.md`, de una skill o de un hook, y cada incidente se convierte en un eval permanente.
- **Maintain, cerrando el loop**: **la detección sigue siendo determinista** (media y desviación estándar en ventana móvil, reglas de Western Electric, un script versionado y probado, sin ningún modelo implicado); Claude solo se invoca una vez cruzada una banda, y el tier fija lo que puede hacer — 1σ registra, 2σ diagnostica en solo lectura, 3σ propone (una PR o un runbook preaprobado). El rollback se señala como la vía que debe ser la **más ensayada** del pipeline.
- ⚠️ **Lo que la pieza no cuantifica**: ningún resultado cuantificado, ni ahorro de tiempo ni tasa de adopción. Las cifras de la guía son **parámetros de implementación** (20-50 evals, dos o tres sesiones paralelas para empezar); los resultados siguen siendo métricas que cada uno debe medir, con su fuente indicada en cada caso (git log, metadatos de la PR, exportación de OpenTelemetry, DORA, herramienta de seguimiento de incidentes).
- **Para conectar**: [[sfeir-sdlc-ia-cycle-11-phases-2026-06-16]] (un desglose competidor, en once fases) y [[sfeir-code-review-anneau-contraintes-2026-07-30]] (el anillo de restricciones alrededor del agente, donde los hooks y la revisión son aquí dos anillos distintos).

## RésuméDe400mots

Louis Claxton, del equipo Applied AI de Anthropic, publicó el 21 de agosto de 2026 una guía de implementación para un ciclo de vida de desarrollo de software "nativo de IA". El punto de partida es un desequilibrio: las organizaciones escriben ahora código a una velocidad inimaginable un año antes, pero los procesos que lo rodean — puertas de aprobación, revisiones, traspasos, políticas — no se han movido. El SDLC tradicional fue diseñado para un mundo en el que escribir código era la etapa más larga y más costosa; sus controles también asumen que cada acción la realiza un humano.

De ahí se derivan tres consecuencias. El cuello de botella se desplaza hacia las etapas que aún funcionan a velocidad humana, a ambos lados de la construcción. Los controles dejan de ser aplicables: leer cada línea tenía sentido cuando una persona la había escrito. Y el coste de la gobernanza aumenta, porque las excepciones pasan por comités periódicos.

La respuesta conserva los objetivos de control y cambia la forma de ejecutarlos. El proceso se convierte en un loop, con la IA integrada en cada punto, organizado en seis etapas — Plan, Design, Build, Test, Deploy, Maintain — desglosadas en *plays* que siguen todas la misma cuadrícula, hasta las métricas. El hilo conductor es el artefacto versionado. La intención la captura su autor original como `intent.md`; los requisitos y el diseño se fusionan en una única sesión que produce `spec.md`, condicionada por las skills de marca, seguridad, cumplimiento y UX; la construcción empieza en plan mode y bloquea `plan.md` antes de escribir ningún código. La cadena de commits sirve de rastro de auditoría.

El conocimiento institucional se convierte en archivos versionados: `CLAUDE.md` para el contexto del repositorio, skills para las políticas transversales, `REVIEW.md` para la doctrina de revisión, `bands.yaml` para los umbrales de producción. La gobernanza se divide en dos capas, con la skill como control consultivo y el hook como capa determinista que bloquea o solicita aprobación. Un ejemplo de *managed settings* detalla, clave por clave, qué aporta cada ajuste en términos de control, desde negarse a leer secretos hasta imponer un umbral mínimo de versión.

La etapa Maintain cierra el loop: un script determinista vigila una métrica, y al cruzar una banda se invoca a Claude sin ningún humano en la cadena de llamadas, con un nivel de autonomía fijado por el tier. Lo que encuentra el agente se reescribe como `intent.md` y se reintroduce en el ciclo. Claude Tag, en beta pública en Slack, extiende el patrón a los incidentes que llegan por chat. No se presentan resultados cuantificados: la guía aporta métricas que medir y nombra su fuente.

## GrapheDeConnaissance

- Anthropic —publie→ The AI-Native SDLC playbook (DOCUMENT, 0.97)
- Louis Claxton —a_créé→ The AI-Native SDLC playbook (DOCUMENT, 0.95)
- The AI-Native SDLC playbook —affirme_que→ le goulot se déplace du build vers les étapes restées à vitesse humaine (AFFIRMATION, 0.94)
- SDLC AI-native —est_variante_de→ SDLC (METHODOLOGIE, 0.92)
- SDLC AI-native —utilise→ artefact committé (CONCEPT, 0.93)
- artefact committé —permet→ piste d'audit (CONCEPT, 0.9)
- intent.md —fait_partie_de→ SDLC AI-native (METHODOLOGIE, 0.92)
- spec.md —est_basé_sur→ intent.md (DOCUMENT, 0.91)
- plan.md —est_basé_sur→ spec.md (DOCUMENT, 0.9)
- Plan mode —permet→ plan accepté avant toute écriture de code (CONCEPT, 0.93)
- CLAUDE.md —s_applique_à→ contexte du dépôt lu à chaque session (CONCEPT, 0.92)
- Claude Skills —s_applique_à→ politique appliquée pendant l'écriture du code (CONCEPT, 0.9)
- hooks —améliore→ Claude Skills (TECHNOLOGIE, 0.88)
- Louis Claxton —affirme_que→ une skill est un contrôle consultatif, rien n'oblige une session à la suivre (AFFIRMATION, 0.92)
- REVIEW.md —s_applique_à→ passes de revue bugs, sécurité et conformité au spec et au plan (CONCEPT, 0.89)
- séparation des tâches —s_applique_à→ l'agent qui écrit le code ne peut pas l'approuver (AFFIRMATION, 0.93)
- evals continues —s_applique_à→ configuration d'agent versionnée, testée comme du code (CONCEPT, 0.9)
- Louis Claxton —recommande→ collecter 20 à 50 tâches réelles pour constituer la suite d'evals (AFFIRMATION, 0.88)
- Louis Claxton —recommande→ démarrer à deux ou trois sessions parallèles par ingénieur (AFFIRMATION, 0.87)
- git worktrees —permet→ sessions Claude Code parallèles isolées (CONCEPT, 0.9)
- bands.yaml —permet→ paliers d'autonomie 1σ, 2σ, 3σ (CONCEPT, 0.9)
- détection de bande de contrôle —affirme_que→ la détection reste entièrement déterministe, sans modèle impliqué (AFFIRMATION, 0.92)
- MCP —permet→ déploiement et rollback exposés comme outils cadrés par environnement (CONCEPT, 0.89)
- managed settings —réduit→ surface d'action de l'agent en environnement régulé (CONCEPT, 0.89)
- Claude Tag —s_applique_à→ réponse à incident depuis un canal Slack (CONCEPT, 0.88)
- DORA —mesure→ performance de livraison, indicateur retardé du play CI/CD (MESURE, 0.85)

---
Canonical: https://www.thekb.eu/es/fiches/claxton-anthropic-ai-native-sdlc-playbook-2026-08-21/