Prompt engineering avanzado: qué sobrevive frente a los modelos razonadores

En 2024, "prompt engineering avanzado" significaba casi siempre tres siglas: Chain-of-Thought (CoT), Tree-of-Thought (ToT) y ReAct. La receta era pedirle al modelo que pensara paso a paso, que explorara varias ramas de razonamiento y que alternara texto de pensamiento con llamadas a herramientas parseadas a mano. Con los modelos razonadores actuales, como Claude Opus 5 y Sonnet 5, GPT-5.6 o Gemini 3, buena parte de esa receta ya no aplica igual. Las ideas detrás de esas técnicas no eran erróneas: los modelos y la infraestructura que los rodea absorbieron buena parte del trabajo que antes hacía el texto del prompt. Esto es una revisión de qué queda vivo de aquellas técnicas, qué se volvió contraproducente y qué se trasladó a otra capa del stack.

Lo que prometían CoT, ToT y ReAct

Chain-of-Thought pedía al modelo que verbalizara su razonamiento antes de responder ("piensa paso a paso"), asumiendo que forzar esa verbalización mejoraba la respuesta final. Tree-of-Thought llevaba la idea más lejos: generar varias ramas de razonamiento, evaluarlas y descartar las peores antes de converger en una respuesta. ReAct combinaba pensamiento y acción en un mismo bucle de texto: "Thought: ... Action: ... Observation: ...", que el propio desarrollador parseaba con expresiones regulares para decidir qué herramienta invocar. Las tres técnicas compartían un supuesto: el modelo no razonaba por sí solo, así que había que inducírselo desde el prompt.

Chain-of-Thought manual: de técnica estrella a recurso de repuesto

Ese supuesto ya no se sostiene con los modelos razonadores actuales. La guía de buenas prácticas de razonamiento de OpenAI para su API es explícita: hay que evitar los prompts de chain-of-thought porque estos modelos razonan internamente, y pedirles que "piensen paso a paso" o "expliquen su razonamiento" es innecesario, y puede llegar a perjudicar el resultado (OpenAI, Reasoning best practices). Anthropic llega a una conclusión equivalente desde el lado de Claude: cuando el extended thinking está disponible, es preferible al chain-of-thought manual, y en la propia documentación de prompting para extended thinking recomiendan instrucciones generales ("piensa a fondo") en vez de un plan paso a paso escrito a mano, porque el razonamiento del modelo suele superar lo que un humano sabría prescribir (Claude Docs, Extended thinking tips).

El prompt que en 2024 se veía así:

Resuelve este problema. Piensa paso a paso:
1. Identifica las variables
2. Plantea la ecuacion
3. Resuelve
4. Verifica el resultado

hoy tiende a rendir igual o mejor así, dejando que el modelo decida su propio proceso interno:

Resuelve este problema. Piensa con el detalle que necesites antes de responder.

Ambos proveedores exponen ahora un control explícito de cuánto debe razonar el modelo (reasoning_effort en la API de OpenAI, el parámetro effort del thinking adaptativo en Claude Opus 5 y Sonnet 5), en lugar de depender de trucos de redacción como "respira hondo" o "piensa muy detenidamente" para inducir más razonamiento. Dicho esto, el CoT manual no ha desaparecido: sigue siendo la opción cuando no hay extended thinking disponible (el plan gratuito de Claude.ai, por ejemplo) o cuando se necesita que el modelo ofrezca una justificación visible, con pasos que un humano pueda revisar, en el propio texto de salida (Claude, Best practices for prompt engineering 2026).

Tree-of-Thought: la idea persiste, ya no vive en el texto del prompt

Ningún proveedor publica hoy una guía específica sobre Tree-of-Thought. Es razonable leer eso como una señal de que la técnica, tal como se practicaba (pedirle a un único modelo que simulara varias ramas dentro de la misma respuesta), perdió relevancia frente a dos alternativas que sí están documentadas. La primera es interna: la documentación de extended thinking de Claude describe que el modelo usa su espacio de razonamiento privado para explorar callejones sin salida, dar marcha atrás, reconsiderar suposiciones y verificar pasos intermedios antes de producir la respuesta visible, que es funcionalmente parecido a lo que ToT intentaba forzar desde fuera (Claude Docs, Extended thinking tips).

