Logo de Area 73

El SDLC nativo en IA, resumido

ai-codingsdlcclaude-codeartificial-intelligencebest-practices

Anthropic ha publicado The AI-Native SDLC playbook, una guía larga (y muy enterprise) sobre cómo rehacer el ciclo de vida del software ahora que los agentes escriben la mayor parte del código. Aquí la tienes destilada: los conceptos y las acciones, etapa por etapa.

El código ya no es el cuello de botella

Los agentes escriben código en horas. Los procesos que lo rodean siguen a ritmo humano.

Con IA el build pasa de semanas a horas, pero plan, diseño, test y deploy mantienen su duración a ritmo humanotiempo →TradicionalIA nativaPlanDiseñoBuildTestDeployPlanDiseñoTestDeploybuild: horasel resto, a ritmo humano

Cuando el build se colapsa pasan tres cosas:

  • El cuello de botella se mueve a izquierda y derecha del build: planificar, revisar/probar y desplegar.
  • Los controles dejan de encajar. Revisar cada línea a mano tenía sentido cuando la escribía una persona, no cuando la escribe un agente.
  • La gobernanza se encarece: las excepciones siguen pasando por comités que se reúnen cada semana o cada mes.

De línea a bucle

La idea que vertebra todo el playbook: cada etapa termina commiteando un artefacto que la siguiente lee, y ese commit es lo que la dispara.

Las seis etapas forman un bucle: cada una commitea un artefacto (intent.md, spec.md, plan.md, tests, PR) y mantenimiento devuelve lo que detecta como un nuevo intent.md1 · Plan2 · Diseño3 · Build4 · Test5 · Deploy6 · Mantenerintent.mdspec.mdplan.md + difftests · evalsPR + revisiónalerta → intent.mdcada etapa acaba en un commitque dispara la siguientelos humanos, en las puertas
  • La cadena de commits es la auditoría: quién pidió qué, qué produjo el agente y quién lo aprobó.
  • Al principio lanzas cada paso a mano. El destino es que cada artefacto aceptado dispare la siguiente puerta.
  • Las personas siguen siendo responsables de cada decisión de criterio, pero su atención se concentra en las puertas: revisan lo que el agente ha señalado en vez de arrancar cada etapa desde cero.

1. Plan: intent.md

Concepto: la idea se captura una sola vez, con las palabras de quien la tiene, como fichero versionado. Sin pasar por backlog, story points y refinamientos que la alejan de lo que se quería decir.

Acciones:

  • Quien tiene la idea hace brainstorming con Claude hasta que sea concreta: alcance, usuarios, restricciones y qué es el éxito.
  • Claude la escribe como intent.md con la plantilla de la organización (problema, resultado, afectados, restricciones, preguntas abiertas). La plantilla, mejor como skill.
  • Vive en una carpeta intent/ del repo, junto al código que saldrá de ella. El PO la revisa y la acepta con un merge.

2. Diseño: spec.md

Concepto: requisitos y diseño se funden en una sola sesión. La política (marca, seguridad, compliance, UX) se aplica mientras se escribe la spec, no en una revisión semanas después.

Acciones:

  • El PO abre sesión con las skills de la organización y el intent.md, y pide la spec con las dudas señaladas.
  • Resuelve primero lo señalado, con el dueño de cada política, antes de que llegue a ingeniería.
  • Commitea spec.md junto a intent.md: lo que se pidió y lo que se decidió.
  • Después, automatízalo: slash command primero; luego, un job que corre al hacer merge del intent.md y abre la spec como PR.
Cadena de artefactos: la idea se convierte en intent.md, luego en spec.md con las skills de la organización y en plan.md en plan mode; cada paso tiene una puerta humanaideaticket · alertacódigobrainstorm+ skills de la org.plan modeintent.mdspec.mdplan.mdpuerta humana →revisael POPO + dueñosde cada políticaapruebael ingenierorevisiónen la PR

Hasta aquí, nadie ha escrito una línea de código.

3. Build: plan, contexto y barandillas

Concepto: nada se implementa sin un plan aceptado, el conocimiento de la casa pasa a ser ficheros que el agente lee y las barandillas corren como código, no como costumbre.

