Nota del editor: Este artículo proviene de Dominik Kundel, miembro de Relaciones con Desarrolladores de OpenAI, y resume su experiencia con la función «goal mode / /goal» de Codex. No trata sobre una técnica común de prompts, sino sobre un cambio de rol en las herramientas de programación con IA: Codex ya no es solo un asistente de código que responde a instrucciones individuales, sino que comienza a actuar como un agente ejecutor que avanza continuamente hacia un objetivo claro.

En el modo /goal, lo realmente importante no es escribir los requisitos tan largos y detallados como sea posible, sino establecer para Codex criterios de salida claros y verificables. Por ejemplo: «reducir el tiempo de despliegue en un 30%», «alcanzar una cobertura de pruebas del 100% de paridad», «reducir el LCP por debajo de 2,5 segundos». Estos indicadores permiten a Codex determinar si la tarea se ha completado y evitan que intente sin fin soluciones en objetivos ambiguos. Al mismo tiempo, el usuario debe proporcionar suficiente orientación, herramientas y un entorno real para que Codex pueda medir el progreso y verificar los resultados, en lugar de simplemente completar una solución que parezca viable solo en condiciones locales o hipotéticas.

El artículo destaca especialmente que las tareas visuales son las más propensas a hacer que Codex se quede atrapado en los detalles. En lugar de solicitar una "reproducción al 100% a nivel de píxeles", es mejor descomponer los objetivos visuales en una lista de funciones, normas del sistema de diseño y métricas evaluables. Para tareas prolongadas que duran horas o incluso días, también es necesario realizar un seguimiento continuo mediante commits, PR de borrador, documentación de progreso, actualizaciones en Slack o chats laterales, para evitar terminar con un conjunto de cambios imposibles de rastrear.

La información adicional de este artículo radica en que redefine /goal como un «mecanismo de gestión de tareas a largo plazo». Cuando la IA puede ejecutar continuamente decenas e incluso cientos de horas, la habilidad central del desarrollador también cambia: ya no se trata solo de hacer que la IA genere código, sino de definirle objetivos, establecer sistemas de medición, configurar el entorno de ejecución y, finalmente, realizar revisiones y análisis posteriores. En otras palabras, la programación con IA está evolucionando de «escribir prompts» hacia «gestionar un ejecutor de proyectos que trabaja de forma continua».

A continuación se encuentra el texto original:

Hemos lanzado el modo objetivo (goal mode, o /goal) para ayudarte a hacer que Codex avance constantemente hacia un resultado específico. Una vez que establezcas un objetivo, Codex seguirá trabajando hasta que se alcance, ya sea que esto tome varias horas o días. Algunos usuarios ya han hecho que Codex trabaje continuamente durante más de 120 horas para el mismo objetivo.

El modo objetivo es muy potente. Para maximizar su efectividad, al usar /goal, ten en cuenta 7 cosas.

Establecer criterios claros y verificables

Al activar el modo objetivo, la instrucción que ingreses servirá como prompt inicial y, lo que es más importante, se convertirá en el criterio de finalización de ese objetivo. Codex verificará después de cada ciclo de trabajo: ¿se ha completado este objetivo?

Por lo tanto, tu indicación de objetivo no debe ser demasiado larga, sino centrarse en un criterio claro: ¿en qué condiciones se considera que el objetivo se ha alcanzado?

En la mayoría de los casos, un buen objetivo debe incluir una métrica numérica clara que el modelo pueda utilizar para determinar si se ha completado. Por ejemplo:

Reduca el tiempo de construcción y despliegue en un 30 %.

Migra esta función de TypeScript a Rust y alcanza una consistencia de pruebas del 100 %.

Optimizar la estructura de la aplicación para que la pintura de contenido más grande (Largest Contentful Paint, métrica que mide la velocidad de carga del contenido principal de la página) sea inferior a 2.5 segundos en producción.

Esta indicación no siempre debe incluir números, pero generalmente los números facilitan los pasos siguientes.

Si aún no estás seguro de cómo definir tu objetivo, o prefieres comenzar con una lluvia de ideas sobre el proyecto junto a Codex, no necesitas iniciar la conversación con el modo de objetivo.

