Cómo usar Goals en Codex

• Goals es una función de objetivo persistente que hace que un hilo de Codex siga trabajando durante varios turnos hacia un resultado definido
• Es adecuada para tareas como perfilado, parches, benchmarking, reproducción de pruebas flaky y auditorías basadas en evidencia, que son difíciles de resolver con un solo prompt
• Si defines el resultado (outcome), la superficie de verificación (verification surface) y las restricciones (constraints), Codex puede determinar por sí mismo, con base en evidencia, si ya terminó
• Permite controlar el ciclo de vida con los comandos /goal, /goal pause, /goal resume, /goal clear, con soporte desde Codex 0.128.0
• Tiene una estructura de contrato de finalización (completion contract) limitada al alcance del hilo; la clave no es una autonomía ilimitada, sino la persistencia bajo control del usuario

---

Qué son Goals y por qué se introdujeron

• Goals es una función que le da a Codex una condición de finalización (completion condition), definiendo qué debe ser cierto, cómo se verifica el éxito y qué restricciones deben mantenerse
• Codex ya funciona bien en tareas de programación con alcance claro como revisar repositorios, corregir bugs, agregar pruebas, explicar fallas o implementar cambios concretos
• Goals es adecuado para trabajos donde el siguiente paso depende de lo que Codex vaya aprendiendo en el camino
  • Perfilado, parches, benchmarking, reproducción de pruebas flaky y convertir preguntas de investigación en auditorías basadas en evidencia
• Este tipo de trabajo no necesita un prompt más grande, sino un objetivo persistente
• Cuando un Goal está activo, Codex mantiene el objetivo, evalúa si ya se cumplió y elige la siguiente acción sin que tengas que reformularlo en cada resultado intermedio
• Un Goal no es autonomía en segundo plano sin límites, sino un contrato de finalización con alcance definido y bajo control del usuario

Quickstart: cómo usar Goals

• Usa un Goal para trabajos donde el punto de llegada es claro, pero la ruta para llegar es incierta
  • Buenos candidatos: optimización de rendimiento, investigación de pruebas flaky, migración de dependencias, rastreo de bugs que requieren reproducción, refactorizaciones de varios pasos, ajuste guiado por benchmarks y tareas de investigación con entregables finales
  • Para ediciones de una sola vez, conviene más un prompt normal

• Instalación y verificación de versión

  • Goals está disponible a partir de Codex 0.128.0
  • npm: npm install -g @openai/codex@latest y luego codex --version
  • Homebrew: brew update && brew upgrade --cask codex y luego codex --version

• Configuración del Goal y comandos del ciclo de vida

  • Se configura con el formato /goal <resultado>, por ejemplo: /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: ver el Goal actual
  • /goal pause: pausar el Goal activo
  • /goal resume: reanudar un Goal pausado
  • /goal clear: eliminar el Goal actual

• Condiciones de detención (stopping condition)

  • Se detiene por éxito, pausa, eliminación, interrupción, llegada al límite de presupuesto o si aparece un bloqueador que requiere entrada del usuario
• En situaciones donde tendrías que dar instrucciones repetitivas en cada turno como “sigue”, “prueba la siguiente corrección posible”, “vuelve a correr el benchmark” o “ahora revisa la prueba”, un Goal expresa esa intención de forma explícita

Goals vs prompts

• Prompt normal: “haz esta siguiente tarea”
• Goal: “sigue trabajando hasta que este resultado sea cierto”

• Diferencia de comportamiento

  • En una solicitud normal, Codex ejecuta la instrucción inmediata, informa el resultado y espera
  • Con un Goal, se adjunta al hilo un objetivo duradero (durable target) y, al final del turno, se revisa la evidencia actual para decidir si el objetivo ya se cumplió
  • Si no se cumplió, el Goal sigue activo y aún hay presupuesto, puede continuar trabajando desde el estado más reciente

• Ejemplo: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • Proporciona un resultado medible, un medio de verificación y restricciones
  • Codex puede iterar entre ejecutar el benchmark → inspeccionar la ruta crítica → hacer cambios específicos → volver a ejecutar el benchmark → correr la suite de exactitud, y seguir si el resultado aún no alcanza

