Dots, ChatGPT Work e Codex: come delegare un lavoro software

Dots può coordinare un lavoro software, mentre Codex resta il prodotto dedicato a codice e sviluppo. ChatGPT Work gestisce attività articolate e deliverable; il dot segue responsabilità nel tempo e può delegare parti del lavoro. La scelta corretta dipende dal risultato, dall'ambiente e dalle prove necessarie per accettarlo. Guida ufficiale a ChatGPT Work e Codex.

Un incarico come «segui le migliorie di questo portale» può avere bisogno di coordinamento. La modifica del codice richiede invece un task tecnico con repository, requisiti e controlli. Lo stato “completato” non dimostra che il comportamento sia corretto. Il responsabile deve poter aprire il risultato, capire le modifiche e verificare ciò che è stato realmente provato.

La documentazione è stata verificata il 9 ottobre 2026. Per la descrizione generale del dot leggi Dots OpenAI: cosa sono; per l'accesso italiano controlla piani e disponibilità Dots. Questa guida non configura account, non esegue spese API e non riporta test svolti su un progetto reale.

Quando usare Dots, Work o Codex per un progetto?

Parti dall'oggetto del lavoro. Se devi chiarire una richiesta, una conversazione può essere sufficiente. Se devi preparare un documento con più passaggi, Work è l'esperienza orientata al deliverable. Se devi intervenire su un repository o su codice, Codex è l'esperienza dedicata. Se vuoi seguire nel tempo richieste, decisioni e attività, il dot può coordinare la responsabilità. Questi ruoli sono descritti nella documentazione dei prodotti.

Il progetto può usare più esperienze senza confonderle. Work può aiutare a rendere leggibile una specifica; Codex può lavorare sull'implementazione; il dot può mantenere il coordinamento entro l'incarico. La documentazione di ChatGPT Work descrive il lavoro sui deliverable. La qualità del passaggio di consegne dipende comunque da requisiti e fonti, non dal numero di prodotti coinvolti.

Per una PMI la separazione evita che una richiesta di business diventi una modifica tecnica non revisionata. «Migliora la pagina» può significare testo, prestazioni, accessibilità o comportamento. Prima di delegare, identifica il problema concreto e il criterio di accettazione. La guida a ChatGPT per programmare aiuta a distinguere supporto conversazionale e lavoro verificabile sul software.

Che cosa può delegare un dot a Codex?

La documentazione Dots descrive la creazione di task locali, la continuazione di task Codex esistenti e l'uso di ambienti Codex Cloud già configurati. Non significa che qualunque repository o qualunque conversazione siano automaticamente accessibili. Il task pertinente e l'ambiente devono essere disponibili nel percorso di lavoro. Tasks and memory Dots.

Per delegare, indica il task esistente o prepara un brief tecnico circoscritto. Specifica il comportamento attuale, quello desiderato, l'area interessata e il risultato da consegnare. Se il problema è riproducibile, descrivi il percorso che lo mostra. Se hai soltanto un'impressione, chiedi prima una diagnosi e una proposta, evitando di autorizzare cambiamenti ampi sulla base di una premessa non verificata.

Il dot dovrebbe mantenere distinguibili decisioni e attività. Una richiesta può essere pronta per l'implementazione; un'altra può richiedere prima una scelta del titolare. Il coordinamento utile rende visibile questa differenza. Non serve assegnare tutto a Codex appena compare la parola “software”: un requisito contraddittorio deve essere chiarito prima di toccare il codice.

La storia di Codex è separata da quella ChatGPT secondo la documentazione dei prodotti. Perciò non supporre che una vecchia conversazione contenga automaticamente il contesto necessario al nuovo task. Fornisci i riferimenti pertinenti e chiedi quali informazioni mancano. Work e Codex. Il confronto su come creare il primo dot aiuta a costruire la responsabilità prima della delega tecnica.

Come scrivere un brief software che si possa accettare?

Il brief deve contenere una condizione osservabile. «Sistema la ricerca» è vago. «Quando l'utente applica questo filtro, i risultati devono rispettare il criterio concordato e mostrare uno stato chiaro se non ci sono corrispondenze» descrive un comportamento. Aggiungi il contesto, i casi esclusi e le parti che non devono essere modificate senza una nuova decisione.

