Título original: Una guía para /goal
Autor original: @dkundel, Miembro del equipo de relaciones con desarrolladores de OpenAI
Traducción: Peggy

Nota del editor: Este artículo proviene del miembro del equipo de relaciones con desarrolladores de OpenAI, Dominik Kundel, quien resume su experiencia usando la función Codex «goal mode / /goal». No se trata de una técnica común de prompts, sino de un cambio de rol en las herramientas de programación AI: Codex ya no es solo un asistente de código que responde a instrucciones de una sola ronda, sino que comienza a convertirse en un agente ejecutor capaz de avanzar continuamente en torno a objetivos claros.

En el modo /goal, lo realmente importante no es escribir requisitos cada vez más largos y detallados, sino establecer estándares de salida claros y verificables para Codex. Por ejemplo: «Reducir el tiempo de despliegue en un 30%», «Alcanzar una cobertura de pruebas del 100% en paridad», «Reducir LCP a menos de 2.5 segundos». Estos indicadores permiten a Codex determinar si la tarea está completa y evitan que pruebe y error indefinidamente en objetivos vagos. Al mismo tiempo, el usuario debe proporcionar suficiente orientación, herramientas y un entorno real para que Codex pueda medir el progreso, verificar resultados y no solo completar una solución aparentemente factible en local o en condiciones hipotéticas.

El artículo advierte especialmente que las tareas visuales son las que más fácilmente hacen que Codex caiga en detalles minuciosos. En lugar de exigir «una reproducción pixel-perfect al 100%», es mejor desglosar el objetivo visual en una lista de funciones, especificaciones del sistema de diseño y métricas evaluables. Para tareas a largo plazo que duren horas o incluso días, también es necesario hacer un seguimiento continuo mediante commits, borradores de PR, documentos de progreso, actualizaciones en Slack o chats laterales, para evitar que al final solo queden cambios no rastreables.

La aportación principal de este artículo es que redefine /goal como un «mecanismo de gestión de tareas a largo plazo». Cuando la IA puede ejecutar durante decenas o incluso cientos de horas seguidas, las habilidades centrales del desarrollador también cambian: no solo hacer que la IA genere código, sino definir objetivos, establecer sistemas de medición, configurar el entorno de ejecución y, al final, realizar revisiones y análisis retrospectivos. En otras palabras, la programación con IA pasa de «escribir prompts» a «gestionar un ejecutor de ingeniería que trabaja continuamente».

A continuación, el texto original:

Hemos lanzado el modo objetivo (goal mode, o /goal) para ayudarte a mantener a Codex en una trayectoria hacia un resultado concreto. Cuando estableces un objetivo, Codex trabajará continuamente hasta alcanzarlo, ya sea en unas horas o en varios días. Ya hay quienes han hecho que Codex trabaje más de 120 horas seguidas en un mismo objetivo.

El modo objetivo es muy potente. Para maximizar su utilidad, hay 7 cosas que vale la pena tener en cuenta al usar /goal.

Establecer estándares claros y verificables

Cuando activas el modo objetivo, la indicación que ingresas puede servir como prompt inicial, pero lo más importante es que se convertirá en el criterio de salida para ese objetivo. Codex verificará después de cada ciclo de trabajo: ¿se ha cumplido ya el objetivo?

Por eso, tu prompt de objetivo no debe ser demasiado largo, sino centrarse en un estándar claro: ¿en qué condiciones se considera que el objetivo está alcanzado?

En la mayoría de los casos, un buen objetivo incluye un indicador numérico claro para que el modelo pueda juzgar si está completo. Por ejemplo:

«Reducir el tiempo de construcción y despliegue en un 30%.»

«Migrar esta funcionalidad de TypeScript a Rust y alcanzar un 100% de coherencia en las pruebas.»

«Optimizar el scaffolding de la aplicación para que el Largest Contentful Paint (medidor de velocidad de carga del contenido principal de la página) sea inferior a 2.5 segundos.»

Este prompt no siempre necesita incluir números, pero generalmente los números facilitan avanzar en los pasos siguientes.

