Flujos de trabajo diarios con Claude Code

Preludio

Después de usar Claude Code a diario durante más de seis meses, no para experimentos o demostraciones sino para trabajo real de producción (construyendo funcionalidades, revisando pull requests, depurando infraestructura, escribiendo documentación, refactorizando módulos enteros), se ha convertido en la herramienta que se abre a primera hora de la mañana y se cierra justo antes de apagar el ordenador.

Lo que sigue no es teoría. Esta es la configuración real, los archivos de configuración reales, la rutina diaria real refinada a lo largo de cientos de sesiones. Parte de ello provino de la documentación. La mayor parte surgió de hacer las cosas mal primero.

La diferencia entre un desarrollador que encuentra Claude Code "interesante" y uno que lo considera indispensable se reduce a la configuración. Los valores por defecto son razonables, pero son genéricos. Una vez que ajustas Claude Code a tu proyecto, tu equipo y tus hábitos, el salto de productividad es sustancial. No porque la IA se vuelva más inteligente, sino porque dejas de luchar contra fricciones que no necesitabas tener.

Esta guía asume que ya tienes Claude Code instalado y lo has ejecutado al menos unas cuantas veces. Si buscas un tutorial de introducción, la documentación oficial es el punto de partida adecuado. Lo que sigue es todo lo que viene después de "empezar".

El problema

La mayoría de los desarrolladores instalan Claude Code, lo ejecutan unas cuantas veces, obtienen resultados impresionantes en tareas sencillas y luego gradualmente dejan de usarlo para cualquier cosa compleja. El patrón es predecible. Las sesiones se alargan y pierden enfoque, y Claude empieza a olvidar el contexto de antes en la conversación.

La IA hace cambios que rompen las convenciones del proyecto. Los avisos de permisos lo ralentizan todo. Los costes se disparan en sesiones largas porque el modelo equivocado está ejecutándose para la tarea equivocada.

Estas no son limitaciones de la herramienta. Son problemas de configuración. Cada uno de ellos tiene una solución que lleva minutos configurar y ahorra horas durante las semanas siguientes.

El problema más profundo es que Claude Code no es simplemente una interfaz de chat pegada a un editor. Es un entorno de desarrollo con su propio lenguaje de configuración, su propio sistema de permisos, su propia gestión de contexto y sus propias convenciones de flujo de trabajo. Usarlo sin configurarlo es como usar VS Code sin instalar extensiones ni personalizar atajos de teclado. Funciona, pero estás dejando la mayor parte del valor sobre la mesa.

Muchos desarrolladores pasan su primer mes en ese estado. Entonces un fin de semana dedicado a repasar cada ajuste, cada comando, cada opción de configuración lo cambia todo. La guía que estás leyendo es la versión destilada de ese proceso, más todo lo aprendido desde entonces.

El camino

Tu CLAUDE.md es tu archivo más importante

Lo más impactante que puedes hacer para la productividad con Claude Code es escribir un buen archivo CLAUDE.md. Este archivo vive en la raíz de tu proyecto y actúa como contexto persistente que Claude lee al inicio de cada sesión. Piensa en él como un documento informativo para un colaborador que estás incorporando. Quieres que sea conciso, específico y centrado en decisiones en lugar de descripciones.

Esto es lo que debe ir en un archivo CLAUDE.md.

Comandos de compilación y ejecución. Claude necesita saber cómo compilar tu proyecto, ejecutar tests, iniciar servicios y verificar cambios. No le hagas adivinar. Sé explícito.

## Inicio rápido

- Compilar: `just build`
- Tests: `cargo test --workspace`
- Iniciar: `just start`
- Lint: `npm run lint`

Reglas de arquitectura que Claude violaría de otro modo. Si tu proyecto tiene convenciones que difieren de los patrones comunes, indícalas. Claude seguirá las convenciones generalizadas por defecto, así que solo necesitas documentar dónde diverge tu proyecto.

