Codex /goal command: mi opinión honesta sobre autonomous coding

La primera vez que le di a Codex un /goal y me alejé de mi escritorio, regresé cuarenta minutos después y descubrí que había reescrito la misma función once veces. Once. Cada versión un poco diferente. Ninguno de ellos objetivamente mejor que el anterior. El agent estaba en bucle, no en el sentido productivo de Ralph-loop, sino en el sentido de "No tengo idea de cuándo parar". Mi objetivo había sido "hacer el renderizado más rápido". Ese fue todo el mensaje. Ese fue todo el problema.

Le había dado un objetivo vago a un agent autónomo de larga duración y luego actué sorprendido cuando se desvió.

El comando Codex /goal llegó a la versión 0.128.0 a finales de abril y cambia la forma de lo que se supone que debe hacer una codificación agent. La mayoría de los comandos de barra diagonal son reactivos: preguntas, responde y vuelves a preguntar. /goal es lo contrario. Usted establece un objetivo una vez y Codex continúa planificando, actuando, probando, evaluando y repitiendo, hasta que el objetivo esté verificablemente logrado o usted le indique que se detenga. Es lo más parecido a "disparar y olvidar" autonomous coding que he usado y que no se siente completamente desquiciado.

Pero "no se siente completamente desquiciado" hace mucho trabajo en esa frase. Porque la diferencia entre una ejecución de /goal que ofrece una ganancia de rendimiento del 25% y una que produce once versiones de la misma función rota no es el modelo. Tampoco es el mensaje. Es algo más sutil y una vez que lo ves, no puedes dejar de verlo.

He pasado las últimas dos semanas viviendo dentro de este comando. Esto es lo que aprendí, en qué me equivoqué y el marco que uso ahora para decidir si un trabajo pertenece a una ejecución de /goal o a una solicitud de extracción normal.

Qué es realmente el comando Codex /goal

Primero, permítanme eliminar el lenguaje de marketing de esto, porque el registro de cambios OpenAI es, como siempre, extremadamente conciso sobre lo que se envió.

El comando Codex /goal es un modo objetivo persistente para Codex CLI. Le das un objetivo. No devuelve el control después de una respuesta. Asigna su repo, planifica, edita archivos, ejecuta pruebas, evalúa el resultado según sus criterios de parada y declara el objetivo completo o inicia otra iteración. El agent permanece unido al hilo en muchas llamadas a herramientas. Sobrevive a los límites del contexto debido a cómo Codex compacta y reutiliza el estado. Registra el progreso. Respeta las normas de aprobación.

Esto no es una charla. Es un proceso de trabajo con una lista de verificación.

Se envió como una característica experimental, que en OpenAI significa "esto es real, pero aún no lo incluiremos en la página de inicio". Lo habilita manualmente en su archivo de configuración, ejecuta Codex en su terminal y aparece un pequeño conjunto de nuevos comandos de barra diagonal en la TUI.

Aquí está la superficie de comando real a partir de Codex CLI 0.128.0:

/goal <objective>: establece un objetivo a largo plazo y comienza el ciclo.
/goal pause: finaliza el paso actual y luego pausa
/goal resume: reanudar un objetivo pausado
/goal clear: borra completamente el objetivo activo
/goal (sin argumentos): muestra el progreso, el uso del token y el tiempo transcurrido
/side <prompt>: abre un hilo lateral para hacer una pregunta sin alterar el objetivo principal; retroceder con la tecla escape

El comando /side es la parte de la que nadie habla y, secretamente, es la mejor característica del paquete. Más sobre eso más adelante.

Ahora, antes de entrar en cómo usar esto, hay una cosa en el video original que vi que está mal, y te ahorrarás una tarde frustrante si lo sabes ahora.

El único detalle de configuración en el que todos se equivocan

El tutorial que seguí originalmente me decía que habilitara objetivos en config.yml. Pasé veinte minutos confundidos preguntándome por qué no pasaba nada antes de verificar la documentación real de Codex.

Codex CLI no usa YAML. Utiliza TOML.

El archivo es ~/.codex/config.toml y la bandera se encuentra en una tabla [features]. El bloque de habilitación mínimo se ve así:

[features]
goals = true