Si aún no estás seguro de cómo definir un objetivo, o quieres hacer una lluvia de ideas con Codex antes de empezar, no es necesario activar el modo objetivo desde el principio.

Codex puede establecer objetivos por sí mismo. Puedes comenzar una conversación normal y, cuando estés listo para que comience a ejecutar, hacer que Codex defina un objetivo basado en lo discutido previamente.

También puedes editar el objetivo en cualquier momento: en la interfaz de Codex, haciendo clic en el botón de editar, o en la CLI, usando nuevamente /goal.

Proporcionar instrucciones lo más completas posible

Indicaciones como «Reducir en un 30% el tiempo de construcción y despliegue» suenan bien y pueden inspirar soluciones creativas, pero si ya tienes una idea aproximada de dónde puede estar el problema, este tipo de indicaciones puede hacer que Codex tome caminos equivocados.

Por eso, cuando sea posible, es mejor decirle a Codex desde dónde comenzar a investigar, qué herramientas puede usar para lograr el objetivo, o dar otras pistas que eviten que se pierda en direcciones incorrectas.

Por ejemplo, mi colega @reach_vb hizo esto en un experimento: le dijo a Codex que podía usar Chrome para acceder a Google Colab, y le explicó algunas restricciones aceptables, como que durante el entrenamiento del modelo, podía hacer que generara conjuntos de datos por sí mismo.

De igual forma, si quieres reducir el tiempo de construcción y ya sabes en qué parte se consume más tiempo, lo mejor es dirigir a Codex hacia esa área en el prompt.

Otra opción es que puedas hacer que Codex investigue en modo plan (plan mode) y cree un archivo de plan para registrar posibles soluciones. Luego, ese plan puede ser referenciado en tu objetivo.

Hacer que el progreso sea medible

Si tu objetivo es ambicioso o Codex tiene varias maneras de acercarse a él, es fundamental proporcionarle herramientas para medir el avance.

Para algunas tareas, esto puede ser natural. Por ejemplo, optimizar tiempos de construcción o aumentar la cobertura de pruebas, ya que Codex suele poder usar herramientas relacionadas o crearlas automáticamente.

Pero en otros casos, es mejor hacer una lluvia de ideas con Codex: ¿Qué herramientas ayudan a verificar el progreso? O darle pistas para que sepa cómo confirmar que se está acercando al objetivo. Por ejemplo, crear una herramienta de comparación visual de diferencias entre capturas de pantalla, o un conjunto de evaluación para un agente en desarrollo.

Una vez, pedí a Codex que reprodujera componentes a partir de un video, y creó una herramienta para comparar capturas y detectar diferencias. Luego, fue iterando esa herramienta, añadiendo diferentes modos de comparación.

Imagen: Una captura generada por Codex para comparación visual de dos cuadros.

Dependiendo de la tarea, también debes considerar si hay estándares adicionales que medir o verificar. De lo contrario, Codex podría pensar que la tarea está terminada cuando en realidad aún no lo está.

Por ejemplo, para «reproducir pixel-perfect» un UI, Codex podría recortar una referencia de diseño y embebérsela en la página; o, para alcanzar un 100% en pruebas, reducir la cobertura en exceso. Estas no son formas reales de completar la tarea.

Crear un entorno real

Si quieres que Codex avance de manera efectiva hacia el objetivo, necesita ejecutarse en un entorno lo más real posible.

En la práctica, esto significa que si quieres optimizar tiempos de despliegue o latencia, Codex debe tener acceso a los entornos de despliegue y prueba, que deben simular lo más posible el entorno de producción. Es decir, usar la misma pila tecnológica, las mismas configuraciones y bases de datos similares.

Por ejemplo, cuando estuvimos depurando la optimización de tiempos de construcción y despliegue en developers.openai.com, ya usábamos despliegues previos, así que Codex podía desplegar en estos entornos y revisar logs. Pero el problema era que estos despliegues previos no eran exactamente iguales a la producción, ya que algunas rutas de construcción estaban desactivadas.

