AIDiveEl playbook que nadie midió
Anthropic publicó un playbook de SDLC nativo de IA para Claude Code: seis etapas, cada una terminada en un archivo commiteado, enseñado como curso gratuito. Su tesis central es que el código ya no es el cuello de botella, y que la cadena de artefactos commiteados gestiona lo que sí lo es. El documento no incluye ninguna medición: ni tiempos, ni costes, ni benchmarks. Hicimos la primera prueba cronometrada sobre un repositorio real: dieciséis sesiones cronometradas de Claude Code, cada gate con su precio y un veredicto que parte la cadena por la mitad. De paso, un arreglo de dos minutos pasado por toda la cadena puso precio a la ceremonia, y nuestro propio deploy fue bloqueado dos veces, una de ellas por cuatro líneas de shell.
El playbook y el banco de pruebas
El banco de pruebas: dieciséis sesiones cronometradas de Claude Code, unos 12 $ de cómputo, un repositorio real. El playbook recorre seis etapas: plan, diseño, build, test, deploy y maintain. Cada etapa termina en un archivo commiteado, y la etapa siguiente lo lee: intent, spec, plan, la pull request, el registro de incidentes. Los commits son el rastro de auditoría. Anthropic lo enseña como un curso gratuito de 14 lecciones, de una hora aproximadamente, pensado para empresas con gates de revisión; nosotros probamos qué sobrevive al contacto con un solo desarrollador.
El repositorio es la app demo RealWorld (Express, TypeScript, Prisma, Postgres): un proyecto real con tests reales, y una suite rota en un clon limpio (cuatro suites que pasan, 14 tests en verde, dos segundos de ejecución). Ese bug será más adelante el grupo de control. La regla de puntuación: un gate se paga cuando su salida cambia lo que se entrega, por menos de lo que cuesta.
La entrada es un archivo de memoria en la raíz del repo: comandos, convenciones, arquitectura, los errores que el modelo repite, todo en menos de una página. El nuestro se escribió y commiteó en 63 segundos por 0,44 $. Una salvedad honesta sobre el método: las ejecuciones headless comprimen las entrevistas del playbook en prompts únicos.
Plan: intent.md en veintinueve segundos
El primer gate captura la idea antes de que nadie diseñe nada. La petición de función: los lectores quieren silenciar a los autores que inundan su feed. El playbook llama al resultado una proto-spec, escrita con el modelo y de tu propiedad, y admite tres orígenes: una idea, un ticket abierto o una alerta de incidente. La plantilla tiene cinco secciones cuyos encabezados hacen el trabajo de pensar: problema, resultado propuesto, usuarios y sistemas afectados, restricciones, preguntas abiertas. El ciclo de trabajo tiene cinco movimientos: describir, hacer brainstorming, generar desde la plantilla, corregir, commitear.
| intent.md | tiempo | coste |
|---|---|---|
| Función de silenciar autores | 29 s | 0,18 $ |
| Suite de tests rota | 39 s | — |
El valor está al final, en las preguntas abiertas: ¿qué pasa con los favoritos de un autor silenciado? ¿Sus páginas siguen siendo accesibles? Son decisiones que un agente de código tomaría en silencio, ahora escritas y fechadas. El archivo se commitea, así que la autoría y la marca de tiempo sobreviven al chat, y el product owner corrige el borrador antes de aceptarlo. El objetivo de Anthropic para esta etapa es una elicitación en horas, no en semanas; en solitario, lleva menos de un minuto.
Design: la spec señala su propio requisito
El gate dos convierte el intent en una spec con un prompt del curso: leer el intent, producir una spec de requisitos y diseño, aplicar las skills disponibles, es decir, las skills que se supone que llevan tu política de marca, seguridad y UX. Dos minutos después teníamos unas 2.300 palabras de spec competente: endpoints, modelo de datos, comportamiento del feed, casos límite. Incluso registró lo que no podía cumplir, exactamente como pide el prompt.
El giro está en sus preocupaciones marcadas, escritas por el propio modelo: "C0. No org skills available. This spec has not been checked against any policy." Toda la premisa de la etapa suponía archivos que no existen en la mayoría de configuraciones; los vídeos explicativos se saltan ese requisito previo, y el agente lo dejó por escrito. La segunda marca fue más suave: los valores por defecto de las preguntas abiertas necesitan la aprobación del producto antes del build.
La lección es estricta con el emparejamiento (spec e intent se commitean juntas, y un humano aprueba el paso a build), y hay una factura de lectura: unos 12 minutos de tiempo del product owner por spec. El playbook incluso rastrea el retrabajo: los commits de spec fechados después de que empiece el build cuentan en tu contra. En un equipo que ha codificado sus políticas, este gate es donde se ejecutan. En solitario, pagas por una promesa que tu configuración todavía no puede cumplir.
Build: plan mode, TDD y lo que el bucle realmente comprueba
El gate tres es Plan Mode, y el listón es brutal y útil: un ingeniero que nunca vio la conversación debería poder implementar solo a partir del plan. Plan Mode hace cumplir por sí mismo la mitad de la lectura: el modelo no puede editar archivos hasta que se acepta el plan. El nuestro salió con unas 4.000 palabras en cuatro minutos, nombrando los archivos que cambian, el orden de trabajo, los riesgos y la prueba, y registrando tres desviaciones etiquetadas respecto a la spec que reaparecen más tarde en la revisión.
El build funciona con un bucle: escribir el test que falla, hacerlo pasar, un solo objetivo, todo en verde o la tarea no está terminada. El bucle está protegido (un agente que arregla código no debe debilitar la comprobación de ese código) y emparejado con un verificador: una segunda comprobación en un contexto limpio, sin influencia de la sesión que escribió el código.
| Resultado del build | valor |
|---|---|
| Tiempo de agente | ~9 min, 91 turnos |
| Coste | ~2 $ |
| Cambio | 15 archivos, tabla Mutes, dos endpoints, ambos feeds filtrados |
| Tests | 5 suites, 50 tests, todos en verde en una repetición independiente |
| Merge a la primera | sí |
El asterisco: el verde prueba lo que el bucle contiene, nada más. Nunca se ejecutó el end-to-end: necesita un servidor activo y una base de datos con datos de prueba, y un bucle apuntado a mocks obsoletos brillaría igual de verde. A escala de equipo se suman sesiones paralelas en worktrees (dos o tres es el techo indicado); no lo probamos.
Deploy: la revisión y el gate que dijo no
El gate de deploy tiene dos capas, y ambas nos dijeron que no. La capa uno lee el diff bajo una política escrita en la raíz del repo: tres pasadas (bugs, seguridad, cumplimiento frente a la spec y el plan), "Important" reservado para comportamiento roto, datos filtrados o una política vulnerada, cinco nits como máximo y el resto resumido en un recuento: la política limita su propio ruido. Dos minutos de revisión, 0,80 $, y ejecutó las comprobaciones reales: tests, build, lint contra la línea base registrada en el plan, formato en nueve archivos. Veredicto: cero hallazgos Important, seis nits, uno por encima del límite resumido. Cerró con una línea que no habíamos pedido: este agente no aprueba; la aprobación queda en manos de un code owner humano tras la protección de rama.
La capa dos es el gate en sí. Pedimos el deploy; el modelo se negó por su cuenta, porque la función no estaba en la rama de producción. Eso es juicio, no cumplimiento forzado. Así que hicimos el merge y pedimos otra vez: cuatro líneas de shell respondieron en 14 segundos: bloqueado, se requiere autorización de release. El código de salida 2 detiene la llamada a la herramienta y el motivo vuelve al modelo. El lado del pipeline recibió el mismo trato: un build roto triado en modo headless en 11 segundos por 0,13 $; leyó el log, nombró la causa exacta y propuso el diff sin tocar ningún archivo. Lo determinista gana a lo educado; un hook vale lo que vale su patrón, y el nuestro coincidía con un solo script.
El impuesto del gate
Mismo bug, mismo punto de partida roto, dos caminos: el experimento de control. Camino uno: simplemente arreglarlo. Camino dos: la cadena completa, de intent a build.
| arreglo directo | cadena completa | multiplicador | |
|---|---|---|---|
| Tiempo total | 2:13 | 11:31 | ×5,2 |
| Coste | 0,70 $ | 3,46 $ | ×4,9 |
| Turnos | 40 | 169 | — |
| Resultado | suite en verde | suite en verde | idéntico |
La factura de la máquina es la mitad pequeña. La cadena escribió unas 5.500 palabras de artefactos para un arreglo de una línea: unos 27 minutos de lectura humana para un diff que se podría escanear de un vistazo. La cadena convierte tiempo de escritura en tiempo de lectura; ese es el impuesto del gate.
El playbook añade un cargo recurrente: las evals continuas. De veinte a cincuenta tareas reales, repetidas con cada cambio de configuración: cada caso es una tarea pasada real, con el prompt tal como era, ejecutada desde el commit anterior al cambio, con aceptación comprobable. Escribir cinco casos desde el historial llevó cinco minutos; ejecutarlos bien no es tan fácil: nuestro primer arnés apuntó dos casos al commit equivocado, y ambos agentes lo detectaron en lugar de fingir un aprobado. A aproximadamente un minuto por caso, una suite completa cuesta hasta una hora de tiempo de agente por ejecución, y se supone que cada incidente de producción se incorpora a la suite como eval de regresión permanente. En un equipo regulado, esa lectura es el entregable; en solitario, es sobrecarga.
Veredicto: tres de seis se pagan
Tres de los seis gates se pagan solos:
| Etapa | veredicto | evidencia |
|---|---|---|
| Plan | conservar | 40 s compran las preguntas que nadie hizo |
| Build | conservar | plan mode + el bucle de tests entregó 50 tests en verde |
| Deploy | conservar | revisión de 0,80 $ con comprobaciones reales, bloqueo determinista en 14 s |
| Design | saltar en solitario | te factura políticas que no has codificado |
| Test (evals continuas) | puede esperar | hasta una hora por ejecución, fácil de apuntar mal |
| Maintain | sin probar | requiere semanas de telemetría de producción |
Maintain es elegante sobre el papel (scripts deterministas vigilan bandas de control, y una brecha escribe un nuevo archivo intent), pero demostrarlo requiere telemetría de producción que no tenemos. El propio documento de Anthropic, como dijo un analista, no contiene ninguna medición; estos son los primeros números, con los límites evidentes: un repo, un desarrollador, un día.
Los datos externos dicen que la presión es real. Faros siguió a más de 10.000 desarrolladores en más de 1.200 equipos: los equipos de alta adopción fusionan un 98 % más de pull requests, el tiempo de revisión sube un 91 % y la pull request media más que duplica su tamaño. El último informe DORA rima: el rendimiento sube con la IA, la estabilidad baja. La revisión se está convirtiendo en el cuello de botella, y el playbook apunta exactamente ahí. Las variantes de la comunidad ya reducen la cadena a dos decisiones humanas: una ofrece plantillas y un registro de gates, la otra mantiene a los humanos solo en diseño y test. Adopta los tres gates que se pagan y crece hacia el resto cuando lo haga tu equipo. La propia frase final de Anthropic es el epitafio adecuado: el bucle sigue corriendo, el juicio humano permanece por encima.