También puedes hacerlo desde la línea de comando: codex features enable goals escribe el mismo valor en el mismo archivo. De cualquier manera, guarde el archivo, reinicie Codex y los comandos /goal y /side aparecerán en la paleta de comandos de barra diagonal. Si no es así, ha editado el archivo incorrecto o tiene una versión Codex anterior a 0.128.0. Ejecute codex --version para confirmar.

Una vez que features.goals = true se configura globalmente, la función funciona tanto en la aplicación Codex CLI como en la Codex. Solo necesita habilitarlo una vez, en CLI, y se propaga.

Pequeño detalle. Gran diferencia entre "esto funciona" y "estoy perdiendo una hora".

Dejando eso de lado, hablemos de lo que realmente importa: es decir, cuándo debes utilizar este comando en primer lugar, porque la respuesta es "mucho menos a menudo de lo que piensas".

Los dos tipos de trabajo de codificación y por qué /goal es incorrecto para uno de ellos

Este es el modelo mental que me tomó una semana de mal uso para llegar a él.

Casi todos los trabajos de codificación que hago se clasifican en una de dos categorías. Las categorías parecen similares desde fuera. Por lo general, un ingeniero experimentado puede distinguirlos en unos treinta segundos. Un codificador agent (y, francamente, muchos ingenieros jóvenes) no pueden distinguirlos en absoluto. Y /goal es sólo la herramienta adecuada para uno de ellos.

Categoría uno: trabajo bien definido. Ya conoces el insumo. Ya conoces el resultado. Sabes aproximadamente cómo se ve la diferencia antes de comenzar. "Integre Notion API para que podamos sincronizar los resúmenes del cliente en la base de datos de un proyecto". "Agregue un controlador de webhook Stripe que se registre en nuestra tabla de eventos existente". "Migrar el modelo de usuario de claves primarias basadas en correo electrónico a claves primarias basadas en UUID". Estas tareas tienen una forma. Hay una cantidad finita de archivos que deben cambiarse, una definición clara de lo que está hecho y la ruta es en su mayor parte mecánica una vez que lo has pensado durante diez minutos.

