M5 · Team Enablement & Operational Productivity — Resumen de estudio
Curso 5 de 5 · 9 pantallas, 4 secciones, 3 checkpoints
Con el sistema ya construido, el foco pasa a que el equipo lo adopte bien y lo mantenga sano sin depender del Architect para todo.
Orden: configurar el entorno → elevar el flujo diario → mantener el sistema sano.
1. Team setup: 4 decisiones del Architect
a) Entorno como configuración compartida
Una línea base para todos, no setups personales:
- CLAUDE.md compartido del proyecto.
- Set acordado de tools y MCP servers.
- Postura de permisos común.
Se revisa, se versiona y se mejora una vez para todos, y así se evita la deriva entre configuraciones.
b) Rollout: champions → batches
- Un champion por departamento recibe acceso primero, prueba un flujo real, absorbe la fricción inicial y es el primer nivel de soporte.
- Después se siembra la adopción por lotes.
- Ejemplo: organización de 200 ingenieros, 4 departamentos. Cada champion tiene 2 semanas para convertir un flujo real (asistencia en code review, generación de tests) y luego da una sesión de 45 min a 5 compañeros. Un email masivo produce prompts confusos y una vuelta silenciosa a los viejos hábitos.
c) Distribución de Skills (4 mecanismos)
| Mecanismo | Mejor cuando | Gobierno y rollback |
|---|---|---|
| Org-provisioned Skill (Organization settings › Skills) | Debe llegar a toda la organización | El owner gestiona disponibilidad y retiro; los usuarios pueden desactivarlo pero no quitarlo. Sin version pinning ni rollback nativo (se re-sube a mano) |
| Plugin asignado a un grupo o a la org | Equipos específicos o un rollout gobernado | Group targeting, preferencias de instalación (required / installed by default / available / not available), actualizaciones versionadas desde un repo conectado. La opción con más gobierno |
Claude Code project Skill (.claude/skills/) | Convención o tool de un equipo en sus proyectos | Vive en el repo: se versiona y hace rollback con el repositorio |
| API Skill (Messages API container) | Productos del partner que lo llaman por código | Se gobierna en el sistema que lo llama; permite version pinning explícito |
- Los managed settings de Claude Code son otro canal: configuración que llega desde los servidores de Anthropic al autenticarse y se refresca cada hora. No es un mecanismo de distribución de Skills.
- Empaquetar un flujo como Skill convierte una buena práctica local en un estándar del equipo.
d) Postura de gasto (antes de la primera factura)
- Modelo por defecto de cada sesión.
- Allowlists y restricciones de modelos.
- Guía de effort (cuánto trabaja el modelo por tarea).
- Límites de gasto, de rate y por usuario.
Sin gestión, el trabajo se va al tier más caro, multiplicado por cada persona y cada request.
⚠️ Watch out: el Skill de release notes se repartió como paquete plano a 40 ingenieros sin actualizaciones versionadas ni rollback. Una edición rompió el formato para todos y el arreglo fue manual mientras seguía saliendo output malo. Un asset compartido sin versión ni vuelta atrás es un pasivo. Distribúyelo en un plugin gestionado por la organización y con un dueño.
Checkpoint (mecanismo + razón):
- A, procedimiento de compliance idéntico, actualizable y con rollback → Plugin org-wide.
- B, para todos, sin versionado → Org-provisioned Skill.
- C, convención de ingeniería en cada proyecto → Claude Code project Skill.
- D, varios productos lo llaman por código → API Skill.
2. Flujos de desarrollo con IA
- La IA rinde cuando vive dentro del flujo existente (editor, review, ciclo de tests), no en un chat aparte.
- Las convenciones, los estándares de review y los procedimientos se codifican en Skills y en la configuración del proyecto.
| Etapa | Dónde ayuda Claude | Disciplina de revisión necesaria |
|---|---|---|
| Escribir código | Boilerplate, tests, primera implementación desde una spec clara | Revisión de correctitud y seguridad; el autor debe entender lo generado |
| Revisar código | Resumir el diff, marcar posibles problemas, explicar código | Decide el humano; las marcas de la IA son input, no veredicto |
| Debugging | Hipótesis desde el síntoma y la traza | Verificar la hipótesis con evidencia antes de actuar |
Dos fallos recurrentes:
- Lumpy adoption: unos pocos la usan mucho y el resto casi nada → la práctica nunca se estandariza (antídoto: champions y batches).
- Estancarse en el chat básico: nunca se pasa a tool use, asistencia con conocimiento del repo ni Skills. Dar acceso no es adopción.
Diligence (competencia 4D): responsabilizarse de verificar y respaldar los outputs que se usan o comparten.
- El código generado por IA se revisa con los mismos estándares de correctitud, seguridad y mantenibilidad.
- Ojo con la erosión del juicio: aceptar código que ya no se entiende porque "se ve bien y pasa el check".
- Entregable: un verification checklist (lo define cada equipo) con 4 dimensiones. Automatiza lo que se pueda (tests de regresión, evals como gate).
Ejercicio, modelo de respuesta:
- Correctness: existen tests y pasan; el comportamiento cumple el requisito, incluidos los edge cases.
- Security: sin secretos en el código, inputs validados, least privilege en tools y llamadas externas.
- Maintainability: legible, sigue las convenciones, sin complejidad inexplicada.
- Human understanding: quien envía el cambio puede explicar qué hace y por qué, incluso con inputs no probados.
⚠️ Watch out: un cambio generado pasó review y tests, y en producción filtró datos por un input sin validar. El autor no podía explicar el código. La velocidad reemplazó a la comprensión.
3. Soporte operativo y debugging
- Traducir, no apagar incendios. El equipo trae un síntoma; el Architect lo conecta con una causa de arquitectura y le enseña el camino para la próxima vez.
| Síntoma | Causa probable | Primera acción |
|---|---|---|
| Calidad degradada gradualmente sin cambio de código | Cambio de modelo o prompt, o retrieval drift al crecer el corpus | Comparar contra el eval set; revisar qué cambió en modelo, prompt o corpus |
| Pico de latencia | El contexto creció, una tool se volvió lenta o el caché dejó de acertar | Telemetría y trazas: el span más lento, tokens por request, tool más lenta, comportamiento del caché |
| Fallos intermitentes de tools | Autorización, rate limits o un error sin manejar | Revisar auth y límites; trazar una llamada fallida de punta a punta |
| Costo sube sin cambio de uso | El tier de modelo subió o el caching empeoró | Tier por request y cache hit rate contra el modelo de presupuesto |
- Autosuficiencia:
- Runbook: caminos conocidos de síntoma → causa → acción.
- Escalation path: quién maneja qué y cuándo sale del equipo.
- Meta: que te necesiten solo para problemas nuevos.
⚠️ Watch out: dashboards en verde todo un trimestre mientras la calidad caía porque el índice no seguía el ritmo del corpus. Con la entrada del runbook ("deterioro gradual sin cambio de código → modelo, prompt o retrieval drift") lo habría resuelto un ingeniero de primera línea en una tarde.
Quiz del módulo (respuestas)
- Adopción desigual en 4 departamentos → B (champion por departamento y luego batches).
- Procedimiento idéntico y revocable desde un solo lugar → B (plugin gestionado por la organización, con versionado y rollback).
- Se coló un problema de seguridad → C (faltaba el verification checklist con dimensión de seguridad).
- El autor no sabe explicar el cambio aunque los tests pasan → B (retenerlo hasta que pueda explicarlo: el check de comprensión humana).
- Calidad baja 2 meses sin cambios de código → B (modelo, prompt o retrieval drift).
Para recordar
- Team setup = configuración compartida + estrategia de distribución de Skills + postura de gasto, decididas de antemano.
- La adopción se diseña con champions y batches; el acceso sin habilitación se estanca en el chat.
- Diligence: mismos estándares para el código generado por IA, el autor debe poder explicarlo y el checklist es un gate.
- Soporte = traducción de síntoma a causa + runbooks y rutas de escalamiento.