El playbook SDLC nativo de IA, medido: tiempos por etapa, costo de compuerta, veredictos

Resumen

• Cada una de las seis etapas del playbook termina en un artefacto commiteado (intent.md, spec.md, plan.md, PR, registro de incidente). El post de lanzamiento y el curso de 14 lecciones describen la forma, ninguno publica una medición.
• Ejecutada de punta a punta en un repo real de Express + Prisma, la cadena completa corrigió un bug en 11 min 31 s por $3.46, mientras que un prompt directo lo hizo en 2 min 13 s por $0.70: ×5.2 en tiempo, ×4.9 en costo, ambos en verde.
• El impuesto real es la lectura: 5,488 palabras de artefactos para un arreglo de clase de una línea, unos 27 min a 200 ppm. La cadena convierte tiempo de escritura en tiempo de lectura.
• Tres de seis etapas valieron la pena en este contexto: Plan (intent.md), Build (plan mode + CLAUDE.md + TDD), Deploy (REVIEW.md + un hook). Design y las evals continuas no para un dev en solitario; Maintain no se ejecutó.
• La etapa de spec señaló su propio prerrequisito: no existían skills de organización, así que nunca se verificó contra políticas de marca, seguridad o UX. El playbook da por hecho que esos skills ya están escritos.
• La compuerta determinista funciona: un hook PreToolUse bloqueó un deploy en 14 s con exit 2. El modelo ya se había negado una vez por su propio criterio antes de que el hook se activara.

Qué dicen las mediciones

El playbook plantea el cambio como "el código ya no es el cuello de botella" y pide que cada etapa termine en un artefacto commiteado, desde intent.md pasando por spec.md y plan.md hasta la PR y el registro de incidente, con bandas de control en Maintain s1. El curso trae los datos citables: de 20 a 50 tareas reales como suite de evals, un tope de 5 nits en REVIEW.md, 2 a 3 sesiones paralelas como máximo, y la regla de que un error cometido dos veces va a CLAUDE.md s2. La lectura neutral más aguda tabula quién redacta y quién acepta cada artefacto y llama al documento "vendor-claim throughout" con "no measurement anywhere" s4.

La tarea de corrección fue un bug real del upstream: un clon nuevo ejecutaba npx nx test api y 1 suite fallaba de fábrica (auth.service.test.ts, "TypeError: Cannot read properties of undefined (reading 'prototype')"), 4 pasaban, 14 tests en verde, 2.2 s. El camino directo llegó a tests totalmente en verde en 2 min 13 s, $0.70, 40 turnos. El camino con cadena, intent luego spec luego plan luego build, también llegó al verde en 11 min 31 s, $3.46, 169 turnos. Eso es ×5.2 en tiempo y ×4.9 en costo solo del lado de la máquina s2.

Donde la cadena duele es del lado humano. Produjo 5,488 palabras de artefactos para leer (intent 558 + spec 2,167 + plan 2,763), unos 27 min a 200 ppm, para un arreglo cuya carga de revisión directa es un diff pequeño s4. La tarea de feature (silenciar autores) a través de toda la cadena tomó 15 min 13 s, $4.11, 158 turnos y entregó un modelo Prisma Mute con migración, endpoints de mute y unmute, filtrado del feed, 1,422 inserciones en 15 archivos, 50 tests en verde con 3 archivos de test nuevos o ampliados y un spec e2e. Sus artefactos pesaron 6,852 palabras (intent 450 + spec 2,337 + plan 4,065), unos 34 min de lectura s2.

La lectura escéptica de la etapa Design se sostuvo. La crítica de LinkedIn dice que el playbook esconde sus prerrequisitos: los skills de organización para marca, seguridad y UX ya deben existir, y alguien debe saber conducir el brainstorm s7. El agente lo confirmó sin que se lo pidieran. La preocupación C0 marcada en spec.md dice, textualmente: "No org skills available. … This spec has therefore not been checked against brand, security or UX policy." Una spec de más de 2,000 palabras que repite el código y no puede verificar políticas es la etapa que conviene saltarse al trabajar solo s7.

La crítica sobre la infraestructura también se sostuvo. El argumento es que cuando los tests golpean fakes obsoletos, "the agent sees the tests pass and reports the work finished", porque la cadena de artefactos registra lo que se decidió, no lo que realmente corre s8. En la prueba, el bucle solo verificó tests unitarios y el build; la propia revisión listó nx e2e como "Not run: needs a running server and a seeded DB" y prisma migrate status como "Not run: needs a DB". El bucle en verde nunca tocó un sistema vivo s8.