La segunda alternativa es arquitectónica, no de prompting: en su guía de context engineering, Anthropic describe arquitecturas de subagentes donde un agente principal coordina subagentes especializados que exploran en paralelo con su propia ventana de contexto limpia y devuelven solo un resumen condensado (entre 1.000 y 2.000 tokens) del trabajo hecho con decenas de miles de tokens propios (Anthropic Engineering, Effective context engineering for AI agents). No es una reimplementación deliberada de ToT: el motivo declarado es aislar contexto, no explorar ramas de razonamiento. Pero el efecto práctico, varias líneas de exploración independientes que convergen en una síntesis, recuerda al problema que ToT atacaba con un solo modelo simulando ramas dentro de un único hilo de texto.

ReAct y tool use: del bucle de texto al function calling nativo

El patrón ReAct original dependía de que el desarrollador parseara a mano el texto de salida del modelo para extraer qué herramienta llamar y con qué argumentos, típicamente con expresiones regulares sobre líneas "Thought:" / "Action:" / "Observation:". Eso es justo lo que las APIs de tool use y structured outputs eliminan. OpenAI ofrece Structured Outputs en dos formas: vía function calling, cuando el modelo debe invocar funciones de tu sistema, o vía response_format / text.format con un json_schema, cuando debe responder directamente al usuario en un formato fijo. En ambos casos, bajo configuración estricta (strict: true), el cumplimiento del esquema queda garantizado para el subconjunto de JSON Schema que soportan (algunas palabras clave de composición y de validación de strings, números y arrays quedan fuera), y aun así hay que gestionar refusals por seguridad y respuestas incompletas cuando se alcanza el límite de tokens, en vez de depender solo de parseo defensivo (OpenAI, Structured model outputs). Claude resuelve el mismo problema con su API de tool use, donde las herramientas se definen con esquema y el modelo devuelve la llamada ya estructurada. Esa garantía tampoco es incondicional: depende de activar el modo estricto correspondiente, y sin él el modelo puede desviarse del esquema declarado, así que conviene validar la respuesta en la propia aplicación de todas formas.

En código, la diferencia es la que separa esto:

# Patron ReAct clasico: parseo manual del texto libre
output = model.generate(prompt)
match = re.search(r"Action: (\w+)\((.*)\)", output)
if match:
    tool_name, raw_args = match.group(1), match.group(2)
    result = call_tool(tool_name, parse_args(raw_args))  # parseo fragil

de esto:

# Tool calling nativo: el esquema se valida antes de llegar a tu codigo
response = client.messages.create(
    model="claude-sonnet-5",
    tools=[{"name": "get_weather", "input_schema": weather_schema}],
    messages=[{"role": "user", "content": prompt}],
)
for block in response.content:
    if block.type == "tool_use":
        result = call_tool(block.name, block.input)  # esquema garantizado solo en modo estricto; valida igual

El bucle pensar-actuar-observar que proponía ReAct no desapareció como concepto; lo que desapareció es la necesidad de que viva dentro del texto libre del modelo y de que el propio desarrollador lo parsee.

El "think tool": el instinto de ReAct, ahora un caso especial

El "think tool" de Anthropic nació en marzo de 2025 como una herramienta que no ejecuta ninguna acción externa, solo le da a Claude un espacio explícito para parar a razonar a mitad de una cadena de llamadas a herramientas. En diciembre de 2025 Anthropic actualizó esa misma página: las capacidades de extended thinking mejoraron lo suficiente como para recomendar usarlas en la mayoría de los casos en lugar de una think tool dedicada, por la mejor integración y el mejor rendimiento que ofrece extended thinking (Anthropic Engineering, The think tool). La distinción que queda en pie es de momento y de objeto: extended thinking ocurre antes de que Claude empiece a generar la respuesta, mientras que el think tool es una pausa a mitad de generación, pensada para cuando Claude necesita procesar información nueva que aparece en resultados de herramientas durante cadenas largas de llamadas o conversaciones de varios pasos, no para razonar sobre la petición inicial del usuario. Para tool use simple, no secuencial o instrucciones directas, Anthropic recomienda extended thinking sin más.

El dato que sostenía la recomendación original sigue siendo el mismo: en τ-Bench (dominio retail, Claude 3.7 Sonnet, k=1), el baseline sin think tool ni extended thinking obtuvo 0,783; extended thinking sin el tool, 0,770; think tool sin ningún prompting adicional, 0,812. La lectura honesta es que es un dato de un benchmark con un modelo hoy superado, y que la propia Anthropic ha revisado desde entonces cuándo conviene reservar la herramienta en vez de tratarlo como garantía universal. Pero confirma que el patrón de parar a pensar antes de actuar que proponía ReAct sigue aportando valor en cadenas de herramientas con políticas complejas, aunque hoy el primer recurso para inducirlo sea extended thinking y el think tool quede como recurso específico para procesar resultados intermedios de herramientas.