## Reglas críticas

1. Los archivos CSS van en `storage/files/css/`, nunca en `extensions/*/assets/css/`
2. El directorio `core/` es de solo lectura. Es un submódulo de git.
3. Todo el código Rust vive en `extensions/`. No hay Rust en `services/`.
4. El nombre de marca es "EntendIA"

Qué dejar fuera. No pongas todo tu README en CLAUDE.md. No describas qué hace cada archivo. No pegues documentación de API. Cada token en CLAUDE.md cuesta espacio de contexto, y el espacio de contexto es finito.

Claude puede leer tus archivos fuente directamente cuando necesite detalles de implementación. Lo que no puede inferir por sí solo son las decisiones de tu equipo, tus convenciones de nomenclatura y tus restricciones de despliegue.

El error más frecuente son archivos CLAUDE.md de miles de líneas, llenos de información que Claude podría obtener leyendo el código real. Un buen CLAUDE.md tiene menos de 200 líneas. El de EntendIA tiene unas 80 líneas y cubre comandos de compilación, reglas críticas, estructura de directorios, convenciones CSS y flujos de depuración. Eso es todo lo que Claude necesita para trabajar en el proyecto sin cometer errores que de otro modo cometería.

La jerarquía importa. Claude Code lee archivos CLAUDE.md de múltiples ubicaciones en un orden específico. El CLAUDE.md de la raíz del proyecto se carga primero. Luego cualquier CLAUDE.md en directorios superiores. Después ~/.claude/CLAUDE.md para instrucciones a nivel de usuario. Si trabajas en múltiples proyectos que comparten convenciones, pon las reglas compartidas en tu archivo de nivel de usuario y mantén las reglas específicas del proyecto en el archivo del proyecto. Para configuraciones de monorepo donde esta jerarquía se vuelve especialmente importante, consulta nuestra guía sobre CLAUDE.md en monorepos.

Un patrón efectivo es estructurar el archivo con las reglas más críticas primero. Claude da más peso al contenido que encuentra al inicio de su contexto. Pon tus reglas de "nunca hagas esto" arriba, tus comandos de compilación a continuación y cualquier orientación secundaria al final.

El archivo de configuración que todo repositorio debería tener

Más allá de CLAUDE.md, el archivo .claude/settings.json controla el comportamiento real de Claude Code. Aquí es donde configuras permisos, comandos permitidos y acceso a herramientas. Todo repositorio en el que trabajes regularmente debería tener uno.

Este es un archivo de configuración mínimo que elimina los puntos de fricción más comunes.

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(cargo build*)",
      "Bash(cargo test*)",
      "Bash(npm run lint*)",
      "Bash(just *)",
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(git push --force*)",
      "Bash(rm -rf*)",
      "Bash(docker rm*)"
    ]
  }
}

La lista allow es lo que te evita hacer clic en "aprobar" cientos de veces por sesión. Cada patrón de comando en esta lista se ejecuta sin solicitar confirmación. La lista deny es tu red de seguridad para comandos que nunca deberían ejecutarse automáticamente, independientemente del contexto.

Los patrones admiten comodines. Bash(git diff*) coincide con git diff, git diff --staged, git diff HEAD~3 y cualquier otra variante de git diff. Bash(just *) coincide con cualquier objetivo de tu Justfile. Esto significa que puedes aprobar categorías amplias de comandos seguros sin enumerar cada posible invocación.

También recomendamos añadir permisos específicos de herramientas. Read, Glob y Grep en la lista de permitidos significan que Claude puede buscar y leer tu código sin pedir permiso para cada archivo. Esto solo ya reduce la fricción de la sesión significativamente, porque las acciones más comunes de Claude son leer archivos y buscar patrones.

Para proyectos de equipo, incluye este archivo en el repositorio. Todos en el equipo obtienen los mismos permisos base. Los desarrolladores individuales pueden añadir sobrecargas personales en ~/.claude/settings.json para comandos específicos de su flujo de trabajo.

