Las semanas 3 y 4 no tratan de arreglar cosas. Tratan de leerlas.

Módulo 9 · Capstone · Lección 4 de 4

Al terminar esta lección podrás diagnosticar los cuatro modos de fallo que aparecen en la recta final de una activación de 30 días, traspasar la herramienta a un champion que pueda gestionarla de forma independiente y dejar un plan que el cliente pueda usar.

Dónde estás

Las semanas 3 y 4 se sienten distintas a las dos primeras. Y deberían.

La energía cambia en este punto de cualquier activación.

La prisa de la instalación ya quedó muy atrás. La emoción de la primera ejecución correcta de CI se ha asentado en algo más parecido a la rutina, que es exactamente lo que buscas. Ahora aparecen los problemas más silenciosos: el CLAUDE.md que no se ha tocado desde el Día 3, el desarrollador que lleva dos semanas repitiendo el mismo tipo de tarea sin avisar, el pipeline que funciona la mayor parte del tiempo. Tu trabajo en la recta final es limpiar esos puntos, dejar al champion listo para gestionar la herramienta y producir un traspaso que no requiera que sigas en la llamada. El readout de 30 días ya está tomando forma. Todo lo que haces ahora alimenta ese readout.

Playbook de troubleshooting

Cuatro modos de fallo que aparecen en la recta final

Ninguno de estos es dramático. Por eso es fácil pasarlos por alto hasta que ya han restado valor al readout del Día 30.

1. Deriva de contexto (context drift). El CLAUDE.md se escribió el Día 3 y no se ha actualizado desde entonces. El código ha cambiado. Las sugerencias empiezan a sentirse ligeramente desfasadas: no están mal, pero ya no encajan del todo con el estado actual del código. Solución: revisa el CLAUDE.md con el champion y actualiza las secciones de arquitectura y convenciones para reflejar el estado actual.

2. Acumulación de permisos (permission creep). Los permisos de herramientas se han ido ampliando durante el piloto, a medida que los desarrolladores necesitaban acceder a más partes del código. Lo que en el Día 3 era una configuración muy acotada ha crecido. Esto importa sobre todo en el pipeline de CI: los permisos amplios en un contexto no interactivo son difíciles de auditar. Confirma que el alcance de allowedTools sigue coincidiendo con el workflow real.

3. Estancamiento de la adopción (adoption plateau). Los adoptantes tempranos están en la etapa 3 o 4 de la curva. Un segmento de la cohorte sigue en la etapa 1: solo modo supervisado, baja tasa de finalización de tareas y tasa de aceptación moderada. No lo han señalado porque no están visiblemente atascados. Detéctalo desde el stack de medición antes del readout del Día 30, no después.

4. Variabilidad del pipeline (pipeline variability). El workflow de GitHub Actions funciona la mayoría de las veces, pero no siempre. Una salida variable con el mismo prompt entre ejecuciones suele deberse a la longitud del contexto o a un problema de salida del modelo, no a un bug del pipeline. Comprueba si el pipeline pasa suficiente contexto y si el formato de salida está restringido. En esta etapa, la consistencia importa más que el rendimiento.

Traspaso al champion

El traspaso no es un evento. Es un estado al que se llega trabajando.

Un champion que necesita llamarte la semana después de que te vayas no está listo. La diferencia entre listo y no listo no es la confianza. Es la capacidad.

No está listo todavía. Sabe usar la herramienta, pero no sabe ser su propietario. El champion puede ejecutar Claude Code en sus propias tareas. Pero consulta contigo las preguntas de troubleshooting, no ha tocado el CLAUDE.md y no sabría explicar el stack de medición a su responsable. Es un usuario capaz, no un propietario. Hacen falta más tiempo o tareas de propiedad estructuradas antes de que te vayas.

Listo para el traspaso. Puede diagnosticar, mantener y promover la herramienta. El champion ha actualizado el CLAUDE.md al menos una vez sin que se lo pidan. Puede responder preguntas básicas de troubleshooting del equipo. Sabe qué mide el stack de medición y puede leer los números. Existe una ruta de escalamiento nombrada para cualquier asunto que exceda su alcance. Ese es el listón.

flowchart LR
    A["No está listo todavía: sabe usarla, no es propietario"] -->|"Más tiempo o tareas de propiedad estructuradas"| B["Listo para el traspaso: diagnostica, mantiene y promueve"]

Comprueba tu comprensión

Semana 4. El champion te envía un mensaje.

Escenario · Semana 4

Varios desarrolladores le dicen al champion que las sugerencias de Claude Code han empezado a sentirse “raras”: no técnicamente incorrectas, pero no del todo adecuadas para el código base. El pipeline de CI está limpio. Las sesiones individuales son productivas. Nada en los datos de OTel señala un problema claro. ¿Cuál es la causa más probable?

• A · El modelo ha cambiado. Anthropic puede haber actualizado el modelo subyacente. Abre un ticket de soporte para confirmarlo y pedir una reversión.
• B · El CLAUDE.md no se ha mantenido al día con el código base. Deriva de contexto: el CLAUDE.md se escribió hace semanas y el código ha evolucionado. Claude trabaja con un contexto desactualizado.
• C · El equipo pide tareas fuera del caso de uso acotado. Los desarrolladores pueden haber ampliado el uso de Claude Code más allá de lo que el piloto estaba diseñado para cubrir. Vuelve a acotar las tareas al caso de uso original.
• D · Cambiar al equipo al modo verbose. Respuestas más detalladas darán a los desarrolladores más contexto sobre el razonamiento de Claude y les ayudarán a corregir el resultado.