• Modelo mental

  • Prompt: ask → work → result → wait
  • Goal: work → check → continue or complete
• Un Goal marca la meta, pero el trabajo igual debe auditarse contra la evidencia

Cómo redactar un Goal

• Un buen Goal no es un prompt más largo, sino un contrato conciso sobre cómo debe trabajar Codex, qué cuenta como éxito y qué hacer cuando aún no se llega a ese éxito

• Los 6 elementos que define un Goal sólido

  • Outcome: lo que debe ser cierto cuando el trabajo termine
  • Verification surface: las pruebas, benchmarks, reportes, entregables, salidas de comandos o materiales fuente que lo demuestran
  • Constraints: lo que no debe degradarse durante el trabajo de Codex
  • Boundaries: archivos, herramientas, datos, repositorios y recursos que se pueden usar
  • Iteration policy: cómo decidir qué hacer después de cada intento
  • Blocked stop condition: en qué momento informar y detenerse cuando ya no queda una ruta defendible dentro de los límites actuales

• Patrón de redacción

  • /goal <estado final deseado> verified by <evidencia específica> while preserving <restricciones>. Use <entradas/herramientas/límites permitidos>. Between iterations, <cómo elegir la siguiente mejor acción>. If blocked or no valid paths remain, <qué reportar y qué entrada se necesita para avanzar>.

• Ejemplo débil vs ejemplo sólido

  • Débil: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • Sólido: especifica además el medio de verificación (checkout benchmark), el alcance de uso (checkout service, benchmark fixtures, pruebas relacionadas), la política de iteración (registrar cambios, resultados del benchmark y siguiente experimento) y hasta cuándo reportar bloqueadores

• Goals de investigación/exploración

  • Si una prueba exacta puede no ser posible, define el estándar de evidencia (evidence standard) antes de empezar
  • Ejemplo: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Delegar en Codex la redacción del Goal

  • Se recomienda un flujo de dos pasos: describir la tarea en lenguaje sencillo → pedirle a Codex que redacte un borrador de Goal → afinar condiciones de éxito, medios de verificación, restricciones y condición de detención por bloqueo antes de activarlo

Qué cambia cuando un Goal está activo

• El objetivo sigue visible

  • Aunque falle una prueba, el hilo mantiene el objetivo original
  • Si un benchmark mejora pero no alcanza el umbral, Codex sigue avanzando
  • Si una ruta de investigación se topa con falta de datos, ajusta el plan de evidencia sin perder el estándar de investigación

• Puede continuar (continuation) en un hilo inactivo

  • No continúa si hay otro turno activo, si hay entrada del usuario en cola o si hay trabajo pendiente en otros hilos
  • Solo continúa cuando el hilo está inactivo, el Goal sigue activo y aún hay presupuesto

• La finalización debe basarse en evidencia

  • No puede darse por terminado solo porque el modelo “cree que probablemente ya acabó”
  • Solo se completa después de revisar el objetivo frente a archivos relevantes, pruebas, logs, salida de benchmarks, artefactos generados u otra evidencia concreta
• Principio central del diseño: Codex puede seguir moviéndose, pero la evidencia decide si terminó

Estructura de diseño de Goals dentro de Codex

• Goals está implementado como un estado persistente con alcance de hilo (persisted thread state), no como memoria global ni como instrucciones a nivel de proyecto
  • El objetivo pertenece al hilo que contiene el contexto relevante, como archivos revisados, comandos ejecutados, diffs generados, logs vistos y trazas de razonamiento

• Capas de la arquitectura

  • Registra objetivo, ciclo de vida, presupuesto y contabilidad de progreso como estado persistente con alcance de hilo
  • Estados del Goal: active, paused, complete, budget-limited
  • Según el estado, Codex decide si continuar, esperar al usuario o resumir el progreso en lugar de iniciar trabajo nuevo

