La tesis de Anthropic es clara: cuando los agentes producen código a velocidad de máquina, las empresas no pueden seguir gestionando el desarrollo con esperas de días[1]. El cambio no consiste en quitar controles, sino en convertirlos en artefactos, evaluaciones y puertas automáticas[1].

La IA ya no es el cuello de botella: el nuevo ciclo del desarrollo de software

El atasco se ha desplazado

Durante años, el problema más visible de producir software estaba en escribir y modificar código[1]. El ciclo tradicional estaba diseñado para una época así: los requisitos pasaban por talleres, los equipos intercambiaban documentos, los ingenieros programaban, QA verificaba y operaciones desplegaba[1]. Cada fase tenía propietarios, reuniones y aprobaciones[1].

La llegada de los agentes de programación ha cambiado el ritmo de esa cadena[1][2]. Anthropic sostiene que ahora las organizaciones pueden generar código a una velocidad difícil de imaginar hace un año, mientras los procesos que rodean al código siguen avanzando a velocidad humana[1][2]. El resultado es un desplazamiento del cuello de botella: ya no está principalmente en la construcción, sino en la planificación, la revisión, las pruebas, el despliegue y el gobierno de lo que se produce[1][2].

No es un problema menor[1]. Si un equipo de seguridad dimensionado para revisar código escrito por personas recibe diez veces más cambios, solo puede ocurrir una de dos cosas: la cola de revisión crece o el código sale sin la revisión necesaria[1]. En una empresa regulada, ninguna de las dos opciones es aceptable[1].

La propuesta de Claude Academy no es abolir el ciclo de desarrollo, sino cambiar su forma[1]. El SDLC nativo en IA deja de ser una línea que avanza mediante traspasos y se convierte en un bucle[1]. Cada fase deja un artefacto en control de versiones; la fase siguiente lo lee, y los resultados de producción pueden iniciar otra vez el recorrido[1].

La idea ya no tiene que esperar a producto

El primer cambio ocurre antes de que exista una línea de código[3]. Anthropic propone capturar la petición en un archivo intent.md: un proto-especificación breve, legible para una persona y accionable por un agente[3]. Debe responder, como mínimo, qué se quiere, por qué se quiere y bajo qué restricciones[3].

La ventaja no es que el archivo sea vistoso[3]. Es que conserva la intención de quien originó la idea en sus propias palabras[3]. En el modelo tradicional, la petición puede pasar por entradas de backlog, historias de usuario, puntos de estimación y reuniones de refinamiento antes de llegar a ingeniería[3]. Cada traspaso añade distancia entre la necesidad original y el trabajo que finalmente se ejecuta[3].

El intent.md cambia ese punto de partida[3]. Una persona describe a Claude el problema, los afectados, la situación actual y el aspecto que tendría una mejora[3]. Claude formula preguntas, ayuda a concretar el alcance y redacta el documento usando una plantilla acordada[3]. La persona corrige lo que no se haya entendido y lo confirma en un commit de un repositorio compartido[3].

Ese commit ya funciona como evidencia[3]. En Git quedan el autor, la marca de tiempo y la historia de revisiones[3]. La aceptación por parte del propietario del producto queda registrada en la mezcla o en la revisión que cierra la decisión[3]. Así, la conversación informal deja de ser un rumor que se pierde en un ticket: se convierte en el primer nudo de una cadena auditable[3].

Anthropic propone medir el resultado con indicadores sencillos[3]. El tiempo entre la primera conversación y el intent.md comprometido debería pasar de semanas a horas[3]. Y la tasa de supervivencia de esos archivos, es decir, la proporción que el propietario acepta para diseño frente a la que cierra, permite comprobar si el proceso filtra mejor las ideas antes de malgastar capacidad de ingeniería[3].

Requisitos, diseño y plan: los artefactos sustituyen a la memoria

