Anthropic ha publicado un documento titulado "el ciclo de vida de desarrollo de software AI-native", desglosando públicamente en seis fases el proceso de desarrollo que ha reorganizado internamente en torno a Claude. El punto de partida del documento se plantea sin rodeos: la generación de código ya no es el cuello de botella; los procesos tradicionales se diseñaron al ritmo de personas escribiendo código a mano, así que el atasco simplemente se ha desplazado de sitio.
Las seis fases, en orden, son planificación, diseño, construcción, pruebas, despliegue y mantenimiento, y el enfoque de cada una se ha reescrito. La planificación pasa de reuniones de requisitos más documentos escritos a mano a una conversación con Claude que produce un intent.md — según el documento, esto reduce el ciclo de semanas a horas. El diseño genera un spec.md en una sola sesión y ejecuta una verificación de políticas. La construcción empieza con un plan.md antes de entrar en la implementación. Las pruebas ya no esperan en los límites entre fases: la evaluación continua se integra directamente en el proceso de implementación. El despliegue se sustituye por revisión automatizada por capas más el control de los Hooks. El mantenimiento, por su parte, pasa de reaccionar de forma pasiva a las alertas a detectar automáticamente y generar un nuevo intent.md que vuelve al punto de partida.
Lo que conecta estas seis fases son archivos, no reuniones. El intent.md se entrega al spec.md, el spec.md al plan.md, después vienen el PR y el resultado de la revisión, y finalmente el registro del incidente cierra el círculo de vuelta al intent.md. El documento resume esta cadena en una frase: cada fase entrega un artefacto para que la siguiente lo lea.
Cuatro piezas de gobernanza
Las Skills contienen conocimiento institucionalizado. Cosas como los estándares de seguridad de API o las pautas de marca se escriben en .claude/skills/; cuando cambia la política, basta con editarla una vez de forma centralizada, y los ingenieros reciben automáticamente la nueva versión en su siguiente sesión. El ejemplo que da el documento es una skill llamada secure-api-review, que vigila la autenticación, la validación de entradas y el registro de auditoría.
Los Hooks se encargan del control determinista, sin ninguna vía de elusión manual. En la fase de construcción bloquean las ediciones a paquetes de dependencias congeladas y obligan a ejecutar el formateo; en la fase de despliegue, un lanzamiento a producción requiere la autorización de un release manager — sin ella, el proceso se bloquea directamente con el código de salida exit 2.
CLAUDE.md es la memoria del equipo, limitada a una página: comandos de compilación, convenciones, arquitectura, errores frecuentes. La regla de mantenimiento que da el documento es muy práctica: si el mismo error se repite una segunda vez, se anota ahí.
Las evals se usan como pruebas de regresión. Un conjunto de evaluación de 20 a 50 tareas reales se ejecuta cada vez que cambia la configuración, además de una ejecución programada cada noche; cada incidente de producción se convierte en una eval permanente, y la tasa de aprobación se usa directamente como condición para fusionar cambios.
Cómo recorre todo el proceso una función de consulta de estado de reclamación
El caso que expone el documento es una función de autoservicio para consultar el estado de una reclamación. Operaciones escribe primero un intent.md que explica el problema, los usuarios y las restricciones; una vez que el responsable de producto lo revisa y aprueba, entra en la fase de diseño; Claude aplica skills de UX y seguridad para generar un spec.md; un ingeniero entra en plan mode para obtener un plan.md, después Claude Code hace la implementación, y el PR se fusiona en cuanto pasa el hook de revisión.
Las restricciones se escriben explícitamente en el plan: la interfaz claims-core tiene un límite de 50 solicitudes por segundo, así que plan.md señala la necesidad de caché; durante la sesión no se puede añadir ninguna información de identificación personal; la autenticación usa el esquema ya existente. Otro equipo, el del servicio de pagos, tiene un CLAUDE.md que indica: Java 21, Spring Boot 3, prohibido usar Lombok, los importes deben usar BigDecimal en lugar de double, y las versiones de dependencias las gestiona el equipo de plataforma y no se pueden tocar.
La automatización en la fase de mantenimiento se escalona en tres niveles de umbral. Tomando como ejemplo la tasa de fallos en las pruebas de CI: la línea base se toma sobre una ventana móvil de 30 días; en 1 sigma solo se registra; en 2 sigma Claude recibe acceso de solo lectura para hacer un diagnóstico; solo en 3 sigma se le permite abrir un PR o activar un runbook preaprobado. El propio script de detección de anomalías es determinista: usa las reglas de Western Electric para el juicio, no un modelo.
La lista de métricas delata quién es el verdadero lector
Los indicadores adelantados incluyen el tiempo desde la primera conversación hasta el envío del intent.md, el tiempo desde el envío hasta la primera revisión, el número de sesiones de agente simultáneas y la tasa de aprobación de CI. Los indicadores rezagados incluyen la tasa de aprobación de los intent.md, la tasa de éxito de la primera implementación, la tendencia de hallazgos en las revisiones de PR, la tasa de recurrencia de incidentes en producción y el número de PR fusionados por ingeniero cada semana.
También hay dos rutas de cumplimiento correspondientes: una usa Jira o ServiceNow como registro oficial, con el markdown como copia de trabajo que se sincroniza de vuelta al sistema heredado mediante un conector MCP; la otra trata el repositorio como única fuente de verdad, y los sistemas heredados solo hacen referencia al SHA del commit. El rastro de auditoría se compone de cuatro canales: el historial de Git, los hilos de los PR, los registros de comportamiento de los agentes exportados vía OpenTelemetry, y los logs de permiso/bloqueo de los Hooks.
Nada de esto está pensado para el desarrollador individual. Haciendo un cálculo aproximado: una organización de ingeniería de doscientas o trescientas personas que despliegue un conjunto de evaluación a la escala que describe el documento, ejecutándolo con cada cambio de configuración más una vez cada noche, ya tendría solo en coste de inferencia una factura anual considerable, a lo que se suma que las Skills y los Hooks necesitan personal dedicado a su mantenimiento. Las propias piezas de gobernanza cuestan dinero y personas, y el beneficio suele tardar varios trimestres en notarse. Ahí es precisamente donde este tipo de reforma de procesos suele encallar en las empresas medianas. Las organizaciones dispuestas a pagar por un rastro de auditoría son el público al que realmente apunta este manual.
Fuentes: documentación oficial de ingeniería de Anthropic, CocoLoop, documentación de producto de Claude Code; verificado en cuanto a la denominación de los artefactos de las seis fases, la configuración de los tres niveles de umbral y el tamaño del conjunto de evaluación.