De ajustar instrucciones a bucles de retroalimentación: DSPy, GEPA y Claude Code

Durante años, la solución habitual para un resultado deficiente de un LLM era sencilla: ajustar el prompt e intentarlo de nuevo. Con los sistemas agentes, el prompt a menudo no es el elemento que necesita ser modificado.

Imagínese un error en producción que solo aparece después de un cambio en la configuración. Póngalo en manos de dos configuraciones de IA diferentes. La primera obtiene el rastro de ejecución junto con una instrucción redactada con cuidado y devuelve un parche. La segunda puede abrir el repositorio, leer las reglas del proyecto, reproducir el fallo, modificar el código, ejecutar las pruebas, determinar qué falló y volver a intentarlo.

El modelo es importante en ambos casos. Lo que tiene la segunda configuración y no la primera es un bucle de retroalimentación ejecutable.

Una vez que existe ese bucle, la redacción de los prompts se convierte en solo uno de los muchos parámetros ajustables. También se puede modificar cómo se divide la tarea, qué se obtiene, qué herramientas están disponibles, los ejemplos, los procedimientos de verificación, las reglas de reintentos, cómo se aísla la ejecución y el evaluador que decide si el trabajo es realmente correcto.

Ese es el hilo conductor que va desde la investigación de Stanford en DSPy, MIPRO, STORM y GEPA hasta el trabajo en producción de Anthropic en Claude Code y el Model Context Protocol. No se trata de una sola arquitectura; la idea común subyacente es que la ingeniería de IA está pasando de perfeccionar un único prompt a crear sistemas que actúan, miden los resultados y mejoran el programa que rodea al modelo.

El prompt ahora es un parámetro

Una aplicación de un solo uso tiene muy pocos controles:

Task → Prompt → Model → Result

Para tareas sencillas y bien delimitadas está bien. Se vuelve frágil cuando el trabajo requiere varias etapas, información externa, efectos secundarios reales, verificaciones o la posibilidad de recuperarse de una mala decisión a mitad del proceso.

Un sistema diseñado para producción se parece más a esto:

 Task
  ↓
Program / Planner
  ↓
Context + Retrieval
  ↓
Tools + Environment
  ↓
Execution Trace
  ↓
Evaluator
  ↓
Retry, Repair, or Optimize
  ↓
Result

Actualmente, un resultado deficiente puede tener muchas causas posibles. Es posible que el modelo no sea lo suficientemente potente. La recuperación de información podría haber obtenido el contexto incorrecto. El planificador podría haber dividido el trabajo de manera inadecuada. Una herramienta podría haber devuelto datos obsoletos. El verificador podría haber aceptado una respuesta inválida. O quizás las instrucciones realmente necesiten ser corregidas.

Por lo tanto, la ingeniería de prompts no desaparece; se convierte en una parte de un problema más amplio de depuración y optimización.

DSPy: hacer explícito el programa

La primera gran idea de DSPy fue dejar de tratar una pipeline de modelos de lenguaje como un conjunto de cadenas de prompts ajustadas manualmente. El artículo original modela las aplicaciones de modelos de lenguaje como grafos computacionales de módulos declarativos y añade un compilador que optimiza dichos módulos según una métrica específica. La documentación actual lo expresa de manera más sencilla: se definen firmas y módulos estructurados, se proporcionan ejemplos y una función de puntuación, y se compila el programa en lugar de ajustar manualmente cada prompt.

Un pequeño programa de DSPy se ve así:

import dspy

class Diagnose(dspy.Signature):
    """Identify the most likely root cause from an issue and repository evidence."""
    issue: str = dspy.InputField()
    evidence: str = dspy.InputField()
    diagnosis: str = dspy.OutputField()

program = dspy.ChainOfThought(Diagnose)

optimizer = dspy.GEPA(
    metric=score_diagnosis,
    auto="medium",
)

optimized = optimizer.compile(
    program,
    trainset=historical_incidents,
)

La sintaxis no es lo importante. Lo que cuenta es que cuatro elementos que normalmente se entrelazan en una sola instrucción ahora están separados: qué debe producir la tarea, cómo se ejecuta, qué ejemplos la guían y cómo se evalúa el éxito.