Ver respuesta

B: deriva de contexto. El síntoma aquí es cualitativo, no cuantitativo: ninguna métrica está rota, pero las sugerencias se sienten desalineadas. Ese patrón casi siempre apunta a que el CLAUDE.md se ha quedado atrás respecto del código, sobre todo en un piloto de cuatro semanas donde la arquitectura y las convenciones siguen evolucionando. Claude trabaja con precisión sobre una descripción del código base que ya no refleja el código real. La solución es una revisión del CLAUDE.md junto con el champion: actualizar la sección de arquitectura, refrescar las convenciones y añadir lo que haya cambiado desde la configuración inicial. La opción C no es irrelevante; conviene vigilar el alcance, pero se manifestaría de otra forma. Las tareas fuera de alcance producen errores o resultados incompletos, no sugerencias sutilmente desviadas.

Artefacto del curso

Deja algo que funcione sin ti

El plan de activación es el documento de traspaso. Le indica al champion qué se configuró, qué vigilar y qué hacer cuando algo no parece correcto.

Artefacto del curso 9 · Plan técnico de activación

Tu referencia para el arco de 30 días, desde la perspectiva del FDE y del arquitecto.

Este plan recoge lo que configuraste, lo que monitorizaste y lo que el champion debe gestionar cuando te vayas. Úsalo como documento de trabajo en el siguiente proyecto: actualízalo a medida que avanzas en lugar de escribirlo al final.

flowchart LR
    A["Días 1–3: configuración del entorno"] --> B["Día 8: primera lectura de los datos"]
    B --> C["Día 14: integración CI/CD"]
    C --> D["Semanas 3–4: preparación del traspaso"]
    D --> E["Readout del Día 30"]

Días 1–3 · Configuración del entorno

1. Se escribió el CLAUDE.md con la descripción de la arquitectura, las convenciones, las herramientas permitidas y la estructura del proyecto. Lo confirmó al menos un desarrollador ejecutando una tarea real antes de que cerrara el Día 3.
2. Servidores MCP configurados si hacen falta. Permisos acotados al caso de uso del piloto, sin ser más amplios de lo necesario. Se demostró a la cohorte la orquestación de subagentes y en paralelo.
3. Stack de medición activo: OTel conectado, cuatro métricas del scorecard instrumentadas (tasa de adopción, tareas por sesión, tasa de aceptación de código, tiempo por tarea). Línea base capturada.

Día 8 · Primera lectura de los datos

1. Se ejecutó con la cohorte el ejercicio de generación de tests en modo bash. Se habló del modo de salida conciso frente al verbose y se configuró según el flujo de trabajo del equipo.
2. Se revisaron las cuatro métricas del scorecard. Se identificó y evaluó a cualquier desarrollador con patrones de bucle (no de iteración): el alcance de la tarea o el vacío en el CLAUDE.md se resolvieron antes del Día 14.

Día 14 · Integración con CI/CD

1. Workflow de GitHub Actions en producción. Clave de API en los secretos del repositorio. ANTHROPIC_BASE_URL configurada explícitamente en el paso del workflow. allowedTools acotado a lo que el pipeline realmente necesita.
2. Se confirmó la primera ejecución headless exitosa. Se verificó el enrutamiento por proxy: el runner llega al gateway, no a la API de Anthropic directamente.

Semanas 3–4 · Preparación del traspaso

1. CLAUDE.md revisado y actualizado junto con el champion. Las secciones de arquitectura y convenciones reflejan el código tal como existe ahora, no como estaba en el Día 3.
2. Se identificó a los desarrolladores en estancamiento de adopción a partir del stack de medición y se les asignó una tarea estructurada para avanzarlos antes del readout del Día 30.
3. Se redactó el readout del Día 30: métrica principal, datos de respaldo frente a los criterios de éxito acordados y la conversación de renovación enmarcada en un siguiente paso concreto, no en un seguimiento por agendar.

Checklist de traspaso al champion

• El champion ha actualizado el CLAUDE.md al menos una vez sin que se lo pidieran.
• El champion puede responder preguntas básicas de troubleshooting de la cohorte.
• El champion sabe qué significan las cuatro métricas del scorecard y dónde encontrarlas.
• Existe una ruta de escalamiento nombrada para los problemas que excedan el alcance del champion.
• La documentación del pipeline de CI está escrita y entregada al equipo, no solo al champion.
• El readout del Día 30 se revisó con el champion antes de la sesión con el patrocinador.

Capstone completado

Puedes ejecutar una activación de Claude Code de principio a fin.

Cuatro lecciones, del Día 3 al Día 30. Has preparado el entorno, leído las señales tempranas, conectado el pipeline de CI, gestionado los fallos de la última etapa y traspasado la herramienta a un champion que puede gestionarla. El Plan técnico de activación es tuyo para llevarlo al siguiente proyecto.

Paso final · Evaluación

Delivery Readiness Assessment

La evaluación final reúne los nueve cursos. Está basada en escenarios, es transversal y tiene límite de tiempo. Complétala para obtener tu certificación Claude Code Delivery Readiness.

Ideas clave

• Cuatro modos de fallo de la última etapa: deriva de contexto, acumulación de permisos, estancamiento de la adopción y variabilidad del pipeline.
• El traspaso se consigue cuando el champion puede diagnosticar, mantener y promover la herramienta, no solo usarla.
• El Plan técnico de activación documenta lo configurado, lo que hay que vigilar y qué hacer cuando algo no parece correcto.
• Revisar el CLAUDE.md junto con el champion mantiene el contexto alineado con el código actual.