Codex puede trabajar durante largos períodos, especialmente cuando un /goal le da un objetivo persistente. La parte más difícil es mantenerse orientado mientras trabaja durante horas o días, descubre nuevos detalles de implementación y pasa por varios tipos de verificación.
Las suposiciones iniciales a menudo cambian una vez que comienza la implementación. El modelo de colaboración debe preservar el objetivo mientras les da tanto a ti como a Codex espacio para revisar el plan a medida que aparece nueva evidencia.
En las últimas semanas, he estado usando cinco prácticas:
- Dejar que Codex planifique el trabajo y mantenga la hoja de ruta.
- Mantener el hilo principal enfocado en la coordinación.
- Auditar la hoja de ruta y revisar el código después de cada hito.
- Usar hilos locales para pruebas de Computer Use.
- Reportar el progreso a través de actualizaciones concisas y paneles de control.
Generado con GPT Image 2 en Codex
1. Dejar que Codex planifique el trabajo y mantenga la hoja de ruta
Normalmente empiezo con una conversación en lugar del modo /plan. Describo lo que intento construir, expreso ideas aproximadas, comparto restricciones y dejo que Codex haga preguntas hasta que tenga suficiente contexto para proponer un plan inicial.
Esto mantiene la discusión temprana flexible. No necesito convertir ideas a medio formar en una especificación formal antes de que Codex pueda empezar a ayudar. Puede entrevistarme, reflejar lo que entendió, identificar vacíos y convertir gradualmente la conversación en un plan viable.
A medida que el proyecto toma forma, le pido a Codex que establezca el Goal actual. El modo Goal le da a Codex un objetivo persistente, permitiéndole seguir trabajando hacia el mismo resultado a través de múltiples turnos hasta que el objetivo esté completo, bloqueado o reemplazado.
Puedo establecer el objetivo yo mismo con /goal, pero normalmente le pido a Codex que lo haga. El modo Goal se expone a través del harness, por lo que Codex puede sintetizar nuestra conversación, el contexto del proyecto y todo lo que ha aprendido hasta ahora en un objetivo claro. También puede definir la evidencia requerida antes de considerar ese objetivo como completado.
Para proyectos más grandes, le pido a Codex que escriba la hoja de ruta más amplia en GOALS.md. Esta es una convención del proyecto en lugar de una función incorporada de Codex, y el archivo puede tener el nombre que prefieras.
Normalmente organizo GOALS.md en torno a hitos en lugar de una lista plana de tareas. Cada hito registra:
- el resultado previsto
- el trabajo actualmente en alcance
- decisiones importantes
- bloqueadores conocidos
- la evidencia requerida antes de continuar
Codex mantiene el archivo a medida que el proyecto se desarrolla. Los nuevos hallazgos pueden cambiar el alcance de un hito, introducir otro o cambiar la evidencia requerida para su finalización.
Solo un objetivo en modo Goal está activo a la vez. A medida que se completan los hitos, Codex actualiza GOALS.md, activa el siguiente objetivo y continúa trabajando hacia él.
2. Mantener el hilo principal enfocado en la coordinación
Una vez que existe la hoja de ruta, mantengo el hilo principal enfocado en el objetivo, las restricciones, las decisiones y el estado actual del proyecto.
Decide qué debería suceder después, delega tareas delimitadas y evalúa los resultados. No necesita cargar con cada detalle de implementación.
Un trabajador puede pasar una hora leyendo código desconocido, probando varios enfoques o rastreando una prueba fallida. El coordinador solo necesita la información que afecta al proyecto en general:
- lo que el trabajador aprendió
- lo que cambió
- la evidencia de respaldo
- lo que debería suceder después
Codex puede delegar este trabajo a un subagent o crear un hilo separado. Funcionalmente, pueden realizar la misma tarea. Uso un hilo separado cuando espero retomar el trabajo más tarde, ya que permanece visible en la aplicación de Codex y mantiene su propio historial.
Esto se vuelve especialmente útil una vez que varias piezas de trabajo se ejecutan en paralelo. El hilo principal puede continuar coordinando el proyecto mientras cada investigación, implementación o revisión sigue siendo fácil de inspeccionar.
3. Auditar la hoja de ruta y revisar el código después de cada hito
GOALS.md refleja lo que se sabía cuando Codex lo actualizó por última vez. Al final de un hito, el proyecto generalmente ha descubierto algo nuevo.
Antes de continuar, le pido a otro hilo que compare la hoja de ruta con el estado actual:
- ¿El hito está realmente completo?
- ¿El siguiente objetivo sigue siendo el correcto?
- ¿Falta algún hito?
- ¿La nueva evidencia ha cambiado el orden del trabajo?
- ¿La definición de "completado" sigue siendo válida?
Realizo esta auditoría al final de cada hito, así como cada vez que la nueva evidencia cambia materialmente la dirección del proyecto.
También ejecuto /review en la implementación.
Supongamos que la implementación y las pruebas remotas para un flujo de inicio de sesión están completas. La auditoría de la hoja de ruta puede notar que nadie ha probado el flujo en un navegador real con sesión iniciada. Al mismo tiempo, /review puede encontrar que la nueva ruta almacena un token incorrectamente, aunque las pruebas remotas pasen.
El coordinador actualiza GOALS.md, delega la corrección del token, agrega la verificación del navegador faltante y solo entonces activa el siguiente hito.
Normalmente mantengo las auditorías y revisiones en hilos separados. Un subagente podría realizar el mismo trabajo, pero un hilo separado deja un registro visible al que puedo volver más tarde.
4. Usar hilos locales para pruebas de Computer Use
La mayoría de mis sesiones de Codex se ejecutan en una instancia remota, para que el trabajo pueda continuar mientras mi laptop está cerrada. Algunas comprobaciones aún dependen de mi máquina local:
- un navegador con sesión iniciada
- credenciales locales
- Xcode
- permisos de macOS
- el Simulador de iOS
El coordinador remoto puede crear un hilo local para una de esas comprobaciones. Aplico el diff remoto o cambio a la rama o commit relevante para que el hilo local pruebe el código correcto.
El hilo local opera el navegador o la aplicación y devuelve capturas de pantalla, registros y hallazgos. Cuando una comprobación falla, un trabajador remoto soluciona el problema y el hilo local prueba de nuevo.
Un ciclo típico se ve así:
- Un trabajador remoto implementa el flujo de inicio de sesión.
- Las pruebas remotas pasan.
- Un hilo local usa la extensión de Chrome de Codex.
- La prueba del navegador revela un error de redirección.
- Un trabajador remoto lo soluciona.
- El hilo local repite la comprobación.
El proyecto permanece remoto por defecto. Mi computadora se une solo para las comprobaciones que la requieren. El hilo remoto también puede seguir verificando si el hilo local vuelve a estar disponible cuando vuelvo a abrir mi laptop.
5. Reportar el progreso a través de actualizaciones concisas y paneles de control
Los hilos de trabajo generalmente reportan sobre una tarea. Cuando regreso al proyecto, necesito una vista del estado general:
- qué está completo
- qué cambió
- qué queda
- qué necesita una decisión
Le pido a Codex que reporte cada vez que el estado del proyecto cambia, usando tres secciones cortas:
**Qué está hecho
Qué sigue
Bloqueadores**
Es casi como tener una reunión diaria con Codex, aunque cada hora.
Codex puede enviar la misma actualización a través de Slack, ya sea como un mensaje directo o en un canal dedicado del proyecto.
Mientras estoy en la aplicación de Codex, también uso /side para consultar sin interrumpir el hilo principal. Desde el hilo lateral, puedo pedir un resumen de lo que se ha completado, lo que queda y si algo necesita mi ayuda, por ejemplo, un clic manual, una aprobación u otra pieza de clickops.
Obteniendo un resumen del hilo lateral
Pidiendo al hilo lateral que transmita mis instrucciones al hilo principal
Luego puedo aclarar una instrucción, resolver un bloqueador, agregar contexto o pedirle al hilo lateral que envíe una guía actualizada de vuelta al hilo principal.
Para proyectos con varios hitos o flujos de trabajo paralelos, también mantengo un progress-dashboard.html. Este es un artefacto de proyecto personalizado, no una interfaz de usuario incorporada de Codex. Puede mostrar:
- el objetivo activo
- hitos completados
- evidencia
- bloqueadores
- decisiones
- actualizaciones recientes
Cuando regreso después de varias horas, puedo entender el estado del proyecto sin leer cada hilo de trabajo. Codex también puede implementar el panel como un Site para que siga siendo accesible de forma remota.
Resumen
Uso esta estructura cuando es probable que un proyecto descubra nueva información, involucre varias piezas de trabajo independientes o requiera evidencia de más de un entorno.
El flujo de trabajo sigue un ciclo simple. Codex convierte la conversación inicial en una hoja de ruta, activa un hito, delega el trabajo y verifica el resultado antes de continuar. Los hilos locales manejan las comprobaciones que requieren mi máquina, mientras que las actualizaciones y los paneles me ayudan a regresar al proyecto sin tener que reconstruir todo desde cero.
La parte importante es mantener el estado del proyecto lo suficientemente actualizado como para que la próxima decisión refleje lo que Codex realmente ha aprendido.
Pruébalo
Pega esto en un nuevo hilo de Codex:
Coordina esto como un proyecto de larga duración.
Comienza entrevistándome sobre lo que estoy tratando de construir. Permíteme describir ideas y restricciones aproximadas de forma conversacional, luego convierte esa discusión en un plan inicial.
Crea GOALS.md como la hoja de ruta compartida. Organízala en torno a hitos, con el resultado previsto, el alcance, las decisiones, los bloqueadores y la evidencia requerida para cada uno.
Establece y mantén un objetivo en modo Goal a la vez. El objetivo activo debe corresponder al hito actual.
Mantén este hilo enfocado en el objetivo, las restricciones, las decisiones y el estado del proyecto. Delega la implementación a subagentes o nuevos hilos.
Exige que los trabajadores devuelvan conclusiones, cambios y evidencia en lugar de transcripciones completas.
Usa hilos separados cuando pueda querer inspeccionar, continuar o revisar el trabajo más tarde. Usa subagentes para trabajo delimitado que no necesita su propio historial visible.
Después de cada hito, usa un hilo separado para auditar GOALS.md contra el estado actual y ejecuta /review en la implementación. Actualiza la hoja de ruta antes de activar el siguiente objetivo.
Usa hilos locales para pruebas de Computer Use que dependan de mi navegador, aplicaciones de escritorio, permisos, credenciales o estado del dispositivo.
*Cuando el estado del proyecto cambie, reporta solo: - Qué está hecho - Qué sigue - Bloqueadores*
Mantén progress-dashboard.html cuando el proyecto abarque varios hitos o trabajadores. No declares la finalización hasta que exista la evidencia acordada.
Alternativamente, también puedes tomar un Appshot de este artículo y pedirle a Codex:
Crea una habilidad reutilizable de Codex llamada orquestar-proyectos a partir de este artículo.
Preserva estas prácticas:
*- dejar que Codex me entreviste y cree los planes iniciales - usar GOALS.md como una hoja de ruta basada en hitos - mantener un objetivo en modo Goal activo a la vez - mantener el hilo principal enfocado en la coordinación - auditar la hoja de ruta y ejecutar /review después de cada hito - usar hilos separados para el trabajo que pueda querer retomar - usar hilos locales para pruebas de Computer Use - reportar el progreso a través de actualizaciones concisas, Slack y progress-dashboard.html*