Eso cambia el trabajo del ingeniero. En lugar de gastar todo el presupuesto de iteración debatiendo si “ser conciso” debería convertirse en “pensar cuidadosamente antes de responder”, se puede plantear una pregunta mejor: ¿qué comportamiento debe mejorar y cómo se medirá?

Sin una métrica significativa, la optimización automática solo hace que el sistema sea mejor en el objetivo incorrecto.

MIPRO: ajustar muchas etapas es un problema de búsqueda

Las cosas se complican cuando el programa cuenta con varios módulos. Tomemos un flujo de corrección de errores que incluye diagnóstico, generación de parches y revisión, en el cual la prueba final falla. ¿Qué módulo lo causó? ¿Qué instrucción debe modificarse? ¿Es engañoso alguno de los ejemplos de pocos casos? ¿Haría que un paso de diagnóstico más preciso empeore la generación de parches?

Se trata de un problema de asignación de créditos, y eso es precisamente a lo que se dirige MIPRO. El artículo de MIPRO va más allá de editar una sola instrucción; ajusta conjuntamente las instrucciones escritas y los ejemplos de pocos casos de cada módulo, combinando propuestas de instrucciones que tienen en cuenta tanto el programa como los datos, evaluaciones en mini lotes y un modelo sustituto que orienta la búsqueda hacia combinaciones prometedoras.

En resumen:

Bootstrap useful demonstrations
          ↓
Propose task-grounded instructions
          ↓
Search instruction + demo combinations
          ↓
Evaluate the whole program

Con Llama-3-8B, el optimizador superó a sus valores de referencia en cinco de los siete programas de múltiples etapas, logrando en el mejor caso un aumento de hasta el 13% en la métrica de precisión reportada.

Esa es una afirmación más limitada que “los prompts automáticos superan a los humanos”. La conclusión más importante es de carácter estructural: una vez que las instrucciones y las demostraciones se convierten en parámetros de un programa de múltiples etapas, mejorarlo se transforma en una búsqueda dentro del sistema en lugar de un ejercicio de redacción sobre una sola cadena de texto.

STORM: la estructura precede a la optimización

Ningún optimizador puede salvar un flujo de trabajo mal diseñado. STORM de Stanford es un buen ejemplo, ya que su enfoque está en cómo está organizado el proceso, no en qué prompt resulta más efectivo.

Un único modelo que realiza toda la investigación y la redacción extensa de una sola vez es la versión ingenua; STORM separa la fase de preparación en pasos independientes. Encuentra diferentes perspectivas sobre el tema, las utiliza para generar preguntas basadas en fuentes, organiza lo recopilado en un esquema y solo entonces escribe.

Frente a un método de recuperación basado en esquemas, el artículo reporta una mejora absoluta de 25 puntos porcentuales en la organización y de 10 puntos en la amplitud. El repositorio STORM también es claro respecto a sus limitaciones: los artículos generados no están listos para publicarse y a menudo requieren una edición extensa.

La lección que se desprende no es “añadir más agentes”. Es que la descomposición permite controlar de manera separada el contexto, las pruebas, el manejo de fallos y la evaluación. Antes de optimizar un flujo de trabajo, asegúrese de que sus etapas coincidan con las formas en que realmente falla.

GEPA: aprenda de lo que realmente sucedió

Una sola puntuación puede indicarle que una carrera fue mediocre. Por lo general, no le permite saber por qué. Una ejecución real deja evidencias mucho más detalladas:

input
  ↓
retrieval choice
  ↓
reasoning
  ↓
tool call
  ↓
tool result
  ↓
constraint failure
  ↓
final output

GEPA, abreviatura de Genetic-Pareto y publicado en julio de 2025, utiliza esa señal. Muestra las trayectorias de ejecución, las analiza en lenguaje natural, propone ediciones de los prompts, califica a los candidatos y mantiene una frontera de Pareto para que no se descarten estrategias complementarias.