Para este tipo de trabajo, /goal es excesivo, casi dañino. No quieres un bucle de autoevaluación. Quieres un PR limpio. Quiere que agent haga exactamente lo que pidió, le devuelva el control y le permita revisar. El flujo de trabajo estándar Codex (mensaje único, respuesta única, revisión normal) maneja esto a la perfección. Escribo sobre cómo ejecuto ese bucle en mi [desglose del flujo de trabajo Codex y Claude Code dos-agent] (https://www.mejba.me/blog/claude-code-codex-two-agent-workflow), y el 90% de mi trabajo real todavía se encuentra allí.

Categoría dos: trabajo exploratorio. Aquí es donde se conoce el objetivo pero no el camino. "Reduzca la latencia P95 en este API en un 20 %". "Reducir nuestra huella de memoria en el grupo de trabajadores". "Encuentra y corrige el cambio de diseño que hace que nuestra puntuación Lighthouse se hunda en el móvil". Puede describir el resultado deseado con una métrica. Sin embargo, no puedes describir la diferencia de antemano. La solución podría ser un cambio de configuración, una optimización de consultas, una refactorización de código, un intercambio de algoritmos, o alguna combinación de los cuatro descubiertos en secuencia después de ejecutar perfiladores.

Para esto se creó /goal. El ciclo de razonamiento (planificar, actuar, probar, evaluar, iterar) tiene exactamente la forma adecuada para la exploración. Estableces un objetivo verificable y dejas que el agent trabaje. Intenta algo. Las pruebas indican si el cambio movió la métrica. En caso afirmativo, intenta ir más allá. Si no, retrocede e intenta un ángulo diferente.

¿La historia de mejora del 25% de FPS que verás en las demostraciones de Codex? Esa es la categoría dos. Alguien le dio a Codex un problema de rendimiento de renderizado con un objetivo claro y medible y lo dejó funcionar durante horas. No sabían qué optimización aterrizaría antes de comenzar. El agent descubrió qué probar y qué conservar.

La idea más profunda aquí, que tuve que aprender de la manera más difícil: la mayoría de los ingenieros adoptan por defecto el pensamiento de categoría uno incluso cuando trabajan en problemas de categoría dos. Intentan especificar la solución antes de comprender el espacio de búsqueda. /goal te obliga a cambiar eso: debes comprometerte con el destino sin comprometerte con la ruta. Eso es incómodo. También es donde está la influencia.

Pero sólo funciona si tu destino es real. Lo que nos lleva a la disciplina que hace o deshace cada objetivo.

La verificabilidad de objetivos es todo el juego

Mira lo que sucede cuando le das a Codex un objetivo vago.

Probé /goal make the search faster en un pequeño proyecto paralelo de Laravel. Codex comenzó ejecutando la búsqueda existente y obtuvo una línea de base (buena). Luego agregó un índice en la columna más consultada (bueno). Luego volvió a comparar y encontró una mejora del 14% (bueno). Luego siguió adelante. Agregó almacenamiento en caché de resultados de consultas. Luego refactorizó el controlador de búsqueda. Luego agregó una capa de Redis. Luego sugirió una migración de búsqueda de texto completo a Meilisearch. En ningún momento se detuvo, porque en ningún momento le había dicho lo que significaba "lo suficientemente rápido".

Codex inyecta una instrucción del sistema al comienzo de cada iteración que dice, en esencia, "tratar la incertidumbre como si no se hubiera logrado". Es una barrera contra falsas afirmaciones de finalización. Pero corta en ambos sentidos. Si su objetivo es realmente no verificable (si no hay métrica, lista de verificación, prueba que pueda arrojar un pase limpio), entonces el agent considerará que el objetivo no se ha logrado perpetuamente. Seguirá iterando hasta que te quedes sin fichas, paciencia o dinero.

La solución es sencilla de describir y sorprendentemente difícil de ejecutar. Cada /goal que configure debe contener dos cosas:

Un objetivo concreto. Ya sea una métrica ("P95 por debajo de 250 ms"), una prueba de aprobación ("todas las pruebas e2e en tests/checkout/ verde") o una lista de verificación verificable ("la barra lateral del panel muestra el enlace de administración de Filament, las pruebas automatizadas pasan, no hay nuevos errores de consola en el registro de compilación").
Una definición de hecho que el agent puede verificar por sí mismo. No "hasta que se vea bien". No "hasta que el desempeño sea aceptable". El agent debe poder ejecutar un comando, observar un resultado y decidir basándose únicamente en esa observación.

Compare estas dos indicaciones. Misma intención. Comportamiento tremendamente diferente:

Malo: /goal speed up the dashboard
Bueno: /goal Reduce dashboard initial paint from current 2.4s baseline to under 1.0s on the staging environment. Success criteria: Lighthouse performance score above 90 on /dashboard, all existing e2e tests in tests/dashboard/ continue to pass, no new TypeScript errors in the build.

El primero es un deseo. El segundo es un contrato. Codex puede cumplir contratos. No puede cumplir los deseos y, peor aún, pretenderá intentarlo.

Cuando no estoy seguro de cómo escribir el contrato, hago algo que los documentos OpenAI Codex recomiendan explícitamente y que ahora me niego a omitir: primero hago una lluvia de ideas sobre el objetivo con Codex, en modo de chat normal, antes de ejecutar /goal. Describo el problema. Le pregunto a Codex qué criterios de éxito verificables propondría. Lo discuto. Aprieto los criterios. Entonces, y sólo entonces, abro un hilo limpio y ejecuto /goal con el contrato refinado. Ese paso de lluvia de ideas requiere quizás diez minutos de trabajo y me ha ahorrado horas de gasto de tokens desperdiciados.

Qué hace realmente Codex una vez que comienza el objetivo

Permítanme recorrer el circuito, porque la mecánica importa.

Cuando escribe /goal <objective>, Codex hace algo que parece corriente pero que en realidad es la base de todo lo que sigue: asigna repository. Lee estructuras de archivos, configuraciones clave y manifiestos de paquetes. Esboza un modelo de cuál es su proyecto y cómo está cableado. Esto no es gratis (cuesta tokens), pero es la diferencia entre un agent que escribe código que parece plausible y uno que escribe código que realmente se ajusta a su base de código. Analizo por qué es importante este tipo de carga de contexto inicial en mi artículo sobre context engineering, y /goal es una de las expresiones más claras de ese principio en cualquier herramienta AI actual.

Entonces planifica. Codex esboza una secuencia de pasos que cree que avanzarán hacia la meta. Elige el primer paso. Lo ejecuta. La "ejecución" puede ser cualquier cosa: editar archivos, ejecutar comandos de shell, ejecutar pruebas, presionar un API, leer registros. Luego evalúa. ¿El paso movió la métrica? ¿Pasó las pruebas? ¿Cumplió con un elemento de la lista de verificación?

En caso afirmativo, elige el siguiente paso. Si no, prueba una variante o retrocede e intenta un ángulo diferente. El bucle continúa.

Puedes ver cómo sucede esto en tiempo real y es realmente hipnótico. Hay un ritmo en ello. Leer, escribir, probar, observar, decidir. El agent no te está esperando. Simplemente está funcionando.

Mientras funciona, puedes emitir comandos. /goal pause finaliza el paso actual y detiene el ciclo limpiamente: sin ediciones a medio aplicar ni llamadas a herramientas huérfanas. /goal resume continúa donde lo dejó. /goal sin argumentos le muestra un resumen del progreso, el gasto de tokens y el tiempo transcurrido sin interrumpir nada.

Y luego está /side.

/side <prompt> abre un hilo lateral efímero que no interrumpe el objetivo principal. El bucle principal sigue funcionando. Puede hacerle una pregunta a Codex: "espera, ¿cuál es la diferencia entre un controlador de desplazamiento limitado y antirrebote?" – y obtener una respuesta en un contexto separado, luego regresar al hilo principal para seguir observando el objetivo. Esto suena menor. Que no es. Antes de /side, cada interrupción interrumpía el flujo de agent. Con /side, puedes comprobar la cordura de tus decisiones, buscar información no relacionada o incluso iniciar un pequeño experimento de clarificación, todo sin envenenar el contexto del objetivo principal.

Esta única característica es lo que me hizo empezar a confiar en /goal para tiradas más largas. La capacidad de preguntar sin interrumpir cambia la relación de "tengo que comprometerme plenamente y tener esperanza" a "puedo supervisar sin sabotear".

El problema de la compactación que nadie ve venir

Aquí es donde las cosas se ponen técnicas y donde vive la diferencia entre una ejecución /goal productiva y una condenada al fracaso.

agents de larga duración acumula contexto. Cada llamada a una herramienta, cada archivo leído, cada resultado de una prueba, todo se acumula en el historial de conversaciones. Al final llegas a la ventana de contexto del modelo y algo tiene que ceder. Codex maneja esto con el mensaje compaction. Lo que resume antes se convierte en un resumen más estricto y luego continúa desde allí.

La compactación parece sencilla. No lo es.

Un buen compaction preserva lo que importa: el objetivo, el estado actual del trabajo, las cosas que funcionaron, las cosas que fallaron y por qué, las limitaciones, las preferencias del usuario. Después de un buen compaction, el agent continúa donde lo dejó y el trabajo se siente continuo. El compaction incorrecto elimina el contexto ganado con tanto esfuerzo: la razón específica por la que falló un enfoque anterior, la elección de configuración que hizo que un punto de referencia fuera válido, la compensación que el usuario eligió explícitamente. Después de un compaction incorrecto, el agent vuelve a intentar enfoques fallidos, vuelve a formular preguntas resueltas y poco a poco se aleja de la intención original.

Vi cómo sucedió esto en un proyecto real. Codex estaba ejecutando /goal para optimizar una canalización de consultas de base de datos. Alrededor del tercer compaction, se perdió el hecho de que había optado explícitamente por no participar en la desnormalización. Volvió a sugerir la desnormalización. Lo capté porque estaba mirando, pero si hubiera estado AFK, el agent habría pasado una hora recorriendo un camino que ya había cerrado.

Hay buenas investigaciones de la comunidad sobre cómo Codex compaction realmente funciona bajo el capó: la investigación de Simon Zhou y el resumen más amplio de investigación de compaction valen la pena si desea conocer los detalles de la sala de máquinas. La versión corta: la calidad de compaction es una función de cómo resume el arnés agent, qué conserva y qué descarta. Codex es razonablemente bueno en esto, pero no perfecto, y los objetivos más largos lo enfatizan más.

La implicación práctica para los usuarios de /goal es pequeña pero importante: escriba la definición de su objetivo en el tipo de lenguaje que sobrevive a compaction. Utilice números específicos. Utilice archivos y funciones con nombre. Indique las restricciones explícitamente con "no hacer" en lugar de "prefiero no hacerlo". Cualquier cosa que diga una vez y asuma que el agent lo recordará está en riesgo. Todo lo que incluya en la definición del objetivo se reinyecta en cada límite de iteración, lo que significa que sobrevive a cada compaction.

Ahora escribo las definiciones de mis objetivos como si estuviera escribiendo un contrato que debe leerse en voz alta al comienzo de cada reunión, porque eso es efectivamente lo que está sucediendo.

El medio ambiente importa más que la elección del modelo

Esta es la parte de /goal que más me sorprendió.

Supuse que la diferencia entre una gran carrera y una mediocre se reduciría al modelo que eligiera. No fue así. La variable más importante en la calidad de /goal, por un amplio margen, es el entorno en el que opera agent.

Una ejecución de /goal es tan buena como las señales disponibles para agent. Si el objetivo es "reducir la latencia de P95 en un 20 %" y el agent no tiene forma de medir la latencia de P95, el objetivo no es verificable en la práctica, sin importar cuán limpio lo haya escrito. El agent lo adivinará. Optimizará lo que puede ver, esperará que se correlacione con lo que no puede y producirá cambios que pueden cambiar o no la métrica real.

Los entornos enriquecidos producen excelentes ejecuciones de /goal. Rico significa:

Registros reales. Registros de aplicaciones, estructurados y consultables, idealmente desde un entorno de prueba que refleje el comportamiento de producción.
Un grupo de ensayo o prueba. Distribuido si el objetivo implica algo relacionado con la red. El agent debe poder realizar un cambio, implementarlo y observar.
Métricas de costos y rendimiento. En vivo, consultables y con líneas de base claras. Si el agent no puede extraer los números actuales, no puede decidir si ya está hecho.
Gráficos de llama y perfiladores. Para trabajos de performance, esto no es negociable. El agent no encontrará una ruta activa leyendo únicamente el código fuente.
Acceso completo a la base de código con permiso para modificar, ejecutar pruebas e inspeccionar el estado de git. Una ejecución de /goal que tiene que solicitar permiso para cada comando consumirá su tiempo en solicitudes de aprobación en lugar de en progreso.

Para objetivos de alto riesgo o que requieren un uso intensivo de recursos (cualquier cosa que requiera consumir CPU durante horas, dañar una base de datos o ejecutar un conjunto de pruebas de referencia largo), no los ejecuto en mi máquina local. Pongo en marcha un VPS en la nube, clono el repo allí, ejecuto Codex desde una sesión SSH y lo dejo funcionar. No se trata sólo del coste de los recursos. Se trata de no tener el ventilador de mi computadora portátil gritando durante seis horas mientras se ejecuta un ciclo de referencia. Se trata de aislar el entorno para que "el agent rompió algo" permanezca contenido.

Si ha estado postergando la ejecución de cloud-based agent, este es el caso de uso que finalmente justifica configurarlo correctamente. Cubro el patrón más amplio en mi artículo de larga duración sobre el arnés agent, y /goal encaja en ese patrón tan claramente como cualquier cosa que haya visto.

La trampa de la rama Scrappy y el bucle PRD que la soluciona

Esto es lo más contradictorio que he aprendido sobre las ejecuciones de /goal, y es la lección que desearía que alguien me hubiera enseñado antes de comenzar.

El resultado de una ejecución exitosa de /goal casi nunca es un código que deba enviar.

Esa frase sonará mal si no la has vivido. Déjame explicarte.

Una ejecución de /goal es, por diseño, exploratoria. El agent busca una solución que no conoce de antemano. El camino que tome incluirá callejones sin salida, declaraciones de impresión de depuración, valores codificados utilizados para pruebas, comentarios como // TODO: revisit this hack y atajos que funcionaron localmente pero que no sobrevivirán a la revisión del código. El agent no es perezoso. Está haciendo exactamente lo que parece el trabajo exploratorio cuando lo hace un humano: hacer que algo funcione, validar el enfoque y luego limpiar. Excepto que a /goal generalmente se le acaba el tiempo, los tokens o la paciencia antes de la fase de limpieza.

Lo que obtienes es lo que ahora llamo un "branch". Funciona. Mueve la métrica. Satisface la definición del objetivo. También es, con frecuencia, un absoluto desastre.

Las primeras veces que ejecuté /goal, intenté fusionar estos branch directamente. Siempre un error. Encontraría impresiones de depuración en el código de producción dos semanas después. Encontraría un truco que dependía de un archivo específico que existía solo en el directorio de trabajo de agent. Encontraría enfoques que resolvieran el objetivo inmediato pero introdujeran una deuda técnica sutil.

La solución es un flujo de trabajo, no un indicador de configuración. Una vez que una ejecución de /goal se completa con éxito, trato el resultado como una prueba de concepto, no como un producto entregable. Leí la diferencia con atención. Extraigo el insight: la técnica real que resolvió el problema. Luego escribo un breve PRD que describe lo que aprendí: el enfoque, las compensaciones, las restricciones, las partes que funcionaron y las partes que necesitan limpieza.

Luego tiro el branch.

Abro un hilo nuevo, le doy a Codex el PRD como una especificación limpia y ejecuto una tarea normal (trabajo de categoría uno, según mi definición anterior) para implementar la misma idea en una base de código limpia. El resultado es dramáticamente mejor. Sin impresiones de depuración. Sin trucos. No hay tejido cicatricial acumulado de la fase de exploración. Simplemente una implementación limpia de un enfoque que ahora ha demostrado que funciona.

Este patrón de dos fases (exploración a través de /goal y luego implementación a través del flujo de trabajo normal) es el patrón de codificación AI de mayor apalancamiento que he encontrado este año. Refleja cómo los buenos ingenieros humanos trabajan realmente en problemas difíciles. Tú exploras. Aprendes. Tiras la púa. Tú construyes lo real.

Algunos ingenieros de la comunidad Ralph-loop han estado escribiendo sobre autonomous coding impulsado por PRD en líneas similares, y la convergencia no es una coincidencia. El patrón funciona porque separa dos tipos de cognición que el agent no debería hacer simultáneamente: descubrir qué construir y construirlo bien.

Mi marco de decisión para /goal frente al flujo de trabajo normal

Después de dos semanas de pruebas, este es el árbol de decisiones que uso ahora antes de optar por /goal:

Pregunta 1: ¿Puedes describir la diferencia antes de comenzar?

En caso afirmativo → flujo de trabajo estándar. Escriba un mensaje enfocado, obtenga una respuesta enfocada, revise el PR. /goal no agrega nada aquí.
En caso negativo → continúe con la pregunta 2.

Pregunta 2: ¿Puedes describir el objetivo como un resultado verificable y mensurable?

En caso afirmativo → /goal está sobre la mesa. Continuar.
Si no → no estás listo. Piensa en el objetivo en modo normal hasta que puedas redactar un contrato limpio.

Pregunta 3: ¿El agent tiene acceso a las señales que necesita verificar?

En caso afirmativo → /goal es la herramienta adecuada. Ejecútelo.
Si no → arregle el medio ambiente primero. Añade métricas. Agregue un clúster de ensayo. Agregue registros reales. Luego reevalúe.

Pregunta 4: Una vez finalizada la ejecución, ¿trata el resultado como un entregable o como un pico?

Trátelo como una espiga. Siempre. Destile la información sobre un PRD. Ejecute una implementación limpia según la especificación refinada. Envía eso.

Eso es todo. Ese es el marco. Me ha ahorrado dinero real en tokens y horas reales en trabajo de limpieza, y es la lente a través de la cual ahora leo cada demostración de /goal en Twitter.

Si alguien le dice que su ejecución /goal envió el código directamente al principal, le preguntaría muy cortésmente cómo se ve su tasa de errores en dos semanas. Porque he estado allí. La primera carrera es embriagadora. La limpieza es donde vive la lección.

¿Dónde creo que va esto a continuación?

/goal es experimental. Va a evolucionar rápidamente. Algunas cosas que estoy viendo:

El límite entre la exploración /goal y la ejecución de tareas estructuradas se va a desdibujar. El patrón de bucle PRD que describí anteriormente probablemente se incorporará a la propia herramienta (destilar, refactorizar, implementar) en lugar de vivir como un flujo de trabajo manual en la parte superior. Una vez que eso sucede, la brecha entre "Tuve una idea" y "Tengo un PR limpio" colapsa dramáticamente.

El problema del medio ambiente se resolverá con mejores valores predeterminados. En este momento, lograr que un /goal ejecute señales lo suficientemente ricas como para verificar su propio trabajo es un ejercicio que requiere mucha configuración. La mayoría de los proyectos no lo tienen. La próxima ola de herramientas agent se entregará con entornos de preparación administrados, observabilidad integrada y plantillas de objetivos para objetivos de optimización comunes. Aún no hemos llegado a ese punto. Lo estaremos pronto.

Las diferencias de calidad compaction entre las herramientas de codificación AI se convertirán en un factor de selección importante. En este momento, la mayoría de los ingenieros eligen una codificación agent según el modelo. En un año, elegirán en función de cómo el arnés gestiona el contexto en recorridos autónomos de horas de duración. Codex, Claude Code, Anthropic administrado por agents: el modelo no es el foso. El arnés lo es.

Si desea seguir rastreando este espacio, escribo sobre las nuevas herramientas de codificación AI cada semana, y la cobertura Codex / Claude Code es donde aterrizan la mayoría de las lecciones prácticas.

Preguntas frecuentes

¿Cómo habilito el comando Codex /goal?

Agregue [features] seguido de goals = true a su archivo ~/.codex/config.toml, guarde y reinicie Codex CLI. Alternativamente, ejecute codex features enable goals, que escribe el mismo valor automáticamente. Verifique ejecutando codex --version y confirmando que está en 0.128.0 o posterior: /goal y /side aparecerán en la paleta de comandos de barra diagonal una vez habilitados.

¿Es seguro ejecutar el comando Codex /goal sin supervisión?

Es más seguro que ejecutar un bucle Ralph arbitrario, pero no dejaría que se ejecute completamente sin supervisión en código adyacente a producción. Utilice un VPS en la nube o un entorno aislado, establezca un presupuesto de token y revise detenidamente el branch resultante. Trate la salida como un pico, no como una entrega; consulte la sección anterior branch.

¿Cuándo debo usar /goal frente a un mensaje Codex normal?

Utilice /goal solo para trabajos exploratorios en los que conozca el destino pero no la ruta: optimizaciones de rendimiento, reducciones de latencia e investigaciones para encontrar errores. Utilice indicaciones normales para cualquier tarea en la que pueda describir la diferencia antes de comenzar. La mayor parte del trabajo de codificación real cae en la segunda categoría.

¿Cuál es la diferencia entre /goal y /side en Codex CLI?

/goal establece un objetivo persistente e inicia un bucle autónomo de larga duración. /side abre una conversación paralela temporal que no interrumpe un objetivo activo: puede hacer preguntas, buscar información o realizar pequeños experimentos mientras el objetivo principal sigue funcionando. Vuelva al hilo principal con la tecla Escape.

¿Por qué mi ejecución de /goal nunca finaliza?

Casi siempre porque el objetivo no es verificable. Codex inyecta "tratar la incertidumbre como si no se hubiera logrado" en cada iteración, por lo que un objetivo vago como "hacerlo más rápido" se repite indefinidamente. Reescriba el objetivo como un contrato concreto (métrica específica, pruebas con nombre, lista de verificación explícita) y el ciclo terminará correctamente cuando se cumplan los criterios.

Trabajemos juntos

¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.

Fiverr (compilaciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
Cartera: mejba.me
Ramlit Limited (soluciones empresariales): ramlit.com
ColorPark (diseño y marca): colorpark.io
xCyberSecurity (servicios de seguridad): xcybersecurity.io

Codex /goal command: mi opinión honesta sobre autonomous coding