Una vez aceptado el intent.md, Claude puede convertirlo en requisitos y diseño en una sola sesión[4]. Para ello recibe las políticas de marca, seguridad, cumplimiento y experiencia de usuario como habilidades que la organización ha convertido en conocimiento operativo[4]. El documento resultante debe señalar las áreas de preocupación que un analista habría escalado[4].

El producto no desaparece: deja de redactar todo a mano y se concentra en revisar[4]. Comprueba que la especificación resuelve el problema, que las preguntas abiertas se han respondido o se han trasladado y que los conflictos entre políticas se han resuelto con sus responsables[4]. Después, intent.md y spec.md quedan juntos en el repositorio[4]. El primer archivo registra lo que se pidió; el segundo, lo que se decidió[4].

Después llega el plan mode de Claude Code[5]. El ingeniero entrega spec.md, y el agente analiza el código sin modificarlo para proponer archivos afectados, orden de trabajo, pruebas, riesgos y alternativas descartadas[5]. El equipo puede interrogar el plan antes de aceptar la implementación[5]. La versión aprobada se guarda como plan.md, de modo que la revisión posterior pueda comparar el diff con lo que realmente se había planeado[5].

Este detalle importa porque invierte el momento de la revisión[5]. En el flujo tradicional, el primer artefacto que suele ver un revisor es el cambio terminado[5]. Si el enfoque era incorrecto, corregirlo resulta caro[5]. Con un plan comprometido, la conversación ocurre antes de generar código y el plan actualizado puede viajar en el mismo commit que se aparta de él[5].

Anthropic también admite una realidad que muchos equipos no quieren oír: no se puede asumir que los agentes conozcan las reglas del negocio[6]. CLAUDE.md se presenta como el equivalente al contexto que necesita una persona recién llegada: arquitectura, comandos, convenciones y errores que el equipo repite con frecuencia[6]. Se guarda en la raíz del repositorio y debería mantenerse por debajo de una página, porque Claude lo lee al comenzar cada sesión[6].

La regla práctica es casi doméstica: si Claude comete el mismo error dos veces, la corrección se añade a CLAUDE.md[6]. No se trata de documentar todo, sino de convertir los fallos repetidos en instrucciones compartidas y versionadas[6].

El conocimiento que antes vivía en la cabeza

Las habilidades de Claude son la otra capa de esa memoria organizacional[7]. Mientras CLAUDE.md contiene el contexto básico del repositorio, una skill convierte una política que debe aplicarse de forma consistente en instrucciones explícitas, con un disparador, un procedimiento y una versión[7].

Por ejemplo, una organización puede distribuir una skill para revisar APIs externas[7]. La skill exige autenticación, validación de entradas, auditoría de operaciones de escritura y protección de los datos personales[7]. La diferencia clave es que esa política deja de depender de que el ingeniero recuerde copiarla en cada prompt[7].

Pero Anthropic no confunde una skill con una garantía[7]. Una skill es un control consultivo: hace probable que Claude aplique la regla, pero nada fuerza a cada sesión a cumplirla[7]. Cuando una política no puede saltarse, la organización necesita un mecanismo determinista detrás, como un hook que bloquee la acción o una revisión automática en el pull request[7].

Construir con varios agentes no significa dejar de pensar

En la fase de construcción, el playbook propone dos tipos de trabajo en paralelo[8]. Una sesión paralela es otra instancia completa de Claude Code, aislada en su propio worktree de Git[8]. Un subagente es un asistente especializado dentro de una misma sesión, con su propio contexto y herramientas[8].

El trabajo se divide a partir del plan[8]. Las tareas que comparten archivos deben permanecer juntas; las independientes pueden recibir un worktree separado[8]. Anthropic recomienda empezar con dos o tres sesiones, no con una orgía de agentes: el límite real es cuántas corrientes puede revisar correctamente una sola persona[8]. El puesto del ingeniero no desaparece, pero se desplaza desde picar código hacia orquestar, dirigir y revisar[8].

Los subagentes sirven para encapsular tareas repetidas, como simplificar código, verificar que la aplicación funciona o investigar una parte del repositorio[8]. Sus definiciones también se guardan en Git[8]. La autonomía, por tanto, no se entrega sin estructura: se construye con aislamiento, permisos y un contexto que puede auditarse[8].

