El modo de planificación de Claude Code como punto de partida predeterminado

Los ingenieros inician las sesiones de Claude Code en modo de planificación, le dan a Claude el spec.md aprobado de la Etapa 2: Diseño, y dejan que los entreviste, iterando sobre el plan hasta que estén satisfechos con él.

Qué cambia

Primeros pasos

• Requisitos previos: El artefacto de intención (intent.md o spec.md) si existe, y el archivo CLAUDE.md ayuda.
• Infraestructura: Claude Code con acceso al repositorio.

Cómo ejecutarlo

1. El ingeniero inicia la sesión en modo de planificación con Claude.
2. El ingeniero le da a Claude el intent.md y el spec.md y le pide un plan de implementación que nombre los archivos que cambian, el orden del trabajo y las pruebas que lo demuestran.
3. Interroga el plan preguntando qué podría romper el cambio, qué paso es el más riesgoso y qué otras opciones Claude decidió no hacer.
4. Itera hasta que un ingeniero que nunca haya visto la conversación pueda implementar el cambio solo a partir del plan.
5. Confirma el plan aprobado como plan.md. El plan se une al registro de auditoría, y la jugada de revisión de PR (Etapa 5: Implementación) verifica el diff final contra él.
6. Acepta el plan y deja que Claude lo implemente. Con un plan sólido, la implementación suele ser una sola pasada.
7. Cuando la implementación se desvía del plan, actualiza plan.md en el mismo commit. Considera usar un hook para forzar la sincronización entre ambos.

Cómo se ve

El plan a continuación es para un cambio en una aseguradora: un panel en el portal del cliente que muestra el estado de un reclamo. El panel llama al backend del portal, claims-api, que lee de claims-core, un sistema interno más antiguo.

plan.md:

# Plan: claims status self-service (from intent.md and spec.md)

## Files that change

portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py, claims-api/tests/test_status.py

## Order of work

1. Add the status endpoint behind existing auth (R1, R2, R3).
2. Panel against the endpoint, with the 60-second cache (R1, R4).
3. Wire into the portal nav.

## Risks

The claims-core API rate-limits at 50 rps; the panel must cache (spec concern 3).

## Proof

test_status.py covers the four claim states (R2) and fails on any extra field (R3); screenshot matches the approved mock.

R1 a R4 son los requisitos numerados en spec.md, y concern 3 es un riesgo que spec.md señaló. Debido a que el plan los cita, un revisor puede verificar el plan contra la especificación línea por línea.

Consideraciones de gobernanza

La revisión de diseño ocurre antes de que se genere cualquier código, cuando cambiar de rumbo todavía es cuestión de editar un documento. El modo de planificación impone esto por sí mismo, ya que Claude no puede editar archivos hasta que el ingeniero acepte el plan. El plan y sus revisiones se registran junto con quién lo aceptó. Los cambios rutinarios son aprobados por el ingeniero, y cualquier cosa que la organización clasifique como de mayor riesgo pasa a un líder técnico o arquitecto.

Cómo medirlo

• Indicador adelantado: Proporción de cambios que se fusionan desde la primera pasada de implementación, y tiempo desde la aprobación del plan hasta el PR fusionado con los datos requeridos dentro de los metadatos del PR.
• Indicador rezagado: Ciclos de retrabajo por cambio, nuevamente a partir de los metadatos del PR, y con qué frecuencia el diff fusionado todavía coincide con el plan.md confirmado.

Claude Code en modo automático

Claude Code también puede ejecutarse en modo automático, donde el ingeniero itera sobre el plan y lo aprueba, y Claude luego aplica cada cambio sin una solicitud por edición. A medida que maduran las barreras de protección de las jugadas posteriores (un CLAUDE.md ajustado, skills que codifican políticas, hooks que bloquean acciones inseguras y un conjunto de pruebas que Claude puede ejecutar), el modo automático se convierte en el predeterminado para el trabajo rutinario: un spec.md ajustado, un radio de impacto pequeño y código que las pruebas ya cubren.

El cambio ahora se aleja de que el usuario observe al agente hacer las ediciones y revise las acciones, hacia la revisión de artefactos después de sesiones autónomas más largas. El modo automático además habilita el paralelismo entre individuos y el equipo cuando se usa con worktrees, y es fundamental para ejecutar el SDLC de forma autónoma y cerrar el ciclo como se describe en la Etapa 6: Mantenimiento.

Sistemas heredados y la fuente de verdad

Los procesos de SDLC existentes probablemente ya rastrean artefactos, solo que no en archivos Markdown. Los elementos de trabajo pueden estar en Jira, los requisitos en una herramienta con trazabilidad regulatoria incorporada, los diseños en Figma, y las aprobaciones de cambios con un comité de cambios. Esos sistemas son difíciles de desplazar porque los auditores y reguladores ya los aceptan y otros equipos dependen de ellos, por lo que el SDLC nativo de IA tiene que adaptarse a lo que existe. Para cada artefacto que produce el proceso, un sistema debe designarse como la fuente de verdad y los demás deben mantener una copia o un enlace.

Las siguientes configuraciones se pueden establecer para tener una fuente de verdad, con la elección variando según el artefacto:

• El repositorio como fuente de verdad. Los artefactos en Markdown son el registro autorizado, y el sistema heredado hace referencia a archivos dentro de los commits. Esta puede ser una de las configuraciones más limpias para organizaciones dirigidas por ingeniería, ya que todos los registros viven en una sola herramienta con una sola autoridad de marca de tiempo.
• El sistema heredado es la verdad. Jira, ServiceNow o la herramienta de requisitos contiene el registro autorizado, y los artefactos en Markdown son copias de trabajo. Claude lee el registro al inicio de la sesión y escribe el resultado de vuelta a través de un conector de Model Context Protocol (MCP) en la misma sesión que produjo la especificación o el plan.
• La vinculación como el mínimo aceptable. Todos los artefactos anotan el ID del registro, y todos los registros heredados contienen el SHA del commit del archivo Markdown. La opción de vinculación es un buen punto de partida al hacer la transición al SDLC nativo de IA, ya que hay dos fuentes de verdad.

Tanto el sistema heredado como el sistema nativo de IA basado en Markdown pueden coexistir siempre que haya un enlace entre ambos o que uno se declare como la fuente de verdad.