Cargando la bóveda…
Cargando la bóveda…
Ultra Think + Plan Mode, sub-agentes en paralelo, /init para CLAUDE.md, y personalización del CLAUDE.md para que Claude verifique su trabajo y guarde memoria. Los 4 que de verdad cambian cómo trabajás. Sin trucos de pacotilla.
Hay listas de "20 trucos para Claude Code" que mezclan cosas obvias con tips marginales. Acá las 4 que realmente mueven la aguja:
/init bien usado — el CLAUDE.md que cambia todoSi no usás ninguna de estas, tu Claude está al 40% de su capacidad real.
Ultra Think es pedirle explícitamente a Claude que "piense más" antes de responder. La palabra-trigger ultrathink (o variantes como think hard) hace que use extended thinking — invierte más tokens en razonar antes de generar la respuesta.
Plan Mode es un modo dentro de Claude Code donde Claude propone un plan antes de ejecutar nada. Te muestra el plan, vos lo aprobás o ajustás, después ejecuta.
Para tareas complejas, el combo gana:
> ultrathink
Necesito refactorizar el módulo de auth de Supabase Auth a Clerk.
Hay ~12 archivos involucrados y la app tiene 8 endpoints autenticados.
Antes de tocar nada, entrá en Plan Mode y proponé el plan completo:
- Qué archivos vas a tocar y en qué orden
- Cómo manejás la migración de usuarios existentes
- Cómo evitás romper la app durante el cambio
- Tests que vas a actualizarClaude:
ultrathink)La diferencia: sin esto, Claude tira código y vos descubrís problemas a mitad de camino. Con esto, los problemas aparecen en la fase de plan donde son baratos de arreglar.
Cuándo NO: tareas chicas obvias. Activar ultrathink para "renombrame esta variable" es overkill.
En lugar de pedirle a Claude que haga una tarea grande secuencial, descomponela en sub-tareas independientes y delegalas a sub-agentes que corren en paralelo.
> Necesito que investigues 3 cosas para una decisión de arquitectura.
Lanzá 3 sub-agentes en paralelo:
Sub-agente 1: investigá las pros/cons de usar Postgres como vector DB
Sub-agente 2: investigá las pros/cons de pgvector vs Pinecone vs Weaviate
Sub-agente 3: investigá qué empresas similares a la nuestra usan cada opción
Cuando terminen los 3, sintetizá las conclusiones en una recomendación.Claude lanza los 3, cada uno trabaja independientemente, los resultados llegan en paralelo, después la síntesis.
Para tareas con investigación distribuida, el speedup es real (típicamente 3-5×).
Cuándo NO: tareas con dependencia secuencial. Si B necesita el output de A, ponerlos en paralelo no aporta.
Más sobre sub-agentes en paralelo en múltiples Claude Code en paralelo.
/init bien usado#/init es el comando que genera tu CLAUDE.md analizando el codebase. El 80% de la gente lo corre una vez al principio y nunca más. Eso desperdicia el truco.
> /initGenera el CLAUDE.md inicial. Pero ahora la parte importante: leelo. Editalo. Agregale lo que no sabe:
npm run dev, scripts custom)/init no es solo para el primer día. Cuando:
Volvé a correr /init (o pedile a Claude que actualice el CLAUDE.md específicamente). El archivo viejo puede tener info obsoleta que confunde.
Si solo querés que mire una parte del proyecto:
> /init src/lib/payments/Te genera contexto específico de ese módulo. Útil cuando el proyecto es enorme y necesitás focus.
Regla práctica: si Claude puede leerlo del código en 30 segundos, no va al CLAUDE.md. Si requiere contexto histórico que no está en el código, sí va.
En tu CLAUDE.md, agregale al final:
## Comportamiento esperado
- Después de hacer cualquier cambio significativo, ejecutá los tests
relevantes y mostrame el output. NO declares "listo" sin verificar.
- Mantené notas de aprendizajes importantes en docs/learnings.md.
Cuando descubras algo no obvio del proyecto, agregalo ahí antes de
terminar la sesión.Esas dos líneas hacen 2 cosas:
Sin esto: Claude implementa algo, dice "listo", vos descubrís que rompió tests. Con esto: Claude implementa, corre tests él mismo, te muestra que pasan antes de declarar listo.
Es la diferencia entre "dev junior que pide review pesado" y "dev senior que valida antes de pedir review".
Sin esto: cada sesión nueva arranca de cero, perdés aprendizajes acumulados ("ah, no me había dado cuenta que el endpoint X tira 500 si no le pasás header Y"). Con esto: Claude va anotando en docs/learnings.md cada vez que descubre algo no obvio.
3 meses después, ese archivo tiene el conocimiento operativo real del proyecto acumulado. Vale oro.
- Antes de proponer un cambio mayor, validar contra docs/decisions.md
por si la decisión ya se tomó (en cualquier dirección).
- Si vas a tomar una decisión nueva (eligiendo entre 2+ opciones),
documentala en docs/decisions/<fecha>-<topic>.md con: opciones
evaluadas, criterios, decisión, razones.- Para tareas mecánicas (renombrar, formatear), usá modelo Haiku.
- Para razonamiento, Sonnet.
- Opus solo para decisiones de arquitectura.
- Si dudás del modelo, preguntame.- Después de cambios en código de hot path, correr el benchmark
(npm run bench) y comparar contra baseline. Reportar regression
si latencia sube >10%.El verdadero ROI viene de combinarlos:
1. /init bien armado con CLAUDE.md customizado (truco 3+4)
2. Para tareas grandes: ultrathink + plan mode (truco 1)
3. Investigaciones complejas: sub-agentes en paralelo (truco 2)
4. CLAUDE.md guarda aprendizajes que ayudan a las próximas sesionesNo es magia — es disciplina. Tu Claude opera 2-3× mejor solo por seguir estos 4.
Muchas listas de "trucos" incluyen cosas como:
Esos pertenecían a la era de los modelos chicos. Los 4 que sí incluí están en cualquier flow de Claude Code maduro.