Indica poi le evidenze richieste. Il risultato dovrebbe mostrare modifiche, ragioni, verifiche eseguite e limiti rimasti. Non chiedere soltanto una frase «test passati»: serve sapere quali controlli sono pertinenti al comportamento. Se un controllo non può essere eseguito perché manca un prerequisito, il report deve indicarlo. Un limite visibile permette di decidere il prossimo passo; un successo presunto lo nasconde.

Brief per una modifica tecnica circoscritta

Problema: descrivi il comportamento osservato e come riprodurlo. Obiettivo: indica il risultato atteso e i casi da coprire. Ambito: identifica repository e area pertinente senza allargare il lavoro a refactor non necessari. Consegna: modifiche revisionabili, controlli eseguiti, risultato osservato e limiti. Prima di rilascio o azioni esterne, prepara il materiale necessario alla decisione del responsabile.

Questo esempio è un modello editoriale, non una configurazione eseguita. Va adattato al progetto e alle sue istruzioni. Un gestionale con dati reali richiede un ambiente appropriato per le prove; una pagina pubblica richiede il controllo del comportamento che vedrà il lettore. Non usare il dot per aggirare prerequisiti, permessi o decisioni aziendali non ancora prese.

Il prompt AI per programmare è utile quando rende leggibile il problema. Non deve diventare una lista di tecnicismi copiata per sembrare precisa. Se il responsabile non sa verificare il criterio di accettazione, serve chiarire il requisito o coinvolgere il referente tecnico, prima di prendere il completamento del task come prova sufficiente.

Quale ambiente usa il lavoro delegato?

Il computer cloud del dot non va confuso con un ambiente Codex Cloud configurato per il software. Codex Cloud esegue lavoro su computer gestiti da OpenAI; il dot può usare ambienti già configurati secondo il percorso descritto. Guida Work e Codex e Tasks and memory.

Per scegliere l'ambiente, verifica repository, dipendenze, comandi di controllo e fonti del task. Un ambiente che apre il codice ma non può eseguire la verifica pertinente non dimostra il comportamento finale. Un task può produrre una proposta utile anche con un limite, ma quel limite deve apparire nel risultato. Il responsabile può allora completare il prerequisito o scegliere un altro ambiente appropriato.

Il collegamento del computer personale Dots resta distinto da Codex e Work Sync. Per l'accesso locale servono dispositivo online e ChatGPT aperto; file e login non vengono automaticamente trasferiti al cloud. Computer e app Dots. La guida a Dots a computer spento entra nelle dipendenze, utili anche quando il coordinamento coinvolge lavoro tecnico.

Non inserire credenziali nei brief per far partire una verifica. Se manca un'autorizzazione, il report deve renderlo esplicito. Le risorse necessarie vanno configurate nel percorso appropriato, con la persona responsabile quando serve. Lo stesso principio vale per un'app o una fonte collegata, trattata nella guida a Dots con Gmail, Drive e Slack.

Come distinguere completamento, verifica e rilascio?

Completamento del task, correttezza del software e rilascio sono stati diversi. Un task può aver preparato modifiche senza dimostrare tutti i casi richiesti. Una verifica può essere positiva nell'ambiente di prova e non rappresentare ancora un rilascio. Un rilascio deve avere un risultato osservabile nell'ambiente previsto. La distinzione è un criterio operativo di qualità, non una promessa automatica del prodotto.

Per la revisione chiedi tre elementi: che cosa è cambiato, che cosa è stato provato e che cosa resta incerto. Il diff permette al tecnico di controllare l'ambito. Le evidenze permettono di confrontare il risultato con il requisito. Le incertezze evitano di trasformare un limite in una certezza. Una descrizione lunga senza questi elementi rende difficile decidere se accettare la modifica.

Se la modifica riguarda un'interfaccia, la revisione deve osservare il percorso dell'utente. Se riguarda un calcolo, deve confrontare input e risultato atteso. Se riguarda importazione dati, deve verificare formati e casi problematici definiti nel progetto. Non occorre inventare un'enorme suite di test per ogni modifica, ma il controllo deve essere pertinente a ciò che è stato chiesto.