Codex puede establecer sus propios objetivos. Puedes iniciar primero una conversación normal y, cuando estés listo para que Codex comience a ejecutar, le pides que establezca objetivos basados en lo discutido anteriormente.

También puedes editar el objetivo en cualquier momento: haz clic en el botón Editar en la aplicación Codex o vuelve a usar /goal en la CLI.

Proporciona orientación siempre que sea posible

Las sugerencias como "reducir el tiempo de construcción y despliegue en un 30%" suenan geniales y podrían llevar a Codex a encontrar soluciones creativas. Pero si ya tienes una idea aproximada de dónde podría estar el problema, esta sugerencia también podría desviar a Codex por un camino equivocado.

Por lo tanto, siempre que sea posible, es mejor indicar a Codex desde dónde comenzar la investigación, qué herramientas utilizar para lograr el objetivo, o proporcionar otras indicaciones para evitar que se desvíe en la dirección equivocada.

Por ejemplo, mi colega @reach_vb lo hizo así en un experimento: le dijo a Codex que podía acceder a Google Colab mediante el navegador Chrome y especificó algunas restricciones aceptables, como permitir que Codex genere su propio conjunto de datos mientras entrena el modelo.

Igualmente, si deseas reducir el tiempo de construcción y ya sabes en qué etapa se consume la mayor parte del tiempo, es mejor que, en el prompt, dirijas primero a Codex hacia esa área.

Otra opción es permitir que Codex realice una investigación preliminar en modo planificación y genere un archivo de plan que documente las soluciones potenciales, y luego hacer que tu objetivo consulte ese plan.

Haz que el progreso sea medible

Si tu objetivo es ambicioso o Codex tiene muchas maneras de acercarse progresivamente al objetivo, es importante que le proporciones a Codex herramientas para medir el progreso.

Para ciertas tareas, esto puede ser inherentemente cierto. Por ejemplo, optimizar el tiempo de construcción o aumentar la cobertura de pruebas, ya que Codex generalmente ya puede utilizar las herramientas relacionadas o las creará naturalmente.

Pero para otros objetivos, es mejor que primero hagas una lluvia de ideas con Codex: ¿qué herramientas ayudan a evaluar el progreso? O dale algunas indicaciones para que sepa cómo determinar si se está acercando a su objetivo. Por ejemplo, crea una herramienta de comparación visual de diferencias entre dos capturas de pantalla, o desarrolla un conjunto de evaluación para el agente que estás depurando.

Antes, pedí a Codex que replicara algunos componentes a partir de un video, y Codex creó una herramienta para comparar capturas de pantalla y verificar diferencias. Posteriormente, siguió iterando esta herramienta, añadiendo distintos modos de comparación de diferencias.

Según la tarea, también debes considerar si hay algunos criterios adicionales que deben medirse o verificarse. De lo contrario, Codex podría pensar que la tarea ya está completada, aunque a tus ojos aún no lo esté.

Por ejemplo, Codex podría recortar directamente la imagen de referencia del diseño e incrustarla en la página para lograr una "reproducción píxel a píxel", o reducir el rango de cobertura de pruebas para alcanzar una tasa de aprobación del 100%. Estas no son formas verdaderamente deseadas de completar el trabajo.

Crea un entorno real

Si deseas que Codex logre progresos efectivos hacia su objetivo, debe funcionar en un entorno lo suficientemente realista.

En la práctica, esto significa: si deseas optimizar los tiempos de despliegue o problemas de latencia, Codex debe tener acceso a los entornos de despliegue y prueba, y estos entornos deben simular lo más posible el entorno de producción. Es decir, utilizar la misma pila tecnológica, los mismos interruptores de configuración y bases de datos similares.

Por ejemplo, anteriormente optimizamos los tiempos de compilación y despliegue en developers.openai.com. En ese momento ya estábamos utilizando previsualizaciones de despliegue, por lo que Codex podía aprovechar esos entornos de previsualización para desplegar y revisar los registros correspondientes. Sin embargo, el problema era que nuestras previsualizaciones de despliegue deshabilitaban ciertas rutas de compilación en comparación con el entorno de producción completo.

Por lo tanto, Codex finalmente tuvo que realizar una implementación manual, desplegando el código en un entorno más cercano a la configuración de producción para poder identificar realmente el problema.

