Collaborare con Codex su attività a lungo termine

Codex può lavorare per lunghi periodi, specialmente quando un /goal gli fornisce un obiettivo persistente. La parte più difficile è mantenere l'orientamento mentre lavora per ore o giorni, scopre nuovi dettagli implementativi e passa attraverso diversi tipi di verifica.

Le ipotesi iniziali spesso cambiano una volta che l'implementazione inizia. Il modello di collaborazione deve preservare l'obiettivo, dando sia a te che a Codex lo spazio per rivedere il piano man mano che emergono nuove evidenze.

Nelle ultime settimane, ho utilizzato cinque pratiche:

1. Lascia che Codex pianifichi il lavoro e mantenga la tabella di marcia.
2. Mantieni il thread principale concentrato sul coordinamento.
3. Verifica la tabella di marcia e rivedi il codice dopo ogni traguardo.
4. Usa thread locali per i test con Computer Use.
5. Riporta i progressi tramite aggiornamenti concisi e dashboard.

Generato con GPT Image 2 in Codex

1. Lascia che Codex pianifichi il lavoro e mantenga la tabella di marcia

Di solito inizio con una conversazione piuttosto che con la modalità /plan. Descrivo cosa sto cercando di costruire, dico pensieri approssimativi, condivido vincoli e lascio che Codex faccia domande finché non ha abbastanza contesto per proporre un piano iniziale.

Questo mantiene la discussione iniziale flessibile. Non ho bisogno di trasformare idee a metà in una specifica formale prima che Codex possa iniziare ad aiutare. Può intervistarmi, riflettere su ciò che ha capito, identificare lacune e trasformare gradualmente la conversazione in un piano attuabile.

Man mano che il progetto prende forma, chiedo a Codex di impostare il Goal corrente. La modalità Goal fornisce a Codex un obiettivo persistente, permettendogli di continuare a lavorare verso lo stesso risultato attraverso più turni finché l'obiettivo non è completato, bloccato o sostituito.

Posso impostare l'obiettivo io stesso con /goal, ma di solito chiedo a Codex di farlo. La modalità Goal è esposta tramite l'harness, quindi Codex può sintetizzare la nostra conversazione, il contesto del progetto e tutto ciò che ha imparato finora in un obiettivo chiaro. Può anche definire le prove necessarie prima di considerare quell'obiettivo completato.

Per progetti più grandi, chiedo a Codex di scrivere la tabella di marcia più ampia in GOALS.md. Questa è una convenzione di progetto piuttosto che una funzionalità integrata di Codex, e il file può essere chiamato come preferisci.

Di solito organizzo GOALS.md attorno a traguardi invece che a un semplice elenco di attività. Ogni traguardo registra:

• il risultato previsto
• il lavoro attualmente in ambito
• decisioni importanti
• blocchi noti
• le prove necessarie prima di procedere

Codex mantiene il file man mano che il progetto si sviluppa. Nuove scoperte possono cambiare l'ambito di un traguardo, introdurne un altro o modificare le prove necessarie per il completamento.

Un solo obiettivo in modalità Goal è attivo alla volta. Man mano che i traguardi vengono completati, Codex aggiorna GOALS.md, attiva l'obiettivo successivo e continua a lavorare verso di esso.

2. Mantieni il thread principale concentrato sul coordinamento

Una volta che la tabella di marcia esiste, mantengo il thread principale concentrato sull'obiettivo, i vincoli, le decisioni e lo stato attuale del progetto.

Decide cosa dovrebbe succedere dopo, delega attività delimitate e valuta i risultati. Non ha bisogno di portare ogni dettaglio implementativo.

Un worker può passare un'ora a leggere codice sconosciuto, provare diversi approcci o tracciare un test fallito. Il coordinatore ha bisogno solo delle informazioni che influenzano il progetto più ampio:

• cosa ha imparato il worker
• cosa è cambiato
• le prove a supporto
• cosa dovrebbe succedere dopo

Codex può delegare questo lavoro a un subagent o creare un thread separato. Funzionalmente, possono svolgere lo stesso compito. Uso un thread separato quando prevedo di rivedere il lavoro in seguito, poiché rimane visibile nell'app Codex e mantiene la propria cronologia.

