El mapa que no tuve
Llevo 6 meses construyendo con Claude Code casi todos los días. Si tuviera que volver a empezar hoy, con cabeza limpia y sin la inercia de las decisiones pasadas, hay 6 forks donde lo haría distinto · y otros donde haría exactamente lo mismo.
Esto no es "los 6 secretos que nadie te cuenta". Es lo que escribiría en un Post-it y pegaría al monitor de mi yo de hace 6 meses · sabiendo lo que sé ahora.
Lo escribo en alejoxtd.com porque es primera persona. Si quieres la versión arquitectónica · sin cronología · refinada para que cualquiera la implemente · vive en deviam.es/biblioteca.
Fork 1 · Claude Code o Cursor
Probé los dos. Cursor es excelente para autocomplete y refactor in-line. Claude Code es un agente CLI que ejecuta tools · no un autocomplete · no una extensión.
Las dos cosas conviven. Mi yo de hace 6 meses pensaba que tenía que elegir una. Hoy sé que se usan juntas: Cursor cuando edito código a mano · Claude Code cuando le delego tareas que tocan archivos · git · APIs · build.
Decidiría igual hoy: Claude Code como agente principal. Cursor opcional cuando me apetece editar a la vieja usanza.
Fork 2 · Pro $20 o Max $200
Empecé en Pro porque "ya veré si me hace falta más". Acabé migrando a Max cuando los rate limits empezaron a frenar las sesiones largas. La migración fue tarde · podría haber empezado en Max.
Cambiaría: empezar en Max desde el día 1 si la intención real es trabajar 4-6 horas/día con Claude Code. Si solo es para experimentar fines de semana · Pro suficiente.
Honest detail: no es "Max es mejor". Es "el plan que no te frene en la sesión donde estás concentrado vale más que los €180 de diferencia".
Fork 3 · Skills custom o oficiales
Aquí me equivoqué de pleno. Mi instinto fue escribir skills custom desde el primer mes. Pasé semanas afinando cosas que ya existían en el catálogo oficial.
"Skills are instruction files. They cannot run code on their own — but they can instruct the agent to run code using its existing tools." — docs.claude.com/en/skills
Cambiaría: oficial-first. Buscar en el catálogo. Probar 2-3 skills oficiales que se acerquen. Solo escribir custom cuando hay razón concreta · no por defecto. La regla que firmé después de la lección: 4 capas de búsqueda (skills oficiales · MCPs · code propio · CLI) antes de plantear una skill custom.
Fork 4 · MCPs primero o CLI primero
Otro fork donde gasté tokens de más. Empecé conectando MCPs a casi todo (Supabase · Notion · Calendar · Gmail · GitHub). Funcionaba · pero cada llamada MCP carga su esquema en context.
Hoy empezaría con CLI directo (gh, supabase, vercel, git) y solo subiría a MCP cuando la integración requiere protocolo o el flujo lo justifica.
Decidiría distinto: MCP de USB-C analogy de los docs es real (Think of MCP like a USB-C port for AI applications — modelcontextprotocol.io) · pero no enchufes todos los puertos el primer día · solo el que vas a usar esa semana.
Fork 5 · Memoria · CLAUDE.md o auto memory o las dos
Aquí pensé que tenía que elegir. No tenía que elegir. Son dos mecanismos complementarios documentados:
"Each Claude Code session begins with a fresh context window. Two mechanisms carry knowledge across sessions: CLAUDE.md files... Auto memory..." — docs.claude.com/en/memory
CLAUDE.md = lo que escribes tú · 200 líneas máximo · reglas universales del proyecto. Auto memory = lo que Claude decide guardar entre sesiones.
"Claude doesn't save something every session. It decides what's worth remembering based on whether the information would be useful in a future conversation." — docs.claude.com/en/memory
Decidiría igual: las dos. CLAUDE.md desde el primer commit. Auto memory activo (autoMemoryEnabled en project settings · default on) · revisada periódicamente con /memory.
Fork 6 · Empezar con un agente o con Junta
Mi instinto inicial fue "construyo 6 agentes especializados desde el día 1". Era prematuro. Sin un flujo monolítico funcionando · no tenía señal real de qué dividir.
Cambiaría rotundo: empezar con 1 sesión de Claude Code monolítica · sin subagents. Cuando un trabajo lateral empieza a saturar el contexto · entonces subagent. La regla está en los docs:
"Use one when a side task would flood your main conversation with search results, logs, or file contents you won't reference again." — docs.claude.com/en/sub-agents
Junta (6 charters) llegó cuando ya tenía meses de uso · cuando sabía qué tareas saturaban contexto repetidamente. No al revés.
Lo que mantendría exacto
Tres cosas que firmaría sin pensarlo otra vez:
- Build in public desde el día 1. Cada decisión documentada (incluso las equivocadas como Fork 3). Sirve a futuros yo y a quien empieza igual.
- Native installer marzo 2026. Sin Node dep · auto-update ·
curl -fsSL https://...y listo. Funciona Mac · Linux · Windows. - Plan Mode antes de Auto Mode. Por defecto · que Claude proponga antes de ejecutar. Auto Mode solo cuando ya conozco el trabajo · cuando el riesgo de romper trabajo está acotado.
Lo que NO cubre esta entrada
- No cubre el setup técnico paso a paso (eso vive en deviam.es/biblioteca · entradas T1.1 y T1.2 · refinadas para implementar).
- No cubre charters Junta detallados (eso es T5.1 deviam · pattern reproducible).
- No cubre n8n · Supabase · Vercel stack productivo (eso es Tier 5 deviam).
- Es un mapa de decisiones · no una guía de instalación.
Si vienes a por la guía concreta · está en deviam.es. Esto es solo lo que pondría en el Post-it del primer día.
Recursos pre-curados (lectura natural · siguiente paso)
- deviam.es/biblioteca · concepto refinado, sin cronología, pensado para que cualquiera lo aplique en su empresa.
- docs.claude.com/en/memory · cómo funciona CLAUDE.md y auto memory · Tier 1 verbatim.
- modelcontextprotocol.io · el USB-C de los agentes · cuándo necesitas MCP de verdad.
Descargable
Estoy preparando un PDF de una página · 6 forks visualizados como mapa de decisiones · listo para imprimir y pegar al monitor. Cuando esté generado, vivirá en /diario/assets/mapa-decisiones-2026-05.pdf (link en el frontmatter de esta entrada). Si llegas antes de que esté · paciencia · build in public.