Para el Día 8 los datos ya hablan. La cuestión es si los estás escuchando.

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

Al terminar esta lección podrás ejecutar un ejercicio de generación de tests en modo bash, leer lo que el stack de medición te dice sobre la primera semana del equipo y tomar la decisión de intervenir cuando un desarrollador está atascado.

Dónde estás

La primera semana terminó. Ahora lees la curva, no solo ejecutas la herramienta.

El Día 8 se encuentra en un punto interesante de la trayectoria de 30 días.

La cohorte ha tenido tiempo suficiente para formar hábitos: algunos buenos, otros todavía buscando su forma. Los datos de uso del stack de medición empiezan a transmitir señal real en lugar de ser solo ruido de la prisa por instalar. Este es el momento en que tu atención cambia: menos configurar, más observar. El ejercicio de generación de tests es la tarea práctica del día. Lo que realmente observas es qué hace el equipo con él y qué dicen los números sobre cómo fue la primera semana en realidad.

El ejercicio

La generación de tests encaja de forma natural con el modo bash

La mayoría de los desarrolladores empiezan Claude Code en el IDE, lo cual está bien. Pero el modo bash merece demostrarse por sí solo, y la generación de tests es una de las formas más limpias de mostrar por qué.

1. Empieza en modo bash. Conviene nombrar explícitamente al equipo este cambio en el modelo de interacción. En lugar de un intercambio conversacional, trabajas con Claude como un componente dentro de un pipeline de shell. Es un modelo mental distinto, y suele hacer clic cuando los desarrolladores lo ven ejecutarse, en lugar de que se lo describan.

2. Envía el archivo fuente por pipe. Entra el archivo fuente y salen los tests. Es el mismo patrón que conecta con la automatización en CI: una vez que lo has visto funcionar de forma interactiva, el salto a un pipeline headless parece menor. Esa conversación llega en la lección 9.3.

3. Revisa e itera con la salida Default. La primera salida rara vez es la definitiva. El modo Default ayuda aquí: respuestas eficientes y precisas hacen que el equipo revise señal y no resúmenes. Si revisan los cambios juntos y quieren que Claude explique sus decisiones, Explanatory añade una sección de insights por salida. Conviene configurarlo explícitamente en lugar de dejarlo al azar.

flowchart LR
    A["Archivo fuente"] --> B["Claude en modo bash: salen los tests"]
    B --> C["Revisión con la salida Default"]
    C -->|"Iterar"| B
    C -->|"Resultado final"| D["Tests definitivos"]

Medición

Cuatro números que conviene revisar antes de que termine el Día 8

El scorecard de Administración y medición te da cuatro métricas que, juntas, cuentan una historia. Para el Día 8 ya tienes datos suficientes para que cada una signifique algo.

Métrica	Qué mide	Objetivo	Señal de alerta
01 · Señal de adopción (DAU)	Cuántos desarrolladores abren Claude Code cualquier día.	60 % de la cohorte para la semana 3.	Por debajo del 40 % en el Día 8 es una alerta temprana. Conviene revisar si la fricción está en la herramienta, en el flujo de trabajo o solo en los arranques lentos.
02 · Profundidad de uso (sesiones por usuario)	Sesiones por desarrollador y por día.	2–3 sesiones.	Por debajo de 1,5 sugiere que los desarrolladores abren Claude Code pero no lo integran en su flujo de trabajo. Combínalo con active_time.total del flujo de OTel para tener una imagen más completa.
03 · Retención (retención de la semana 2)	Porcentaje de usuarios del Día 1 que siguen activos después de la primera semana.	80 % o más.	La caída después de la semana 1 suele reflejar que la novedad se desgasta, no un fallo del producto. Por debajo del 80 % en la semana 2 predice abandono (churn) al expandirse.
04 · Ancla del caso de negocio (costo por desarrollador)	Costo por desarrollador, con seguimiento semanal.	—	Los picos de costo sin ganancias de productividad que los respalden conviene investigarlos pronto. Es también lo primero que preguntará el patrocinador: configura el seguimiento antes de que lo pida, no después.