De manera similar, también puedes hacer que Codex utilice computer use (la capacidad del modelo para operar interfaces de aplicaciones reales) para probar aplicaciones reales. Para optimizar algunos problemas de rendimiento en iOS, @dimillian incluso utilizó dispositivos físicos para obtener el entorno de prueba más preciso.

Establezca metas visuales con precaución

Darle a Codex un objetivo visual, como «reproduce este UI al 100% en píxeles según esta imagen», es ciertamente atractivo. Pero según la configuración específica, también puede generar problemas.

Si no proporcionas orientación y restricciones adecuadas, Codex podría profundizar demasiado en ciertos detalles, descuidando así el objetivo general. Por ejemplo, si la imagen de referencia incluye algunos elementos gráficos y esperas que Codex genere esos elementos —ya sean íconos SVG o imágenes—, podría dedicar gran parte de su esfuerzo a «cómo replicar exactamente estos elementos» en lugar de descomponer correctamente todo el problema.

Además, Codex necesita herramientas para realizar comparaciones visuales correctamente. Esto implica más entradas de imágenes y un mayor consumo total de tokens, pero no necesariamente proporciona a Codex una forma sencilla de identificar oportunidades de mejora verdaderamente valiosas.

Por lo tanto, las imágenes suelen ser más adecuadas como contexto de objetivo que como único criterio de finalización. Debes buscar otras formas de que Codex determine si el objetivo ya se ha logrado, como listas de funciones, especificaciones de implementación o si se ajusta al sistema de diseño.

Seguimiento del progreso

Si Codex funciona en segundo plano durante horas o incluso días, incluso en otra máquina, es fácil olvidar hasta dónde ha avanzado y qué tareas ya ha completado.

Según diferentes objetivos, encontré que las siguientes formas son muy útiles:

· Haz que Codex envíe código en puntos clave y lo envíe a un PR borrador. Esto será especialmente útil si estás trabajando en un sitio web con implementación de previsualización.

·Haz que Codex actualice un entregable dirigido a la gerencia. Puede ser un archivo HTML que puedas mantener abierto en el navegador integrado de la aplicación; o una página desplegada a través de Sites para que el equipo la consulte; puede ser una gráfica de progreso renderizada, o simplemente un archivo Markdown común.

Indica a Codex que publique actualizaciones proactivas. También puedes incluir esto como un objetivo: que Codex envíe actualizaciones al canal de Slack, o a cualquier otro lugar donde desees registrar el progreso, cuando logre avances importantes.

Consulta el estado en otra ventana de chat. Si solo deseas obtener rápidamente el estado actual, ejecuta /side para iniciar un nuevo chat lateral y haz tu pregunta allí. Como se ramifica desde el hilo actual, tiene todo el contexto hasta el momento, pero tiene una duración breve.

Otra alternativa en la aplicación Codex es iniciar un nuevo chat normal, permitir que Codex lea otro hilo objetivo y responda tus preguntas. Este enfoque es especialmente poderoso si le pides a Codex que configure una tarea automatizada para verificar el progreso periódicamente.

Limpiar y confirmar finalmente los resultados

¡Excelente, ¡el objetivo finalmente se logró! ¿Ahora podemos simplemente entregar los resultados al equipo y terminar por hoy?

Por lo general, especialmente en tareas de optimización, he encontrado útil pedirle a Codex que revise y evalúe su propio trabajo. Puedes comenzar ejecutando una revisión local de código con /review, pero también vale la pena que Codex reflexione más profundamente: ¿qué caminos intentó seguir para lograr el objetivo? ¿Qué intentos fueron efectivos? ¿Cuáles no lo fueron? Luego, limpia el código en base a esa reflexión.

Como Codex seguirá trabajando hasta alcanzar el objetivo, puede haber intentado algunos métodos que no funcionaron bien o que fueron completamente ineficaces, y estos cambios residuales podrían seguir presentes en el código final.

Establece un objetivo para tu próxima tarea.

La función objetivo de Codex es una herramienta extremadamente poderosa que puede ayudarte a resolver algunos de los desafíos de ingeniería más significativos. Pero solo alcanzará su máximo rendimiento cuando le proporciones el entorno y las instrucciones adecuados.

¿Qué has hecho con /goal?