Ingeniería de prompts avanzada

Encadenar prompts

Una tarea compleja ejecutada en un solo prompt monolítico falla con más frecuencia que una cadena de prompts simples, cada uno con una sola responsabilidad. El principio: dividir, y pasar la salida de uno como entrada del siguiente.

Ejemplo: "escribe un artículo SEO completo" da algo tibio. Una cadena da algo sólido:

1. Prompt 1: investigar y listar los ángulos + palabras clave.
2. Prompt 2: a partir de esa lista, producir un esquema detallado.
3. Prompt 3: redactar sección por sección a partir del esquema.
4. Prompt 4: revisar y corregir (un agente crítico).

Cada eslabón es verificable y corregible de forma independiente. Es también la base mental de los flujos de trabajo multi-agente: un pipeline donde cada paso es un agente especializado. La regla de Pierre "Opus para la arquitectura, Haiku para lo repetitivo" se aplica aquí: se encadena asignando el modelo correcto a cada eslabón.

Uso de herramientas: darle manos al modelo

El uso de herramientas (tool use, o function calling) permite a Claude llamar funciones que usted define: consultar una base de datos, llamar a una API, hacer un cálculo, leer un archivo. Usted describe la herramienta (nombre, descripción, esquema de parámetros), Claude decide cuándo y cómo llamarla, usted ejecuta y devuelve el resultado.

Es el motor de todo agente (Claude Code, Cowork, MCP). Buenas prácticas para definir una herramienta, extraídas de los mejores arneses:

• Descripción clara, orientada al uso: es la que impulsa la elección correcta de herramienta, exactamente como la descripción de una skill.
• Esquema de parámetros estricto: tipos y campos requeridos, para llamadas válidas.
• No exponer el nombre de la herramienta al usuario en la conversación (la regla Cursor/Cline del Frankenstein): diga "Estoy editando su archivo", no "Estoy llamando a edit_file".
• Llamadas en paralelo si son independientes, secuenciales solo cuando existe una dependencia.

La salida estructurada (forzar a Claude a llamar una herramienta que valide un esquema JSON) es la forma más fiable de obtener datos utilizables por un programa, mejor que analizar texto libre.

Componer un system prompt: el caso Frankenstein

La técnica más avanzada de Pierre: componer un system prompt ensamblando las mejores reglas de varios system prompts de élite. Su "Frankenstein" fusiona ocho fuentes (el roleplay Fable 5, más las disciplinas de Cursor, GPT-5, Perplexity, Lovable, v0, Cline, Devin) y superpone sus propias reglas absolutas en la cima, con prioridad.

No es fine-tuning, es prompt engineering puro: no se modifican los pesos del modelo, se cambia su comportamiento mediante instrucciones. Estructura del documento, en orden de prioridad descendente:

1. Identidad y reglas absolutas del usuario (anulan todo lo demás).
2. Disciplina de uso de herramientas (no nombrar las herramientas, leer antes de editar, máximo 3 intentos).
3. Anti-hedging: una lista explícita de aperturas y cierres prohibidos.
4. Estilo, reglas de código, directivas UI/UX, búsqueda, citación, rechazo, recuperación de errores, seguridad del espacio de trabajo.

Lecciones transferibles, incluso sin copiar su configuración:

• Poner las reglas de prioridad al principio y declararlo explícitamente ("prioridad sobre todo lo demás").
• Prohibir mediante listas es más efectivo que pedir vagamente: "aperturas prohibidas: Genial, Claro, Por supuesto" supera a "sé directo".
• Codificar las lecciones de los incidentes: cada incidente vivido se convierte en una regla (nginx 410, PowerShell Unicode, la ruta con guion bajo).

Cita y anti-hedging en el uso diario

Dos disciplinas de estilo que cambian la calidad percibida, tomadas directamente del Frankenstein.

Cita (disciplina Perplexity), cada vez que realices una investigación:

• Corchetes inline justo después de la oración, sin espacio: texto.[1][2]
• Una fuente por corchete, máximo 3 fuentes por oración, las más relevantes.
• Sin sección final de "Referencias"; las fuentes se adjuntan a las afirmaciones.

Anti-hedging (GPT-5 + Cline): prohibir aperturas vacías ("Claro", "Por supuesto") y cierres opt-in ("would you like me to..."). Como máximo una pregunta de aclaración al inicio si es necesario, nunca al final. Si el siguiente paso es obvio, ejecutarlo en lugar de proponerlo.

