MENU
Tal vez esto te suena:
Copiar un correo y escribir "analízame esto". Sin más.
La respuesta llega. Regular. Vaga. No es lo que querías.
Y piensas: este modelo es un desastre.
Casi nunca lo es. El problema es que la petición es muy vaga e imprecisa: no le has dicho qué quieres que analice, con qué objetivo, ni en qué formato. El modelo no está dentro de tu cabeza sino que hace lo que le dices, ni más ni menos.
¿Y si el problema no fuera el modelo, sino cómo le hablas?
Esa es la idea alrededor de la que desarrollamos esta sesión de la Comunidad, en la que recorremos la ingeniería de prompts y de contexto: desde cómo está hecho un prompt por dentro hasta por qué tu modelo "se vuelve tonto" en las conversaciones largas, pasando por las técnicas que llevan años puliéndose y que hoy separan un resultado mediocre de uno que puedes meter en producción.
Un prompt es, sencillamente, las instrucciones que le das a un modelo.
Y la ingeniería de prompts es el arte (muy sencillo y muy difícil a la vez) de escribir esas instrucciones para que el modelo entienda exactamente qué buscas.
Lo sencillo: darle un objetivo claro con instrucciones concisas. Lo difícil: tener tú mismo claro qué quieres, que muchas veces es lo que de verdad cuesta. Cuando das vueltas media hora a un prompt sin acertar, casi siempre es porque todavía no has terminado de definir qué esperas.
De ahí sale la regla número uno, poco intuitiva:
Un buen prompt suele ser bastante largo, porque tiene que ser detallado.
"Mira a ver si soy buena candidata para esta oferta" es un prompt vago; "compara mi experiencia con los requisitos y dime qué me falta, como haría un reclutador especializado" empieza a ser útil.
Todo prompt tiene dos capas.
El system prompt es el que fija las reglas, el formato y lo que el modelo puede o no puede hacer. En el chat que usas a diario no lo ves ni lo tocas: lo pone el fabricante. Es la razón por la que a veces un modelo se niega a responder (el ejemplo extremo son los modelos más potentes, a los que su propio system prompt les prohíbe ayudar con temas sensibles como armas o ciberseguridad). Pero si construyes tu propia aplicación vía API, ese system prompt sí es tuyo (o al menos una de las capas que lo componen): es lo que convierte un modelo genérico en "el chatbot de mi tienda que solo habla de mis productos".
El user prompt es tu petición concreta, la que cambia en cada mensaje.
En la sesión, aterrizamos la diferencia entre usar la IA en el chat (para explorar y pulir ideas) y usarla vía API para producción, con ejemplos de proyectos reales de la Comunidad.
Un repaso de las principales técnicas de prompting que conviene tener en el vocabulario:
Lo interesante es que muchas de estas técnicas ya vienen "de fábrica" en los modelos modernos pero en ocasiones sigue siendo interesante depurar un prompt en lugar de usar un modelo súper potente.
Escribir buenos prompts es importante. Pero la gestión del contexto lo es más.
El contexto no es solo tu prompt: es tu prompt más todo el histórico de la conversación, más los documentos que adjuntas, más las herramientas que le das.
Es toda la información a la que accede un modelo del lenguaje para generar tu respuesta.
Y es un recurso finito que se degrada.
Aunque un modelo presuma de un millón de tokens, su ventana efectiva puede llegar a ser bastante menor de lo que parece.
En la sesión, vemos por qué el contexto es tan importante e impacta tanto en la calidad de las respuestas del modelo, los cuatro modos de fallo relacionados con el contexto y qué hacer cuando una conversación se enturbia (la respuesta es menos evidente de lo que parece).
Un recorrido completo por la ingeniería de prompts y de contexto, con demos en directo:
Probablemente te reconozcas en alguno de estos perfiles:
Usas ChatGPT, Claude o Gemini a diario, a veces te dan justo lo que quieres y a veces no, y no sabes muy bien por qué. Esto es para ti.
Quieres pasar de "hablar con la IA" a construir algo con ella (una automatización, un pequeño producto) y necesitas que los resultados sean fiables y repetibles. Esto también es para ti.
Has oído hablar de RAG, few-shot, prompt injection o context engineering, te suenan a jerga, y quieres que alguien te lo ordene con ejemplos reales y demos en directo. Esto sobre todo es para ti.
La sesión completa, con las demos en directo y el resto del archivo de sesiones de la Comunidad, está disponible para miembros.
🎥 La encontrarás a continuación.
Estas son algunas de las preguntas que surgieron en directo, resumidas para quien llegue buscando respuestas rápidas.
Sí, aunque con matices. Un proyecto te evita repetir tus instrucciones y documentos en cada conversación; cuando ese material es mucho, la herramienta recupera lo relevante en vez de leerlo entero (de ahí que se parezca a un RAG), y por eso a veces se le escapa justo lo que necesitas.
Al 100%: es la forma natural de tratar los prompts como código y reutilizarlos en vez de reescribirlos cada vez. Y tiene sentido tener uno por modelo, porque las buenas prácticas cambian de Opus 4.8 a Fable 5. De hecho, en Microsoft Copilot ya existe un agente de serie para hacer esto.
La pregunta de la Comunidad, planteada con una cita de Lisa Simpson: "¿quién es la policía de la policía?". En pocas palabras: el juez debería ser más potente que el modelo evaluado, y casi todo se reduce a un equilibrio de costes.
Los que repitió el grupo: pedir salida estructurada, usar delimitadores (etiquetas XML o triples comillas invertidas) para separar instrucciones de datos, resumir en bullets una conversación larga antes de abrir otra, apoyarse en ficheros de memoria tipo CLAUDE.md / AGENTS.md y no tener miedo a resetear y empezar de cero, sobre todo programando.