• La continuación (continuation) es guiada por eventos

  • No es un loop simple; solo se revisa en límites seguros: al final del turno, sin tareas pendientes, sin entrada del usuario en cola y con el hilo inactivo
  • El comportamiento del dispatcher es conservador: las tareas solo de planeación no activan continuación, una interrupción pausa el objetivo, al reanudar el hilo el objetivo se restaura si corresponde, y si un turno de continuación no llama herramientas se suprime la siguiente continuación automática para evitar spin

• Capa de prompting

  • El prompt de continuación alinea a Codex alrededor del Goal activo, pero exige auditoría antes de marcarlo como completado
  • Compara el objetivo con evidencia concreta: archivos modificados, comandos ejecutados, pruebas aprobadas, salida de benchmarks, artefactos generados y evidencia de investigación

• Manejo de presupuesto (budget)

  • Cuando se alcanza el presupuesto, se detiene el trabajo sustantivo, se resume el progreso y los bloqueadores, y se identifican los siguientes pasos útiles
  • Alcanzar el límite de presupuesto no equivale a completar el objetivo

• Contrato de herramientas (tool contract)

  • El modelo puede iniciar un Goal, y solo puede marcar como completado un Goal existente cuando la evidencia respalda esa finalización
  • Pausar, reanudar, eliminar y cambiar a estado de límite de presupuesto siguen bajo control del usuario o del sistema

Convertir un Goal débil en uno sólido

• Ejemplo de ajuste de rendimiento

  • Débil: /goal Improve performance
  • Sólido: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • La versión sólida aporta resultado, forma de verificación y restricciones, y permite reconocer cuándo no debe detenerse
    • Si p95 mejora de 180 ms a 135 ms, el Goal sigue incompleto
    • Si la latencia baja de 120 ms pero fallan las pruebas de exactitud, sigue incompleto
    • Si no se puede ejecutar el benchmark, en vez de declarar éxito se expone el bloqueador

• El alcance adecuado de un Goal

  • Debe ser lo bastante estrecho para poder auditarse, pero lo bastante amplio para elegir la siguiente acción
  • “Fix the failing checkout test” es demasiado estrecho si el problema real está en una dependencia upstream
  • “Improve the whole system” es demasiado amplio porque no tiene superficie de auditoría
  • “Make the checkout test suite pass on the current branch without changing public API behavior” sí tiene un alcance adecuado

• Los mismos principios aplican a artefactos generados (generated artifacts)

  • Débil: /goal Write docs for this feature
  • Sólido: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • La versión sólida aporta una página verificable, un comando de build y comportamiento de comandos comprobable

• Estándar de evidencia para Goals de investigación

  • Debe definirse antes de iniciar la investigación: qué cuenta como reproducción exacta, reconstrucción parcial, respaldo proxy o elemento bloqueado
  • Un Goal de investigación sólido exige construir un inventario de afirmaciones, mapear afirmación-evidencia, implementar las partes ejecutables, etiquetar bloqueadores y generar una auditoría que separe afirmaciones confirmadas, evidencia solo de respaldo, afirmaciones bloqueadas e incertidumbre restante

Uso de Goals en investigación compleja: caso de reproducción de un paper de quant

• Resumen del caso

  • Objetivo: el paper Deep Hedging de Buehler, Gonon, Teichmann y Wood
  • Tema del paper: si las estrategias de trading con redes neuronales pueden reproducir coberturas basadas en modelo en escenarios de preferencias de riesgo, costos de transacción y mercados de alta dimensión
  • Un Goal correcto no es el abstracto “reproducir el paper”, sino intentar las afirmaciones numéricas principales, separar mecanismos exactos de sustitutos de entrenamiento aproximados y señalar qué partes no pueden reproducirse exactamente con los materiales disponibles

• Goal de investigación débil vs sólido

  • Débil: /goal Reproduce Buehler et al., "Deep Hedging"
    • No define qué secciones importan, qué cuenta como reproducción, cómo tratar la falta de estados de entrenamiento ni cómo distinguir coincidencia aproximada de reproducción exacta
  • Sólido: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• Qué trabajo hace realmente Codex

  • Separa afirmaciones principales y afirmaciones de soporte
  • Mapea cada afirmación a la evidencia disponible
  • Reconstruye localmente las partes que se pueden probar
  • Etiqueta las afirmaciones que no pueden reproducirse exactamente con los materiales disponibles