Le azioni esterne richiedono un confine riconoscibile. Preparare una proposta di rilascio non equivale a pubblicare. La documentazione Dots distingue autorizzazioni e azioni; la guida a permessi e approvazioni applica il principio anche ai passaggi con conseguenze esterne. Il responsabile deve sapere quale versione e quale ambiente sono coinvolti.

Due progetti software ipotetici per PMI italiane

Un e-commerce corregge un comportamento dei filtri

Immagina un e-commerce italiano che riceve segnalazioni su un filtro del catalogo. Il dot può aiutare a tenere ordinati richiesta, requisito e domande aperte. Il task Codex riguarda una modifica circoscritta nel repository disponibile. Il brief descrive il percorso osservato e il risultato desiderato, senza autorizzare una riscrittura completa della ricerca.

Il risultato tecnico da revisionare comprende diff, controlli pertinenti e limite eventualmente incontrato. Un referente prova il percorso nell'ambiente appropriato e confronta il comportamento con il requisito. Il dot può mantenere visibile lo stato della richiesta, ma non deve riassumerla come “risolta” soltanto perché il task è terminato. Nessun test è stato eseguito per questo esempio: è un modello di distribuzione delle responsabilità.

Uno studio migliora un'importazione di file

Immagina uno studio italiano che usa un piccolo software per importare file dimostrativi. Il problema è una gestione poco chiara di alcune righe incomplete. Work può aiutare a preparare una specifica comprensibile; Codex può lavorare sulla modifica; il dot può coordinare i punti da decidere. Il titolare deve però stabilire quali campi siano obbligatori e che cosa fare con i dati mancanti.

Il task non inventa una regola aziendale. La modifica si valuta con esempi concordati e output atteso. Se il software deve trattare dati reali, le prove vanno organizzate nell'ambiente appropriato, senza inserirli casualmente nel brief. Il risultato utile rende chiaro se una riga viene accettata, respinta o segnalata secondo la decisione presa. La continuità del dot mantiene il progetto leggibile, non sostituisce la scelta del criterio.

Dots è anche un'API per costruire agenti nel software?

La documentazione degli strumenti per sviluppatori descrive API e SDK agentici separati: strumenti per integrare agenti nell'applicazione e gestirne l'esecuzione. Non li presenta automaticamente come un'API self-service del proprio dot ChatGPT. Nelle fonti consultate non è stata trovata una base per dedurre quella disponibilità dalle capacità generali. Guida ufficiale agli strumenti Agents.

Se vuoi un agente dentro un gestionale, la domanda riguarda architettura, dati, identità, costi e controllo dell'applicazione. Se vuoi che il tuo dot segua un progetto, la domanda riguarda una responsabilità personale nell'esperienza ChatGPT. Sono bisogni diversi. La guida a che cosa sono le API AI chiarisce il primo percorso senza trasformarlo in una funzione Dots.

Anche gli agenti condivisibili di workspace hanno una documentazione distinta. Non vanno chiamati tutti dot. Per confrontare strumenti di sviluppo puoi leggere Kimi Code, ma il confronto deve riguardare lavoro tecnico, ambiente e prove, non un'equivalenza automatica con la responsabilità persistente di Dots.

Quali errori evitare e come avviare una delega utile?

Il primo errore è dare un requisito ambiguo e aspettarsi che l'agente scelga la regola di business. Il secondo è confondere ambiente cloud del dot e ambiente Codex. Il terzo è chiamare “verificato” un task soltanto completato. Il quarto è dedurre un'API Dots dalle API agentiche generali. Un quinto è usare la continuità per allargare l'ambito senza una nuova decisione.

Per iniziare prepara un problema riproducibile, un obiettivo e un criterio di accettazione. Scegli un task tecnico circoscritto e chiedi modifiche revisionabili, evidenze e limiti. Il dot può aiutare a mantenere la mappa del lavoro, mentre il referente tecnico verifica il risultato. La guida agli agenti AI per aziende aiuta a dare un proprietario a queste responsabilità.

Se il tuo progetto richiede di collegare coordinamento, codice e processo operativo, il percorso di software su misura di Giallo può partire da quel primo requisito e dal suo criterio di prova. La scelta degli strumenti viene dopo una domanda concreta: quale comportamento serve e quali evidenze ci permetteranno di accettarlo.