Questo diventa particolarmente utile quando più parti di lavoro sono in esecuzione in parallelo. Il thread principale può continuare a coordinare il progetto mentre ogni indagine, implementazione o revisione rimane facile da ispezionare.

3. Verifica la tabella di marcia e rivedi il codice dopo ogni traguardo

GOALS.md riflette ciò che era noto quando Codex lo ha aggiornato l'ultima volta. Entro la fine di un traguardo, il progetto di solito ha scoperto qualcosa di nuovo.

Prima di procedere, chiedo a un altro thread di confrontare la tabella di marcia con lo stato attuale:

• Il traguardo è effettivamente completato?
• L'obiettivo successivo è ancora quello giusto?
• Manca qualche traguardo?
• Nuove evidenze hanno cambiato l'ordine di lavoro?
• La definizione di "completato" è ancora valida?

Eseguo questo audit alla fine di ogni traguardo, così come ogni volta che nuove evidenze cambiano materialmente la direzione del progetto.

Eseguo anche /review sull'implementazione.

Supponiamo che l'implementazione e i test remoti per un flusso di accesso siano completi. L'audit della tabella di marcia potrebbe notare che nessuno ha testato il flusso in un browser reale con accesso effettuato. Allo stesso tempo, /review potrebbe scoprire che il nuovo percorso memorizza un token in modo errato, anche se i test remoti passano.

Il coordinatore aggiorna GOALS.md, delega la correzione del token, aggiunge la verifica del browser mancante e solo allora attiva il traguardo successivo.

Di solito tengo audit e revisioni in thread separati. Un subagent potrebbe svolgere lo stesso lavoro, ma un thread separato lascia una traccia visibile a cui posso tornare in seguito.

4. Usa thread locali per i test con Computer Use

La maggior parte delle mie sessioni Codex viene eseguita su un'istanza remota, quindi il lavoro può continuare mentre il mio laptop è chiuso. Alcuni controlli dipendono ancora dalla mia macchina locale:

• un browser con accesso effettuato
• credenziali locali
• Xcode
• permessi macOS
• il simulatore iOS

Il coordinatore remoto può creare un thread locale per uno di questi controlli. Applico il diff remoto o faccio checkout del branch o commit pertinente in modo che il thread locale testi il codice corretto.

Il thread locale opera il browser o l'applicazione e restituisce screenshot, log e risultati. Quando un controllo fallisce, un worker remoto risolve il problema e il thread locale testa di nuovo.

Un ciclo tipico si presenta così:

1. Un worker remoto implementa il flusso di accesso.
2. I test remoti passano.
3. Un thread locale utilizza l'estensione Chrome di Codex.
4. Il test del browser rivela un bug di reindirizzamento.
5. Un worker remoto lo risolve.
6. Il thread locale ripete il controllo.

Il progetto rimane remoto per impostazione predefinita. Il mio computer si unisce solo per i controlli che lo richiedono. Il thread remoto può anche continuare a verificare se il thread locale diventa di nuovo disponibile quando riapro il mio laptop.

5. Riporta i progressi tramite aggiornamenti concisi e dashboard

I thread worker di solito riportano un singolo compito. Quando torno al progetto, ho bisogno di una visione dello stato generale:

• cosa è completo
• cosa è cambiato
• cosa rimane
• cosa necessita di una decisione

Chiedo a Codex di fare rapporto ogni volta che lo stato del progetto cambia, usando tre brevi sezioni:

**Cosa è stato fatto

Cosa c'è dopo

Eventuali blocchi**

Il che è quasi come avere un daily standup con Codex, anche se ogni ora.

Codex può inviare lo stesso aggiornamento tramite Slack, sia come messaggio diretto che in un canale di progetto dedicato.

Mentre sono nell'app Codex, uso anche /side per fare un check-in senza interrompere il thread principale. Dal thread laterale, posso chiedere un riepilogo di ciò che è stato completato, cosa rimane e se c'è qualcosa che necessita del mio aiuto—ad esempio, un clic manuale, un'approvazione o un altro pezzo di clickops.