La referencia completa de configuración documenta todas las opciones disponibles. El sistema de permisos es el que más usarás.

Elegir el modelo adecuado para la tarea adecuada

Claude Code soporta múltiples modelos, y elegir el correcto para cada tarea es una de las formas más sencillas de gestionar tanto el coste como la calidad. No toda tarea necesita el modelo más potente.

Opus es el predeterminado y el más capaz. Úsalo para refactorizaciones complejas, cambios en múltiples archivos, decisiones arquitectónicas, depuración de problemas sutiles y cualquier tarea donde necesites que Claude razone profundamente sobre tu código. Es la opción más cara, pero para tareas donde acertar a la primera importa, se paga solo.

Sonnet es más rápido y más barato. Destaca en tareas rutinarias como escribir tests para código existente, generar código repetitivo, cambios de formato y correcciones de errores sencillas donde el problema ya está identificado. La diferencia de calidad respecto a Opus es notable en tareas complejas pero insignificante en las sencillas. En mi experiencia, Sonnet cubre la mayoría de las necesidades típicas de desarrollo diario.

Haiku es la opción ligera. Es ideal para preguntas rápidas, consultas simples y tareas donde esencialmente usas Claude como un motor de búsqueda rápido sobre tu código. "¿Qué archivo contiene la migración de base de datos para usuarios?" o "Muéstrame todos los lugares donde se llama a esta función." Haiku responde a esto en segundos con un coste mínimo.

Puedes cambiar de modelo durante la sesión usando el comando /model. Un flujo de trabajo típico es empezar una sesión en Sonnet para trabajo rutinario, cambiar a Opus al encontrar algo complejo, y luego volver a Sonnet o Haiku cuando la parte difícil haya terminado.

La dimensión del coste importa. Los modelos de vanguardia cuestan significativamente más por token que las alternativas más ligeras. Consulta la página de precios de Anthropic para ver las tarifas actuales, ya que cambian con el tiempo. Si tu equipo ejecuta cientos de sesiones de Claude Code al día, la selección de modelo se convierte en una consideración presupuestaria real. El enfoque correcto no es usar siempre el modelo más barato. Es usar el modelo más caro solo cuando la tarea lo justifica. Para una visión más detallada de la gestión de costes, consulta nuestra guía sobre optimización de costes de Claude Code.

Tu distribución ideal de modelos dependerá del tipo de trabajo que hagas. En mi experiencia, la mayoría de los desarrolladores terminan canalizando el grueso de sus tokens a través de Sonnet, reservando Opus para tareas de razonamiento complejo y usando Haiku para consultas rápidas. Si pasas la mayor parte del día depurando problemas de producción, te apoyarás más en Opus. Si pasas la mayor parte del día escribiendo tests y documentación, Sonnet y Haiku lo cubrirán.

Revisiones de PR con Claude Code

Este es uno de los flujos de trabajo más sorprendentemente efectivos. Usar Claude Code para revisiones de pull requests suele empezar casi por accidente, y rápidamente se convierte en uno de los casos de uso más consistentes.

El enfoque más simple es hacer checkout de la rama del PR y pedir a Claude que lo revise.

git checkout feature/new-dashboard
claude

Luego, dentro de la sesión, pide a Claude que compare contra main.

Revisa los cambios en esta rama comparados con main. Céntrate en la corrección,
posibles errores y cumplimiento de las convenciones de nuestro proyecto.

Claude ejecutará git diff main...HEAD, leerá los cambios y te dará una revisión estructurada. Lo que hace esto mejor que leer el diff tú mismo es que Claude también lee el código circundante. No solo revisa el diff de forma aislada. Comprueba si los cambios son coherentes con el resto del código.

Para una revisión más dirigida, puedes canalizar el diff directamente.

git diff main...HEAD | claude --print "Revisa este diff en busca de errores,
problemas de seguridad y violaciones de estilo."

