En los artículos anteriores de esta serie vimos qué es Claude Code, cómo instalarlo y cómo manejar sesiones y memoria. En algún punto de esas lecturas probablemente notaste que casi todo lo que escribes para comunicarte con el agente es texto libre en lenguaje natural. Sin sintaxis especial, sin métodos, sin tipos. Solo texto.
Eso suena simple, pero tiene una trampa: cuando el medio de comunicación es el lenguaje natural, la calidad de lo que escribes importa mucho más de lo que intuitivamente esperarías. El mismo agente, con el mismo modelo, puede darte respuestas brillantes o respuestas mediocres dependiendo de cómo le formules la misma tarea. Y la diferencia entre las dos formulaciones puede ser más pequeña de lo que piensas.
En este artículo vamos a entender por qué ocurre eso, y qué puedes hacer al respecto. Empezamos desde los fundamentos: qué es exactamente un prompt, cómo lo procesa el modelo, qué son los tokens y por qué importan. Después pasamos a los tips concretos. Y terminamos con la pregunta que todo el mundo tiene pero pocos admiten haber buscado: ¿debo decirle "por favor" y "gracias" al modelo?
Sin más, vamos al tema.
Contenido
¿Qué es exactamente un prompt?
En el contexto de los modelos de lenguaje, un prompt es toda la información que el modelo recibe como entrada antes de generar su respuesta. Cuando abres Claude Code y escribes "refactoriza esta clase", eso es un prompt. Pero en realidad el prompt es más que solo tu mensaje. Incluye todo lo que está en la ventana de contexto en ese momento:
- Las instrucciones del sistema (cómo debe comportarse Claude Code)
- El historial completo de la conversación: todos tus mensajes y todas las respuestas anteriores
- El contenido del
CLAUDE.mdsi está configurado - Los resultados de las herramientas ejecutadas (archivos leídos, comandos corridos)
- Tu mensaje nuevo
Todo eso junto es el prompt que el modelo procesa cada vez que generas una respuesta. Esto explica algo que desconcierta a mucha gente al principio: por qué el agente "recuerda" cosas de mensajes anteriores. No las recuerda en ningún sentido humano. Es simplemente que todo el historial se incluye como parte del prompt en cada turno.
Un prompt no es solo lo que escribes en este momento. Es la foto completa de todo lo que el modelo puede ver. Entender eso cambia cómo piensas sobre la comunicación con el agente.
Cómo interpreta el modelo lo que escribes
Para escribir buenos prompts, conviene tener un modelo mental (aunque sea simplificado) de lo que hace el modelo cuando recibe tu texto. Porque no lo está "leyendo" de la misma forma en que lo harías tú.
El modelo no entiende: predice
Un modelo de lenguaje no comprende el significado de las palabras en el sentido semántico. Lo que hace es, fundamentalmente, predecir qué tokens tienen más probabilidad de venir a continuación dado todo lo que ha visto hasta ese momento. Fue entrenado con cantidades masivas de texto humano, y aprendió los patrones estadísticos de ese texto. Cuando le escribes, está buscando el patrón más probable de continuación.
Esto tiene implicaciones concretas:
- Un prompt ambiguo activa múltiples patrones al mismo tiempo y el modelo tiene que "apostar" por uno. Si apostó mal, obtienes una respuesta que no querías.
- El texto que produces regularmente en el mundo real tiende a estar escrito con ciertos patrones: preguntas claras, respuestas claras, instrucciones directas. Cuanto más se parezca tu prompt a esos patrones, más predecible (y útil) será la respuesta.
- El contexto circundante influye en la interpretación de cada parte del prompt. La misma frase puede interpretarse diferente según qué hay antes y después de ella.
El modelo es sensible a la estructura, no solo al contenido
Aquí hay algo contraintuitivo: la forma en que organizas la información en tu prompt influye tanto como el contenido de esa información. No es lo mismo poner el contexto al principio que al final. No es lo mismo usar una lista que un párrafo. No es lo mismo pedir una cosa o pedirla y luego especificar exactamente cómo debe presentarse la respuesta.
Anthropic describe este concepto como "context engineering": no se trata solo de encontrar las palabras correctas, sino de configurar el conjunto óptimo de tokens que maximice la probabilidad de obtener el comportamiento deseado del modelo.
Tokens: la unidad de medida de todo
Antes de hablar de técnicas específicas de prompting, necesitamos hablar de tokens. Es el concepto técnico más importante para entender cómo funciona todo esto, y el que más se subestima en tutoriales básicos.
¿Qué es un token?
El modelo no procesa texto directamente: convierte el texto en números. Un token es la unidad básica de ese proceso: puede ser una palabra completa, parte de una palabra, o incluso un solo carácter, dependiendo del algoritmo de tokenización que use cada modelo.
Para hacer esto tangible, aquí está cómo se tokenizaría la frase "Refactoriza el método de pago":
Esa frase de 5 palabras se convierte en 7 tokens. Cada color representa un token diferente. Nota cómo "Refactoriza" se divide en tres piezas: el modelo nunca ha visto esa palabra tan frecuentemente como para tratarla como una unidad. En cambio, "método", "el", "de" y "pago" son tan comunes en texto en español que cada uno tiene su propio token.
Por qué los tokens importan en la práctica
Los tokens son la unidad de medida de casi todo en el mundo de los LLMs:
| Factor | Relación con los tokens |
|---|---|
| Ventana de contexto | Se mide en tokens (Claude tiene ~200,000). Todo lo que cabe en el prompt se cuenta en tokens. |
| Costo por API | Se factura por tokens de entrada + tokens de salida. Prompts largos e innecesarios cuestan dinero real. |
| Velocidad de respuesta | Más tokens en el prompt ralentizan el tiempo de respuesta. En sesiones largas esto se acumula. |
| Calidad de la atención | A medida que crece el contexto, el modelo pierde precisión para recuperar información de partes anteriores del prompt. Más tokens no siempre es mejor. |
Regla empírica de conversión
Para español, la relación aproximada es: 100 tokens ≈ 65-75 palabras. El español genera más tokens por palabra que el inglés (así es, tu YouTuber o influencer favorito no escribe sus promts en inglés porque sea más cool, lo hace porque es más "barato"). La razón de esto es que el español tiene más morfología (conjugaciones, sufijos, acentos). Una clase Java de 200 líneas puede consumir entre 800 y 1,500 tokens dependiendo de la complejidad.
https://platform.openai.com/tokenizer. Es útil para calibrar el tamaño de tus prompts antes de usarlos en producción.
Anatomía de un buen prompt
La mayoría de los prompts efectivos tienen cuatro componentes. No todos son obligatorios siempre, pero conocerlos te ayuda a saber qué le falta a un prompt que no está dando los resultados que esperas.
| Componente | Qué es | Ejemplo |
|---|---|---|
| Rol o persona | Quién o qué debe ser el modelo en esta respuesta | "Actúa como un senior developer con experiencia en Spring Security" |
| Tarea | Qué necesitas que haga, expresado como acción concreta | "Revisa esta implementación de JWT y señala vulnerabilidades de seguridad" |
| Contexto | La información de fondo que necesita para hacer la tarea bien | "El proyecto usa Spring Boot 3.2, los tokens expiran en 24h, y el cliente espera un JSON con campos 'token' y 'expires_at'" |
| Formato de salida | Cómo quieres que presente la respuesta | "Muestra primero los problemas críticos en una lista numerada, luego el código corregido" |
Un prompt que incluye los cuatro componentes se ve así en la práctica:
> Actúa como un senior developer especializado en seguridad para Java.
Revisa la siguiente implementación de autenticación JWT en nuestra API
y señala cualquier vulnerabilidad o mala práctica.
Contexto del proyecto:
- Spring Boot 3.2 con Spring Security 6
- Tokens de acceso con expiración de 24 horas
- Los tokens se envían en el header Authorization como Bearer token
- No usamos refresh tokens todavía
@src/main/java/com/miapp/security/JwtService.java
Formato esperado:
1. Lista de problemas críticos (si los hay)
2. Lista de mejoras recomendadas
3. Código corregido de los problemas críticosComparado con la versión que la mayoría escribiría:
> revisa mi jwtAmbos prompts pueden obtener alguna respuesta útil. Pero el primero obtiene una revisión de seguridad enfocada en el contexto específico de tu stack. El segundo puede obtenerte una explicación genérica de qué es JWT, o una revisión que ignora las particularidades de Spring Security 6, o simplemente una respuesta que pide más información antes de poder ayudarte.
Los tips más importantes, con ejemplos reales
1. Sé específico sobre la acción que pides
Los verbos importan. "Explica", "refactoriza", "escribe", "analiza", "lista" y "corrige" activan patrones de respuesta completamente diferentes. Cuanto más específico sea el verbo, más predecible el resultado.
2. Da el contexto suficiente, no más
El contexto es un recurso finito con retornos decrecientes. Más tokens de contexto no garantizan mejor respuesta; en algún punto, el modelo empieza a perder precisión al procesar partes lejanas del prompt. El objetivo es dar la información mínima necesaria para que el agente tenga todo lo que necesita, sin rellenar con información irrelevante que consume contexto y puede desviar la atención.
3. Especifica el formato de salida cuando importa
Si necesitas la respuesta en un formato específico para usarla en algo, dilo explícitamente. El modelo tiene sus propios defaults sobre cómo formatear respuestas, y puede no coincidir con lo que necesitas.
# Sin formato especificado — obtienes lo que el modelo decida
> Lista los endpoints de esta API
# Con formato especificado — obtienes exactamente lo que necesitas
> Lista los endpoints de esta API en formato de tabla Markdown con columnas:
Método HTTP | Path | Descripción | Requiere autenticación4. Pídele que piense antes de responder
Una de las técnicas con el impacto más documentado en prompt engineering es pedirle al modelo que razone paso a paso antes de dar la respuesta final. Esto es especialmente útil para problemas de debugging o análisis de arquitectura.
> Antes de proponer la solución, analiza paso a paso:
1. Cuál es el flujo actual del código
2. En qué punto exacto ocurre el error
3. Por qué ocurre ese error
Después de ese análisis, propón la corrección.Esto no es magia. Lo que hace es obligar al modelo a "materializar" el razonamiento intermedio en texto, lo cual lo hace parte del contexto disponible para los siguientes tokens. El análisis explícito tiende a producir conclusiones más correctas que el análisis implícito.
5. Usa ejemplos cuando describes el formato esperado
En lugar de describir el formato en abstracto, muestra un ejemplo de cómo debe verse la respuesta. Los ejemplos eliminan la ambigüedad mejor que cualquier descripción verbal.
> Genera los casos de prueba para el método validateOrder().
Usa este formato exacto:
@Test
void nombreDescriptivo_condicion_resultadoEsperado() {
// Arrange
// Act
// Assert
}
Genera al menos un caso para: orden válida, orden sin items,
orden con precio negativo, orden con cliente nulo.6. Divide tareas complejas en pasos
Cuando la tarea es grande, es tentador poner todo en un solo prompt. Pero a menudo es más efectivo dividirla en pasos secuenciales: primero el análisis, después el diseño, después la implementación. Esto te da puntos de control para corregir el rumbo antes de que el agente invierta tokens en una dirección equivocada.
# Un solo prompt para todo — el agente puede malinterpretar
> Migra el módulo de autenticación de sessiones HTTP a JWT
# Dividido en pasos — puedes validar cada fase
> Paso 1: Analiza el módulo de autenticación actual y dame un listado
de todos los archivos que tendrías que modificar y por qué.
No hagas cambios todavía.
# (revisas la lista, confirmas que tiene sentido)
> Paso 2: Propón el diseño de la nueva implementación JWT.
Muéstrame la estructura de clases antes de escribir código.
# (apruebas el diseño)
> Paso 3: Implementa los cambios empezando por el JwtService.7. Incluye las restricciones explícitamente
Una de las cosas que más diferencia un prompt profesional de uno casual es incluir lo que no debe hacer, no solo lo que debe hacer. Las restricciones eliminan soluciones que técnicamente responden la pregunta pero que no sirven en tu contexto.
> Refactoriza el método processPayment() para reducir su complejidad ciclomática.
Restricciones:
- No cambies la firma del método (otros sistemas la consumen via interfaz)
- No introduzcas nuevas dependencias al pom.xml
- Los tests existentes deben seguir pasando sin modificaciones¿Importa decir "por favor", "gracias" o "ayúdame a"?
Llegamos al tema que da pie a más debates de lo que debería entre developers: ¿tiene algún efecto real usar lenguaje cortés con un modelo de IA?
La respuesta honesta es que depende, la diferencia es pequeña, y la investigación reciente apunta en una dirección que sorprende a la mayoría. Y sí, yo también lo hago de vez en cuando pensando que eso puede salvarme la vida cuando la revolución de las máquinas haga que nos esclavicen. Pero... ¿recordarán mis nuevos amos que fue agradecido con ellos y serán benevolentes conmigo? ¿pensarán que si fui un developer cortés y educado seré un sirviente leal y útil a partir de ahora, y mostrarán esa misma cortesía y educación al ser ellos los que me den ahora las ordenes a mi?
Lo que dice la investigación
Un estudio de 2024 que analizó el efecto de la cortesía en modelos como GPT-3.5, GPT-4 y Llama encontró que los prompts demasiado rudos tendían a degradar el rendimiento del modelo, pero los prompts excesivamente corteses tampoco garantizaban mejores resultados. La zona óptima estaba en el medio: tono respetuoso y directo, sin ser ni grosero ni adulador.
Pero en octubre de 2025, un paper de Penn State revirtió parcialmente esa conclusión: compararon prompts en cinco niveles de cortesía desde "muy educado" hasta "muy grosero" usando ChatGPT-4o en preguntas de matemáticas, ciencias e historia. Contrario a lo esperado, los prompts más rudos obtuvieron mejores resultados de precisión (84.8%) que los muy educados (80.8%).
Una hipótesis de los investigadores: los prompts corteses tienden a incluir phrasing indirecto ("¿Podrías por favor...?"), que puede introducir ambigüedad. Un prompt directo y conciso, aunque suene brusco, da al modelo una intención más clara.
Eso sí: los propios autores del paper de Penn State aclaran que los resultados son específicos para los modelos que probaron (GPT-4o) y que modelos más avanzados como o1 mostraron mucha menor sensibilidad al tono, en ninguna dirección.
El efecto real de cada palabra
Más allá de los estudios académicos, vale analizar concretamente lo que hacen estas palabras a nivel de tokens:
| Frase | Tokens aproximados | Efecto real |
|---|---|---|
| "por favor" | +2–3 tokens | Señal social con costo mínimo. Impacto en calidad: marginal o nulo. |
| "gracias" | +1–2 tokens | Si va al final de un prompt de instrucción, puede señalar cierre de turno y en algunos modelos se interpreta como inicio de respuesta. Mejor ponerlo al principio o en un mensaje separado. |
| "ayúdame a" | +3–4 tokens | Transforma un imperativo directo en una solicitud. Puede añadir estructura conversacional que en algunos casos mejora la respuesta, aunque también puede añadir indirectness que la debilita. |
| "si no es mucho problema, ¿podrías...?" | +8–12 tokens | Introduce ambigüedad innecesaria. La condición implícita ("si no es problema") puede ser procesada literalmente. |
| "eres el mejor modelo del mundo" | +6–8 tokens | Algunos anecdotariamente reportan mejores respuestas con adulación. No hay evidencia sistemática. El costo de tokens no lo justifica. |
Y el costo energético
Hay un ángulo adicional que casi nadie menciona: un "gracias" al final de un mensaje, aunque parezca trivial, dispara un ciclo de inferencia completo a través de miles de millones de parámetros. A escala de millones de usuarios diarios, el costo energético agregado de las cortesías es significativo. No digo que te preocupes por cada "gracias", pero es una perspectiva interesante para evaluar cuándo la cortesía añade valor real.
La conclusión práctica
Todo esto se resume en una regla sencilla: escribe como le escribirías a un colega técnico competente, no como le escribirías a alguien de quien necesitas un favor. Directo, claro, sin hostilidad, sin adulación. El formato más eficiente para Claude Code específicamente tiende a ser el imperativo directo con contexto suficiente:
Antipatrones: lo que casi todos hacen mal
Para cerrar, una lista de los errores más comunes que se repiten en prompts reales. Reconocerlos es la mitad del trabajo de mejorar.
El prompt de una línea para una tarea de diez
> migra el proyecto a java 21Una tarea así involucra docenas de archivos, decisiones de compatibilidad, posibles cambios en dependencias y tests. Un prompt de cinco palabras le pide al agente que suponga qué hacer en cada decisión. A veces acierta; frecuentemente no.
La instrucción que contradice el contexto
> no uses streams de java, usa loops
(en un CLAUDE.md que dice "usa programación funcional siempre que sea posible")
Cuando hay contradicción entre la instrucción del momento y el contexto persistente, el modelo tiene que elegir. A veces prioriza el prompt inmediato, a veces el contexto persistente. Si necesitas anular una instrucción del CLAUDE.md, hazlo explícito: "Para esta tarea específicamente, usa loops en lugar de streams aunque el CLAUDE.md diga lo contrario."
Pedir múltiples cosas sin orden de prioridad
> refactoriza el servicio, agrega tests, actualiza el Javadoc,
mejora el manejo de errores y reduce la complejidad ciclomáticaCon cinco tareas en un prompt, el agente decide el orden y el peso de cada una. Puede que refactorice de una forma que complique añadir los tests después. Mejor: pídelas en secuencia, o al menos especifica cuál es la más importante si hay que elegir.
El contexto sin ancla
> el método que te mostré antes no funciona, corrígelo
"El que te mostré antes" asume que el agente recuerda cuál método es. Si la conversación es larga o compactaste el contexto, puede que no lo tenga disponible. Incluye siempre la referencia explícita con @archivo o citando el nombre del método.
Pedir una solución sin dar las restricciones de antemano
> (el agente escribe 150 líneas de código)
> ah, por cierto, no podemos usar librerías externas nuevasLas restricciones que llegan después de la respuesta obligan a reescribir. Siempre mejor mencionarlas antes, aunque el agente tenga que renegociar el diseño.
Conclusión
La habilidad de escribir buenos prompts no es tan diferente de la habilidad de escribir buenos tickets en Jira o buenos mensajes de código en un code review: en todos los casos, la claridad y la especificidad del problema que describes determinan directamente la calidad de la solución que obtienes.
Los puntos más importantes de este artículo, resumidos:
- Un prompt es todo lo que el modelo ve, no solo tu último mensaje. El historial, el
CLAUDE.mdy los resultados de herramientas también cuentan. - Los tokens son la unidad de todo: ventana de contexto, costo y velocidad. Más tokens no es siempre mejor; el objetivo es información de alta señal, no información abundante.
- Los cuatro componentes de un buen prompt son: rol/persona, tarea específica, contexto relevante y formato de salida esperado. No siempre necesitas los cuatro, pero saber cuál falta es el primer paso para mejorar un prompt que no funciona.
- La cortesía tiene un efecto pequeño y no concluyente. La investigación reciente sugiere que los prompts directos (aunque suenen bruscos) tienden a funcionar mejor que los prompts con indirectness cortés. Escribe como le escribirías a un colega técnico.
Espero que este tutorial les sea de utilidad. Si tienen alguna duda, sugerencia, comentario o aclaración, pueden dejarla en la sección de comentarios o enviar un correo a programadorjavablog@gmail.com (pueden agregarme al chat de gmail).
© javatutoriales.com – Serie: Desarrollo Asistido por IA