Cómo usar Claude Code con prompts: una guía práctica para mejores resultados

Claude Code no es un chatbot, así que deja de usarlo como uno

La mayoría de las personas llegan a Claude Code desde una ventana de chat y lo usan de la misma manera: una solicitud vaga, una pared de intercambios, mucho "no, no así." Funciona en su mayor parte, y también es la forma más lenta de usar la herramienta.

El modelo mental es diferente. Como señala Anthropic en su guía de mejores prácticas, Claude Code "explora, planifica e implementa" por sí solo: lee archivos, ejecuta comandos y trabaja en un problema mientras tú observas, rediriges o te vas. Así que tu trabajo deja de ser "escribir la respuesta" y se convierte en "preparar el trabajo". Sean Tierney, que ha pasado un año construyendo aplicaciones reales con la herramienta, lo describe como aprender "a actuar como el creador de juego, no como el quarterback."

Ese cambio de perspectiva es todo el artículo. Todo lo siguiente es una forma concreta de preparar el trabajo para que Claude lo haga bien a la primera en vez de a la cuarta.

Sé específico: describe el resultado, no los pasos

"Cuanto más precisas sean tus instrucciones, menos correcciones necesitarás", señala Anthropic. "Claude puede inferir intención, pero no puede leer tu mente." Este es el único cambio de mayor impacto que puedes hacer, y no cuesta nada.

El antes y después en la propia guía de Anthropic lo hace obvio. No digas "añade pruebas para foo.py." Di: "escribe una prueba para foo.py que cubra el caso límite donde el usuario está desconectado. sin mocks." No digas "corrige el bug de inicio de sesión." Di "los usuarios reportan que el inicio de sesión falla después del tiempo de espera de la sesión, revisa el flujo de autenticación en src/auth/, especialmente la actualización de tokens, escribe una prueba fallida que reproduzca el problema, luego corrígelo."

El truco es declarar el resultado y las restricciones, luego dejar que Claude encuentre el dónde. El centro de ayuda de Anthropic lo llama "Declara el resultado, no los pasos": no "abre userService.ts, encuentra la función validate, añade una verificación nula en la línea 42", sino "los usuarios sin correo electrónico están rompiendo la validación, haz que lo maneje con elegancia y añade una prueba." No estás microadministrando el diff, estás describiendo el mundo que quieres que sea verdad.

Una advertencia que vale la pena mantener: vago está bien cuando estás explorando. "¿Qué mejorarías en este archivo?" es un gran prompt precisamente porque muestra cosas que no pensarías en preguntar. La especificidad es para cuando sabes lo que quieres, no para explorar.

Dale el material en bruto: archivos, capturas de pantalla, URLs, logs canalizados

Un prompt preciso todavía necesita material en bruto. Claude Code tiene varias formas de extraer contexto directamente a la conversación, y usarlas supera a describir las cosas de memoria:

• Referencia archivos con @. Escribir @src/auth/login.ts hace que Claude lea el archivo antes de responder. Cuando ya conoces la ruta, eso es más rápido y barato que dejarlo buscar. Por eso una estructura de repositorio limpia es valiosa, y por eso artículos como navegar una base de código con Claude Code importan.
• Pega imágenes. Arrastra o pega una captura de pantalla de un diseño o un error, luego di "implementa este diseño, toma una captura de pantalla del resultado y lista las diferencias." Claude puede ver la interfaz de usuario.
• Dale URLs. Apúntalo a una página de documentación o una referencia de API. Puedes incluir en la lista blanca los dominios que usas con frecuencia con /permissions.
• Canaliza datos. cat error.log | claude envía el archivo directamente. Esta es la puerta de entrada a usar Claude Code en la terminal como una herramienta Unix componible.

El centro de ayuda tiene una regla directa adjunta a esto: dale el error, literalmente. Pega el stack trace completo en lugar de resumirlo. El nombre exacto del archivo, el número de línea y el mensaje son lo que le permite a Claude saltar al código correcto en lugar de adivinar. Para sesiones más complicadas, nuestra guía de depuración con Claude Code profundiza más.

Haz que planifique antes de escribir una línea de código

Esto es lo que separa a las personas que les gusta Claude Code de las que lo aman. "Dejar que Claude salte directamente a codificar puede producir código que resuelve el problema equivocado", advierte Anthropic. La solución es un bucle de cuatro fases: explorar, planificar, implementar, confirmar.

Las primeras dos fases ocurren en modo de planificación, donde Claude lee archivos y propone un enfoque pero no hace ninguna edición. Entras con Shift+Tab (presiónalo dos veces para llegar al modo de planificación), o inicia una sesión con claude --permission-mode plan. En VS Code, el plan se abre como un documento markdown en el que puedes comentar en línea; en la terminal, Ctrl+G abre el plan en tu editor para que puedas editarlo directamente antes de que Claude continúe. Puedes leer la configuración completa en nuestra guía de modo interactivo.