Por eso, al final, tuvimos que hacer despliegues manuales en entornos más cercanos a producción para verificar los problemas.

De igual forma, puedes hacer que Codex use la capacidad de manipular aplicaciones reales para probar en entornos reales. Para mejorar algunos problemas de rendimiento en iOS, @dimillian incluso usó dispositivos físicos para obtener resultados más precisos.

Ser cauteloso con los objetivos visuales

Dar a Codex un objetivo visual, como «reproducir al 100% este UI a nivel pixel», puede parecer muy atractivo. Pero, dependiendo de cómo se configure, también puede traer problemas.

Si no proporcionas instrucciones y restricciones adecuadas, Codex puede centrarse demasiado en detalles específicos y perder de vista el objetivo general. Por ejemplo, si en la referencia hay elementos gráficos y esperas que Codex genere esos elementos —ya sean íconos SVG o imágenes—, puede dedicar mucho esfuerzo a «recrear exactamente estos recursos» en lugar de desglosar el problema correctamente.

Además, Codex necesita herramientas para hacer comparaciones visuales. Esto implica más entradas de imágenes, mayor consumo de tokens, y no siempre una forma sencilla de que identifique oportunidades de mejora valiosas.

Por eso, las imágenes suelen ser más útiles como contexto del objetivo, no como único criterio de finalización. Es mejor buscar otras formas de verificar si se ha alcanzado el objetivo, como listas de funciones, especificaciones de implementación o cumplimiento del sistema de diseño.

Seguir el progreso

Si Codex trabaja en segundo plano durante horas o días, o en otra máquina, es fácil perder la pista de qué ha avanzado y qué tareas ha realizado.

Dependiendo del objetivo, estas estrategias pueden ser útiles:

·Hacer que Codex envíe commits en puntos clave y los suba a un borrador de PR, especialmente útil en sitios web con despliegues previos.

·Hacer que actualice un entregable para gestión, como un archivo HTML visible en el navegador, una página desplegada en un sitio interno, un gráfico de progreso renderizado, o simplemente un archivo Markdown.

·Indicarle que envíe actualizaciones de progreso automáticamente, por ejemplo, enviando mensajes a Slack cuando logre avances importantes, o en otros canales de registro.

·Usar otro chat para consultar el estado. Si solo quieres una respuesta rápida, puedes iniciar /side para abrir un chat lateral, que tendrá todo el contexto actual pero será breve.

Otra opción en la interfaz de Codex es abrir un chat nuevo y hacer que lea otro hilo de objetivos, y responder a tus preguntas. Si configuras tareas automáticas para revisar el progreso periódicamente, esta estrategia puede ser especialmente poderosa.

Limpiar y confirmar resultados finales

¡Perfecto, el objetivo ya está cumplido! ¿Se puede simplemente entregar el resultado al equipo y cerrar?

Por lo general, especialmente en tareas de optimización, es útil que Codex revise y analice su propio trabajo. Puedes usar /review para hacer una revisión local del código, pero también vale la pena que Codex reflexione más profundamente: ¿Qué caminos intentó para alcanzar el objetivo? ¿Qué funcionó? ¿Qué no? Y limpiar el código en consecuencia.

Dado que Codex trabaja hasta que se alcanza el objetivo, puede haber probado métodos ineficaces o incluso inútiles, y esas modificaciones residuales pueden quedar en el código final.

Establece un objetivo para tu próxima tarea

La función de objetivos de Codex es una herramienta extremadamente poderosa para resolver algunos de los desafíos más importantes en ingeniería. Pero solo cuando proporcionas el entorno y las instrucciones correctas, puede llegar de manera más eficiente a la meta.

¿Has usado /goal? ¿Qué lograste?

[Enlace al original]

Haz clic para conocer las oportunidades laborales en BlockBeats

Únete a la comunidad oficial de BlockBeats:
Telegram suscripción: https://t.me/theblockbeats
Telegram grupo: https://t.me/BlockBeats_App
Cuenta oficial en Twitter: https://twitter.com/BlockBeatsAsia