La prueba de que el agente trabaja no puede llegar tarde

La pieza que evita que un agente muy rápido se convierta en una fábrica de código defectuoso es un bucle de retroalimentación[9]. El curso recomienda que cada sesión tenga una forma de verificar su propio trabajo: tests, compilación, diff de capturas o una comprobación de comportamiento[9].

Ese bucle debe ser ejecutable con un solo comando y devolver un resultado inequívoco[9]. Para corregir un bug, el equipo pide primero a Claude que reproduzca el fallo con un test, comprueba que falla por la razón esperada y lo confirma en un commit[9]. Después se le permite hacer que pase, sin editar la prueba[9]. Así, una prueba que existía antes del arreglo y que el agente no podía reescribir se convierte en prueba de que el fallo se ha resuelto[9].

La interfaz de usuario añade una comprobación visual: Claude implementa, hace una captura, la compara con el diseño y ajusta[9]. No se trata de añadir una capa de teatralidad al proceso, sino de devolverle al agente una señal comparable a la que recibe una persona que abre la aplicación[9].

Los evals llevan esa idea al propio sistema de agentes[10]. Anthropic propone reunir entre 20 y 50 tareas reales, con un resultado esperado o aceptado, y convertirlas en pruebas: el prompt y las comprobaciones que definen si la respuesta es aceptable[10].

La suite se ejecuta en CI cuando cambia CLAUDE.md, una skill o un hook, porque esos archivos orientan al agente y también merecen pruebas de regresión[10]. Cada incidente de producción se convierte en un eval permanente[10]. Así, el equipo no solo detecta si el modelo ha empeorado: conserva los fallos del pasado como guardia contra la siguiente versión[10].

La revisión humana cambia de objeto

Cuando el código llega al pull request, el trabajo de revisar cada línea deja de ser escalable[11]. Anthropic propone que Claude ejecute un conjunto uniforme de pases: errores lógicos, seguridad, cumplimiento de spec.md, respeto de plan.md y principios de diseño[11]. Los hallazgos se ordenan por severidad y la atención humana se concentra en la intención y el riesgo[11].

La organización puede formalizar esa política en REVIEW.md, definiendo qué cuenta como importante, qué es una molestia menor y qué debe omitirse[11]. Los hallazgos de la IA no aprueban por sí solos un cambio: sigue siendo necesaria la aprobación de un code owner[11]. La diferencia es que la persona llega a una revisión con un mapa de riesgos en lugar de tener que reconstruirlo desde cero[11].

Los hooks llevan la gobernanza un paso más allá[12]. Son scripts que se ejecutan antes de que Claude actúe y pueden permitir, pedir aprobación o bloquear[12]. Un hook puede impedir cambios en migraciones sin ticket, rechazar que el agente edite el test de una corrección o exigir una autorización concreta antes de desplegar en producción[12]. Los hooks de equipo viven en .claude/settings.json; los no negociables deben residir en ajustes gestionados por la plataforma o TI[12].

La idea importante es que el control se ejecuta mientras la IA actúa, no semanas después en un comité[12]. Un bloqueo debe explicar por qué ocurre y cuál es el camino de aprobación[12]. La gobernanza deja de ser una ceremonia periódica y se convierte en una propiedad verificable del sistema[12].

El despliegue también entra en el bucle

El playbook propone ejecutar Claude Code de forma no interactiva dentro de CI/CD para tareas que requieren juicio, como diagnosticar un fallo, clasificar un test inestable o redactar el changelog[13]. Al principio, esas tareas deben ser de solo lectura[13]. Después, los cambios escritos por el agente llegan como pull requests y la protección de rama evita que pueda enviar cambios directamente a la rama principal[13].

