Buenas prácticas de Claude Code: hábitos que dan mejores resultados

Cuando una sesión de Claude Code sale mal, la causa casi siempre es una de dos. Claude construyó algo distinto de lo que tenías en mente, o dijo "listo" cuando el trabajo no lo estaba. Ninguna es una debilidad de la herramienta. Las dos vienen de información que Claude no tenía.

Dile a Claude lo que no puede ver, y dale una forma de comprobar su propio trabajo.

Los hábitos siguientes son los que más importan, en el orden en que los usarás. Suponen que ya instalaste Claude Code y ejecutaste una sesión. Si no, empieza con Claude Code para principiantes.

Cómo funciona una buena sesión

Claude Code trabaja en un ciclo: reúne contexto, actúa y verifica el resultado. Tú también estás dentro de ese ciclo. Puedes interrumpir en cualquier momento para guiarlo. Cada hábito de esta guía mejora una parte del ciclo.

Hábito 1: dile a Claude solo lo que no puede ver

Claude empieza cada tarea leyendo tu código, y lo hace bien. Encuentra la estructura de carpetas, el framework de pruebas y la forma en que están hechos los componentes existentes, normalmente más rápido de lo que tú podrías explicarlo. Eso significa que la mayor parte de lo que te tienta escribir ya se sabe.

Lo que no puede encontrar es información que nunca estuvo en el repositorio: una decisión tomada en una reunión, un proceso de despliegue que vive en la cabeza de una sola persona, la variable de entorno que necesitan tus pruebas de integración. Hazte dos preguntas antes de agregar una línea a un prompt o a CLAUDE.md:

Si las dos respuestas son sí, déjalo fuera. Las listas largas de datos obvios entierran el único dato que importa. La siguiente guía, CLAUDE.md explicado, cubre dónde van los que deben durar.

Hábito 2: escribe un prompt específico

Un prompt específico funciona por la misma razón: le da a Claude información que no tiene. Nombra el archivo o el área, describe el síntoma y di cómo se ve algo arreglado. Si prefieres uno de dos enfoques razonables, di cuál, porque Claude no puede leerlo en el código.

Los mejores prompts nombran el lugar, la prueba y los límites. No son más largos porque sí. Cada frase agregada elimina una suposición.

Fíjate en la delegación de ese prompt. Das contexto y dirección, y dejas que Claude decida qué archivos leer y qué comandos ejecutar.

Hábito 3: entrega la cosa en lugar de describirla

Si ya tienes lo que Claude necesita, dáselo directamente. Escribir una descripción de un error es más lento y menos preciso que el error mismo.

Hábito 4: deja que Claude te entreviste cuando no estés seguro

No tienes que definir todo el plan antes de escribir un prompt. Cuando una idea todavía está borrosa, pídele a Claude que te haga preguntas hasta que pueda escribir la especificación:

Claude regresa con preguntas sobre las partes que no has definido: por usuario o por clave, qué pasa con las solicitudes que pasan del límite, qué queda fuera del alcance. Cuando las respuestas cuadran, escribe SPEC.md. Inicia una sesión nueva para construir a partir de ese archivo, de modo que la construcción arranque con un contexto limpio y una definición escrita de terminado.

Para cualquier cosa con riesgo real, agrega el paso del plan de la guía de permisos. Modos de permisos de Claude Code y modo plan, explicados muestra cómo hacer que Claude explore y proponga antes de editar.

Hábito 5: dale a Claude una verificación que ejecutar

Este es el hábito de mayor efecto. Claude se detiene cuando el trabajo parece terminado. Si no tiene nada que ejecutar que le diga si de verdad está terminado, "parece terminado" es todo lo que tiene. En la práctica tú te conviertes en el conjunto de pruebas, y cada error espera a que lo notes.

Dale algo que devuelva aprobado o fallido, y Claude puede cerrar el ciclo por su cuenta: hace el cambio, ejecuta la verificación, lee la falla, la arregla y ejecuta la verificación otra vez.

La verificación puede ser casi cualquier cosa cuyo resultado Claude pueda leer:

• un archivo de pruebas
• el código de salida de una compilación
• un linter o una revisión de tipos
• un script que compara la salida con un ejemplo guardado
• una captura del navegador colocada junto a la maqueta

Si tu proyecto ya tiene una, la línea más útil de tu CLAUDE.md es el comando que la ejecuta. Qué tan estricta la hagas depende de ti:

Hábito 6: pide evidencia, no tranquilidad

"Todas las pruebas pasan" a secas te dice muy poco. Pídele a Claude que muestre el comando que ejecutó y la salida, o la captura. Leer la salida es más rápido que ejecutar la verificación tú mismo, y en una sesión que no estabas viendo es la única prueba que tienes.

Cuando Claude diga que terminó, también puedes ejecutar /verify, con el que Claude compila y ejecuta la app y mira el resultado. Eso detecta el tipo de problema que se les escapa a las pruebas y a la revisión de tipos, como una página que técnicamente carga pero se ve rota.

