Patrones de Prompt Engineering que sí funcionan: de prompts ingenuos a sistemas de prompts

17 de julio de 2026 · 9 min de lectura · Prompt Engineering

Jose Chirinos Ingeniero de IA y Software

La mayoría de los prompts que me he encontrado en producción — incluidos muchos de los míos al principio — eran prompts ingenuos. No porque alguien fuera flojo, sino porque el prompt engineering parece escribir texto y en realidad es diseño de interfaces, y a pocos nos enseñaron a tratarlo así.

Me dedico a construir sistemas de IA agéntica. Mi plataforma personal, Jarvis, orquesta agentes sobre Claude y Gemini mediante tool-calling con MCP, con pipelines de RAG y suites de evals por detrás. Y aplico mi propia medicina: antes de construir algo serio, primero le pregunto a Jarvis — «¿cuál es la mejor forma de lograr esto? ¿cómo crees que deberíamos abordarlo?». Me propone varios enfoques distintos, elijo el más fuerte, y ese se convierte en el prompt maestro que realmente ejecuto. Cada problema de confiabilidad que he depurado en ese sistema se remonta a una misma causa raíz: un prompt que le pedía al modelo adivinar en lugar de decirle cuál era el trabajo.

Este post es un recorrido por los patrones de prompt que uso de verdad — el patrón de persona, el patrón de entrevista (interview pattern), chain of thought, tree of thought — con una evaluación honesta de lo que cada uno ha hecho por mí, lo que no, y cuándo la estructura extra se pagó sola. Una cosa antes de empezar: estas son notas de campo, no leyes. Los modelos cambian rápido, gente muy capaz opina distinto sobre todo esto, y cada afirmación de aquí merece ponerse a prueba contra tu propio stack.

Cómo se ve el prompting ingenuo (y por qué falla en producción)

Un prompt ingenuo es una petición sin contrato:

Resume este feedback de clientes.

Se lee bien. Incluso funciona — a veces. Ese «a veces» es el problema. Córrelo cien veces dentro de un pipeline y obtendrás bullets, párrafos, cinco ítems, doce ítems, resúmenes en inglés de feedback en español, y de vez en cuando un preámbulo servicial tipo «¡Aquí está tu resumen!» que te rompe el parser de JSON a las 2 a. m.

Los prompts ingenuos fallan de tres maneras predecibles:

1. Ambigüedad — el modelo rellena las decisiones no especificadas (longitud, formato, idioma, audiencia) con lo que sea estadísticamente probable, y «estadísticamente probable» cambia entre ejecuciones y versiones del modelo.
2. Sin restricciones — nada le dice al modelo qué no hacer, así que servicialmente hace cosas extra que nunca le pediste.
3. Sin contrato de salida — el código downstream espera una forma; el prompt nunca prometió ninguna.

La solución no son palabras mágicas. Es la misma disciplina que aplicarías al diseño de cualquier API: definir entradas, salidas y comportamiento en la frontera.

Eres un analista de producto senior que convierte feedback
crudo de clientes en decisiones de roadmap.

Resume el feedback de clientes de abajo para un product manager
que está decidiendo el roadmap del próximo trimestre.

Reglas:
- Devuelve exactamente 3 bullets, de máximo 20 palabras cada uno.
- Cada bullet nombra el área de producto y el dolor del usuario.
- Mantén el idioma original del feedback.
- Si el texto no contiene feedback accionable, devuelve "NO_SIGNAL".

Bullet de ejemplo:
- Checkout: los usuarios abandonan el carrito porque el pago
  falla en móvil.

Feedback:
"""
{feedback}
"""

La misma tarea. Pero ahora el rol, la longitud, el formato, la audiencia, el caso borde y el modo de fallo están todos especificados — y un ejemplo fija la forma de la salida. Ese es todo el juego: un prompt es una interfaz, y las interfaces necesitan contratos. Todo lo demás en este post es un patrón construido sobre esa idea.

El patrón de persona: bastante útil, pero malinterpretado

El patrón de persona es el que todo el mundo aprende primero: «Actúa como un ingeniero de seguridad senior…». Y esta es mi opinión honesta después de usarlo en producción: el patrón de persona es bastante útil — pero se le suele pedir un trabajo que nunca iba a hacer.

En mis pruebas, ponerle «eres un experto» a un prompt no ha hecho al modelo más inteligente — fue entrenado con los mismos datos de todas formas. Lo que una persona sí me ha cambiado de forma confiable es el punto de vista: el tono, el vocabulario, las prioridades y a qué decide prestarle atención el modelo.

Revisa este código Dart.

Eres un ingeniero Flutter senior revisando código Dart de una
app en producción con expectativas de escala de 400M de
usuarios. Te importan: la correctitud del manejo de estado, el
costo de rebuild de los widgets y los casos borde de
null-safety. No comentas sobre formato ni nombres.

Revisa el código de abajo. Para cada problema: cita la línea,
explica el escenario de fallo y califica la severidad
(bloqueante / conviene-arreglar / detalle).