La flag --print ejecuta Claude en modo no interactivo. Lee la entrada, produce una respuesta y sale. Esto es perfecto para pipelines de CI o revisiones rápidas donde no necesitas una sesión interactiva completa.

Un alias de shell hace esto aún más rápido para usarlo varias veces al día.

alias pr-review='git diff main...HEAD | claude --print "Revisa este diff.
Céntrate en errores, problemas de seguridad, manejo de errores faltante y
desviaciones de los patrones en CLAUDE.md."'

Para PRs más grandes, el enfoque interactivo funciona mejor porque puedes hacer preguntas de seguimiento. "¿Qué pasa si esta llamada a la base de datos falla?" o "¿Esta nueva función es coherente con cómo manejamos errores en el resto del módulo?" Estas preguntas de seguimiento son donde Claude Code aporta más valor, porque puede buscar en el código para responderlas.

Un patrón especialmente valioso es pedir a Claude que sugiera casos de prueba para los cambios del PR. Después de revisar el diff, pregunta "¿Qué casos de prueba cubrirían los casos límite de estos cambios?" Claude identificará las condiciones frontera y generará código de prueba que ya está adaptado al framework de testing y las convenciones de tu proyecto.

Cinco ajustes que ahorran horas

Después de meses de ajustar la configuración, cinco ajustes específicos destacan como los que más tiempo ahorran.

1. Patrones de auto-aprobación extendidos. El conjunto de permisos por defecto es conservador. Añadir las herramientas de compilación específicas de tu proyecto, los ejecutores de tests y los comandos de despliegue a la lista de permitidos elimina la mayor fuente de fricción.

{
  "permissions": {
    "allow": [
      "Bash(cargo test*)",
      "Bash(cargo clippy*)",
      "Bash(just *)",
      "Bash(npm run *)",
      "Bash(systemprompt *)"
    ]
  }
}

Cada comando que añades aquí es un clic de aprobación menos por sesión. A lo largo de un día completo de desarrollo, esto suma cientos de interrupciones evitadas.

2. Patrones de denegación para comandos destructivos. Lo inverso de la auto-aprobación. Denegar explícitamente los comandos que nunca quieres que Claude ejecute automáticamente significa que puedes ser más liberal con tus patrones de aprobación sin preocuparte por los casos extremos.

{
  "permissions": {
    "deny": [
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(rm -rf *)",
      "Bash(*DROP TABLE*)",
      "Bash(*DROP DATABASE*)"
    ]
  }
}

3. Directorios adicionales. Si tu proyecto abarca múltiples repositorios o directorios, configúralos en el archivo de ajustes para que Claude tenga visibilidad completa sin que tengas que añadirlos manualmente en cada sesión.

{
  "additionalDirectories": [
    "/var/www/html/core",
    "/var/www/html/shared-libs"
  ]
}

4. Configuración específica por entorno. Diferentes entornos pueden tener diferentes ajustes. Tu configuración de desarrollo local podría permitir la ejecución amplia de comandos, mientras que tu configuración de CI restringe Claude a operaciones de solo lectura.

5. Conciencia del umbral de compactación. Esto no es un ajuste que configures, sino un comportamiento que aprendes. Cuando el contexto de tu sesión se alarga, las respuestas de Claude se degradan. El comando /compact resume el historial de la conversación y libera espacio de contexto.

Ejecútalo aproximadamente cada 30-40 mensajes, o siempre que Claude empiece a olvidar cosas mencionadas antes. Esto mantiene las sesiones productivas. Más sobre esto en la sección de gestión de contexto.

Depuración en serio

El flujo de trabajo de depuración es donde Claude Code se gana su lugar en el kit de herramientas diario de manera más convincente. El ciclo tradicional de depuración es: leer logs, formular una hipótesis, encontrar el código relevante, trazar la ruta de ejecución, probar la corrección. Claude Code comprime este ciclo drásticamente porque puede hacer los pasos de búsqueda y rastreo más rápido que cualquier persona.

