Colaboración con Codex en tareas de larga duración

Codex puede trabajar durante largos períodos, especialmente cuando un /goal le proporciona un objetivo persistente. La parte más difícil es mantener el rumbo 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, dando tanto a ti como a Codex espacio para revisar el plan a medida que surge nueva evidencia.

En las últimas semanas, he estado usando cinco prácticas:

1. Dejar que Codex planifique el trabajo y mantenga la hoja de ruta.
2. Mantener el hilo principal enfocado en la coordinación.
3. Auditar la hoja de ruta y revisar el código después de cada hito.
4. Usar hilos locales para pruebas con Computer Use.
5. 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, dicto ideas generales, comparto limitaciones y dejo que Codex haga preguntas hasta que tenga suficiente contexto para proponer un plan inicial.

Esto mantiene la discusión inicial 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. Esto es una convención del proyecto, no 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 limitaciones, las decisiones y el estado actual del proyecto.

Decide qué debería suceder después, delega tareas acotadas 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 apoyo
• lo que debería suceder después

Codex puede delegar este trabajo a un subagente o crear un hilo separado. Funcionalmente, pueden realizar la misma tarea. Yo 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 permanece 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 con 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 reviso 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 vuelve a probar.

Un ciclo típico se ve así:

1. Un trabajador remoto implementa el flujo de inicio de sesión.
2. Las pruebas remotas pasan.
3. Un hilo local usa la extensión de Chrome para Codex.
4. La prueba del navegador revela un error de redirección.
5. Un trabajador remoto lo soluciona.
6. El hilo local repite la comprobación.

El proyecto permanece remoto por defecto. Mi computadora se une solo para las comprobaciones que lo requieren. El hilo remoto también puede seguir comprobando si el hilo local vuelve a estar disponible cuando reabra mi laptop.

5. Reportar el progreso a través de actualizaciones concisas y paneles de control

Los hilos de trabajo generalmente informan 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 informe cada vez que cambie el estado del proyecto, usando tres secciones breves:

**Qué está hecho

Qué sigue

Algún bloqueador**

Es casi como tener una reunión diaria con Codex, aunque sea cada hora.

Codex puede enviar la misma actualización a través de Slack, ya sea como mensaje directo o en un canal de proyecto dedicado.

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, aprobación u otra pieza de clickops.

Obteniendo un resumen desde el 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 pedir 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 desplegar el panel como un Site para que siga siendo accesible de forma remota.

Resumen

Utilizo 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 para que la próxima decisión refleje lo que Codex ha aprendido realmente.

Pruébalo

Pega esto en un nuevo hilo de Codex:

Coordina esto como un proyecto de larga duración.

Empieza entrevistándome sobre lo que intento construir. Déjame describir ideas generales y limitaciones 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 limitaciones, 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 acotado 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 con 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 - Algún bloqueador*

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 orchestrate-projects a partir de este artículo.

Preserva estas prácticas:

*- deja que Codex me entreviste y cree los planes iniciales - usa GOALS.md como una hoja de ruta basada en hitos - mantén un objetivo en modo Goal activo a la vez - mantén el hilo principal enfocado en la coordinación - audita la hoja de ruta y ejecuta /review después de cada hito - usa hilos separados para el trabajo que pueda querer retomar - usa hilos locales para pruebas con Computer Use - reporta el progreso a través de actualizaciones concisas, Slack y progress-dashboard.html*