La maggior parte degli sviluppatori utilizza per la prima volta gli agenti di codifica per il codice: ispezionare un repository, apportare una modifica, eseguire i test e aprire una pull request.
Questo resta il fulcro di Codex. Ma gran parte del lavoro su un computer è già mediato dal codice: eseguire comandi shell, navigare in pagine web, chiamare API, esportare documenti, rispondere a eventi e attivare automazioni. Quando queste superfici diventano disponibili per Codex, esso inizia a sembrare meno un assistente di codifica in senso stretto e più un sistema per svolgere lavoro al computer.
L'app Codex rende concreto questo cambiamento. Un thread può mantenere il contesto, utilizzare strumenti, mostrare artefatti e proseguire tra diversi prompt invece di resettarsi dopo ogni scambio.
Per ottenere di più da Codex, è necessario utilizzare queste capacità insieme:
- thread durevoli che preservano il contesto
- voce, controllo e accodamento mentre l'utente è ancora nel ciclo
- browser, uso del computer, server MCP e connettori che permettono a Codex di agire al di fuori del repository
- automazioni dei thread e Obiettivi che continuano il lavoro mentre l'utente è assente
- il pannello laterale, dove gli utenti possono rivedere codice, documenti, presentazioni e altri artefatti
Thread durevoli
Thread durevoli:
Thread di Codex a lunga esecuzione che preservano il contesto di lavoro attraverso sessioni ripetute.
I thread fissati sono un modo per tenere i thread durevoli a portata di mano. Sono utili per flussi di lavoro ricorrenti come:
- un thread di Capo di Stato Maggiore
- un thread di rilascio
- un thread di revisione della documentazione
- un thread dedicato al monitoraggio esterno
Questi sono spazi di lavoro persistenti, non brevi chat. Codex può rivisitarli nel tempo, preservando decisioni precedenti, preferenze e contesto di lavoro che altrimenti dovrebbero essere ricostruiti da zero.
Le scorciatoie per i thread fissati rendono tutto ciò pratico. I comandi Command-1 fino a Command-9 saltano direttamente nei thread salvati.
Input vocale
L'input vocale è prezioso perché cattura la versione approssimativa di un pensiero prima che venga compresso in una prosa rifinita.
Codex ha un input vocale integrato. Funziona particolarmente bene per punti di partenza vaghi che sono naturali da dire ma scomodi da digitare:
Penso che qualcuno di nome Ben ne abbia parlato su Slack.
Non ricordo i dettagli.
Per favore, vai a vedere.
Per un agente che può cercare, raccogliere contesto e riferire, spesso è sufficiente.
Funziona bene anche per un flusso di pensieri di due o tre minuti prima che il compito sia completamente formulato.
Le trascrizioni funzionano allo stesso modo. Una trascrizione grezza di riunione o un appunto di pianificazione dettato spesso forniscono materiale migliore di un breve riassunto, perché preservano incertezza, enfasi e linee di pensiero incomplete.
Controllo e accodamento
La voce diventa ancora più utile se abbinata a un controllo esplicito su un'attività in corso.
Controllo:
Interrompere un'attività di Codex in corso con una nuova direzione prima che il passo corrente termini.
Il controllo è utile quando l'agente sta andando nella direzione sbagliata e ha bisogno di una correzione prima di finire. Durante una revisione di un sito web, ad esempio, l'utente può interrompere il lavoro mentre annota la superficie nel pannello laterale:
- riduci questo
- la spaziatura tra questi due elementi non è giusta
- questo testo è sbagliato
Accodamento:
Aggiungere lavoro per Codex dopo il completamento del passo corrente.
L'accodamento è diverso. Non interrompe l'attività in corso. Aggiunge l'attività successiva alla coda. Un utente potrebbe dire:
Una volta finito il lavoro, invia il link di anteprima al revisore su Slack.
Il controllo cambia ciò che Codex sta facendo ora. L'accodamento cambia ciò che dovrebbe accadere dopo. Entrambi tengono l'utente vicino al lavoro mentre si svolge.
Strumenti e portata
Una volta che un thread ha continuità, la domanda successiva è su cosa può agire. Codex può muoversi verso l'esterno a strati:
- $browser per il browser integrato nel pannello laterale, dove Codex può ispezionare e annotare superfici web
- @chrome per lo stato del browser con accesso e flussi di lavoro basati su Chrome
- @computer per lavoro che esiste solo attraverso un'interfaccia GUI desktop
$browser è adatto per la revisione del browser nel pannello laterale. @chrome è adatto per lavoro nel browser con accesso che dipende dal contesto Chrome dell'utente. @computer è adatto per compiti che esistono solo attraverso un'interfaccia GUI desktop.
I server MCP e i connettori estendono la stessa idea al resto del flusso di lavoro. Slack, Gmail e Calendar sono importanti perché molti compiti importanti appaiono prima come messaggi, elementi della posta in arrivo o problemi di pianificazione prima di diventare codice.
Le competenze rendono riutilizzabili i flussi di lavoro ripetuti. Una volta che un flusso di lavoro si dimostra utile, confezionalo come competenza in modo che Codex possa eseguirlo di nuovo senza reimparare la routine da capo.
Lavora da qualsiasi luogo
L'app mobile Codex cambia quando l'utente deve essere alla scrivania. Un'attività può iniziare su un Mac dove risiedono già file, permessi e configurazione locale, poi continuare mentre l'utente fa un check-in dal telefono.
Questo è importante nei piccoli momenti. Qualcuno può allontanarsi dalla scrivania mentre Codex esegue un'attività più lunga, rispondere a una domanda dall'esterno, approvare il passo successivo o reindirizzare il thread prima di tornare. L'ambiente locale rimane al suo posto; l'utente non deve spostarsi.
Automazioni
Le automazioni eseguono il lavoro di Codex secondo una pianificazione. Usa un'automazione pianificata quando il lavoro ricorrente deve iniziare da zero da uno spazio di lavoro, come un rapporto giornaliero o un controllo regolare del repository. Usa un'automazione del thread quando la pianificazione deve tornare a una conversazione attiva con il suo contesto in esecuzione.
Automazioni dei thread:
Chiamate di risveglio ricorrenti a battito cardiaco che tornano allo stesso thread di Codex secondo una pianificazione.
I thread fissati sono utili, ma aspettano ancora che l'utente torni. Un'automazione del thread può controllare qualcosa ogni pochi minuti o ogni poche ore, continuare fino a soddisfare una condizione e regolare la cadenza nel tempo.
Un thread di Capo di Stato Maggiore potrebbe essere eseguito ogni 30 minuti:
Ogni 30 minuti, controlla Slack e Gmail per messaggi senza risposta che richiedono la mia attenzione.
Aiutami a prioritizzare ciò che è più importante.
Se qualcuno mi fa una domanda, ricerca la risposta il più approfonditamente possibile e abbozza una risposta per me, ma non inviarla.
Quando l'utente torna, la parte costosa della raccolta del contesto è spesso già fatta. L'umano decide ancora cosa viene inviato.
Le automazioni dei thread sono adatte anche per cicli di feedback. Un'automazione del thread può monitorare commenti su pull request, commenti su Google Docs o risposte su Slack e mantenere in movimento il lavoro circostante mentre l'utente è assente.
Considera un flusso di lavoro di animazione in cui un revisore condivide un video su Slack. Un'automazione del thread può controllare il thread secondo una pianificazione, renderizzare una versione aggiornata quando arrivano commenti e rispondere nello stesso thread taggando il revisore. Se un'integrazione non può completare il caricamento finale, l'automazione desktop può completare il passaggio attraverso la GUI.
Il ciclo abbraccia Slack per il feedback, il codebase per il rendering e l'automazione desktop per il caricamento finale.
Obiettivi
Gli obiettivi sono più potenti quando il compito ha un vero traguardo verso cui l'agente può continuare a spingere. Un obiettivo debole è:
Obiettivi:
Attività di Codex a più lunga esecuzione con un traguardo verso cui l'agente può continuare a lavorare nel tempo.
Implementa il piano in questo file Markdown.
Un obiettivo più forte ha un criterio di successo misurabile.
Ad esempio, un ingegnere potrebbe migrare uno strumento interno da Python a Rust impostando la nuova directory, definendo l'obiettivo e rendendo esplicito il traguardo: la nuova implementazione non è completa fino a quando i test unitari non superano.
Un obiettivo combina esecuzione continua con un verificatore. L'utente definisce il risultato, la condizione di arresto e il segnale che dice se Codex si sta avvicinando.
I verificatori utili includono:
- una suite di test
- un benchmark
- una riproduzione di bug
- una matrice di validazione
- un flusso di lavoro end-to-end che deve continuare a passare
L'ambizione conta, ma senza verifica è solo un desiderio.
Il pannello laterale
Il pannello laterale mantiene il lavoro accanto alla conversazione che lo ha prodotto. Invece di esportare un artefatto e cambiare contesto, l'utente può rivederlo sul posto. L'output potrebbe essere codice, ma potrebbe anche essere una presentazione, un PDF, una pagina del browser, una tabella o un altro artefatto creato lungo il percorso.
Supporta particolarmente bene quattro lavori:
- Ispezionare artefatti
- Annotare ciò che deve cambiare
- Operare superfici web
- Rivedere modifiche
Il pannello laterale consente agli utenti di rivedere Markdown, fogli di calcolo, tabelle di dati, documenti e diapositive sul posto. Possono ispezionare, annotare e rivedere artefatti senza interrompere il ciclo.
Annotazioni
La presentazione o il PDF possono rimanere aperti accanto al thread che li ha prodotti, pronti per revisione e riparazione diretta.
Fogli in Codex
Il browser integrato consente a Codex di ispezionare una pagina renderizzata, controllarla e rispondere alle annotazioni direttamente sulla superficie in revisione. I commenti su una pagina o un artefatto rimangono all'interno del ciclo di lavoro invece di diventare un passaggio di consegne separato.
Il web diventa sia output che superficie di controllo. Codex può costruire un artefatto, aprirlo nel pannello laterale, ispezionarlo, eseguirne il debug e continuare a perfezionare lo stesso oggetto sul posto.
Queste superfici funzionano particolarmente bene:
- index.html per artefatti statici leggeri
- Storybook per la revisione dell'interfaccia utente
- Remotion Studio per l'animazione programmatica
- presentazioni basate su browser per diapositive
- app di dati per flussi di lavoro di analisi
Un singolo file index.html può diventare un artefatto interattivo durevole senza bisogno di server. Le automazioni dei thread possono anche aggiornare artefatti statici nel tempo, in modo che un thread abbia qualcosa di nuovo in attesa quando l'utente torna.
Memoria condivisa
I thread a lunga esecuzione diventano più utili quando condividono la memoria al di fuori di una singola conversazione.
Memoria condivisa:
Contesto durevole memorizzato al di fuori di un singolo thread in modo che il lavoro futuro possa riprendere da qualcosa di esplicito e revisionabile.
Un pattern durevole è ancorare i thread persistenti in un vault Obsidian. In pratica, significa una cartella di file di testo semplice che rimane facile da ispezionare, modificare, spostare e conservare per molto tempo. I team possono memorizzare quella cartella in cloud storage, Git, Dropbox, Google Drive o un altro livello di sincronizzazione adatto al loro flusso di lavoro.
Un vault potrebbe assomigliare a questo:
vault/
├── TODO.md
├── persone/
├── progetti/
├── agente/
└── note/
Al primo livello, AGENTS.md può definire come Codex dovrebbe aggiornare quello spazio di lavoro mentre impara di più su persone, progetti, decisioni e questioni aperte.
Non copiare esattamente una struttura di vault. Insegna all'agente dove dovrebbe risiedere il contesto durevole, quale contesto preservare e quando non creare confusione.
Un AGENTS.md pratico potrebbe dire:
- Tratta ~/vault come memoria di lavoro durevole.
- Preferisci note canoniche piuttosto che proliferazione di note.
- Instrada TODO, persone, progetti, riepiloghi giornalieri e note di appunti in modo esplicito.
- Preserva decisioni, blocchi, proprietari, date e link utili.
- Se non è cambiato nulla di significativo, non creare confusione nel vault.
I repository contengono codice. Il vault contiene contesto continuo: le persone coinvolte, cosa è cambiato, cosa è bloccato, cosa necessita di follow-up e cosa altrimenti sparirebbe tra una sessione e l'altra.
Il contesto importante non dovrebbe vivere solo all'interno di una trascrizione di conversazione. Scrivilo da qualche parte dove il prossimo thread possa riprenderlo.
Codex ha anche funzionalità di memoria di prima parte in Impostazioni > Personalizzazione > Memorie. Forniscono un livello di richiamo locale per preferenze, flussi di lavoro ricorrenti e insidie note. Completano il contesto scritto esplicito piuttosto che sostituirlo. Chronicle spinge nella stessa direzione aiutando Codex a costruire memoria dal contesto recente dello schermo.
Dal codice verso l'esterno
Codex parte ancora dal codice. Ma gran parte del lavoro attorno al codice è ora raggiungibile attraverso lo stesso sistema: server MCP, superfici del browser, controlli desktop, automazioni dei thread e artefatti revisionabili.
Questo cambia il modello di controllo. Il controllo interrompe il lavoro in corso. L'accodamento mette in fila il compito successivo. Le automazioni dei thread mantengono un thread attivo quando l'utente si allontana. Gli obiettivi aggiungono un traguardo concreto verso cui Codex può continuare a lavorare.
Codex può ora portare un flusso di lavoro dall'istruzione all'esecuzione alla revisione dell'artefatto, anche quando il lavoro esce dal repository.
