Llevo tres meses usando Claude Code como herramienta principal. No como asistente ocasional — como parte del flujo de trabajo diario. Esto es lo que aprendí.
Lo que cambió desde el primer mes
El primer mes lo usé como un autocomplete potente. Pedía código, lo revisaba, lo ajustaba. Productividad razonable pero no espectacular.
El cambio llegó cuando empecé a trabajar con tareas, no con preguntas. En lugar de “escribe una función que haga X”, empecé a describir el objetivo completo: “implementa el endpoint /users/:id con validación de permisos, manejo de errores estándar, y tests”. La diferencia es sustancial — Claude puede mantener el contexto de una tarea completa mejor que de preguntas fragmentadas.
Lo que mantuve: el CLAUDE.md como memoria
El archivo CLAUDE.md en la raíz del proyecto es lo más valioso que adopté. Incluye:
- Stack exacto del proyecto (versiones, librerías)
- Convenciones de código (naming, estructura de carpetas)
- Reglas específicas del dominio (“no usar
anyen TypeScript”, “los errores van en formato{ code, message }”) - Contexto de negocio que Claude no puede inferir del código
Sin esto, cada sesión empezaba desde cero. Con esto, Claude tiene el contexto necesario para tomar decisiones correctas sin preguntarme cada vez.
Lo que descubrí: los hooks son poderosos
Los hooks de Claude Code (pre-tool, post-tool) permiten automatizar acciones alrededor de las herramientas. Lo uso para: loggear qué archivos modifica, ejecutar el linter automáticamente después de cada Write, y alertar si intenta modificar archivos fuera del scope permitido.
Esto convierte Claude Code de “agente que ejecuta lo que le pides” a “agente con guardarraíles automáticos”.
El límite real: el contexto window
Después de tres meses, el límite principal no es la calidad de las respuestas — es el contexto window. En proyectos grandes, el contexto se llena y la calidad baja. La solución no es forzar más contexto, es trabajar en sesiones más cortas con tareas más específicas. Una sesión = una tarea bien definida.