AI Prompting: El Proceso de Pensamiento

¿Cuál es la mejor forma de aprender prompting?

Antes de hablar de técnicas, vale la pena empezar con una pregunta más fundamental: ¿qué estás haciendo realmente cuando escribes un prompt?

La mayoría de recursos enseñan prompting como un catálogo de técnicas — Chain of Thought, few-shot, role prompting. Son útiles, pero son herramientas. Aprender herramientas sin entender el problema que resuelven limita tu capacidad de adaptarte cuando encuentras algo nuevo.

Lo que realmente escala es un proceso de pensamiento que puedas ejecutar cada vez que interactúas con un LLM. Las técnicas se vuelven derivaciones naturales de ese proceso. Este documento es, justamente, ese proceso — cada sección es un paso, cada diagrama un checkpoint mental.

Paso 0: Calibrar el modelo mental

Antes de escribir un solo prompt, necesitas una representación precisa de qué es un LLM y cómo opera:

      flowchart LR
        A["Le hago una pregunta
y me da una respuesta"]
        B["Le doy una especificación
y genera el output más probable
dado esa especificación"]
        A -- "→" --> B

        style A fill:#fff,stroke:#d0d0d0,color:#999,stroke-width:1px,rx:10,ry:10
        style B fill:#f5f5f5,stroke:#888,color:#333,stroke-width:1.5px,rx:10,ry:10

Esta distinción tiene implicaciones directas en cómo estructuras tu comunicación:

Tres propiedades del sistema que condicionan todo lo demás:

1. El modelo solo opera sobre lo explícito. No tiene acceso a tu intención. Información que no está codificada en el prompt no existe para el sistema.

2. Siempre genera output. No tiene mecanismo para señalar "información insuficiente". Llena gaps con la distribución más probable — que tiende hacia lo genérico.

3. Interpreta literalmente. "Hazlo bien" no tiene resolución semántica útil. "Genera una tabla con 3 columnas: problema, impacto, solución" sí.

Para reflexionar: Si el modelo solo trabaja con lo que recibe explícitamente, ¿qué información necesita tener para producir exactamente lo que quieres?

CHECKPOINT Pregúntate: Lo que estoy escribiendo, ¿es una pregunta abierta o una especificación con resultado definido?

Paso 1: Definir el resultado antes de escribir el prompt

El error más frecuente en prompting no es técnico — es comenzar a escribir sin haber definido el criterio de éxito. Si tu intención es difusa, tu especificación va a ser difusa, y el output va a converger hacia lo genérico.

      flowchart TD
        A["¿Puedo describir en una oración
qué constituye un
resultado exitoso?"]
        A -->|"SÍ"| B["Esa oración se convierte
en tu criterio de evaluación"]
        A -->|"NO"| C["Vale la pena definirlo primero.
La claridad previa al prompt
es lo que más impacta el output."]
        C -.->|"clarifica"| A

        style A fill:#f5f5f5,stroke:#888,color:#333,stroke-width:1.5px,rx:10,ry:10
        style B fill:#eef7ee,stroke:#8cb88c,color:#333,stroke-width:1px,rx:10,ry:10
        style C fill:#fff,stroke:#d0d0d0,color:#666,stroke-width:1px,rx:10,ry:10

En la práctica:

Intención difusa:  "Quiero aprender sobre bases de datos"

     ↓ (aplica: ¿qué resultado exitoso se ve?)

Resultado definido: "Una comparación de PostgreSQL vs MySQL
                     para una app SaaS multi-tenant con <1000 usuarios,
                     en formato de tabla con 5 criterios operacionales"

     ↓

El prompt se estructura naturalmente cuando el resultado está definido.

Para reflexionar: ¿Notas cómo la segunda versión elimina prácticamente toda la ambigüedad? El modelo ya no tiene que inferir qué tipo de comparación, para qué contexto, en qué formato. Eso es lo que hace la diferencia.

CHECKPOINT Define tu resultado exitoso en una oración. Si cuesta formularlo → la tarea necesita más claridad antes de convertirse en prompt.

Paso 2: Los 5 filtros de completitud

Tienes tu resultado definido. Ahora vas a escribir el prompt. Antes de enviarlo, pásalo por estos 5 filtros — cada uno que falta es un grado de libertad que el modelo resolverá con lo más probable (lo más genérico):

      flowchart TD
        P["TU PROMPT
(borrador)"]
        P --> F1
        P --> F2
        P --> F3
        P --> F4
        P --> F5

        F1["Filtro 1
¿Verbo de acción preciso?
Analiza · Compara · Genera"]
        F2["Filtro 2
¿Contexto relevante?
Stack · Proyecto · Audiencia"]
        F3["Filtro 3
¿Formato de salida?
Tabla · JSON · Bullets"]
        F4["Filtro 4
¿Exclusiones definidas?
Sin intro · Máx N"]
        F5["Filtro 5
¿Criterio de evaluación?
¿Es medible?"]

        F1 --> R["PROMPT LISTO"]
        F2 --> R
        F3 --> R
        F4 --> R
        F5 --> R

        style P fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1.5px,rx:12,ry:12
        style R fill:#eef7ee,stroke:#8cb88c,color:#333,stroke-width:1.5px,rx:12,ry:12
        style F1 fill:#fff,stroke:#d0d0d0,color:#333,stroke-width:1px,rx:8,ry:8
        style F2 fill:#fff,stroke:#d0d0d0,color:#333,stroke-width:1px,rx:8,ry:8
        style F3 fill:#fff,stroke:#d0d0d0,color:#333,stroke-width:1px,rx:8,ry:8
        style F4 fill:#fff,stroke:#d0d0d0,color:#333,stroke-width:1px,rx:8,ry:8
        style F5 fill:#fff,stroke:#d0d0d0,color:#333,stroke-width:1px,rx:8,ry:8

Para reflexionar: Estos 5 filtros no son específicos de LLMs. Son los mismos criterios de una buena delegación en cualquier contexto — definir la tarea, dar contexto, especificar formato, establecer límites, y tener forma de evaluar el resultado. La diferencia es que un LLM, a diferencia de un colega, nunca va a pedirte clarificación. Simplemente infiere.

CHECKPOINT Pasa cada prompt no-trivial por los 5 filtros. Se automatiza con la repetición — al principio vale la pena hacerlo de forma consciente.

Paso 3: Diagnóstico de fallos — las técnicas como compensaciones

Enviaste tu prompt y el resultado no es lo que esperabas. Aquí es donde la mayoría reescribe el prompt intuitivamente. Pero hay un enfoque más preciso: diagnosticar qué tipo de fallo ocurrió, porque cada tipo tiene una compensación específica.

      flowchart TD
        O["RECIBES EL OUTPUT"]
        O -->|"Es lo que querías"| OK["Extrae el patrón
Guárdalo como template"]
        O -->|"No es lo que querías"| D["¿Qué tipo
de fallo es?"]

        D --> D1["Razonamiento
débil"]
        D --> D2["Formato
incorrecto"]
        D --> D3["Superficial
o genérico"]
        D --> D4["Longitud
incorrecta"]
        D --> D5["Falta
información"]

        D1 --> R1["+ Chain of Thought"]
        D2 --> R2["+ Few-shot examples"]
        D3 --> R3["+ Role prompting"]
        D4 --> R4["+ Restricciones"]
        D5 --> R5["+ Contexto / RAG"]

        R1 --> RE["Reescribe con
el ajuste específico"]
        R2 --> RE
        R3 --> RE
        R4 --> RE
        R5 --> RE

        RE -.->|"reenvía"| O

        style O fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1.5px,rx:12,ry:12
        style OK fill:#eef7ee,stroke:#8cb88c,color:#333,stroke-width:1px,rx:10,ry:10
        style D fill:#f5f5f5,stroke:#888,color:#333,stroke-width:1.5px,rx:10,ry:10
        style RE fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1.5px,rx:12,ry:12
        style D1 fill:#fff,stroke:#d0d0d0,color:#555,stroke-width:1px,rx:8,ry:8
        style D2 fill:#fff,stroke:#d0d0d0,color:#555,stroke-width:1px,rx:8,ry:8
        style D3 fill:#fff,stroke:#d0d0d0,color:#555,stroke-width:1px,rx:8,ry:8
        style D4 fill:#fff,stroke:#d0d0d0,color:#555,stroke-width:1px,rx:8,ry:8
        style D5 fill:#fff,stroke:#d0d0d0,color:#555,stroke-width:1px,rx:8,ry:8
        style R1 fill:#f9f9f9,stroke:#bbb,color:#555,stroke-width:1px,rx:20,ry:20
        style R2 fill:#f9f9f9,stroke:#bbb,color:#555,stroke-width:1px,rx:20,ry:20
        style R3 fill:#f9f9f9,stroke:#bbb,color:#555,stroke-width:1px,rx:20,ry:20
        style R4 fill:#f9f9f9,stroke:#bbb,color:#555,stroke-width:1px,rx:20,ry:20
        style R5 fill:#f9f9f9,stroke:#bbb,color:#555,stroke-width:1px,rx:20,ry:20

Este es el punto clave: cada técnica de prompting es la compensación natural para una limitación específica del modelo. Cuando lo ves desde esta perspectiva, las técnicas se derivan del diagnóstico — no se memorizan de un catálogo:

Observas en el output Limitación subyacente Compensación
Salta a conclusiones sin justificación El modelo optimiza brevedad sobre razonamiento Chain of Thought — forzar pasos intermedios explícitos
Contenido correcto, estructura incorrecta Las instrucciones verbales son ambiguas para definir formato Few-shot — los ejemplos definen el patrón con mayor precisión
Respuesta correcta pero genérica, sin profundidad La distribución por default es generalista Role prompting — filtrar hacia una distribución de expertise específica
Se extiende sin control o es demasiado breve No tiene restricciones de alcance Definir límites explícitos (longitud, exclusiones, scope)
Le falta información que no está en su training El modelo no puede acceder a datos que no tiene Inyectar contexto directamente en el prompt (RAG)

Para reflexionar: ¿Ves cómo este enfoque es más robusto que memorizar técnicas? Si entiendes la limitación que cada técnica compensa, puedes adaptarlas o crear variaciones propias cuando encuentres un tipo de fallo nuevo.

CHECKPOINT Cuando un output no es lo esperado, diagnostica antes de reescribir. El tipo de fallo te indica exactamente qué ajustar.

Paso 4: Escalar — de prompt individual a pipeline

Una vez que el loop de un solo prompt es fluido, la siguiente pregunta natural es: ¿qué hago cuando la tarea excede la capacidad de un prompt individual?

La respuesta es componer prompts. Hay tres niveles de composición:

NIVEL 1 — Prompt aislado

          flowchart LR
            P["Prompt"] --> R["Resultado"]
            style P fill:#f0f0f0,stroke:#888,color:#333,rx:10,ry:10
            style R fill:#eef7ee,stroke:#8cb88c,color:#333,rx:10,ry:10

NIVEL 2 — Pipeline

          flowchart LR
            P1["P1"] --> P2["P2"] --> P3["P3"]
            style P1 fill:#f0f0f0,stroke:#888,color:#333,rx:10,ry:10
            style P2 fill:#f0f0f0,stroke:#888,color:#333,rx:10,ry:10
            style P3 fill:#eef7ee,stroke:#8cb88c,color:#333,rx:10,ry:10

NIVEL 3 — Sistema autónomo

      flowchart LR
        A["Observa"] --> B["Decide"] --> C["Actúa"] --> A

        style A fill:#f0f0f0,stroke:#888,color:#333,rx:10,ry:10
        style B fill:#f0f0f0,stroke:#888,color:#333,rx:10,ry:10
        style C fill:#f0f0f0,stroke:#888,color:#333,rx:10,ry:10

La mayoría de tareas profesionales se resuelven bien en el Nivel 1 ejecutado con rigor. Las tareas complejas viven en el Nivel 2. El Nivel 3 (agents) es donde todo converge, pero no es prerequisito para obtener valor significativo.

Para reflexionar: ¿Hay alguna tarea recurrente en tu trabajo donde descomponer en 2-3 prompts secuenciales mejoraría la calidad del resultado final?

CHECKPOINT Si una tarea se siente demasiado amplia para un prompt → probablemente lo es. Diseña la secuencia antes de escribir cualquier prompt individual.

Paso 5: El loop de competencia

Todo este proceso se internaliza con práctica deliberada sobre tareas reales:

      flowchart LR
        A["Tarea
real"] --> B["Resultado
definido"] --> C["5 filtros
al prompt"] --> D["Envía"]
        D --> E["Diagnostica"]
        E -->|"Ajusta"| C
        E -->|"✓ OK"| F["Extrae
template"]

        style A fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1.5px,rx:10,ry:10
        style B fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1px,rx:10,ry:10
        style C fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1px,rx:10,ry:10
        style D fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1px,rx:10,ry:10
        style E fill:#f5f5f5,stroke:#888,color:#333,stroke-width:1.5px,rx:10,ry:10
        style F fill:#eef7ee,stroke:#8cb88c,color:#333,stroke-width:1px,rx:10,ry:10

Para reflexionar: ¿Cuál es la tarea que más repites en tu trabajo diario? Esa es tu campo de práctica óptimo — porque la iteración sobre un problema real que te importa es más efectiva que cualquier ejercicio artificial.

El principio unificador

      flowchart LR
        A["Claridad
de intención"] --> B["Precisión
de spec"] --> C["Calidad
de output"]

        style A fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1.5px,rx:10,ry:10
        style B fill:#f0f0f0,stroke:#888,color:#333,stroke-width:1.5px,rx:10,ry:10
        style C fill:#eef7ee,stroke:#8cb88c,color:#333,stroke-width:1.5px,rx:10,ry:10

Cuando la intención es clara, la especificación es precisa, y el output es predecible. Prompting es, en esencia, claridad de pensamiento aplicada a un medio específico.

Las técnicas son compensaciones útiles para limitaciones concretas del sistema. Pero el fundamento es más simple: la capacidad de articular con precisión qué quieres antes de pedirlo. Esa capacidad mejora cómo escribes specs, cómo delegas, cómo estructuras problemas. El prompting mejora como consecuencia natural.

Seguir explorando

¿Cómo cambia la estrategia de prompting entre modelos con capacidades distintas? Un prompt óptimo para Claude no es necesariamente óptimo para GPT-4 o Gemini. ¿Qué propiedades del modelo determinan qué técnicas funcionan mejor, y cómo se detectan empíricamente?

¿Existe un framework formal para medir la calidad de un prompt de forma objetiva? Más allá de "me gustó el output" — ¿cómo se diseñan evaluaciones reproducibles, métricas de consistencia, y benchmarks para comparar variantes de un mismo prompt?

¿Cuál es la relación entre la longitud del contexto y la degradación de atención del modelo? Los LLMs tienen context windows grandes, pero no procesan toda la información con la misma fidelidad. ¿Dónde se pierde señal, y cómo se estructura un prompt largo para minimizar esa pérdida?

¿Cómo se diseña un system prompt que sea robusto ante variaciones de input del usuario? Un system prompt que funciona para un caso se rompe con otro. ¿Qué principios de diseño hacen que un system prompt sea estable sin ser restrictivo?

¿Qué diferencia estructural hay entre un prompt que genera código correcto y uno que genera código que parece correcto? La tasa de errores sutiles en code generation es alta. ¿Qué patrones de prompt reducen errores lógicos, no solo errores sintácticos?

¿Cómo se implementa un pipeline de evaluación automática para prompts en producción? Cuando un prompt se usa miles de veces, la evaluación manual no escala. ¿Qué arquitecturas existen para monitorear calidad de output, detectar drift, y triggear re-optimización?

¿Cuándo es más efectivo inyectar conocimiento vía few-shot examples vs vía contexto RAG, y por qué? Ambos aportan información al modelo, pero por mecanismos distintos. ¿Cuál tiene mejor signal-to-noise ratio para qué tipos de tarea?

¿Cómo se diseña un agent loop que sea predecible sin ser rígido? Los sistemas agénticos tienden al caos o a la sobre-restricción. ¿Qué patrones arquitectónicos producen comportamiento autónomo pero confiable?

¿Qué técnicas de prompt optimization existen más allá de la iteración manual? DSPy, automatic prompt engineering, constitutional AI — ¿cómo funcionan, cuándo justifican su complejidad, y qué trade-offs introducen?

¿Cómo interactúan las restricciones de seguridad (RLHF, constitutional training) con la efectividad del prompt? El modelo no es solo un predictor de tokens — tiene capas de alineamiento que modifican su comportamiento. ¿Cómo se trabaja con esas restricciones en vez de contra ellas?