Codex e workflow multi-agent: lavorare con gli agenti senza perdere il controllo

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2La prima volta che un agente di coding sistema davvero un bug al posto tuo, la reazione è quasi sempre la stessa: un misto di entusiasmo e sospetto. Bello, certo. Però poi guardi il diff e ti chiedi: "Ok, ma cosa ha toccato esattamente? Posso fidarmi? Lo rifarà nello stesso modo domani?".
3~
4È lì che secondo me inizia la parte interessante. Non quando l'agente scrive una funzione, ma quando diventa abbastanza capace da prendersi pezzi di lavoro interi: leggere il repository, creare una patch, eseguire i test, aprire una PR, tornare dopo un commento di review. Codex si sta muovendo proprio in quella direzione: lavoro in background, worktree separati, browser integrato, automazioni, plugin, memoria e controlli più espliciti sui permessi.
5~
6Il punto non è immaginare un futuro in cui nessuno legge più codice. Sarebbe un pessimo futuro, oltre che abbastanza ingenuo. Il punto è capire come lavorare con agenti che possono fare molto senza lasciare che facciano qualsiasi cosa.
7~
8## Il cambio di abitudine
9~
10Con l'autocomplete tradizionale restavi sempre tu al volante. L'AI suggeriva una riga, tu decidevi. Con un agente, invece, il rapporto cambia: gli dai un obiettivo e lui attraversa più passaggi da solo.
11~
12Questo è potente, ma sposta il problema. La domanda non è più solo "il modello sa programmare?". La domanda diventa:
13~
14- gli ho dato uno scope abbastanza piccolo?
15- sa come verificare il risultato?
16- sto lavorando in un ambiente isolato?
17- la review finale è ancora umana e attenta?
18~
19Un workflow sano assomiglia più a questo che a una bacchetta magica:
20~
21```mermaid
22flowchart LR
23    Idea[Task umano] --> Scope[Scopo piccolo e verificabile]
24    Scope --> Agent[Agente in worktree isolato]
25    Agent --> Checks[Test, lint, build, browser]
26    Checks --> Review[Review umana]
27    Review --> Merge[Merge o nuova iterazione]
28    Review --> Iterate[Commenti precisi sul diff]
29    Iterate --> Agent
30```
31~
32Sembra meno romantico di "l'agente costruisce tutto", ma funziona molto meglio. Ed è anche il modo in cui lavorano i team bravi con gli esseri umani: task chiari, feedback rapido, responsabilità esplicita.
33~
34## Il prompt buono è quasi un ticket buono
35~
36Il prompt più pericoloso è quello vago ma sicuro di sé: "sistema la pagina invoices", "migliora l'architettura", "ripulisci il modulo auth". Sono richieste che suonano produttive e generano diff enormi. Poi però ti ritrovi a fare archeologia.
37~
38Un prompt utile è più noioso. Per esempio: implementa l'export CSV per la pagina invoices, sapendo che la tabella è in `app/(dashboard)/invoices/page.tsx`, le query stanno in `src/server/invoices.ts` e c'è già un pattern simile in `app/(dashboard)/reports`.
39~
40Poi aggiungi vincoli chiari: non cambiare lo schema del database, non aggiungere dipendenze se basta una piccola utility, mantieni lo stile UI esistente. E chiudi con la verifica: `npm test -- invoices` e `npm run build`.
41~
42Questo tipo di brief non serve a "spiegare meglio all'AI". Serve soprattutto a chiarire meglio a te cosa stai delegando. Se non riesci a scriverlo in modo concreto, forse il task non è ancora pronto per un agente.
43~
44## Tre lavori che delego volentieri
45~
46Il primo è il lavoro ripetitivo ma verificabile: aggiungere test, migrare chiamate a una nuova API interna, aggiornare import, sostituire componenti deprecati, sistemare errori TypeScript. Qui l'agente può risparmiare ore e il rischio è controllabile.
47~
48Il secondo è il lavoro esplorativo: "trova dove viene calcolato questo totale", "spiegami perché questo test è fragile", "riproduci il bug e dimmi quali file sembrano coinvolti". Anche quando non produce subito una patch, può fare una ricognizione utile.
49~
50Il terzo è il lavoro di manutenzione ricorrente: dependency update piccoli, cleanup di feature flag vecchi, riassunto di PR bloccate, controllo di TODO dimenticati. Non è glamour, ma è proprio il tipo di lavoro che tende ad accumularsi.
51~
52## Tre lavori che tengo umani
53~
54Le decisioni di prodotto restano umane. Se una modifica cambia il modo in cui un utente paga, cancella dati, vede prezzi o capisce un permesso, voglio una persona responsabile.
55~
56Anche i confini di sicurezza meritano attenzione umana: auth, ruoli, token, logging di dati sensibili, migrazioni database. Un agente può aiutare a implementare, ma non deve essere l'unico a decidere.
57~
58Infine, tengo umano tutto ciò che richiede gusto architetturale. Un agente può proporre un refactor, ma capire se un'astrazione è davvero necessaria o se stiamo solo lucidando un problema inesistente resta un mestiere.
59~
60## La review non è opzionale
61~
62La tentazione, quando un agente è bravo, è fidarsi del verde della CI. È comprensibile. È anche il momento in cui iniziano i problemi.
63~
64Io guardo sempre almeno cinque cose:
65~
661. La patch risolve solo il task richiesto?
672. Ha toccato file che non c'entravano?
683. I test coprono il comportamento nuovo o solo il caso felice?
694. Il codice segue i pattern locali?
705. Gli errori sono gestiti come nel resto del progetto?
71~
72Quando qualcosa non va, il feedback deve essere specifico. "Fix it" è pigro. Meglio: questa utility duplica `parseMoney` in `src/lib/money.ts`; riusa quella funzione, aggiungi un test per il caso EUR e non cambiare l'API pubblica del modulo billing.
73~
74Gli agenti rispondono molto meglio a commenti piccoli e verificabili. Curiosamente, anche le persone.
75~
76## Guardrail che valgono la fatica
77~
78Se un agente può leggere file, scrivere codice ed eseguire comandi, va trattato come un processo potente. Non serve paranoia, serve igiene.
79~
80Usa worktree o branch separati. Così puoi confrontare il diff, buttare via esperimenti falliti e non mescolare il lavoro dell'agente con quello che stavi facendo tu.
81~
82Limita i permessi. Comandi come `rg`, `git diff`, `npm test` e `npm run build` possono essere abbastanza liberi. Deploy, migrazioni database, accesso a segreti e comandi distruttivi devono restare espliciti.
83~
84Riduci l'accesso alla rete quando non serve. Per molti task bastano documentazione ufficiale, package registry e servizi interni specifici. Meno superficie, meno sorprese.
85~
86Tieni traccia delle azioni. Quando una patch arriva in review, dovresti poter ricostruire prompt, comandi eseguiti, test passati e file modificati. Non per fare burocrazia, ma per poter capire cosa è successo se qualcosa va storto.
87~
88## Un modo semplice per iniziare in team
89~
90Se dovessi introdurre agenti in un team piccolo, partirei senza grandi rivoluzioni.
91~
92Creerei una label `agent-ready` per issue con scope chiaro. Aggiungerei un template con contesto, vincoli e comandi di verifica. Chiederei PR piccole, idealmente sotto qualche centinaio di righe. Pretenderei test o screenshot per le modifiche visibili. E soprattutto terrei una persona responsabile del merge.
93~
94Dopo due settimane guarderei i dati: quali task sono stati davvero accelerati, quali review sono state pesanti, quali prompt hanno prodotto confusione, quali parti del codebase sono troppo fragili per essere delegate.
95~
96È un approccio meno spettacolare del "da oggi facciamo tutto con gli agenti", ma è quello che ti permette di arrivare alla terza settimana senza rimpianti.
97~
98## La parte più umana
99~
100La cosa buffa è che più gli agenti diventano autonomi, più tornano importanti le competenze classiche: scrivere un buon ticket, fare tagli piccoli, creare test, leggere diff, comunicare trade-off. L'agente accelera chi sa già lavorare bene. Amplifica anche il caos di chi delega male.
101~
102Quindi no, non vedo i workflow multi-agent come una scorciatoia per smettere di fare ingegneria. Li vedo come un modo per spostare più energia sulle parti che contano: decidere cosa costruire, verificare che funzioni, mantenere il sistema comprensibile.
103~
104Gli agenti possono diventare ottimi colleghi asincroni. Ma un collega asincrono, per essere utile, ha bisogno di contesto, confini e review. Esattamente come tutti gli altri.
105~
106## Fonti utili
107~
108- [Codex for (almost) everything - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [Running Codex safely at OpenAI](https://openai.com/index/running-codex-safely/)
110- [Introducing Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [What's new with GitHub Copilot coding agent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

2La prima volta che un agente di coding sistema davvero un bug al posto tuo, la reazione è quasi sempre la stessa: un misto di entusiasmo e sospetto. Bello, certo. Però poi guardi il diff e ti chiedi: "Ok, ma cosa ha toccato esattamente? Posso fidarmi? Lo rifarà nello stesso modo domani?".

4È lì che secondo me inizia la parte interessante. Non quando l'agente scrive una funzione, ma quando diventa abbastanza capace da prendersi pezzi di lavoro interi: leggere il repository, creare una patch, eseguire i test, aprire una PR, tornare dopo un commento di review. Codex si sta muovendo proprio in quella direzione: lavoro in background, worktree separati, browser integrato, automazioni, plugin, memoria e controlli più espliciti sui permessi.

6Il punto non è immaginare un futuro in cui nessuno legge più codice. Sarebbe un pessimo futuro, oltre che abbastanza ingenuo. Il punto è capire come lavorare con agenti che possono fare molto senza lasciare che facciano qualsiasi cosa.

8## Il cambio di abitudine

10Con l'autocomplete tradizionale restavi sempre tu al volante. L'AI suggeriva una riga, tu decidevi. Con un agente, invece, il rapporto cambia: gli dai un obiettivo e lui attraversa più passaggi da solo.

11~

12Questo è potente, ma sposta il problema. La domanda non è più solo "il modello sa programmare?". La domanda diventa:

13~

14- gli ho dato uno scope abbastanza piccolo?

15- sa come verificare il risultato?

16- sto lavorando in un ambiente isolato?

17- la review finale è ancora umana e attenta?

18~

19Un workflow sano assomiglia più a questo che a una bacchetta magica:

20~

21```mermaid

22flowchart LR

23 Idea[Task umano] --> Scope[Scopo piccolo e verificabile]

24 Scope --> Agent[Agente in worktree isolato]

25 Agent --> Checks[Test, lint, build, browser]

26 Checks --> Review[Review umana]

27 Review --> Merge[Merge o nuova iterazione]

28 Review --> Iterate[Commenti precisi sul diff]

29 Iterate --> Agent

30```

31~

32Sembra meno romantico di "l'agente costruisce tutto", ma funziona molto meglio. Ed è anche il modo in cui lavorano i team bravi con gli esseri umani: task chiari, feedback rapido, responsabilità esplicita.

33~

34## Il prompt buono è quasi un ticket buono

35~

36Il prompt più pericoloso è quello vago ma sicuro di sé: "sistema la pagina invoices", "migliora l'architettura", "ripulisci il modulo auth". Sono richieste che suonano produttive e generano diff enormi. Poi però ti ritrovi a fare archeologia.

37~

38Un prompt utile è più noioso. Per esempio: implementa l'export CSV per la pagina invoices, sapendo che la tabella è in `app/(dashboard)/invoices/page.tsx`, le query stanno in `src/server/invoices.ts` e c'è già un pattern simile in `app/(dashboard)/reports`.

39~

40Poi aggiungi vincoli chiari: non cambiare lo schema del database, non aggiungere dipendenze se basta una piccola utility, mantieni lo stile UI esistente. E chiudi con la verifica: `npm test -- invoices` e `npm run build`.

41~

42Questo tipo di brief non serve a "spiegare meglio all'AI". Serve soprattutto a chiarire meglio a te cosa stai delegando. Se non riesci a scriverlo in modo concreto, forse il task non è ancora pronto per un agente.

43~

44## Tre lavori che delego volentieri

45~

46Il primo è il lavoro ripetitivo ma verificabile: aggiungere test, migrare chiamate a una nuova API interna, aggiornare import, sostituire componenti deprecati, sistemare errori TypeScript. Qui l'agente può risparmiare ore e il rischio è controllabile.

47~

48Il secondo è il lavoro esplorativo: "trova dove viene calcolato questo totale", "spiegami perché questo test è fragile", "riproduci il bug e dimmi quali file sembrano coinvolti". Anche quando non produce subito una patch, può fare una ricognizione utile.

49~

50Il terzo è il lavoro di manutenzione ricorrente: dependency update piccoli, cleanup di feature flag vecchi, riassunto di PR bloccate, controllo di TODO dimenticati. Non è glamour, ma è proprio il tipo di lavoro che tende ad accumularsi.

51~

52## Tre lavori che tengo umani

53~

54Le decisioni di prodotto restano umane. Se una modifica cambia il modo in cui un utente paga, cancella dati, vede prezzi o capisce un permesso, voglio una persona responsabile.

55~

56Anche i confini di sicurezza meritano attenzione umana: auth, ruoli, token, logging di dati sensibili, migrazioni database. Un agente può aiutare a implementare, ma non deve essere l'unico a decidere.

57~

58Infine, tengo umano tutto ciò che richiede gusto architetturale. Un agente può proporre un refactor, ma capire se un'astrazione è davvero necessaria o se stiamo solo lucidando un problema inesistente resta un mestiere.

59~

60## La review non è opzionale

61~

62La tentazione, quando un agente è bravo, è fidarsi del verde della CI. È comprensibile. È anche il momento in cui iniziano i problemi.

63~

64Io guardo sempre almeno cinque cose:

65~

661. La patch risolve solo il task richiesto?

672. Ha toccato file che non c'entravano?

683. I test coprono il comportamento nuovo o solo il caso felice?

694. Il codice segue i pattern locali?

705. Gli errori sono gestiti come nel resto del progetto?

71~

72Quando qualcosa non va, il feedback deve essere specifico. "Fix it" è pigro. Meglio: questa utility duplica `parseMoney` in `src/lib/money.ts`; riusa quella funzione, aggiungi un test per il caso EUR e non cambiare l'API pubblica del modulo billing.

73~

74Gli agenti rispondono molto meglio a commenti piccoli e verificabili. Curiosamente, anche le persone.

75~

76## Guardrail che valgono la fatica

77~

78Se un agente può leggere file, scrivere codice ed eseguire comandi, va trattato come un processo potente. Non serve paranoia, serve igiene.

79~

80Usa worktree o branch separati. Così puoi confrontare il diff, buttare via esperimenti falliti e non mescolare il lavoro dell'agente con quello che stavi facendo tu.

81~

82Limita i permessi. Comandi come `rg`, `git diff`, `npm test` e `npm run build` possono essere abbastanza liberi. Deploy, migrazioni database, accesso a segreti e comandi distruttivi devono restare espliciti.

83~

84Riduci l'accesso alla rete quando non serve. Per molti task bastano documentazione ufficiale, package registry e servizi interni specifici. Meno superficie, meno sorprese.

85~

86Tieni traccia delle azioni. Quando una patch arriva in review, dovresti poter ricostruire prompt, comandi eseguiti, test passati e file modificati. Non per fare burocrazia, ma per poter capire cosa è successo se qualcosa va storto.

87~

88## Un modo semplice per iniziare in team

89~

90Se dovessi introdurre agenti in un team piccolo, partirei senza grandi rivoluzioni.

91~

92Creerei una label `agent-ready` per issue con scope chiaro. Aggiungerei un template con contesto, vincoli e comandi di verifica. Chiederei PR piccole, idealmente sotto qualche centinaio di righe. Pretenderei test o screenshot per le modifiche visibili. E soprattutto terrei una persona responsabile del merge.

93~

94Dopo due settimane guarderei i dati: quali task sono stati davvero accelerati, quali review sono state pesanti, quali prompt hanno prodotto confusione, quali parti del codebase sono troppo fragili per essere delegate.

95~

96È un approccio meno spettacolare del "da oggi facciamo tutto con gli agenti", ma è quello che ti permette di arrivare alla terza settimana senza rimpianti.

97~

98## La parte più umana

99~

100La cosa buffa è che più gli agenti diventano autonomi, più tornano importanti le competenze classiche: scrivere un buon ticket, fare tagli piccoli, creare test, leggere diff, comunicare trade-off. L'agente accelera chi sa già lavorare bene. Amplifica anche il caos di chi delega male.

101~

102Quindi no, non vedo i workflow multi-agent come una scorciatoia per smettere di fare ingegneria. Li vedo come un modo per spostare più energia sulle parti che contano: decidere cosa costruire, verificare che funzioni, mantenere il sistema comprensibile.

103~

104Gli agenti possono diventare ottimi colleghi asincroni. Ma un collega asincrono, per essere utile, ha bisogno di contesto, confini e review. Esattamente come tutti gli altri.

105~

106## Fonti utili

107~

108- [Codex for (almost) everything - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [Running Codex safely at OpenAI](https://openai.com/index/running-codex-safely/)

110- [Introducing Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [What's new with GitHub Copilot coding agent](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~