El segundo prompt funciona — pero fíjate bien por qué. La persona («un ingeniero Flutter senior en una app en producción») aporta el lente. La ganancia real de calidad viene de las restricciones y del contrato de salida que están debajo. Quita la persona y deja las reglas, y pierdes un poco de foco. Deja la persona y quita las reglas, y estás otra vez lanzando una moneda.

Dónde las personas sí se ganan su lugar:

• Tono y ajuste a la audiencia — escribir para ejecutivos vs. escribir para ingenieros.
• Vocabulario de dominio — una persona de «especialista en documentación clínica» hace aflorar de forma confiable la terminología correcta.
• Separación de roles multiagente — este es el grande. En Jarvis, el system prompt de cada agente es una persona: un planificador que solo planifica, un investigador que solo recupera y cita, un crítico que solo ataca el plan. Ahí la persona no es decoración; es el mecanismo que mantiene a cada agente dentro de su carril.

Usa personas para fijar el punto de vista. Usa contratos para conseguir la calidad.

El patrón de entrevista: haz que el modelo te entreviste a ti

Este es uno de los patrones sobre los que menos se escribe, y es al que más recurro cuando los requisitos están difusos: invierte la dirección de la conversación. En lugar de meter todo lo que sabes en un mega-prompt y cruzar los dedos, dile al modelo que te interrogue a ti primero.

Necesito una política de retención de datos para una app móvil
que almacena mediciones relacionadas con la salud.

Antes de escribir nada, entrevístame: hazme preguntas de una en
una, hasta que tengas suficiente información para redactar una
política que un revisor de compliance aceptaría. Empieza por la
pregunta de mayor impacto. No empieces a redactar hasta que yo
diga "adelante".

Por qué funciona: el modelo ha visto miles de políticas de retención de datos. Sabe qué decisiones importan — jurisdicciones, categorías de datos, SLAs de borrado, procesadores externos — mejor de lo que tú puedes enumerarlas de memoria. El patrón de entrevista convierte el checklist latente del modelo en preguntas, y tus respuestas se convierten en la especificación.

Cuándo le gana al enfoque del mega-prompt: en cualquier tarea donde tú eres el cuello de botella de requisitos desconocidos — decisiones de arquitectura, planes de migración, documentos con aristas legales, alcance de proyectos. Cuándo no: en tareas que ya especificaste por completo de antemano. La entrevista sirve para descubrir la especificación, no para ejecutarla.

Hay aquí un meta-punto que vale la pena transparentar: este artículo — su audiencia, su estrategia de idiomas, incluso qué opiniones aparecen en él — se definió usando exactamente este patrón. Una IA me entrevistó, un lote de decisiones concretas a la vez, antes de que existiera un solo párrafo. El patrón no es un truco de fiesta; así es como empiezo la mayoría de mi trabajo serio con IA.

Prompting con chain of thought: mayormente absorbido por los modelos frontera

El prompting con chain of thought — «piensa paso a paso» — fue la técnica de la era temprana de los LLM, y produjo ganancias reales: forzar pasos intermedios de razonamiento mejoraba de forma medible las matemáticas, la lógica y las preguntas multi-hop.

Mi experiencia en 2026, en las cargas de trabajo que yo corro: los modelos frontera de razonamiento ya absorbieron la mayor parte. Claude, las variantes con thinking de Gemini y sus pares hoy ejecutan razonamiento interno extendido sin que se los pidas. En las tareas que he medido, pedirles que «piensen paso a paso» se sintió como decirle a un motor de ajedrez que «considere sus movimientos» — el consejo llegó unos años tarde. Pero esos son mis datos; tus tareas pueden decir otra cosa, y el experimento es barato de repetir.

El CoT explícito todavía se gana el sueldo en tres lugares:

1. Trazas de auditoría. Cuando una decisión necesita ser revisable — un bot de triaje justificando niveles de severidad, un pipeline de filtrado que compliance va a inspeccionar — quieres el razonamiento en la salida, no escondido dentro del modelo.

Clasifica la severidad de este ticket de soporte (P1-P4).

Formato de salida:
razonamiento: 2-4 oraciones citando frases específicas del ticket
severidad: P1 | P2 | P3 | P4
confianza: alta | media | baja

2. Salidas intermedias estructuradas. Forzar una descomposición específica («primero extrae las entidades, luego mapea las relaciones, luego responde») no es realmente CoT — eres tú diseñando el algoritmo y el modelo ejecutando cada paso. Esa estructura todavía vale la pena especificarla de forma explícita.

3. Modelos pequeños y locales. Los modelos sub-frontera y on-device no absorbieron la técnica. Si estás enrutando las tareas fáciles a un modelo barato — y deberías estar haciéndolo — tu andamiaje de CoT de repente vuelve a importar.

Así que mi sugerencia — sugerencia, no mandamiento: antes de ponerle «piensa paso a paso» por defecto a un modelo frontera, pregúntate qué razonamiento necesitas visible, ponlo en el contrato, y deja que tus evals decidan si el andamiaje todavía se gana sus tokens.