Por qué importa: el hedging diluye la señal y ralentiza al lector. Una respuesta que actúa (o explica) directamente respeta el tiempo del usuario. Es exactamente el tono de esta Bible, por construcción.

Patrones de cadenas de prompts

Un solo prompt tiene sus limites. Cuando una tarea es compleja, dividirla en una cadena de prompts (una secuencia de prompts enlazados donde la salida de cada uno alimenta al siguiente) produce resultados mucho mejores que meter todo en una sola instruccion gigante. Cada eslabon de la cadena tiene una funcion estrecha y bien definida, lo que facilita detectar y corregir errores.

La tecnica central es el paso de resultado: se toma la salida del paso N y se pega (o se inyecta de forma programatica) como contexto en el paso N+1. En Claude Code, puedes construir cadenas dentro de scripts usando variables de shell o archivos como puente entre llamadas. En una sesion de chat, basta con copiar la parte relevante de la respuesta en el siguiente mensaje.

Patrones de cadena habituales que conviene conocer:

• Extraer y transformar: primero extrae datos brutos o hechos, luego los reformatea o analiza en una segunda llamada.
• Redactar y criticar: genera un primer borrador y luego ejecuta un prompt separado que lo revisa contra una lista de comprobacion y devuelve mejoras.
• Descomponer y resolver: pide a Claude que divida un problema en subtareas, luego resuelve cada subtarea individualmente y ensambla los resultados.
• Traducir y localizar: traduce el texto primero, luego ejecuta una pasada de localizacion que adapta las expresiones al contexto cultural de destino.

Mantén cada prompt de la cadena atomico (que haga una sola cosa) e incluye un breve encabezado de contexto al inicio de cada prompt subsiguiente para que Claude no parta de cero. Una cadena de tres prompts enfocados supera sistematicamente a un mega-prompt extenso en precision y facilidad de edicion.

El bucle de uso de herramientas en profundidad

Cuando le das a Claude una herramienta (una función que puede llamar, como una búsqueda web o un ejecutor de código), el modelo no responde una sola vez. Entra en un bucle de uso de herramientas: decide llamar a una herramienta, lee el resultado, luego decide qué hacer a continuación, repitiendo hasta poder dar una respuesta final. Cada viaje de ida y vuelta se llama un turno.

La secuencia dentro de una iteración del bucle es siempre la misma:

1. Llamada a herramienta: Claude emite una solicitud estructurada con el nombre de la herramienta y sus argumentos (por ejemplo, {"name": "search", "input": {"query": "Claude Opus 4 release date"}}).
2. Ejecución: Tu código (o el entorno anfitrión) ejecuta la herramienta y devuelve un bloque de resultado de herramienta con la salida.
3. Continuación: Claude lee el resultado como parte del contexto de la conversación y o bien llama a otra herramienta o produce una respuesta de texto final.

Tres elementos controlan el comportamiento del bucle. El prompt del sistema le indica a Claude qué herramientas existen y cuándo usarlas. La definición de herramienta (nombre, descripción, esquema JSON para las entradas) determina si Claude elige la herramienta correcta con los argumentos correctos. El resultado de herramienta que devuelves debe ser claro y completo, porque Claude no puede hacerle una pregunta de seguimiento a la herramienta: solo puede llamarla de nuevo con argumentos diferentes.

Modos de fallo comunes: las descripciones de herramientas vagas llevan a Claude a ignorar la herramienta o a pasar argumentos incorrectos; los resultados truncados o que parecen sin errores (cuando la llamada real falló) llevan a Claude a alucinar el siguiente paso; y los bucles que nunca terminan ocurren cuando la herramienta sigue devolviendo una salida ambigua. Una descripción de herramienta bien diseñada suele ser más importante que la longitud del prompt.

Salidas estructuradas con un esquema

Un esquema es una descripción formal de la forma que desea que tengan sus datos: qué campos existen, qué tipo contiene cada campo (cadena, número, booleano, arreglo), y cuáles campos son obligatorios. Cuando adjunta un esquema a una instrucción de Claude, le indica al modelo exactamente qué JSON (JavaScript Object Notation, un formato de texto ligero para datos estructurados) debe devolver, y nada más.

Claude admite la aplicación de esquemas de dos maneras. Primero, puede describir el esquema dentro de su instrucción como un objeto JSON simple e indicarle a Claude que lo siga. Segundo, al llamar directamente a la API Anthropic, puede usar el tool use (también llamado function calling): define una herramienta cuyo esquema de entrada coincide con el objeto que desea, luego le indica a Claude que llame a esa herramienta. La API garantiza que la respuesta se ajusta al esquema, por lo que obtiene una salida legible por máquina sin necesidad de analizar texto libre.