Un flujo de depuración productivo tiene este aspecto.

Inicia una sesión nueva. La depuración funciona mejor con un contexto limpio porque quieres que Claude se centre en el problema, no distraído por lo que estabas trabajando antes.

claude

Describe el síntoma, no tu teoría sobre la causa. "La página del dashboard devuelve un error 500 cuando filtro por rango de fechas" es mejor que "Creo que la consulta SQL en dashboard.rs está mal." Deja que Claude forme su propia hipótesis después de leer el código.

Claude típicamente empezará buscando archivos relevantes, leyendo el código de manejo de errores y trazando la ruta de ejecución desde el handler HTTP hasta la consulta de base de datos. Aquí es donde tener Read, Grep y Glob en tu lista de auto-aprobación da sus frutos. Claude podría leer veinte archivos durante una sesión de depuración, y no quieres aprobar cada uno manualmente.

Una vez que Claude identifique una causa probable, pídele que verifique antes de arreglar. "¿Puedes confirmar que este es el problema mostrándome qué produce la consulta SQL con un rango de fechas que cruza la medianoche?" Verificar antes de arreglar te ahorra el frustrante ciclo de aplicar una corrección, descubrir que estaba mal, revertir e intentar de nuevo.

Para depuración en producción, combina Claude Code con tus herramientas de logging.

systemprompt infra logs view --level error --since 1h | claude --print \
  "Analiza estos logs de error. Identifica los errores más frecuentes y
  sugiere las causas raíz probables basándote en el código."

Esto canaliza tus logs de error recientes directamente a Claude con contexto del código. Claude puede correlacionar los mensajes de log con tu código fuente real, algo que las herramientas de análisis de logs no pueden hacer.

Para rastrear solicitudes específicas a través del sistema, un enfoque en múltiples pasos funciona bien.

systemprompt infra logs audit <request-id> --full

Luego pega la salida en Claude y pídele que rastree la solicitud a través del código, identificando dónde falló y por qué. La combinación del rastreo de la solicitud y el acceso al código significa que Claude normalmente puede señalar la línea exacta de código responsable.

Los comandos que deberías conocer

Claude Code tiene un conjunto de comandos slash que controlan la sesión misma. La mayoría de los desarrolladores descubren /help y se quedan ahí. Estos son los que vale la pena usar regularmente.

/help muestra los comandos disponibles. Ejecútalo una vez para familiarizarte. Los comandos específicos disponibles pueden variar según la versión, así que /help es siempre la referencia definitiva.

/compact es el comando más importante para sesiones largas. Resume el historial de la conversación y comprime el contexto. Ejecútalo de forma proactiva, no solo cuando Claude empiece a olvidar cosas. Una buena regla general es compactar después de cada tarea importante dentro de una sesión. ¿Terminaste una funcionalidad? Compacta. ¿Arreglaste un error? Compacta. ¿Estás a punto de cambiar a otra área del código? Compacta.

/model te permite cambiar entre modelos durante la sesión. Así es como te mueves entre Opus, Sonnet y Haiku sin iniciar una nueva sesión.

/mcp muestra el estado de los servidores MCP conectados. Si has extendido Claude Code con servidores MCP para capacidades adicionales, este comando te dice cuáles están conectados y funcionando correctamente.

/add-dir añade otro directorio al alcance de la sesión. Equivalente a iniciar Claude Code con --add-dir, pero usable durante la sesión. Esto es especialmente útil cuando un rastro de depuración te lleva a una dependencia o biblioteca compartida que vive en un directorio diferente.

/add-dir /var/www/html/core

Estos comandos son controles a nivel de sesión. No modifican tus archivos de configuración ni persisten entre sesiones. Piensa en ellos como el panel de control de tu sesión de trabajo actual. Ejecuta /help para ver la lista completa de tu versión, ya que se añaden nuevos comandos regularmente.

