Esta semana el post es un video porque hay cosas que se entienden mejor viéndolas que leyéndolas.
Les voy a mostrar exactamente cómo trabajo con Claude Code y mis sub-agentes y comandos. No un tutorial de “cómo instalar” — eso ya lo vieron. Esto es el workflow real que uso todos los días para mantener cinco proyectos mientras tengo un trabajo de tiempo completo.
El problema (y por qué importa)
Mi sitio personal (soyserg.io) tenía un bug pequeño: la fecha de “last updated” se estaba generando en el cliente (cada vez que alguien visitaba el sitio) en lugar de mostrar cuándo realmente lo actualicé.
¿Es urgente? No. ¿Lo hubiera dejado así por meses si tuviera que arreglarlo manualmente? Probablemente sí.
Pero con mi workflow actual, tardé 30 minutos desde identificar el problema hasta tenerlo en producción. Y esos 30 minutos fueron en paralelo — yo grabando para explicarles, Claude Code haciendo el trabajo real.
Lo que van a ver en el video
Mi proceso completo de desarrollo:
Crear el issue — con el comando
/create-github-issue, Claude investiga el repo, identifica el problema, y documenta todo en GitHubImplementar la solución — con
/solve-github-issue, crea un feature branch, hace los cambios, ejecuta tests, y publica la pull requestCode review — con
/review-pull-request, un agente separado revisa el código como si fuera otra persona del equipoMerge a producción — Claude resuelve los comentarios de la review y hace merge
Todo documentado. Todo con el mismo flujo que usaría un equipo profesional.
La parte que nadie te cuenta
“Sergio, gastaste 30 minutos en algo que pudiste haber arreglado en 3.”
Sí. Si yo supiera TypeScript bien. Si recordara dónde está cada cosa. Si no tuviera que verificar que no rompí nada más.
Pero aquí está lo que realmente pasó: esos 30 minutos no fueron míos. Yo estaba explicándoles a ustedes, pero en un día normal estaría en una junta o escribiendo o pensando en otra cosa completamente diferente.
Claude Code trabaja en paralelo. Mientras tanto, yo hago lo que solo yo puedo hacer — decidir qué construir, no cómo construirlo.
Y lo más importante: ahora existe documentación completa de por qué cambié esto, cómo lo cambié, y quién (qué agente) lo revisó. En seis meses cuando regrese a este código, no voy a tener que adivinar qué estaba pensando.
El flujo que escala
Este ejemplo es simple — un cambio de una línea. Pero el mismo proceso funciona para features completas. La diferencia entre “arreglar una fecha” y “agregar autenticación OAuth” no está en el workflow — está en cuánto contexto necesita Claude para resolverlo.
Los pasos son idénticos:
Issue que documenta el problema
Branch dedicado para no romper producción
Review de código antes de merge
Documentación automática del proceso
Cambios pequeños toman 30 minutos. Cambios grandes toman 30 minutos. Porque el tiempo no se gasta escribiendo código — se gasta supervisando que el código haga lo correcto.
Para qué me sirve esto
No soy experto en TypeScript. No soy experto en Next.js. Pero mantengo un sitio en Next.js + TypeScript porque tengo un equipo que sí sabe.
Ese equipo es Claude Code y mis comandos. Cada uno especializado:
Uno crea issues bien estructurados
Otro implementa soluciones
Otro hace code review
Otro me ayuda con investigación profunda
Y todos trabajan con el mismo contexto — los archivos markdown en mi repo que explican qué me importa, cómo quiero que se vea el código, qué filosofía sigue el proyecto.
No estoy reemplazando mi criterio. Lo estoy amplificando.
Ve el video
Es largo (30 minutos) pero es real. No edité los errores. No aceleré las partes lentas. Así es como trabajo todos los días.
Si después del video tienes preguntas sobre cómo configurar tus propios comandos o sub-agentes, respóndeme. Estoy considerando hacer un deep-dive sobre cómo estructurar los archivos de contexto que hacen que todo esto funcione.
Hasta la próxima — y si estás experimentando con workflows similares, cuéntame. Me encanta ver cómo otros están orquestando sus equipos de IA.