La etapa Deploy fue la ganancia barata. REVIEW.md corrió en 117 s por $0.80: nx test (5/5 suites, 50 pasados), nx build (ok), un delta de lint contra la base del plan (34 vs 33, el +1 permitido explícitamente por el ítem A3 del plan) y una verificación de prettier (9 archivos fallando, registrado como nit N1). Veredicto: 0 Important, 6 nits, 5 listados y 1 resumido porque aplicó el tope. La revisión se negó a aprobar su propio trabajo con "this agent does not approve", la separación de funciones tal como la escribe el curso s2. La compuerta por hook se comportó como describen los docs: al pedirle desplegar antes del merge, el agente se negó por su propio criterio sin ejecutar el script, así que el hook nunca se activó. Tras el merge, el intento de deploy fue bloqueado por el hook PreToolUse (exit 2) en 14 s con el mensaje de la compuerta s19.

Las evals fueron baratas de escribir y fáciles de hacer mal. Cinco casos salieron del historial de git en 283 s por $1.44. Las dos ejecuciones corrieron contra la base equivocada, porque el runner creó la rama después de que el arreglo se mergeara, y ambos agentes lo detectaron ("the bug was already fixed here") en vez de fingir un pase. Una ejecución de eval cuesta unos 60 a 70 s, así que el dimensionamiento del propio playbook, de 20 a 50 casos, equivale a unos 20 a 55 min de tiempo de agente por ejecución de CI s2. La configuración de CLAUDE.md tomó 63 s y $0.44 por una página commiteada, la jugada más barata de todas; un triage de log de CI de solo lectura nombró la causa correcta en 11 s por $0.13 s2.

El hilo de la comunidad aporta telemetría más amplia: en 10,000 desarrolladores, los equipos con mucha IA mergean 98% más PRs mientras el tiempo de revisión sube 91% y el tamaño de las PR 154% s6.

Mediciones

Protocolo: la cadena corrió en headless (claude -p, modelo claude-opus-5-5, permisos acotados a acceptEdits más una allowlist, --setting-sources project,local) sobre un clon desechable de gothinkster/node-express-realworld-example-app (Express + TypeScript + Prisma + Postgres 16 en Docker, workspace Nx). Cada etapa se cronometró y se registró en exp/metrics.jsonl (17 filas). Total: $11.90 + $0.14 por la repetición del hook, 539 + 3 turnos, unos 41 min de tiempo de agente.

Salvedades: un repo, un desarrollador, un día. No se ejecutaron las jugadas a escala de equipo, el modo headless comprime los pasos de entrevista en prompts únicos, y las ejecuciones de evals cuentan solo el costo por ejecución.

Haz esto el lunes

• Escribe una página de CLAUDE.md para tu repo principal: comandos de build, test y lint, y los dos errores que el agente cometió la semana pasada. Commitéala. Presupuesta 63 s de tiempo de agente.
• Antes de tu próxima tarea no trivial, pide primero un intent.md: objetivo, no objetivos, decisiones abiertas. Responde las preguntas abiertas y luego deja que el agente planifique. Salta spec.md salvo que tengas skills de políticas de organización contra los que verificarlo.
• Ejecuta la etapa build en plan mode con un bucle TDD y exige que el plan registre las desviaciones (D1, D2, ...) para que la revisión tenga en qué apoyarse.
• Añade una pasada REVIEW.md ejecutada por una sesión nueva con un tope de nits y una línea explícita "this agent does not approve". Haz que ejecute tests, build, un delta de lint y una verificación del formateador.
• Pon una compuerta determinista: un hook PreToolUse que salga con exit 2 en deploy cuando la rama no sea main.
• Antes de confiar en un bucle en verde, lista al final de la revisión lo que no ejecutó (e2e, migraciones, cualquier cosa que necesite una base de datos viva).
• Mide tu propio impuesto de compuerta: cronometra el camino directo y el camino con cadena en el mismo bug pequeño, y cuenta las palabras que tuviste que leer.

Para ir más lejos