Trabajar con múltiples directorios

Los proyectos reales rara vez viven en un solo directorio. Podrías tener un monorepo con múltiples paquetes, o un conjunto de repositorios relacionados que se referencian entre sí, o un proyecto que depende de una biblioteca local que también estás desarrollando.

Claude Code gestiona esto a través de la flag --add-dir al inicio y el comando /add-dir durante la sesión.

claude --add-dir /var/www/html/core --add-dir /var/www/html/shared-libs

Esto da a Claude acceso de lectura a los tres directorios (el directorio de trabajo más los dos adicionales). Cuando Claude busca archivos o lee código, busca en todos ellos. Esto es esencial para depurar problemas que cruzan los límites entre repositorios.

Para directorios que siempre quieres incluir, añádelos a tu archivo de configuración.

{
  "additionalDirectories": [
    "/var/www/html/core",
    "/var/www/html/shared-libs"
  ]
}

Con esta configuración, cada sesión en el proyecto incluye automáticamente estos directorios sin que tengas que especificarlos en la línea de comandos.

Un aspecto a tener en cuenta es que los directorios adicionales aumentan la presión sobre el contexto. Claude necesita procesar más archivos, más resultados de búsqueda y más código cuando hay directorios adicionales en el alcance. Si añades un monorepo masivo como directorio adicional, podrías encontrar que el contexto se llena más rápido y necesitas compactar con más frecuencia. Sé selectivo. Añade directorios que realmente necesites, no todos los que puedan ser tangencialmente relevantes.

Para configuraciones empresariales con ajustes gestionados, los administradores pueden configurar directorios adicionales a nivel de organización. Esto asegura que todos los desarrolladores del equipo tengan visibilidad de las bibliotecas compartidas y paquetes internos por defecto.

Gestión de contexto y disciplina de sesión

La gestión de contexto es la habilidad que separa a los usuarios productivos de Claude Code de los frustrados. La ventana de contexto es grande pero finita. Cada mensaje que envías, cada archivo que Claude lee, cada salida de comando se añade a ella. Cuando el contexto se llena, Claude empieza a perder el hilo de la conversación anterior, y la calidad de las respuestas se degrada.

La primera regla es iniciar sesiones nuevas para tareas no relacionadas. Si acabas de terminar una funcionalidad y quieres revisar un PR, inicia una nueva sesión. El contexto de la funcionalidad es ruido para la revisión del PR, y el contexto de la revisión será ruido para lo que venga después. Un día productivo típico implica de cuatro a seis sesiones separadas de Claude Code, cada una centrada en una tarea específica o un conjunto de tareas estrechamente relacionadas.

La segunda regla es compactar de forma proactiva. No esperes a que Claude empiece a olvidar. El comando /compact preserva la información esencial de tu conversación mientras libera espacio de contexto. Compacta después de cada hito significativo dentro de una sesión.

La tercera regla es mantener los prompts enfocados. Un prompt como "refactoriza este módulo, también arregla el error en el handler de login, y ya que estás actualiza el README" produce peores resultados que tres prompts separados y enfocados. Claude funciona mejor cuando puede concentrarse en una cosa a la vez.

La cuarta regla es dejar que Claude lea los archivos en lugar de pegarlos. Cuando pegas un archivo de 500 líneas en el chat, ese contenido ocupa espacio de contexto durante toda la sesión. Cuando Claude lee un archivo usando sus herramientas, puede procesar el archivo y retener solo las partes relevantes. El contenido del archivo sigue usando contexto, pero Claude lo gestiona más eficientemente que un pegado directo.

Cuando necesites continuar una sesión larga, busca señales de fatiga de contexto. Claude repitiendo preguntas que ya respondiste, olvidando restricciones que indicaste antes, o produciendo código que ignora patrones establecidos anteriormente en la sesión. Cualquiera de estas señales significa que es hora de compactar o empezar de nuevo.