Un límite es muy importante en la producción. GEPA optimiza a partir de las trayectorias que ya se han observado. No se trata de permitir que un agente en tiempo real se reescriba después de cada solicitud del usuario. Antes de que cualquier candidato optimizado entre en funcionamiento, debe tener una versión específica, evaluarse en casos en los que nunca se entrenó, mantenerse dentro de un presupuesto de optimización fijo y superar un paso de promoción explícito frente a un conjunto de evaluación seleccionado cuidadosamente. Esa es la línea que separa la automejora útil de la automodificación incontrolada.

Claude Code: el bucle dentro de un entorno real

DSPy aborda el problema desde el punto de vista de la optimización del programa. Claude Code lo hace desde el lado del tiempo de ejecución. Según la visión de Anthropic, se trata de un agente que reside en tu repositorio: recoge las instrucciones del propio proyecto, modifica archivos, ejecuta comandos de shell y conjuntos de pruebas, y sigue ajustándose según los resultados. Sus materiales sobre patrones avanzados hablan sobre dividir el trabajo entre subagentes, ejecutar complementos entre pasos e integrar servicios internos de la empresa a través de MCP.

La arquitectura no es “chatear con un programador más inteligente”. Está más cerca de esto:

Repository + Project Rules + Task
              ↓
            Model
       ↙      ↓      ↘
     Read    Edit   Execute
       ↘      ↓      ↙
      Tests / Runtime Evidence
              ↓
         Next Decision

Esa evidencia en tiempo de ejecución cambia lo que el modelo puede hacer. Una prueba fallida es una retroalimentación mejor que “por favor, reconsideréelo”. Un error del compilador es mejor que que un modelo evalúe su propio parche. Se puede verificar mecánicamente si una diferencia queda dentro de los límites, en lugar de preguntar a otro modelo si el cambio tiene un alcance adecuado.

Las cifras internas de productividad de Anthropic son interesantes pero fáciles de interpretar de forma excesiva. Su informe de análisis de 2026 indica aproximadamente ocho veces más líneas de código por ingeniero al día para el segundo trimestre de 2026 en comparación con períodos anteriores, y advierte explícitamente que las líneas de código exageran la verdadera productividad. Ese período también incluye grandes cambios tanto en los modelos como en Claude Code, por lo que la cifra no demuestra que la orquestación por sí sola generó esa mejora. La señal más clara es que los sistemas de programación modernos siguen convirtiendo la salida del modelo en acciones, observaciones y, a continuación, en otra decisión.

MCP conecta herramientas; no orquesta

A menudo se asocia a MCP con agentes, uso de herramientas y orquestación, como si fueran lo mismo. Pero no lo son. La arquitectura MCP es una especificación cliente-servidor: una aplicación de IA se conecta a los servidores y descubre qué herramientas, recursos e instrucciones exponen, para luego llamarlas de manera uniforme. El host coordina a los clientes y se encarga de los permisos, la gestión de contexto, la política de seguridad y la forma en que se integra el LLM.

Por lo tanto, MCP abarca una capa de una estructura más amplia:

Model                  capability envelope
Program / graph         task decomposition
Context / state         what the model can see
Tools / MCP             what the system can access or do
Runtime / harness       where actions execute
Evaluator               what counts as success
Optimizer               how the program improves
Observability           why a run succeeded or failed

Ningún framework posee todo esto, y ese es precisamente el motivo por el cual pensar en términos de sistemas es beneficioso.

Optimiza el ciclo de corrección de errores, no la instrucción

Volvamos al error desde el principio. En lugar de una sola instrucción que diga “encuentra el problema y corrígelo”, detalla el flujo de trabajo:

  Issue + Repository
        ↓
    Diagnosis
        ↓
      Patch
        ↓
Tests + Lint + Runtime Checks
        ↓
    Diff Review
        ↓
  Accept or Revise

Cada etapa genera ahora pruebas: los registros de ejecución indican qué archivos se leyeron, qué comandos se ejecutaron, los parches que fallaron, los resultados de las pruebas y la diferencia final.