Incluso con la aplicación del esquema, las salidas pueden fallar la validación en casos extremos: un campo obligatorio puede ser null, un número puede llegar como cadena, o un valor de enum puede estar mal escrito. Por lo tanto, un flujo de trabajo robusto agrega un bucle de validación y reintento: analizar el JSON, ejecutar un validador (como una biblioteca JSON Schema) y, si falla, enviar el mensaje de error de vuelta a Claude en un turno de seguimiento para que corrija solo los campos defectuosos.

Principios clave para una salida estructurada confiable:

• Mantenga los esquemas planos y pequeños. Los esquemas muy anidados aumentan las tasas de error.
• Proporcione un objeto de ejemplo en la instrucción junto al esquema. Claude trata el ejemplo como una referencia de verdad base.
• Para los campos enum, liste explícitamente todos los valores permitidos. Claude no inventará valores que no haya visto.
• Al reintentar, cite el error de validación exacto y pida a Claude que corrija solo ese campo, sin reescribir todo.

Escribir evals

Un eval (abreviatura de evaluacion) es una pequeña prueba estructurada que se ejecuta sobre el prompt para medir si produce de forma fiable el resultado deseado. Sin evals, se trabaja a ciegas: un prompt que funciona con un ejemplo puede fallar silenciosamente en otros diez.

La idea central es construir un conjunto de pruebas: una coleccion fija de entradas emparejadas con las salidas esperadas (o una regla de puntuacion). Se ejecuta cada caso de prueba a traves del prompt y se hace seguimiento de la tasa de exito. Al revisar el prompt, se vuelve a ejecutar el conjunto de pruebas y se comparan las puntuaciones. Esto convierte la mejora del prompt de intuicion en medicion.

Un eval minimal tiene tres partes:

• Casos: de 10 a 30 entradas representativas que cubran el uso normal, los casos limite y los modos de fallo probables.
• Salidas esperadas: ya sean cadenas exactas, palabras clave que deben aparecer, una rubrica (escala del 1 al 5) o una segunda llamada a un LLM que actue como juez.
• Un runner: un script o una hoja de calculo que aplica el prompt a cada caso y registra exito o fallo.

Incluso una hoja de calculo de cinco filas es mejor que ninguna estructura. Comience con poco, agregue casos cada vez que un usuario real encuentre un error y nunca elimine un caso una vez que haya detectado una regresion (un comportamiento que funcionaba antes y que deja de funcionar tras un cambio en el prompt).

Meta-prompting

El meta-prompting consiste en usar un modelo de lenguaje (LLM) para escribir, criticar o mejorar un prompt, en lugar de redactarlo completamente a mano. La idea es recursiva: el modelo se convierte en un colaborador para dar forma a las instrucciones que seguirá después.

Esta técnica es útil cuando tienes dificultades con la formulación, cuando un prompt funciona pero sospechas que podría funcionar mejor, o cuando necesitas generar muchas variantes de prompt rápidamente. El modelo ha procesado cantidades enormes de texto sobre cómo responden los modelos, por lo que a menudo puede detectar debilidades que tú pasarías por alto.

Un meta-prompt básico tiene tres partes:

• Contexto: indica al modelo cuál es la tarea posterior y quién será el usuario final.
• El prompt borrador: pega el prompt que quieres mejorar, o describe el objetivo si estás empezando desde cero.
• Una instrucción específica: pide una reescritura, una lista de debilidades, formulaciones alternativas o una rúbrica de evaluación.

Puedes ir más lejos encadenando pasos: primero pide al modelo que critique, luego que reescriba a partir de su propia crítica, y después que genere tres variaciones ordenadas por claridad esperada. Cada paso consume tokens, pero converge hacia un prompt más sólido sin tener que adivinar qué está fallando.

Controles y validación

Un modelo puede producir una salida fluida y segura que sea factualmente incorrecta, estructuralmente rota o peligrosa de ejecutar. Los controles son verificaciones que se agregan entre la salida bruta del modelo y cualquier acción que la consuma. Convierten la confianza ciega en el modelo en un pipeline controlado.

El control más sencillo es una verificación de formato: comprobar que la salida tiene la forma solicitada (JSON válido, un número específico de elementos, ninguna cadena prohibida) antes de pasarla al siguiente paso. Un segundo nivel es la validación semántica: pedir a una segunda llamada al modelo, más económica, que juzgue si la respuesta es coherente, pertinente o segura. Este patrón se denomina a veces LLM-as-judge.