La ejecución se realiza en contenedores, con políticas de red y credenciales de corta duración[13]. El despliegue no se entrega como un script de shell con credenciales permanentes, sino como herramientas MCP restringidas por entorno[13]. La autonomía se organiza por niveles: más libertad en desarrollo, más controles a medida que el cambio se acerca a producción[13].

Producción vuelve al principio

La última fase es la que cierra el círculo[14]. Un monitor detecta que se ha roto un control band, un ticket entra por el canal correspondiente o se cumple un horario[14]. Claude diagnostica, actúa solo por rutas gated y escribe lo que encuentra en un nuevo intent.md[14].

Una corrección pequeña y acotada puede llegar como pull request[14]. Un problema mayor vuelve a planificación y atraviesa requisitos, diseño, plan, construcción, pruebas y revisión[14]. El equipo ya no tiene que arrancar manualmente cada etapa, pero sí debe decidir dónde se sitúan los límites de autonomía y dónde se requiere una mirada humana[14].

Conclusión: el cuello de botella también se puede programar

El SDLC nativo en IA de Anthropic no es una promesa de desarrollo sin fricción[1]. Al contrario, reconoce que la fricción no desaparece: se mueve[1]. La generación de código se acelera, pero la alineación, la verificación, el gobierno y la respuesta a incidentes deben acelerarse con ella[1].

La aportación más interesante del playbook es convertir el proceso en una cadena de artefactos comprometidos[1][3][4]. intent.md conserva el origen; spec.md fija lo decidido; plan.md permite revisar el camino; el diff y sus pruebas muestran el resultado; el pull request concentra la evaluación; y el incidente reabre el ciclo[1][3][4]. La revisión humana deja de ser la única garantía y se convierte en la última decisión en puntos concretos[11].

Para una empresa que está metiendo agentes de programación en su repositorio, la pregunta ya no es si puede escribir más código[1]. La pregunta es si su sistema de controles puede viajar a la misma velocidad[1]. La ventaja no estará en tener el agente más rápido, sino en tener el bucle más corto, más observable y más difícil de eludir[1].

Datos del artículo

• La fuente principal es el curso gratuito de Claude Academy The AI-Native SDLC Playbook, compuesto por 14 lecciones y declarado como una hora de trabajo[1].
• Su foco son equipos de ingeniería, plataforma y seguridad que ya usan Claude Code y necesitan adaptar sus puertas de aprobación, revisión y despliegue[1].
• La propuesta organiza el ciclo en seis etapas: planificación, diseño, construcción, pruebas, despliegue y mantenimiento[1].
• El curso está publicado por Anthropic y describe buenas prácticas de su equipo de Applied AI, inspiradas en el trabajo con clientes[1].

Sources:

[1] https://academy.claude.com/courses/ai-native-sdlc-playbook
[2] https://academy.claude.com/courses/ai-native-sdlc-playbook/introduction
[3] https://academy.claude.com/courses/ai-native-sdlc-playbook/capture-intent
[4] https://academy.claude.com/courses/ai-native-sdlc-playbook/requirements-and-design
[5] https://academy.claude.com/courses/ai-native-sdlc-playbook/plan-mode
[6] https://academy.claude.com/courses/ai-native-sdlc-playbook/claude-md
[7] https://academy.claude.com/courses/ai-native-sdlc-playbook/skills-as-institutional-knowledge
[8] https://academy.claude.com/courses/ai-native-sdlc-playbook/parallel-sessions-and-subagents
[9] https://academy.claude.com/courses/ai-native-sdlc-playbook/give-claude-a-feedback-loop
[10] https://academy.claude.com/courses/ai-native-sdlc-playbook/continuous-evals-in-ci
[11] https://academy.claude.com/courses/ai-native-sdlc-playbook/ai-in-the-pr-review-loop
[12] https://academy.claude.com/courses/ai-native-sdlc-playbook/hooks-as-approval-gates
[13] https://academy.claude.com/courses/ai-native-sdlc-playbook/ci-cd-integration-and-deployment
[14] https://academy.claude.com/courses/ai-native-sdlc-playbook/closing-the-loop-on-metrics