• Partes que sí pudieron ejecutarse

  • Reconstrucción de mecanismos de pricing y hedging
  • Reproducción del precio de referencia de Heston
  • Entrenamiento de políticas para experimentos de cobertura con CVaR
  • Reconstrucción de los histogramas principales y de los artefactos de superficie de cobertura
  • Reproducción de la pendiente de costos de transacción en Black-Scholes
  • Ejecución de comprobaciones entrenadas para ejemplos de costos de transacción de Heston y alta dimensión

• Partes que siguieron bloqueadas

  • El paper no proporciona semillas aleatorias exactas, trayectorias de entrenamiento generadas, grafos de TensorFlow, estado del optimizador, checkpoints ni el estado completo de simulación original
  • El resultado más honesto es una reproducción parcial y aproximada, no una reproducción exacta de la red neuronal original

• Preservar el nivel epistemológico de respaldo en el reporte

  • Los sustitutos entrenados pueden respaldar una afirmación, una coincidencia numérica cercana puede elevar la confianza y las figuras reconstruidas pueden validar parte de los resultados, pero nada de eso debe describirse como una restauración exacta del experimento original
  • Ejemplo de ledger:
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: reconstruir la mecánica del modelo, comparar cobertura de referencia, entrenar política de red neuronal
    • Evidence surface: comprobaciones de pricing, histogramas, superficie de cobertura
    • Status: Close approximate reproduction
    • Remaining uncertainty: no se dispone de las trayectorias de entrenamiento originales, seeds ni checkpoints
• El valor demostrativo de Goals en investigación es que mantiene el trabajo en marcha en medio de la ambigüedad, pero evita que entregables plausibles se conviertan en conclusiones sobredimensionadas; define el significado de completar como una auditoría por afirmaciones basada en evidencia, explicitando aproximaciones y siendo honesto sobre el límite entre reproducción y replay

Cuándo no conviene usar Goals

• No es adecuado para una edición de una línea, una explicación simple, una revisión corta de código o preguntas donde quieres que se detenga tras una sola respuesta → para eso conviene un prompt normal de Codex
• No conviene cuando la meta es ambigua
  • “Make this better” no ofrece una condición de finalización confiable
  • “Refactor this code” también es débil si no define estado final esperado, pruebas y restricciones
• No debe usarse para ocultar incertidumbre
  • Si los datos pueden no estar disponibles, indícalo en el Goal
  • Si el benchmark puede ser flaky, especifica cómo manejarlo
  • Si se permite evidencia proxy, define cómo etiquetarla
• Goals es más fuerte cuando se combinan tres propiedades: objetivo persistente, meta final basada en evidencia y una ruta que requiere investigación durante varios turnos

Conclusión: deja que el objetivo persista, pero que la evidencia decida la finalización

• Goals cambia el modelo operativo de Codex al convertir el hilo de una secuencia de prompts aislados en un loop de trabajo basado en estado alrededor de un resultado definido
• La arquitectura tiene límites deliberados
  • Un Goal tiene alcance acotado al hilo, cuenta con estado de ciclo de vida y contabilidad de presupuesto, y puede pausarse, reanudarse, eliminarse, completarse o detenerse por presupuesto
  • Codex puede seguir trabajando, pero solo dentro del contrato definido por el usuario
• Ya es útil para los trabajos donde Codex aporta más valor: debugging, optimización, migraciones, pruebas e investigación
• El usuario aporta el objetivo, Codex sigue la evidencia y el Goal conecta ambas cosas hasta que el trabajo se completa o queda honestamente bloqueado
• En investigación compleja, marca la diferencia entre generar una respuesta y producir una auditoría
• Un buen Goal no solo le pide a Codex que termine, sino que le dice qué significa haber terminado

[hmmhmmhm]

/goal Hasta el mediodía, a las 12, por favor revisa todo lo que se pueda hacer con base en el trabajo que hice antes y avanza con ello. No debes detener el trabajo antes de las 12.

[shakespeares]

Qué buen comando.