Quiero compartir mi propia forma de usar mejor Claude Code.

Problema

Cuando empiezas un proyecto con vibe coding, las primeras horas se sienten como descubrir un mundo nuevo. Lanzas un prompt, sale código, parece que algo funciona, y llega ese momento de pensar: “¿De verdad estoy construyendo esto?”.

Y entonces empiezan a aparecer los errores.

Le pides que lo arregle y se rompe otra cosa, a los 30 minutos la IA ya olvidó lo que dijo antes, y después de 1 hora yo tampoco tengo claro qué estaba construyendo. Si lo vuelves a abrir al día siguiente, estás otra vez frente a una hoja en blanco. Al final, terminas dando vueltas en el mismo lugar.

Si llevas varios proyectos al mismo tiempo, es todavía peor. Si quieres retomar el jueves lo que estabas haciendo el lunes, tienes que volver a preparar todo el contexto desde cero.

Causa

El cuello de botella no estaba en el código. Estaba en la memoria.

La IA olvida cuando se corta la sesión, y yo también olvido después de unos días. Pero como nadie deja registro, el proyecto sigue reiniciándose una y otra vez.

Método que probé

Empecé a usar Obsidian como almacén de memoria a largo plazo para el proyecto.

• Obsidian — gestión en Markdown de toda la planificación, diseño, logs de sesión y registro de errores
• Claude Desktop + MCP — cumple el rol de “director”, leyendo directamente las notas de Obsidian y discutiendo el diseño
• Claude Code + MCP — cumple el rol de “ejecutor”, implementando de verdad el trabajo una vez terminado el diseño

El problema de pérdida de contexto en Claude Desktop lo resolví registrando el traspaso entre sesiones en archivos fecha_handoff.md. Cuando abro una sesión nueva, con leer ese archivo el contexto se recupera de inmediato.

La clave fue repetir el ciclo “registro → diseño → implementación → registro”.

Resultado

Antes repetía el ciclo de empezar un proyecto de juguete y borrar la carpeta tres días después, pero desde que cambié a este método, los proyectos que antes no lograba terminar empezaron a entrar, uno por uno, en un ciclo de primera versión completada → despliegue → revisión → corrección. Ahora mismo gestiono más de 10 proyectos al mismo tiempo en un canvas de Obsidian.

Recientemente Claude Code añadió la función Auto Memory, pero eso son notas que la IA escribe para la IA, mientras que este método son registros que los humanos escriben para los humanos. Creo que ambas cosas se complementan.

Resumen

Organicé este flujo de trabajo y lo publiqué como libro en Wikidocs. El texto completo es gratuito.

“Por qué falla el vibe coding — Guía de colaboración con IA” https://wikidocs.net/book/19307

Incluye desde el prólogo hasta el Ch.22 más un apéndice, y si dejan comentarios en cada página, los incorporaré de inmediato. También serán bienvenidas las críticas directas.

[runableapp]

Uso Cursor y por eso me desconcierta cuando a veces leo casos así con Claude. He tenido problemas por baja calidad o por no especificar con precisión, pero no porque “se le olvide”; y situaciones complicadas por errores en otra parte sí me pasaron algunas veces en las primeras etapas del producto Cursor, pero ahora ya no me ocurre. ¿Será porque mi proyecto no es lo bastante grande?

Yo lo hago de esta manera:

• Escribo un documento de unas 10 a 20 líneas con la idea general, el método y, si existe, algún enfoque similar.
• Le pido que lea eso y redacte en detalle un documento con la idea, la arquitectura, las pruebas y el plan. También le digo que me haga preguntas si las tiene. (Entonces bastante seguido me pregunta eligiendo entre opciones numeradas). Y lo voy completando mientras lo discutimos. Además, hablo por separado con Gemini para investigar más y también conversamos sobre eso.
• Luego reviso el documento terminado y lo voy corrigiendo poco a poco mientras seguimos hablando, y después le ordeno que lo construya. Mientras lo hace, le digo que marque las partes completadas como terminadas y que avance actualizando ese documento. Y si es algo lo bastante grande o complejo como para llevar tiempo, le digo en las reglas de Cursor que registre en otro documento lo que hizo cada día.

Como el documento está dentro del proyecto, no hace falta gestionarlo de forma especial por separado. Y Cursor no sigue trabajando indefinidamente. Por más que le digas que llegue hasta el final, siempre se detiene a mitad de camino y te obliga a conversar (dicen que es una medida de seguridad para que no entre en un loop raro, pero me molesta no tener la posibilidad de elegir). De todos modos, eso sí ayuda. También evita que, cuando vuelves a mirar horas después, termine construyendo algo completamente fuera de lugar.

Como todo se resuelve dentro de un mismo IDE, no hace falta agregar otros servicios. De Claude solo he usado la función de LLM por API, así que no sé qué tal sea para programar, aunque mucha gente dice que es muy bueno. Pero cuando a veces veo publicaciones sobre que “se le olvida” o que da errores, también pienso que quizá es porque mi proyecto es pequeño...

En conclusión, avanzo igual que cuando en una empresa se gestionan proyectos y equipos: documentación y registros, conversación, decisiones... exactamente el mismo modo de trabajo que con personas; no es un workflow nuevo. Por eso me da mucha curiosidad qué workflow usan quienes dicen que lo hicieron de forma “totalmente automática” con Claude, y aunque no sea completamente automático, también me pregunto cómo reducir la frecuencia de esas “reuniones” (igual que con equipos humanos también intentamos reducir las reuniones frecuentes).

[pari0130]

Si usas algo llamado qmd, te administra localmente una base de datos para gestionar las sesiones anteriores.

[sharpscar]

Gracias por la buena información.