Un speech escrito por slide, para tener abierto en otra pantalla/pestaña mientras avanzás index.html. No hace falta leerlo textual — es para referenciar si te trabás o para no olvidarte un punto.
~0.5 min
Buenas a todos. La idea de los próximos 30 minutos es simple: salir de acá con un solo estándar de cómo usamos Claude Code en el equipo — no con una lista de tips sueltos que cada uno interpreta distinto. Al final hacemos un quiz en vivo de 29 preguntas que también nos sirve de registro de asistencia, así que quédense atentos incluso en las partes que les suenen obvias.
~1.5 min
Esta es la regla más importante de toda la charla, así que la digo clara: todo el desarrollo se hace en Claude Code CLI. No en el chat web, no en la app de escritorio, no en la extensión del IDE. Miren la tabla: el chat web no tiene ninguna de estas columnas. La app de escritorio y la extensión del IDE tienen el triángulo amarillo en casi todo — y eso no significa "anda un poco distinto", significa que directamente no corren hooks y no aplican toda la jerarquía de CLAUDE.md. Si desarrollás ahí, te estás perdiendo la mitad del estándar sin darte cuenta. El chat web tiene su lugar: preguntas generales, borradores, pensar en voz alta — pero nunca tocar código del repo.
~1 min
¿Por qué nos tomamos el trabajo de estandarizar esto? Tres riesgos concretos: perder contexto porque no hay repo ni CLAUDE.md a mano, hacer cambios sin red de contención porque no corrimos tests antes y después, y perder conocimiento porque cada sesión arranca de cero. Pero hay algo más de fondo, y quiero que se lo lleven: esto no es solo para evitar errores. Es para que todos sigamos el mismo set de reglas, y que el trabajo del equipo cumpla con un estándar de calidad y de explicabilidad — que cualquiera de nosotros pueda mirar lo que hizo otro y entender por qué se hizo así.
~1.5 min
El primer comando que corremos en un repo nuevo es /init. Genera el CLAUDE.md del proyecto explorando el código: detecta el stack, los comandos de build y test, la estructura. Eso se commitea al repo, como cualquier otro archivo — no es una nota personal, es documentación viva para todo el equipo. Ahí tienen el CLAUDE.md real de este mismo proyecto, para que vean que no es texto genérico: dice explícitamente que se usa pnpm y no npm, que hay que correr los tests antes de tocar el servidor, y qué archivos no se versionan.
~2.5 min
Acá es donde la gente se confunde, así que vamos despacio. Hay un CLAUDE.md de usuario, en ~/.claude/CLAUDE.md, que aplica a TODOS tus proyectos: ahí van tus reglas personales, cómo querés que te conteste Claude, tus hábitos. Y hay un CLAUDE.md de proyecto, el ./CLAUDE.md de cada repo, que es información sobre ESE repo puntual — se commitea, es para todo el equipo. Existe un tercer nivel, CLAUDE.local.md, pero no lo usamos hoy, así que ni me voy a detener en él. Lo que sí quiero que vean es el template de CLAUDE.md de usuario: noten que no hay ni una credencial ahí adentro. Esa es una regla dura: nunca credenciales en CLAUDE.md.
~2.5 min
Esto es lo más importante técnicamente de toda la charla. Un CLAUDE.md es una petición — Claude puede, bajo presión de contexto, terminar ignorándola. Un hook es distinto: es código que se ejecuta sí o sí, pase lo que pase. Yo tengo dos configurados. log_conversation.py guarda cada conversación en un .log — así queda registro de todo. snapshot_html.py copia cualquier .html a una carpeta temp_old/ antes de editarlo — así nunca perdés una versión anterior por accidente. Hagan click en cada fila si quieren ver el código real, son scripts de Python cortos, nada mágico.
~2 min
Antes de tocar código en cambios grandes, usamos el modo plan. Se activa con Shift+Tab o escribiendo /plan. Lo que hace es explorar el repo, hacerte preguntas, armar un plan y esperar tu aprobación — no toca NINGÚN archivo hasta que vos decís que sí. Es obligatorio en cambios que tocan varios archivos, features nuevas, o cualquier cosa riesgosa. Este extracto que ven es del plan real que armamos para esta misma charla — así fue como se construyó todo lo que están viendo hoy.
~1 min
Tres palabras que van a escuchar todo el tiempo y que conviene tener claras. Un plugin es un paquete instalable que trae adentro skills, agentes y comandos — claude-mem, superpowers e impeccable son plugins. Una skill es una habilidad puntual que Claude activa cuando la tarea la necesita — find-skills, task-observer y graphify son skills. Y MCP conecta Claude con sistemas externos: Jira, una base de datos, Google Drive.
~4 min
Esta es la lista de instalación. Cinco son obligatorias para todo el equipo: claude-mem te da memoria entre sesiones, superpowers te guía en brainstorming y TDD, impeccable audita y diseña interfaces, task-observer hace seguimiento de tareas en curso, y find-skills te deja buscar e instalar skills de la comunidad. La única opcional es graphify, que convierte cualquier input en un grafo de conocimiento — instálenla si les sirve, pero no es parte del estándar mínimo. Después, por rol: Ansible para infra, los generadores de documentos para quien los necesite, y los comandos de revisión — code-review, security-review, simplify — que están disponibles para todos.
~2 min
Quiero que quede clarísimo para qué sirve esto, porque no es un checklist genérico. Es para hacer QA manual después de que Claude hizo un cambio: le pedís un ítem por cada cosa que tocó, y después vos revalidás una por una, a mano, para no confiarte y no dejar nada sin mirar. Es ideal cuando trabajás en frontend — un ítem por pantalla o componente que cambió — pero aplica exactamente igual en backend, un ítem por endpoint o caso de uso afectado. Y la parte técnica: no hace falta backend ni base de datos, el navegador se acuerda de lo que tildaste en localStorage aunque recargues la página. Vamos a la demo en vivo: abro qa-checklist.html, tildo un par de cosas, recargo la página... y siguen tildadas.
~2.5 min
Regla no negociable: antes de tocar código, corremos los tests y guardamos ese resultado como baseline. Hacemos el cambio. Corremos los tests de nuevo y comparamos. Si algo que pasaba antes ahora falla, es una regresión — se para y se investiga, nunca se edita el test para que vuelva a pasar. Dos ejemplos reales, no de juguete. El primero es test_documentacion.py en 824-golang-api: se loguea como cada usuario real del sistema y compara qué ve antes y después de tocar un endpoint; el reporte te dice por usuario exactamente qué cambió. El segundo es distinto: en COMEX, cuando el cambio es en una vista de base de datos con lógica de negocio pesada, no podés comparar a ojo — son cientos de miles de filas. Ahí se comparan tres versiones de esa vista al mismo tiempo — la de producción, la anterior, y la que se va a promover — cruzadas por sus columnas clave, y el reporte HTML te muestra solo las filas donde las tres no coinciden. Mismo principio en los dos casos: no confiar en "me parece que anda", verificar cada diferencia antes de dar por bueno el cambio. Miren la demo en vivo: threeway-demo.html — mismo mecanismo, pero con datos 100% inventados, porque el caso real tiene datos de cliente que no corresponde mostrar en una pantalla compartida.
~1 min
Repasemos los siete puntos. Uno: desarrollo solo en la CLI. Dos: /init genera el CLAUDE.md del proyecto. Tres: CLAUDE.md de usuario son reglas para Claude, CLAUDE.md de proyecto es información del repo, y nunca credenciales en ninguno de los dos. Cuatro: los hooks garantizan lo que CLAUDE.md solo pide. Cinco: modo plan para cambios grandes o riesgosos. Seis: claude-mem, superpowers, impeccable, task-observer y find-skills son obligatorias, graphify es opcional. Siete: tests antes y después de cada cambio.
~0.5 min
Hasta acá, IA. Lo que sigue no tiene nada que ver con Claude: es sobre calidad al servir productos de software. Aplica a cualquier cosa que entreguemos — un programa, una web, un reporte — la hayamos hecho con IA o sin ella. La pregunta es simple: ¿qué hace que el cliente quede conforme, y dónde se nos pierde la calidad en el camino?
~2 min
Pensemos en un café. El beneficio sustancial es el café en sí: la razón por la que entraste. Si está malo, no hay nada que lo salve. El formal es cómo te lo dan: taza limpia, que acepten tarjeta, el ticket, pedirlo por app sin hacer fila. No cambia el sabor, pero cambia la experiencia. Y el añadido es lo que no esperabas: el corazón de espuma, la galletita, el Wi-Fi. En software es igual. Sustancial: el core del sistema, las funcionalidades, las pantallas, que sea útil. Formal: la presentación, UI, UX, performance, manuales, videotutoriales, documentación. Añadido: las features extra que el usuario no esperaba, los detalles que suman. Si falla lo sustancial, lo demás no importa; pero si solo entregamos lo sustancial, el cliente percibe un servicio pobre.
~3.5 min
Este ciclo arranca y termina en lo mismo: lo que el cliente espera. En el medio hay seis etapas: lo que el cliente tiene en mente, lo que nosotros entendemos que quiere, nuestras normas de calidad internas, el resultado formal del desarrollo, lo que le logramos comunicar con claridad, y lo que finalmente percibe. Entre cada etapa hay un gap, un lugar donde se pierde calidad. Voy haciendo click en cada uno. Gap 2: lo que ya sabemos que hay que hacer contra nuestros estándares de desarrollo y diseño. Gap 3: básicamente QA y tests. Gap 4: documentación simplificada — funcionalidades, videotutoriales, limitaciones técnicas, el ciclo end to end de cada entidad — y un manual APB, apto para boludos. Gap 5: UX, UI, diseño y performance, multiplicado por documentación más producto. Gap 6 no debería existir si cerramos los anteriores. Y dejo para el final el Gap 1, que es el que importa.
~2 min
El 80% de los quilombos de calidad están acá: entre lo que el cliente tiene en mente y lo que nosotros entendemos que quiere. Y se cierra antes de escribir código, iterando: mostrar una demo, una maqueta, un canvas, un diagrama que se entienda en dos minutos, y ajustar hasta que haya consenso. Ojo: documentación no es lo mismo que consenso. La doc. de ZYSS de Isa, por ejemplo, no cumple para cerrar este gap, porque es extensa y necesita cráneo — el cliente no la va a leer con el detalle que hace falta para detectar que entendimos mal. La tabla de abajo es el resumen para llevarse; el quiz pregunta sobre esto.
~2 min
Ayer sumamos detección de secretos a nivel git en esta clase. Dos capas: un hook pre-commit local que corre en la máquina de cada uno, y un pre-receive del lado del servidor GitLab que revisa igual aunque el commit local haya pasado. Por qué las dos: GitLab CE, la versión que usamos, no tiene secret push protection nativo — eso es Premium/Ultimate — así que lo armamos nosotros con hooks. El pre-commit mira el diff staged línea por línea buscando patrones de alta señal: claves privadas, tokens de GitLab (glpat-/glrt-), claves de AWS (AKIA/ASIA), tokens de Slack, connection strings de DB con user y contraseña adentro, y archivos .env con valores reales en vez de placeholders. Todo esto vive en secret-patterns.sh, compartido entre el hook local y el del servidor, así no duplicamos la lógica.
~2 min
El pre-receive del servidor se puede saltear con git push -o secret-override=bypass, y hay que ser muy cuidadosos con eso. Primero, lo obvio: es seguridad — el chequeo existe para frenar un secreto real antes de que llegue al remoto que comparte todo el equipo, no es un trámite. Pero además hay un costo operativo grande si el secreto ya quedó pisado en el historial: la única forma correcta de sacarlo no es un commit que lo borre, es reescribir el historial completo, con filter-repo o similar, y forzar el push. Y un force-push sobre un historial reescrito deja desincronizado el clone de cada persona del equipo — no alcanza con un pull, cada uno tiene que resetear o volver a clonar, coordinado, para no terminar mezclando historiales viejos y nuevos. Esto no es teórico: es literalmente lo que pasó el lunes-martes con zyss-web-backend, un secreto viejo reapareció por un merge de un clone desactualizado, y arreglarlo bien nos tomó bastante más de lo que hubiera costado evitarlo de entrada. Por eso el bypass es para casos puntuales y justificados, no un hábito.
~0.5 min
Y ahora el quiz. Son 30 preguntas — las últimas sobre calidad de servicio y sobre los hooks de git que acabamos de ver — 20 segundos cada una, en formato Kahoot. Entren a play.html y elijan su nombre de la lista — esto también nos sirve como registro de asistencia. Yo manejo todo desde la pantalla de presentador. ¿Preguntas antes de arrancar?
← Volver al deck · pantalla de presentador