Mi Workflow con IA: Skills, Agentes y un Segundo Cerebro

Déjame adivinar cómo usas la IA en tu día a día. Abres un chat, pegas un trozo de código, pides una función y copias el resultado. Funciona, ¿no? Te destraba el momento y sigues.

El problema es que eso no es un workflow. Es un truco. Y yo estuve atrapado en ese truco por un buen tiempo hasta que me cayó la ficha de algo: la ganancia de verdad no está en el prompt ingenioso. Está en la estructura a su alrededor.

Este es el workflow que armé en TryTech después de más de un año aprendiendo a los golpes, y no inventé nada de cero acá. Fui juntando ideas de workflows que vi usar a colegas, quedándome con lo que me funcionaba y descartando el resto, hasta que se volvió este setup. Son tres piezas: un contrato escrito, skills que se vuelven un pipeline, y una memoria externa que no muere cuando se cierra la sesión.

El contrato: CLAUDE.md

Empieza con un archivo de texto, así de simple. Claude Code lee un CLAUDE.md global cada vez que arranca, y el mío es básicamente un contrato de ingeniería. Minimalismo implacable (el mejor código es el que no escribes), commits pequeños y en imperativo, validación solo en el borde del sistema, y la regla de oro del TDD científico, a la que ya llego.

¿Sabes qué resuelve esto? Dejo de repetir instrucciones. La IA ya llega sabiendo que prefiero borrar antes que agregar, que la duplicación la tolero hasta la tercera vez, y que las preguntas se hacen todas de una, no de a gotas.

Piénsalo: si usas IA todos los días y todavía escribes “no pongas comentarios obvios” cada santa semana, estás pagando un peaje al pedo. Escríbelo una vez, en un archivo que la herramienta siempre lee, y listo.

Skills: workflows con nombre

El corazón del setup son las skills. En Claude Code funcionan como comandos que cargan un workflow entero. En vez de explicar el proceso de nuevo cada vez, llamo al proceso por su nombre. Las que más uso forman un ciclo cerrado de desarrollo:

• /po se pone el sombrero de Product Owner: explora el codebase, hace las preguntas correctas y escribe un PRD enfocado en requisitos de producto, no en solución técnica.
• /dev toma ese PRD (o un issue, o un prompt suelto) y lo implementa en TDD estricto, en tres modos: par de agentes (uno conduce, el otro navega y fiscaliza), solo, o pareando conmigo en el teclado.
• /review suelta revisores en paralelo para seguridad, performance y calidad, y encima tira un auditor red team que revisa a los revisores, buscando falsos positivos y severidad inflada.
• /qa actúa como un segundo dev: levanta la app, prueba en el navegador lo que se construyó y valida comportamiento de verdad, no solo tests verdes.
• /commit cierra todo con commits pequeños, convencionales, escritos como los escribe una persona.

Y mira, no hay magia acá. Es la vieja disciplina de proceso, solo que ejecutable. Cada skill es un markdown que describe cómo trabajaría yo si tuviera tiempo infinito. La diferencia es que ahora la IA tiene ese tiempo.

TDD científico, o: cómo no caer en el cuento de tu propia IA

Sí, sé lo que estás pensando: IA escribiendo el test y la implementación al mismo tiempo es el zorro cuidando el gallinero. Estoy de acuerdo contigo. Es justamente por eso que existen las reglas.

El mayor peligro de programar con IA no es que se equivoque. Es que se equivoque con confianza, entregándote algo lindo y roto con la cara más dura. Mi defensa es un TDD que huele a método científico: el test que falla es la hipótesis, la implementación es el experimento, y hay un paso que casi nadie hace, que es revertir la corrección después del verde solo para confirmar que el test vuelve a fallar. Si no se pone rojo de nuevo, nunca probó nada. Nunca.

Dos reglas cierran el juego. Cada paso cambia el test o el código de producción, nunca los dos a la vez, porque así uno de los lados sigue honesto. Y si el bug no se puede reproducir, la sesión para y yo asumo. Acá no se adivina.

¿Quieres un ejemplo concreto? En una sesión reciente de nuestro servidor web en C, esto se volvió hasta una receta: un stub que retorna -1 para tener un RED comportamental de verdad. ¿Por qué? Porque un test que ni siquiera compila por un header faltante es un RED demasiado débil para confiar en él.

El segundo cerebro: un vault de Obsidian

La IA tiene memoria de pez entre una sesión y la otra, y fingir que no sale caro. Mi salida fue pegar el workflow a un vault de Obsidian, con tres skills cuidándolo. /note captura una idea o un TIL en el momento en que aparece, /recap cierra cada sesión grabando lo que aprendí, lo que decidí y lo que quedó abierto, y /vault trae todo eso de vuelta cuando lo necesito.

El recap es el héroe silencioso de la historia. Cada sesión que importa termina en un archivo estructurado: contexto, lo que aprendimos con los detalles técnicos bien puestos, lo que se decidió y por qué, y los cabos sueltos. Después pasan dos semanas, vuelvo al mismo tema, y la IA no empieza de cero. Lee el recap y sigue la conversación justo donde la dejamos.

¿Sabes qué? Así nació este mismo post. Pedí una idea, y lo primero que hizo la IA fue revisar los recaps recientes del vault.

Qué cambia al final

Seamos honestos: nada de esto jubila al ingeniero, y desconfío de quien te promete lo contrario. Lo que cambia es a dónde va mi tiempo. Escribir PRDs, armar suites de tests, revisar PRs en tres frentes, documentar sesiones, todo eso se volvió proceso ejecutable. Y lo que me queda es lo que siempre fue el trabajo de verdad: decidir qué construir, pesar trade-offs y decir no a la complejidad que nadie pidió.

Si te ves usando IA todos los días con esa sensación de que siempre estás recomenzando, el consejo es uno solo. Deja de coleccionar prompts y empieza a escribir tus workflows. Un archivo a la vez.

Love to you all.