El consenso entre practicantes es aún más fuerte que el de Anthropic. Aquí está Sean Tierney, que construye con la herramienta a diario:

"Siempre comienza en el Modo de Plan. Resiste la tentación de sumergirte directamente en la implementación. Puedes darle a CC exactamente el mismo prompt, pero al comenzar primero en el modo de plan y hacer que piense las cosas de antemano, te dará un resultado mucho mejor cada vez al tener que proponer y defender un plan por adelantado. Esta gratificación ligeramente retrasada frente a precipitarse en la implementación vale bien la espera de 2 minutos."

Sean Tierney, Vibecode Lisboa

¿Cuándo no planificar? La regla general de Anthropic es la que yo uso: si puedes describir el diff en una oración, omite el plan. Un error tipográfico, una línea de log, un renombrado de variable, simplemente pídelo. La planificación vale la pena cuando no estás seguro del enfoque, el cambio abarca múltiples archivos o no conoces bien el código todavía.

Dale a Claude una forma de verificar su propio trabajo

Aquí está el modo de fallo del que nadie te advierte: Claude se detiene cuando el trabajo parece terminado. Sin una verificación ejecutable, "parece terminado" es la única señal que tiene, lo que significa que tú te conviertes en el bucle de verificación, releyendo cada diff a mano.

La solución es entregarle algo que devuelva aprobado o fallido: una suite de pruebas, una compilación, un linter, un script que compara la salida con un fixture, o una captura de pantalla para comparar con un diseño. "Dale a Claude una verificación que pueda ejecutar", dice Anthropic. "Es la diferencia entre una sesión que observas y una de la que puedes alejarte." Así que la verificación pertenece al prompt: "escribe una función validateEmail, casos de prueba de ejemplo: user@example.com es true, invalid es false, user@.com es false, ejecuta las pruebas después de implementar."

Por eso el prompting basado en pruebas funciona tan bien. Pídele a Claude que escriba las pruebas primero, confirma que fallan, luego implementa hasta que pasen. Y pídele que muestre evidencia en lugar de afirmar éxito: la salida de la prueba, el comando que ejecutó, la captura de pantalla. Revisar la evidencia es más rápido que volver a ejecutar la verificación tú mismo. Si quieres que esto tenga un control más estricto, puedes escalarlo a un hook determinista que se activa cuando Claude intenta terminar, lo cual nuestra referencia de hooks explica.

Trata tu ventana de contexto como un presupuesto

Casi todos los problemas de prompting en Claude Code se remontan a una cosa: la ventana de contexto contiene toda la sesión (cada mensaje, cada lectura de archivo, cada salida de comando) y el rendimiento del modelo se degrada a medida que esa ventana se llena. Una sola sesión de depuración puede quemar decenas de miles de tokens, y una vez que está llena, Claude empieza a "olvidar" tus instrucciones anteriores.

Así que adminístrala deliberadamente:

• /clear entre tareas no relacionadas. Este es el grande. Tierney lo llama la "opción nuclear, úsala libremente entre características." Una ventana limpia con un prompt preciso supera a una larga llena de callejones sin salida.
• /compact <instrucciones> cuando quieras continuar pero recortar la grasa, por ejemplo /compact enfócate en los cambios de API.
• Delega a subagentes. Investigar una base de código grande llena tu ventana con lecturas de archivos. Un subagente hace esa lectura en su propia ventana y solo reporta el resumen. "Dado que el contexto es tu restricción fundamental, los subagentes son una de las herramientas más poderosas disponibles", dice Anthropic. Solo di "usa un subagente para investigar cómo manejamos la actualización de tokens." Nuestra guía sobre subagentes de Claude Code que puedes construir tiene más patrones.

Si quieres ver exactamente qué está consumiendo tu ventana, /context visualiza lo que está cargado, incluyendo qué herramientas conectadas son las que más tokens consumen.

Corrige rápido y sabe cuándo empezar de nuevo

Anthropic es claro en que "los mejores resultados vienen de bucles de retroalimentación ajustados." No esperas a que Claude termine un camino equivocado para explicar todo de nuevo. Las herramientas de corrección:

• Esc detiene a Claude en medio de la acción. El contexto se conserva, por lo que puedes redirigir en el acto.
• Esc Esc (o /rewind) abre el menú de retroceso para restaurar un estado de conversación o código anterior.
• "Deshaz eso" hace que Claude revierta sus propios cambios.