Prompting con tree of thought: ramas, puntajes y un costo alto

Tree of thought extiende el CoT de una línea a un árbol: genera varios caminos candidatos de razonamiento, evalúalos, expande los prometedores y poda el resto. En su forma de investigación es un algoritmo de búsqueda sobre estados de razonamiento, y puedes aproximarlo en un solo prompt:

Propón 3 arquitecturas fundamentalmente distintas para sync
offline-first en una app móvil de estado compartido entre dos
usuarios.

Para cada una: describe el enfoque en 3 oraciones y luego
puntúala del 1 al 10 en: complejidad de resolución de conflictos,
costo de batería/red y tiempo hasta lanzar. Después elige una
ganadora y defiende la elección frente a la opción rival más
fuerte.

Esa es la versión honesta y de bajo presupuesto — y para la mayoría de las decisiones alcanza. La versión cara es donde tree of thought se pone interesante para mí: las ramas no tienen que vivir en una sola ventana de contexto. En un sistema multiagente, cada rama puede ser su propio agente explorando una hipótesis en paralelo, con un agente juez puntuando los resultados. Tree of thought, implementado como orquestación, es una técnica real de producción — así es, en esencia, como Jarvis despliega alternativas en paralelo frente a problemas difíciles.

El problema es el costo. Cada rama son tokens, y la mayoría de las ramas se descartan — ese es justamente el punto del patrón. Úsalo para decisiones donde equivocarse sale caro: elecciones de arquitectura, diseños de seguridad, cualquier cosa para la que normalmente reunirías a tres ingenieros senior a discutir. No lo uses para escribir un mensaje de commit.

Cómo elegir un patrón de prompt: la guía rápida de 30 segundos

Una advertencia honesta: esta tabla es cómo decido yo hoy, no un estándar. Otras tareas, otros modelos y otros equipos moverán estas líneas — y justo por eso la siguiente sección es sobre medir en lugar de confiar en los valores por defecto, incluidos los míos.

Prompt engineering en producción: los recibos

Todo lo de arriba está corriendo en Jarvis hoy, y los recibos son medibles. El más claro: la ingeniería de contexto — ser deliberado con lo que entra a la ventana de contexto del modelo, respaldado por guardarraíles deterministas — recortó mis costos de inferencia en aproximadamente un 30%. No fue un modelo nuevo ni un cambio de precios; las mismas tareas, con prompts y contexto de ingeniería en lugar de ingenuos.

La otra lección de correr una suite de evals contra mis propios prompts: mi intuición sobre qué prompt es «mejor» se equivoca con la frecuencia suficiente como para que dejara de confiar en ella. Los cambios de prompt se lanzan como cambios de código: medidos, no por sensaciones. Si te llevas una sola cosa de este post, que sea esa: los patrones te dan un buen primer borrador de un prompt; los evals te dicen la verdad sobre él.

FAQ: las preguntas que de verdad me hacen

¿El patrón de persona mejora la precisión?

En mis pruebas, en tareas de razonamiento no — el modelo fue entrenado con los mismos datos, lo llames experto o no. Lo que las personas cambian de forma confiable es el punto de vista: el tono, el vocabulario y a qué le presta atención el modelo. En mis proyectos, las ganancias de precisión que se les suelen atribuir a las personas casi siempre vinieron de las restricciones y los contratos de salida escritos debajo de ellas.

¿El prompt engineering está muerto?

Desde donde yo lo veo: la era de las palabras mágicas se está apagando; la era de la ingeniería, no. El prompt engineering se está profesionalizando hacia diseño de interfaces, orquestación y medición — las partes que siempre fueron ingeniería. Que los modelos absorbieran el chain of thought jubiló una técnica, no la disciplina.

¿Debería seguir usando prompting con chain of thought en 2026?

Mi regla práctica: con modelos frontera, principalmente cuando necesitas el razonamiento visible — trazas de auditoría, decisiones revisables, descomposiciones que diseñas tú mismo. Con modelos pequeños y locales, sí: en mi experiencia nunca absorbieron la técnica, así que el andamiaje de CoT todavía hace trabajo real ahí. En ambos casos, yo trataría «piensa paso a paso» como una hipótesis para evaluar, no como un conjuro.

Arregla los prompts antes de actualizar el modelo

Si estás construyendo funcionalidades con IA y tus prompts todavía se parecen a los ejemplos ingenuos de arriba, eso tiene arreglo — y el arreglo suele costar menos que la actualización de modelo que estabas considerando en su lugar.

Sobre el autor — Jose Chirinos Ingeniero de IA y Software con más de 10 años lanzando productos para Pinterest, Netflix, Intel y United Airlines a escala de más de 400M de usuarios. Hoy especializado en IA agéntica — orquestación multiagente, MCP y RAG — y creador de Jarvis, una plataforma agéntica personal que orquesta Claude y Gemini.