Acciones:

  • Plan mode por defecto. Dale la spec.md, deja que te entreviste y pregúntale qué puede romper y qué alternativas ha descartado. Itera hasta que alguien ajeno a la conversación pudiera implementarlo sólo con el plan. Commitéalo como plan.md. Con un buen plan, la implementación suele salir en una pasada.
  • CLAUDE.md de menos de una página. Lanza /init y recórtalo a lo que un recién llegado necesita el primer día. Regla: si Claude comete el mismo error dos veces, va al CLAUDE.md.
  • Una skill por cada conocimiento que hoy se aplica de forma irregular (un estándar de seguridad, una convención de API, una regla de marca), con un dueño que firme sus cambios.
  • Hooks para lo que no admite excepciones: rutas protegidas, formatter y linter tras cada edición, credenciales fuera del diff. Rápidos y acotados al fichero que cambia.
Tres capas de control de menos a más deterministas: CLAUDE.md da contexto, una skill aconseja y un hook garantizamás deterministaCLAUDE.mdskillhookconvenciones · comandos · errores típicospolítica versionada, con dueñoscript antes de cada acción: allow · ask · blockcontextoconsejogarantía

La skill hace que las violaciones sean raras; el hook, que sean casi imposibles.

  • Sesiones en paralelo: dos o tres, cada una en su worktree (claude --worktree feature-auth). El límite no lo pone la máquina, sino cuánto eres capaz de revisar bien. Los trabajos repetidos se convierten en subagentes en .claude/agents/.
Un ingeniero dirige varias sesiones en paralelo, cada una en su propio worktree y con subagentes para tareas repetidas como verificar, simplificar o investigarsesiones en paralelo · un worktree cada unasubagentesingenierodirige y revisaclaude –worktree feature-authclaude –worktree fix-rate-limitclaude –worktree docs-apiverifiersimplifierresearcher
  • Auto mode: con todo lo anterior maduro, deja de ser la excepción para el trabajo rutinario (spec ajustada, radio de impacto pequeño, código ya cubierto por tests). Ya no miras cada edición: revisas artefactos al final de sesiones largas.

4. Test: que el agente se corrija solo

Concepto: cada sesión verifica su propio trabajo antes de que lo vea una persona. Y la configuración que guía al agente se prueba igual que el código que escribe.

Bucle de feedback: Claude implementa, verifica con tests, build o captura y, si no pasa, corrige y repite; sólo llega a la persona lo que ya ha pasadoimplementaverificatests · build · captura¿pasa?llega al humanoya verificadosíno → corrige y repite

Acciones:

  • Un solo comando por verificación (make test, npm test) que salga con código distinto de cero si falla, y listado en el CLAUDE.md con un ejemplo de salida sana.
  • Objetivos medibles para que no tenga que preguntarte: «pasan todos los tests de test_status.py», «la captura coincide con el mock».
  • En los bugs, primero el test que falla: que Claude lo reproduzca, comprueba que falla por el motivo correcto y commitéalo. Luego pide el arreglo sin tocar el test, con un hook que bloquee editar tests.
  • En la UI, dale navegador o capturas y el mock. Dos o tres vueltas es lo normal.
  • «Hecho» incluye los tests en verde, con la salida a la vista.
  • Evals en CI: entre 20 y 50 tareas reales con su resultado aceptado, que corren en cada cambio de CLAUDE.md, skills o hooks. Cada incidente de producción deja una eval nueva.

5. Deploy: revisión en dos sentidos y puertas como código

Concepto: el agente hace todo hasta la puerta de producción y nada más allá.

Acciones:

  • Claude en la revisión de PR: todas las PR reciben las mismas pasadas (bugs, seguridad y cumplimiento de spec.md y plan.md), definidas en un REVIEW.md. La persona juzga intención y riesgo, y la aprobación sigue siendo suya: el agente que escribe el código no puede aprobarlo.
  • Un @claude en un comentario y Claude lo arregla y hace push. Lo que la revisión señala por segunda vez va al CLAUDE.md.
  • Hooks como puertas: lista las aprobaciones que tienen que sobrevivir (change management, autorización de release) y convierte cada una en un hook que permite, pregunta o bloquea. Los innegociables, en managed settings que nadie puede desactivar en local.
  • CI/CD: empieza por pasos de sólo lectura con claude -p (triar un build roto, resumir un test flaky, redactar el changelog). Después, escritura, pero siempre llegando como PR. Sandbox, tokens de vida corta y deploy, status y rollback expuestos por MCP.
  • Rollback ensayado: un único comando que el agente pueda lanzar y que se practique a menudo en staging.