Ottenere un riepilogo dal thread laterale

Chiedere al thread laterale di inoltrare le mie istruzioni al thread principale

Posso quindi chiarire un'istruzione, risolvere un blocco, aggiungere contesto o chiedere al thread laterale di inviare indicazioni aggiornate al thread principale.

Per progetti con diversi traguardi o flussi di lavoro paralleli, mantengo anche un progress-dashboard.html. Questo è un artefatto di progetto personalizzato, non un'interfaccia utente integrata di Codex. Può mostrare:

• l'obiettivo attivo
• i traguardi completati
• le prove
• i blocchi
• le decisioni
• gli aggiornamenti recenti

Quando torno dopo diverse ore, posso capire lo stato del progetto senza leggere ogni thread worker. Codex può anche distribuire la dashboard come un Site in modo che rimanga accessibile da remoto.

Riepilogo

Uso questa struttura quando è probabile che un progetto scopra nuove informazioni, coinvolga diversi pezzi di lavoro indipendenti o richieda prove da più di un ambiente.

Il flusso di lavoro segue un ciclo semplice. Codex trasforma la conversazione iniziale in una tabella di marcia, attiva un traguardo, delega il lavoro e verifica il risultato prima di procedere. I thread locali gestiscono i controlli che richiedono la mia macchina, mentre aggiornamenti e dashboard mi aiutano a tornare al progetto senza ricostruire tutto da zero.

La parte importante è mantenere lo stato del progetto abbastanza aggiornato in modo che la decisione successiva rifletta ciò che Codex ha effettivamente imparato.

Provalo

Incolla questo in un nuovo thread di Codex:

Coordina questo come un progetto a lungo termine.

Inizia intervistandomi su cosa sto cercando di costruire. Lasciami descrivere idee approssimative e vincoli in modo colloquiale, poi trasforma quella discussione in un piano iniziale.

Crea GOALS.md come tabella di marcia condivisa. Organizzalo attorno a traguardi, con il risultato previsto, l'ambito, le decisioni, i blocchi e le prove richieste per ciascuno.

Imposta e mantieni un solo obiettivo in modalità Goal alla volta. L'obiettivo attivo dovrebbe corrispondere al traguardo corrente.

Mantieni questo thread concentrato sull'obiettivo, i vincoli, le decisioni e lo stato del progetto. Delega l'implementazione a subagent o nuovi thread.

Richiedi che i worker restituiscano conclusioni, modifiche e prove piuttosto che trascrizioni complete.

Usa thread separati quando potrei voler ispezionare, continuare o rivedere il lavoro in seguito. Usa subagent per lavori delimitati che non necessitano di una propria cronologia visibile.

Dopo ogni traguardo, usa un thread separato per verificare GOALS.md rispetto allo stato corrente ed esegui /review sull'implementazione. Aggiorna la tabella di marcia prima di attivare l'obiettivo successivo.

Usa thread locali per i test con Computer Use che dipendono dal mio browser, applicazioni desktop, permessi, credenziali o stato del dispositivo.

*Quando lo stato del progetto cambia, riporta solo: - Cosa è stato fatto - Cosa c'è dopo - Eventuali blocchi*

Mantieni progress-dashboard.html quando il progetto si estende su diversi traguardi o worker. Non dichiarare il completamento finché non esistono le prove concordate.

In alternativa, puoi anche fare un Appshot di questo articolo e chiedere a Codex:

Crea una skill Codex riutilizzabile chiamata orchestrate-projects da questo articolo.

Preserva queste pratiche:

*- lascia che Codex mi intervisti e crei i piani iniziali - usa GOALS.md come tabella di marcia basata su traguardi - mantieni un solo obiettivo in modalità Goal attivo alla volta - mantieni il thread principale concentrato sul coordinamento - verifica la tabella di marcia ed esegui /review dopo ogni traguardo - usa thread separati per il lavoro che potrei voler rivedere - usa thread locali per i test con Computer Use - riporta i progressi tramite aggiornamenti concisi, Slack e progress-dashboard.html*