Cómo podría ser un día típico

Aquí hay un ejemplo ilustrativo de cómo estos flujos de trabajo encajan a lo largo de un día completo. Tu día real variará, pero esto da una idea del ritmo.

Mañana: revisiones de PR. Abre un terminal e inicia Claude Code en el directorio principal del proyecto. Si hay PRs de compañeros de equipo, haz checkout y sigue el flujo de revisión descrito anteriormente. Dos o tres revisiones de PR podrían llevar unos treinta minutos en total, incluyendo preguntas de seguimiento y sugerencias de pruebas.

Media mañana: trabajo en funcionalidades. Inicia una sesión nueva para la tarea principal del día. Describe la funcionalidad a alto nivel, haciendo referencia a los patrones existentes en el código. Claude lee el código existente, el esquema de base de datos, los archivos de plantillas, y propone un enfoque. Itera sobre el diseño durante unos mensajes, luego deja que Claude empiece a implementar mientras revisas cada cambio.

Aquí es donde la selección de modelo importa. Usa Opus para la discusión de diseño inicial y la lógica compleja. Una vez que la arquitectura esté definida y Claude esté escribiendo código de handlers y plantillas sencillo, cambia a Sonnet para el trabajo de implementación.

Después de comer: depuración. Algo está roto. Inicia una sesión nueva dedicada al problema y describe el síntoma claramente. Deja que Claude rastree el código para encontrar la causa raíz. Verifica la corrección antes de aplicarla. Las sesiones nuevas con contexto enfocado hacen la depuración significativamente más rápida.

Tarde: documentación y limpieza. Cambia a Sonnet para escribir documentación y limpiar el código del trabajo de la mañana en funcionalidades. Añadir comentarios inline, actualizar archivos de configuración. Este es trabajo rutinario donde Sonnet rinde bien y cuesta menos.

Final de la tarde: automatización. Si el tiempo lo permite, trabaja en hooks y automatización para mejorar el flujo de trabajo en sí. Configurar un nuevo hook PostToolUse para ejecutar tests automáticamente cuando Claude modifique ciertos archivos. Añadir un nuevo servidor MCP para una herramienta que el equipo ha estado pidiendo. Estas mejoras meta se acumulan con el tiempo.

A lo largo del día, se podrían iniciar y cerrar cinco o seis sesiones separadas. Cada una centrada en una tarea específica, compactando dentro de las sesiones cuando se alargan, cambiando modelos según la complejidad de la tarea. Nada de esto es dramático. Es el resultado acumulado de configurar la herramienta para encajar con cómo realmente trabajas.

Errores comunes y solución de problemas

Incluso con una buena configuración, algunos problemas surgen regularmente.

Sintaxis inválida en settings.json. Si Claude Code ignora tu configuración, la causa más común es un error de sintaxis JSON. Una coma de más, un corchete faltante o una cadena sin comillas romperán silenciosamente el archivo. Pasa tu configuración por un validador JSON o ábrelo en un editor con linting de JSON antes de asumir que los ajustes no funcionan.

CLAUDE.md es demasiado grande. Si tu CLAUDE.md supera unos cientos de líneas, consume una porción significativa de tu ventana de contexto antes de que empieces a trabajar. Mantenlo por debajo de 200 líneas. Si te encuentras añadiendo más, mueve el detalle extra a archivos de documentación que Claude pueda leer bajo demanda.

El contexto se llena inesperadamente. Si Claude empieza a olvidar instrucciones o a producir salida inconsistente durante la sesión, la presión de contexto es la causa probable. Ejecuta /compact para recuperar espacio. Si eso no es suficiente, inicia una sesión nueva. Añadir muchos directorios con --add-dir o pegar grandes bloques de texto acelera el uso de contexto.