• La variante de dos compuertas: una compuerta de revisión adversarial (sdlc-gate) y solo dos puntos de decisión humana en vez de uno por etapa, la forma pragmática para un equipo pequeño s12.
• La cadena completa instalable: plantillas de intent, spec, plan y REVIEW, un validador de compuertas, un runner de evals y detección de bandas de control, si prefieres no armar el andamiaje a mano s5.
• Planificación con entrevista primero: una pregunta a la vez supera al lote, y "AI agents don't ask clarifying questions. They assume." Un relato de configuración sin mediciones de tiempo s11.
• Por qué un pipeline fijo único acaba esquivándose: "a docs fix and a payments migration shouldn't travel the same path", y el proceso real se vuelve invisible. Agrupa el playbook con Kiro y GitHub Spec Kit s9.
• Los huecos que te va a vender un proveedor de plataforma: entrada de señal a intent, enrutamiento por radio de impacto, un panel de métricas. s13.
• Una consultora que aplicó la misma forma (CRAFT) en equipos de clientes desde enero y admite "we don't yet have a formal answer for what a control band looks like" s10.
• Un ejemplo trabajado de intent.md (una casilla Select All) que muestra el trabajo del archivo: sacar a la luz decisiones abiertas en lugar de dejar que el agente elija en silencio s14.

Fuentes

• The AI-Native SDLC Playbook (launch post), claude.com. Por qué leerlo: la forma de seis etapas y la regla del artefacto commiteado en cinco minutos.
• The AI-native SDLC playbook (course, 14 lessons), Claude Academy. Por qué leerlo: el único lugar donde viven los números (20 a 50 tareas de eval, tope de 5 nits, 2 a 3 sesiones), gratis y sin login.
• The Committed-Artifact Chain, howardism.dev. Por qué leerlo: quién redacta y quién acepta cada artefacto, y la afirmación directa de que nada en el playbook está medido.
• bashebr/ai-native-sdlc, GitHub. Por qué leerlo: plantillas, validador de compuertas y runner de evals que puedes instalar en vez de escribir.
• Anthropic published an AI-native SDLC playbook, r/ClaudeAI. Por qué leerlo: el hilo que trae la telemetría de Faros (98% más PRs, +91% de tiempo de revisión) al debate.
• The AI-native SDLC Playbook is basically "do everything you did before, but inside Claude", LinkedIn. Por qué leerlo: el argumento de los prerrequisitos ocultos que la etapa spec confirmó por su cuenta.
• The AI-Native SDLC Starts With Your Infrastructure, MetalBear blog. Por qué leerlo: el problema de los fakes obsoletos, con voz de proveedor pero el argumento se sostiene solo.
• The AI-native SDLC won't be one process, worldprogramming.org. Por qué leerlo: el argumento de la ceremonia contra un único camino para cada cambio.
• Anthropic Wrote the AI-Native SDLC Playbook in August. We Wrote Ours in January., Substack. Por qué leerlo: un equipo independiente que converge en la misma forma y admite el hueco de Maintain.
• AI-Native SDLC: First Try, kyle.pericak.com. Por qué leerlo: la única primera ejecución práctica con entrevista primero, escrita antes de que existiera el playbook.
• TsCarpe/claude-sdlc-skills, GitHub. Por qué leerlo: la variante de dos compuertas con un paso de revisión adversarial.
• Implementing the Anthropic AI-Native SDLC Playbook, Port blog. Por qué leerlo: la lista de lo que el playbook deja fuera, para leerla como un mapa de huecos.
• What Is intent.md in Claude Code?, dev.to. Por qué leerlo: un intent.md concreto cuya estructura puedes copiar.
• Hooks guide, Claude Code docs. Por qué leerlo: cómo un hook PreToolUse con exit 2 se convierte en la compuerta determinista en la que se apoya el playbook.

FAQ

¿Vale la pena alguna vez la cadena completa para un arreglo de una línea?

No en esta prueba: ×5.2 en tiempo y ×4.9 en costo para el mismo resultado en verde, más 5,488 palabras que leer. Usa solo intent.md para tareas pequeñas.

¿Por qué saltarse spec.md al trabajar en solitario?

La spec se señaló a sí misma: sin skills de organización para marca, seguridad o UX no pudo verificar políticas, y gastó más de 2,000 palabras repitiendo el código.

¿El hook reemplaza el criterio del modelo?

No, lo respalda. El agente rechazó por su cuenta el deploy previo al merge; el hook bloqueó el intento posterior al merge en 14 s con exit 2.