Las verificaciones deterministas abarcan lo que se puede demostrar de forma mecánica: las pruebas requeridas se superan, no se modifican los archivos prohibidos, el linter muestra resultados limpios y el parche se mantiene dentro de su ámbito permitido. El juicio basado en modelos se reserva para cuestiones realmente semánticas, como determinar si el diagnóstico explica la causa raíz probable.

Con el tiempo, los casos anteriores se convierten en un conjunto de evaluación. MIPRO puede buscar instrucciones y ejemplos en los módulos de diagnóstico y reparación. GEPA puede tomar trayectorias fallidas y los comentarios de los evaluadores para proponer un texto de programa mejor. Pero la optimización debe realizarse más allá de los límites de una versión:

Production traces
      ↓
Curated evaluation set
      ↓
Offline optimizer
      ↓
Candidate program
      ↓
Held-out validation
      ↓
Controlled promotion

Aquí es donde la investigación y la producción finalmente se encuentran. El entorno de ejecución del agente genera acciones y registros. El evaluador convierte esos registros en evidencia. El optimizador sugiere un programa mejor. El proceso de despliegue decide si es seguro lanzarlo.

Qué significa esto para los ingenieros de IA

Los prompts no han dejado de ser relevantes; simplemente existen más puntos en los que se pueden intervenir de manera útil. Cuando un flujo de trabajo no rinde como debería, no comience por revisar la redacción de forma automática. Determine primero qué capa falló:

• ¿Podría el modelo base manejar la tarea en absoluto?
• ¿La recuperación de información proporcionó el contexto adecuado?
• ¿La tarea se dividió en límites razonables?
• ¿Las herramientas devolvieron evidencia en la que se pueda confiar?
• ¿La ejecución fue aislada y observable?
• ¿El evaluador mide el comportamiento que realmente importa?
• ¿El optimizador mejora la calidad en datos no utilizados, o solo se ajusta al conjunto de desarrollo?

Al analizar todo el sistema también se ponen de manifiesto los compromisos que la exageración tiende a pasar por alto. Envolver un modelo débil en un grafo no lo convierte en un modelo de vanguardia. Una métrica deficiente optimiza un comportamiento incorrecto. Cuantos más herramientas haya, más rutas de fallo y una superficie de seguridad más amplia existirán. Cada ejecución de optimización consume tokens y tiempo de evaluación. Lo peor de todo es que un agente que se modifica a sí mismo sin historial de versiones ni casos de prueba intactos puede volverse más inestable, aunque en teoría parezca más independiente.

Por lo tanto, la conclusión no es que el modelo haya dejado de ser importante. La calidad del modelo establece el límite máximo de sus capacidades. El diseño del sistema determina cuánto de esas capacidades se traduce en un funcionamiento fiable.

Ese es el verdadero vínculo entre la investigación de Stanford y las herramientas de Anthropic. Con DSPy, el programa deja de ocultarse dentro de las cadenas de texto de instrucción. MIPRO permite buscar instrucciones y ejemplos en todas las etapas. STORM recuerda que la estructura del flujo de trabajo es lo más importante. GEPA analiza los registros completos de ejecución en busca de mejoras. Claude Code coloca el modelo dentro de un entorno de ingeniería funcional, mientras que MCP estandariza uno de los límites con las capacidades externas. Proyectos diferentes en diferentes niveles, todos apuntando en la misma dirección.

La próxima vez que un sistema de IA falle, “¿qué instrucción debo probar a continuación?” no debería ser la única pregunta. Pregúntese qué parte del sistema se ha dañado y qué evidencia le permitirá repararlo.

Leer más

• Un Harness de Producción para Claude Code: Seis capas desde Slack hasta el código fusionado — Cómo un harness de seis capas convierte los tickets de Slack en código fusionado: captura de eventos, bucles de agente con control de acceso, estado duradero, capacidad de autoreparación, observabilidad y control por parte del operador.
• Bucles de Programación Agente: De una línea de comandos en Bash hasta /goal, verificaciones y paradas forzadas — Una guía práctica para trabajar con bucles de agente: el bucle ralph, los comandos goal y loop de Claude Code, verificación externa, tres límites de uso y habilidades que vale la pena conservar, además de un plan para la primera semana.