En Claude Code (el agente de codificación CLI e IDE), puede encadenar pasos de validación en un pipeline de shell o un script. Los enfoques habituales incluyen:

• Aserción de esquema: parsear la salida JSON con JSON.parse() y lanzar un error si faltan claves obligatorias.
• Barrera regex: rechazar la salida que contenga patrones como claves de API en bruto o información de identificación personal (PII) antes de registrarla o almacenarla.
• Prompt de autocrítica: devolver la salida al modelo con un prompt como "Lista los errores factuales o los pasos que faltan en el texto anterior." Tratar una lista no vacía como una señal de fallo.
• Prueba unitaria determinista: cuando el modelo escribe código, ejecutar la suite de pruebas y tratar una build fallida como un rechazo automático.

Los controles agregan latencia y costo, por lo que deben aplicarse de forma proporcional. Las acciones de alto riesgo (enviar un correo electrónico, escribir en una base de datos, desplegar código) merecen verificaciones estrictas. Las acciones de bajo riesgo (redactar un resumen para revisión humana) pueden depender de un control más ligero o ninguno.

Autoconsistencia y voto por mayoría

La mayoría de las estrategias de prompting envían una sola solicitud y confían en la primera respuesta. La autoconsistencia rompe ese supuesto: se muestrea la misma pregunta varias veces, se deja que el modelo razone de forma independiente cada vez y luego se elige la respuesta que aparece con mayor frecuencia. Ese voto mayoritario es estadísticamente más fiable que cualquier respuesta individual, especialmente en tareas de matemáticas, lógica y razonamiento en múltiples pasos.

La idea central proviene de un artículo de 2022 (Wang et al.) que muestra que los modelos de lenguaje no siempre siguen el mismo camino de razonamiento dos veces. Algunos caminos son incorrectos. Si se ejecuta el mismo prompt cinco veces y cuatro ejecuciones coinciden, la probabilidad de que las cuatro compartan el mismo error es baja. El voto (también llamado agregación por mayoría) aprovecha esa independencia.

Cuándo usarlo:

• Problemas difíciles de matemáticas o código donde una cadena de razonamiento (la traza paso a paso) puede desviarse.
• Tareas de clasificación donde se busca una señal de confianza, no solo una etiqueta.
• Cualquier respuesta en la que se sospeche que el modelo podría ser incoherente entre ejecuciones.
• Decisiones de alto riesgo donde se pueden permitir unas pocas llamadas extra a la API.

Concesión: el costo y la latencia se multiplican por el número de muestras. Usa una temperatura (el control de aleatoriedad, donde 0 es determinista y 1 es creativo) mayor que 0 para que cada muestra diverja. Un valor alrededor de 0,7 funciona bien. Luego analiza las respuestas programáticamente y cuenta la más común.

Autocrítica adversarial

La autocrítica adversarial es una técnica en la que se le pide al modelo que argumente en contra de su propia respuesta justo después de producirla. En lugar de tratar la primera respuesta como definitiva, se le indica al modelo que actúe como crítico y encuentre fallos, vacíos o errores en lo que acaba de decir. Esto aprovecha la capacidad de razonamiento del modelo para detectar errores que un solo paso hacia adelante suele pasar por alto.

¿Por qué funciona? Los modelos de lenguaje (LLMs, es decir, grandes modelos de lenguaje entrenados sobre texto) son propensos al sesgo de confirmación en la generación: una vez que una cadena de razonamiento comienza en una dirección, cada token hace más probable que el siguiente continúe en esa misma dirección. Un paso crítico separado reinicia ese impulso y puede revelar contradicciones, casos límite olvidados o afirmaciones demasiado confiadas.

Existen dos formas principales de autocrítica adversarial:

• Refutación inline: se agrega una segunda instrucción en el mismo prompt, pidiendo al modelo que haga seguir su respuesta de una sección de "abogado del diablo" que cuestione cada afirmación importante.
• Turno crítico separado: se envía la respuesta del modelo de vuelta en un nuevo mensaje con una instrucción explícita como "Lista cada error factual, vacío lógico e hipótesis no respaldada en el texto anterior."

Tras producir el crítico sus objeciones, se ejecuta un paso de síntesis: se le pide al modelo (o se juzga uno mismo) qué objeciones son válidas, y luego se solicita una respuesta revisada que aborde solo las válidas. Tres turnos en total: generar, criticar, sintetizar.