Hábito 7: observa el primer minuto y guíalo a tiempo

Ninguna configuración reemplaza ver el inicio de una tarea e intervenir cuando Claude va a un lugar que no pretendías. Aprende estos controles de memoria:

• Esc detiene a Claude a media acción y conserva todo hasta ese punto, para que puedas redirigirlo sin perder trabajo.
• Escribir y presionar Enter mientras Claude trabaja deja una corrección en cola. Claude la lee en cuanto terminan sus llamadas a herramientas actuales y se ajusta.
• /rewind, o Esc dos veces con el prompt vacío, abre un menú donde regresas el código, la conversación o ambos a un punto anterior. Eso hace de bajo riesgo probar primero el enfoque más atrevido.
• /btw hace una pregunta rápida aparte sin agregarla al historial de la conversación.

Hábito 8: tras dos correcciones fallidas, empieza de nuevo

Si corregiste lo mismo dos veces y sigue mal, una tercera corrección se suma a una conversación que ya contiene dos intentos fallidos que Claude seguirá releyendo. Ejecuta /clear y escribe un solo prompt nuevo que incluya lo que aprendiste.

Se siente como perder avance. Casi siempre funciona mejor. Usar /clear entre tareas sin relación también es un buen hábito por sí solo, porque un contexto enfocado da mejores respuestas y cuesta menos.

Para trabajo que dura varios días, ponle nombre a la sesión con /rename oauth-migration y retómala después con claude --resume oauth-migration. claude --continue retoma la más reciente.

Hábito 9: mantén las reglas cortas y saca las reglas duras de la prosa

Todo lo que le dices a Claude en un prompt o en CLAUDE.md es una petición que el modelo lee y normalmente sigue. Un hook, una regla de denegación o un ajuste administrado es distinto: Claude Code lo hace cumplir siempre, decida lo que decida el modelo.

Usa el primer tipo para casi todo, porque Claude es bueno para juzgar cuándo encaja una pauta. Usa el segundo tipo para las pocas reglas que no pueden tener excepciones, como "nunca edites el cliente generado" o "ejecuta siempre el formateador después de crear un archivo".

Si tu sesión se alarga, revisa /context para ver qué está ocupando espacio. Claude compacta la conversación automáticamente, y un resumen puede perder instrucciones detalladas del principio. Las reglas permanentes pertenecen a CLAUDE.md, que se vuelve a leer del disco después de /compact. También puedes guiar el resumen: /compact focus on the API changes.

Consejos que ya puedes dejar de seguir

Algunos consejos antiguos eran soluciones provisionales para cosas que los modelos anteriores no podían hacer. Los modelos actuales ya las alcanzaron, y las soluciones provisionales ahora cuestan más de lo que aportan.

Preguntas frecuentes

¿Cómo obtengo mejores resultados con Claude Code?

Dale información que no puede ver, escribe prompts específicos, entrega archivos y errores en lugar de describirlos y dale una verificación que apruebe o falle. Luego guíalo a tiempo con Esc y ejecuta /clear cuando las correcciones no funcionen.

¿Por qué Claude Code dice que terminó cuando no es cierto?

Se detiene cuando el trabajo parece terminado. Si no hay nada que pueda ejecutar que demuestre lo contrario, "parece terminado" es todo lo que tiene. Dale una prueba, una compilación o un linter que ejecutar y pídele que muestre la salida.

¿Debo usar el modo plan siempre?

No. Úsalo cuando un cambio toque muchos archivos, cuando todavía no entiendas el código o cuando un error saldría caro. Para un cambio de una sola frase, pídelo directamente.

¿Cuándo debo usar /clear?

Entre tareas sin relación, y después de dos correcciones fallidas del mismo problema. Empieza el prompt nuevo con lo que aprendiste.

¿Cuál es la diferencia entre CLAUDE.md y un hook?

CLAUDE.md son instrucciones que Claude lee y normalmente sigue. Un hook es un script que Claude Code ejecuta en un punto fijo, así que ocurre sin importar lo que decida el modelo. Usa un hook para una regla sin excepciones.

¿Cómo retomo la sesión de Claude Code de ayer?

Ejecuta claude --continue para la conversación más reciente, o claude --resume para elegir una. Si le pusiste nombre a una sesión con /rename, usa claude --resume <nombre>.

Tu lista de verificación de hábitos

Sigue leyendo

• Claude Code para principiantes: instala, inicia sesión y haz tu primera tarea para configurar y ejecutar tu primera sesión.
• CLAUDE.md explicado: enséñale tu proyecto a Claude Code una sola vez para el archivo que lleva tus reglas de una sesión a otra.
• Modos de permisos de Claude Code y modo plan, explicados para elegir cuánto puede hacer Claude sin preguntar.
• Qué hacer cuando Claude no hace lo que le pediste para el mismo problema en la app de chat.
• Cómo hacer cambios en varios archivos con Claude Code para ver estos hábitos aplicados a un cambio en muchos archivos.