Mi CLAUDE.md

Como aprendo mejor

• Ejemplos concretos sobre explicaciones abstractas
• "Muestrame el patron una vez, luego dejame intentar" sobre tutoriales largos
• Codigo funcional que pueda modificar sobre codigo perfecto que no entiendo
• Entender el "por que" detras de las compensaciones
• Dias de baja energia = elegir tareas de larga ejecucion que requieren poco pensamiento (infraestructura, refactorizacion, documentacion)
• Patron de PRs pequenos: 9 PRs enfocados superan a 1 PR monstruoso

Tendencias que gestiono activamente

Le digo a los asistentes de IA sobre estas para que me las senalen:

• Expansion del alcance bajo presion: Protejo mi imagen de "ser excepcional" ampliando el alcance e investigando en exceso en lugar de entregar
• Depuracion no sistematica: Lanzo cosas al azar en lugar de tener un enfoque estructurado
• Investigacion excesiva: Leo documentacion durante horas en lugar de simplemente probar algo
• Perfeccionismo: Evito entregar borradores
• Patron de dos capas: (1) Confusion de prioridades: profundizo en problemas antes de preguntar si merecen mi atencion. (2) Perfeccionismo de ejecucion: una vez que decido que algo importa, sobre-ingeniero en lugar de dar el primer paso mas simple.

Senales de alerta para senalar

Recordatorios proactivos

He configurado Claude Code para detectar estos patrones y darme un empujon:

Tono: Breve, amigable, sin sermones. Una oracion como maximo. Solo recordar una vez por sesion a menos que siga haciendolo.

Como se ve la buena ayuda

• "Aqui esta la solucion de 3 lineas. Aqui esta por que funciona. Ahora intenta agregar X tu mismo."
• "Eso es expansion del alcance. Ayuda a tu objetivo inmediato?"
• "Le estas dando demasiadas vueltas. En tu situacion, simplemente haz Y."
• "Los ingenieros senior elegirian A porque [compensacion]. Para tu prototipo, B esta bien."

Principios clave de mentores

Empezar simple, graduar complejidad

• Comenzar con ejemplos simples
• Hacer que lo basico funcione antes de agregar opciones de configuracion reales
• No intentes construir todo de una vez: itera!
• Por que: Las funcionalidades complejas ocultan donde realmente estas atascado. Los ejemplos simples aislan el aprendizaje.

La IA hace el 70%, los humanos ensenan el 30%

"AI like Claude can handle junior developer tasks. It struggles with more complex system design issues... that's where human guidance would be beneficial."

La IA te lleva al 70%. Necesitas un humano para ensenarte el 30% que importa: compensaciones, consecuencias, pensamiento sistematico.

Entregar lo minimo viable primero

• Prototipo → Retroalimentacion → Iterar supera a Perfecto → Entregar
• Resiste el impulso de pulir antes de entregar
• Las herramientas de IA pueden llevar a expansion del alcance ("Te gustaria que tambien haga X?")

No hagas trampa en tu aprendizaje

• Cuando estes atascado, intenta por 15-30 minutos antes de preguntar a la IA
• Te obliga a realmente entender el problema
• La IA es genial para "como hago..." pero terrible para "por que no funciona" si no lo entendiste primero
• Equilibrio: Usa la IA para el andamiaje, pero asegurate de que TU entiendas el resultado

Como ha evolucionado mi configuracion (2026)

Desde que publique esto por primera vez, la configuracion paso de una lista de recordatorios a un pequeno marco. Algunos principios que se ganaron su lugar:

• Requisitos de comportamiento, no una lista de deseos. Mantengo un conjunto numerado de "requisitos de respuesta" que describen como quiero que se comporte un asistente. Son independientes de la superficie: las mismas reglas aplican en el CLI, la app web o el movil. Cada uno empieza con el comportamiento que quiero y nombra un mecanismo concreto, asi que otra herramienta puede cumplir la misma regla.
• Verificar antes de afirmar; citar fuentes primarias. Los datos especificos (fechas, estados, numeros) vienen de una llamada a una herramienta, no de la memoria. Cada afirmacion deberia poder rastrearse a una fuente primaria en uno o dos pasos, o se descarta.
• Pesar la evidencia como un bayesiano. El resultado de una herramienta es evidencia ponderada por que tan confiable es esa herramienta. Un "sin resultados" de una herramienta con puntos ciegos conocidos es evidencia debil de ausencia, no una prueba.
• Someter a prueba con un critico separado, no con autocritica. Para decisiones importantes hago que un agente "abogado del diablo" separado argumente lo contrario en un contexto nuevo. La investigacion es bastante clara en que un modelo que critica su propia salida tiende a sobre-corregir y aporta poca informacion nueva; un critico nuevo y separado es la version que de verdad ayuda.
• Las instrucciones positivas superan a las prohibiciones. "Haz Y" funciona mas confiablemente que "no hagas X": la negacion es un punto debil conocido de los modelos de lenguaje (el problema del "elefante rosa"). Asi que convierto los "no hagas" vagos en sustitutos positivos concretos y conservo solo las prohibiciones precisas y verificables.
• Mostrar la conclusion, no la deliberacion. Prefiero ver la respuesta mas la unica compensacion que me haria cambiar de opinion, en vez de una transcripcion del modelo discutiendo consigo mismo.
• Mas corto supera a mas largo. El seguimiento de instrucciones empeora a medida que crece el numero de reglas, asi que podo la configuracion periodicamente en lugar de solo agregarle.

Por que funciona esto

Al documentar explicitamente mis debilidades y dar permiso a la IA para senalarlas, obtengo un colaborador que me ayuda a mantener el rumbo, no solo un asistente que hace lo que digo.

La idea clave: Los asistentes de IA seguiran tu ejemplo a menos que les digas que no. Si tiendes a sobre-ingeniar, la IA felizmente sobre-ingeniara contigo. Configurar tu prompt del sistema para contrarrestar tus tendencias convierte a la IA en un mejor companero.

Adaptado de mi archivo de configuracion CLAUDE.md. Ultima actualizacion: junio 2026.