Lo que apenas cambió: few-shot para formato, delimitadores para estructura

No todo lo del prompt engineering clásico quedó obsoleto. Los ejemplos (few-shot) siguen siendo la vía más fiable para fijar formato o estilo, con un consejo parecido en ambos proveedores: empezar sin ejemplos y añadirlos solo si el resultado no cumple lo que se pide. OpenAI recomienda probar zero-shot primero con modelos razonadores, porque a menudo no necesitan ejemplos para producir buenos resultados, y añadir few-shot solo ante requisitos de formato complejos (OpenAI, Reasoning best practices). Claude aconseja algo similar desde el otro lado: empezar con un ejemplo (one-shot) y sumar más solo si la salida sigue sin ajustarse, con la advertencia de que los modelos actuales prestan mucha atención a los detalles de los ejemplos, así que un patrón no intencionado en un ejemplo se replica con más fidelidad que antes (Claude, Best practices for prompt engineering 2026).

Los delimitadores tienen un matiz más fino entre proveedores. OpenAI sigue recomendando explícitamente markdown, tags XML y títulos de sección para modelos razonadores, como forma de marcar qué parte del input es qué. Anthropic, en cambio, señala que los modelos actuales entienden estructura sin tags XML mejor que antes, y reserva su uso a prompts extremadamente complejos que mezclan varios tipos de contenido, o a los casos donde hace falta certeza absoluta sobre los límites de un bloque de texto. Para el resto, títulos claros y lenguaje explícito cumplen la misma función con menos ceremonia (Claude, Best practices for prompt engineering 2026). La diferencia no es una contradicción entre proveedores: el margen de mejora que quedaba en estructurar visualmente el prompt se redujo en general, y cada guía lo redondea a su manera.

El desplazamiento de fondo: de redactar prompts a curar contexto

El cambio más grande no está en ninguna técnica suelta, sino en dónde vive el trabajo. Anthropic lo nombra "context engineering" y lo describe como la evolución natural del prompt engineering: dado que los modelos tienen un presupuesto de atención finito, la tarea deja de ser encontrar las palabras correctas para un prompt puntual y pasa a ser curar, en cada turno, el conjunto más pequeño de tokens de alta señal que puede llevar al resultado buscado. Eso incluye el "altitude" correcto de las instrucciones del system prompt (ni tan rígidas que se vuelvan frágiles, ni tan vagas que no den señal) y qué se carga en contexto y cuándo (Anthropic Engineering, Effective context engineering for AI agents). Las herramientas de memoria persistente fuera de la ventana de contexto y las arquitecturas de subagentes que vimos en la sección de ToT son parte de esa misma disciplina, no técnicas aisladas.

Para el post original, esto significa que buena parte de lo que llamaba "avanzado" se trasladó de la redacción del prompt a decisiones de arquitectura. El prompt sigue importando, pero ya no es donde se libra la parte más difícil del problema.

Auditoría rápida para un prompt heredado de esa época

Si hay un prompt de 2024 todavía en producción apuntando a un modelo razonador, esto es lo que vale la pena revisar primero:

• Si el prompt incluye "piensa paso a paso" o un plan de razonamiento escrito a mano y el modelo tiene extended thinking o reasoning_effort disponible, esa instrucción probablemente compite con el razonamiento interno en vez de ayudarlo. Conviene probar a quitarla y comparar resultados.
• Si hay un bucle "Thought/Action/Observation" parseado con regex sobre texto libre, migrarlo a function calling o structured outputs elimina una fuente de fallos silenciosos sin cambiar la lógica de negocio.
• Si el prompt fuerza varias ramas de razonamiento dentro de una sola llamada al modelo, vale la pena medir si el extended thinking nativo ya cubre ese caso antes de mantener la orquestación manual.
• Si hay una cadena larga de llamadas a herramientas con políticas que verificar entre pasos, conviene probar primero extended thinking o el thinking adaptativo, y evaluar el think tool solo si el agente necesita razonar específicamente tras recibir resultados externos a mitad de la cadena.
• Si el prompt tiene tags XML o role prompting pesado heredados de guías antiguas, conviene comprobar si headings claros y lenguaje directo producen el mismo resultado con menos texto, sobre todo en Claude, donde esa recomendación es explícita.