Autonomía por entorno: en dev el agente despliega libremente, en staging tiene autonomía intermedia y en producción prepara la release pero la autoriza una persona tras una puertapuertadevstagingproducciónel agente despliegalibrementeautonomíaintermediael agente prepara,una persona autorizaautonomía del agenteautonomía del agenteautonomía del agenteel agente actúa hasta la puerta de producción, nunca más allá

6. Mantener: cerrar el bucle

Concepto: un disparador (una alerta, un ticket, un mensaje, un cron) invoca a Claude sin nadie en medio, y lo que encuentra vuelve a entrar como intent.md. Las personas ya no arrancan el trabajo: lo triagean y lo revisan.

Bandas de control: una métrica oscila dentro de 1, 2 y 3 sigmas; a 1σ sólo se registra, a 2σ Claude diagnostica en sólo lectura y al romper 3σ propone una PR o un rollback3σ → proponePR o rollback2σ → diagnosticaen sólo lectura1σ → registray nada másdetección determinista; Claude sólo entra al romperse una banda

Acciones:

  • Detección determinista: un script vigila las métricas con bandas de control (un bands.yaml). Claude sólo entra cuando se rompe una banda, y el nivel decide qué puede hacer.
  • Ejemplos: tests de CI fallando por encima de 3σ → pone en cuarentena el test flaky o abre una PR de revert; 5xx disparados tras un deploy → lanza el rollback.
  • Escaneos de seguridad programados (semanales es un buen punto de partida): cada hallazgo pasa por la misma puerta de PR, y lo que no cabe en una PR se convierte en intent.md.
  • Guardia en el canal: con Claude Tag en Slack, Claude es el primero en responder a un incidente. El hilo es la auditoría: petición, diagnóstico, autorización humana y arreglo.

Cómo saber si funciona

Cada play se mide con datos que ya tienes: timestamps de git, metadatos de las PR, el tracker de incidentes y las métricas DORA. Tres ejemplos:

  • De la primera conversación al intent.md commiteado: de semanas a horas.
  • Porcentaje de cambios que se integran a la primera pasada.
  • Regresiones cazadas en CI frente a regresiones encontradas en producción.

Por dónde empezar

No hace falta transformarlo todo a la vez. Los plays que no dependen de nada son la puerta de entrada.

Orden de adopción: primero CLAUDE.md, el bucle de feedback, hooks, skills e intent.md; después spec.md, plan mode, sesiones en paralelo, evals y revisión de PR; al final CI/CD con agente y cerrar el bucle1 · empieza aquí2 · después3 · al finalCLAUDE.mdbucle de feedbackhooksskillsintent.mdspec.mdplan modesesiones en paraleloevals en CIrevisión de PRCI/CD con agentecerrar el bucle

Mi lista corta:

  1. Un CLAUDE.md en el repo, de menos de una página.
  2. Un comando de verificación y la regla de que nada está hecho sin los tests en verde.
  3. Plan mode como punto de partida, y el plan.md commiteado.
  4. Un hook para lo innegociable: tests en los fixes, rutas protegidas, producción.
  5. Una skill para la política que peor se aplica hoy.
  6. Revisión de PR con Claude y un REVIEW.md.
  7. Sólo entonces, CI/CD con agente y cerrar el bucle.

Si ya vives en Jira, Figma o un gestor de requisitos, no hace falta tirarlo: declara una fuente de verdad por artefacto. Como mínimo, el ID del ticket en el fichero y el SHA del commit en el ticket.

Lo que me llevo

El bucle sigue girando. El criterio humano queda por encima.

El playbook no va de escribir código más rápido (eso ya ha pasado), sino de convertir el proceso en ficheros versionados que el agente lee y las puertas en código que se ejecuta. Casi todo lo que propone cabe también en un repo pequeño: este blog ya tiene su CLAUDE.md, hooks de git que impiden empujar a master y tests que el agente ejecuta antes de dar nada por terminado.