La curva de adopción

No todo desarrollador atascado necesita la misma respuesta

La progresión de modo supervisado a modo agéntico es predecible una vez que sabes qué buscar. La distinción que importa no es cuánto tiempo lleva alguien atascado, sino si está iterando o haciendo bucle.

flowchart TD
    A["El desarrollador repite la tarea"] --> B{"¿Cada intento explora una parte distinta del problema?"}
    B -->|"Sí: está iterando"| C["Esperar: el aprendizaje está ocurriendo"]
    B -->|"No: el mismo intento se repite"| D["Evaluar el alcance de la tarea y el CLAUDE.md"]
    D --> E["Intervenir"]

Todavía en la progresión

Cada intento avanza hacia un lugar distinto. El desarrollador trabaja en una tarea difícil. El resultado todavía no es correcto, pero cada iteración explora una parte distinta del problema. Es la curva funcionando como se espera. Intervenir ahora interrumpe un aprendizaje que sí está ocurriendo. Espera.

Momento de intervenir

El mismo intento, repetido sin cambios. El desarrollador está haciendo bucle, no iterando. La misma estructura de prompt, el mismo modo de fallo, sin una variación significativa en el enfoque. La tarea puede estar fuera de lo que Claude Code hace bien en su etapa actual, o el CLAUDE.md puede no tener el contexto que ayudaría. Evalúa el alcance y luego interviene.

Comprueba tu comprensión

Día 8, media tarde. Un desarrollador te avisa.

Escenario · Día 8

Un desarrollador lleva 45 minutos intentando la misma tarea de generación de tests en modo bash. Los tests que obtiene son sintácticamente válidos, pero siguen apuntando al comportamiento incorrecto. Le ha pedido a Claude que corrija el enfoque tres veces. Cada respuesta cambia la estructura, pero no el problema de fondo. ¿Qué haces?

• A · Dejar que siga. Superar los fallos forma parte de la curva de aprendizaje. 45 minutos no son suficientes para considerarlo atascado.
• B · Intervenir y evaluar el alcance. Tres intentos con el mismo modo de fallo es bucle, no iteración. Averigua si la tarea en sí es el problema y luego decide.
• C · Revisar primero los datos de OTel. Revisa las métricas de la sesión antes de tomar una decisión. Necesitas más señal que una sola observación.
• D · Pedir al champion del cliente que se encargue. Acompañar a los desarrolladores en la curva de aprendizaje es el rol del champion, no el tuyo en el Día 8.

Ver respuesta

B es la respuesta correcta: primero evalúa y después decide. La distinción que importa aquí es iterar frente a hacer bucle. Tres intentos con el mismo fallo estructural y sin una variación significativa en el enfoque es bucle. Esa es la señal para intervenir. Pero “intervenir” significa evaluar, no corregir. ¿La tarea en sí está fuera de lo que Claude Code maneja bien en esta etapa? ¿Le falta algo al CLAUDE.md que ayudaría a Claude a entender el código base? Averigua eso antes de hacer cualquier otra cosa. La opción C no es errónea en principio, pero los datos de OTel no te dirán qué ocurre en esta sesión concreta. Eso requiere una conversación.

Ideas clave

Los datos ya estaban ahí. Ahora sabes qué hacer con ellos.

• Generación de tests en modo bash: entra el archivo fuente, salen los tests y la revisión se hace con la salida Default.
• Las cuatro métricas del scorecard son DAU, sesiones por usuario, retención de la semana 2 y costo por desarrollador.
• Iterar no es lo mismo que hacer bucle: en el primer caso se espera; en el segundo, se evalúa el alcance antes de intervenir.
• Antes de corregir, evalúa si la tarea está fuera de lo que Claude Code maneja bien en esta etapa y si el CLAUDE.md necesita más contexto.

Para el Día 14, el equipo pide automatizar lo que hace de forma interactiva. La lección 9.3 cubre el pipeline headless, la autenticación en CI y la configuración del proxy, que sorprende a la mayoría de los equipos.

Siguiente: Integración de CI/CD mediante GitHub Actions