Los cambios de configuración no surten efecto. Los cambios en .claude/settings.json se aplican a nuevas sesiones, no a la actual. Si editas el archivo durante la sesión, inicia una nueva sesión para que los cambios surtan efecto.

Claude sigue pidiendo permiso. Si has configurado patrones de aprobación pero Claude aún solicita aprobación, verifica que tus patrones coincidan exactamente. Bash(cargo test*) coincide con cargo test --workspace pero no con cd src && cargo test. Los patrones coinciden con toda la cadena del comando, así que los comandos con prefijos de cd o pipes necesitan sus propios patrones.

La lección

La lección de seis meses de uso diario de Claude Code es simple. La configuración es apalancamiento.

Cada minuto dedicado a escribir un CLAUDE.md, ajustar un settings.json y aprender los comandos se devuelve sustancialmente en productividad diaria. Los desarrolladores que prueban Claude Code y lo abandonan casi siempre se saltan el paso de configuración. Usaron los valores por defecto, encontraron fricción y concluyeron que la herramienta no estaba lista. La herramienta estaba lista. Su configuración no lo estaba.

Las conclusiones específicas, en orden de impacto.

Escribe un CLAUDE.md conciso y específico. Menos de ~500 líneas. Céntrate en reglas que Claude violaría de otro modo, no en descripciones de lo que hace el código. Este único archivo elimina la mayoría de los momentos de "Claude hizo algo mal".

Configura tus permisos. Auto-aprueba los comandos seguros. Auto-deniega los peligrosos. Esto elimina la mayoría de los momentos de "Claude es lento porque sigo haciendo clic en aprobar".

Usa el modelo adecuado para la tarea adecuada. Opus para razonamiento complejo. Sonnet para desarrollo rutinario. Haiku para consultas rápidas. Esto gestiona los costes sin sacrificar calidad donde importa.

Inicia sesiones nuevas para tareas no relacionadas. Compacta de forma proactiva dentro de sesiones largas. Estos dos hábitos mantienen la calidad de las respuestas durante todo el día.

Aprende los comandos slash. /compact, /model, /mcp y /add-dir son los que más usarás. Te dan control en tiempo real sobre la sesión sin salir de la conversación. Ejecuta /help para ver la lista completa de tu versión.

Construye tu flujo de depuración alrededor de la capacidad de Claude Code para buscar y leer código. Describe síntomas, deja que Claude rastree la causa, verifica antes de arreglar. Esto produce consistentemente una depuración más rápida y precisa que el enfoque manual tradicional.

Nada de esto es complicado. Nada requiere conocimiento técnico profundo. Requiere dedicar una o dos horas a la configuración y luego prestar atención a qué funciona y qué no durante las semanas siguientes.

Conclusión

Claude Code no es una herramienta que instalas y olvidas. Es una herramienta que configuras, adaptas y refinas. La superficie de configuración no es grande. Un archivo CLAUDE.md, un archivo settings.json, un puñado de comandos slash y una conciencia de la selección de modelos y la gestión de contexto. Esa es toda la superficie.

Pero dentro de esa superficie, la diferencia entre una configuración por defecto y una ajustada es enorme. Es la diferencia entre una herramienta que ayuda ocasionalmente y una herramienta que cambia fundamentalmente cómo trabajas.

Si estás empezando, comienza con CLAUDE.md y settings.json. Haz que funcionen bien y verás la diferencia inmediatamente. Luego añade hooks para automatización, explora servidores MCP para capacidades extendidas, y si gestionas un equipo, consulta los ajustes gestionados empresariales para una configuración consistente en toda tu organización.

La referencia completa de configuración documenta todas las opciones disponibles. Pero no necesitas leerla toda de una vez. Empieza con lo que cubre esta guía, úsala durante una semana y luego profundiza en las áreas donde quieras más control.

La mejor herramienta de productividad es la que has configurado para encajar con cómo realmente trabajas. Claude Code te da la superficie de configuración para hacer exactamente eso. El resto es solo práctica diaria.