Hay una nota de tono aquí que importa más de lo que suena: corrígelo como a un colega, no como a un motor de búsqueda. No reescribes toda la solicitud, simplemente dices qué está mal, como "eso cambia la API pública, mantén la misma firma", y Claude ajusta solo eso. Y la heurística en la que más me apoyo: si has corregido a Claude más de dos veces en el mismo problema, el contexto está contaminado con enfoques fallidos. Ejecuta /clear y comienza de nuevo con un prompt mejor que incorpore lo que acabas de aprender. Una sesión limpia casi siempre supera a una larga que lleva correcciones acumuladas.

Escribe un CLAUDE.md: el prompt que solo escribes una vez

Todo lo anterior es por sesión. Un archivo CLAUDE.md es la parte de tu prompt que persiste. Claude lo lee al inicio de cada conversación, por lo que es donde vive el contexto permanente de tu proyecto: los comandos de compilación que no puede adivinar, tus reglas de estilo de código, etiqueta del repositorio, las peculiaridades del entorno de desarrollo, los problemas. El centro de ayuda lo llama "el briefing que le darías a un nuevo compañero de equipo capaz en su primera mañana."

Ejecuta /init para generar uno inicial a partir de tu proyecto, luego mantenlo conciso. La advertencia de Anthropic es enfática: "Los archivos CLAUDE.md inflados hacen que Claude ignore tus instrucciones reales." Para cada línea, pregunta "¿eliminar esto haría que Claude cometiera un error?" Si no, córtalo. Añade una regla cuando Claude se equivoque dos veces, podalo trimestralmente y confirma el archivo para que todo el equipo contribuya. La historia completa de configuración, incluido dónde vive el archivo y cómo se fusiona entre directorios, está en nuestra guía de configuración de Claude Code y la referencia de settings.json. Para flujos de trabajo repetibles, la misma lógica se extiende a los comandos slash.

Los hábitos de prompting que silenciosamente desperdician tus tokens

La mayoría de las sesiones desperdiciadas provienen de un puñado de errores repetibles. Anthropic nombra cinco, y la solución para cada uno es un hábito de prompting:

El meta-punto con el que Anthropic cierra vale la pena retener: estos son puntos de partida, no leyes. A veces deberías dejar que el contexto se acumule (cuando estás profundo en un problema difícil), omitir el plan (trabajo exploratorio), o lanzar un prompt vago (para ver cómo interpreta antes de restringir). Observa qué sucede cuando el resultado es excelente, y pregunta por qué cuando lucha. Así es como construyes la intuición que ninguna lista de verificación puede reemplazar. Si buscas un conjunto seleccionado, nuestro resumen de mejores prácticas de Claude Code recopila las que sobrevivieron el contacto con proyectos reales.

Qué tiene que ver esto con la IA que responde tickets de soporte

Aquí está lo que no esperaba cuando comencé a usar Claude Code: la disciplina de prompting es la misma disciplina que usamos para poner IA en una cola de soporte en vivo. Dale al agente el contexto correcto. Delimita lo que puede tocar. Haz que verifique antes de actuar. Corrige rápido y captura la lección.

Aprendí ese orden a las malas. Al principio, vimos cómo bots que sonaban seguros entregaban silenciosamente respuestas incorrectas a los clientes, por eso ahora simulamos cada lanzamiento contra los tickets históricos de una empresa antes de que salga una sola respuesta en vivo. Ese es el modo de planificación para soporte: leer el mundo, proponer cómo lo manejarás, obtener aprobación, luego actuar. Cuando Gridwise lo ejecutó, el agente resolvió el 73% de sus solicitudes de nivel 1 en el primer mes, y los resultados se mostraron durante una prueba de 7 días. El número vino de la configuración, no de un modelo más inteligente.

Si escribes contenido de la misma manera, la analogía también vale para la escritura con IA: el escritor de blogs de eesel AI es, bajo el capó, un agente que informas y verificas en lugar de un cuadro de chat con el que peleas.

Prueba eesel

eesel AI pone esa misma disciplina agéntica a trabajar en tu helpdesk. Conectas tus herramientas existentes (Zendesk, Freshdesk, HubSpot, Gorgias, Slack y 100+ más), y el agente aprende de tus tickets pasados y documentos de ayuda desde el primer día. La parte que se mapea directamente a todo lo anterior: lo configuras en lenguaje simple y lo ejecutas en simulación contra miles de tus tickets reales pasados antes de que responda a un cliente, para que veas exactamente lo que habría dicho y dónde habría escalado.

Es la misma lección que usar prompts con Claude Code, dirigida a tu cola de soporte: el agente es tan bueno como el contexto y las barreras que le das. Puedes probar eesel gratis, sin tarjeta de crédito, y verlo ejecutarse contra tu propio historial antes de confiarle un cliente.