Codex e workflow multi-agent: lavorare con gli agenti senza perdere il controllo
· 6 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
La 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?".
È 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.
Il 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.
Il cambio di abitudine
Con 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.
Questo è potente, ma sposta il problema. La domanda non è più solo "il modello sa programmare?". La domanda diventa:
- gli ho dato uno scope abbastanza piccolo?
- sa come verificare il risultato?
- sto lavorando in un ambiente isolato?
- la review finale è ancora umana e attenta?
Un workflow sano assomiglia più a questo che a una bacchetta magica:
Sembra 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.
Il prompt buono è quasi un ticket buono
Il 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.
Un 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.
Poi 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.
Questo 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.
Tre lavori che delego volentieri
Il 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.
Il 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.
Il 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.
Tre lavori che tengo umani
Le 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.
Anche 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.
Infine, 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.
La review non è opzionale
La tentazione, quando un agente è bravo, è fidarsi del verde della CI. È comprensibile. È anche il momento in cui iniziano i problemi.
Io guardo sempre almeno cinque cose:
- La patch risolve solo il task richiesto?
- Ha toccato file che non c'entravano?
- I test coprono il comportamento nuovo o solo il caso felice?
- Il codice segue i pattern locali?
- Gli errori sono gestiti come nel resto del progetto?
Quando 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.
Gli agenti rispondono molto meglio a commenti piccoli e verificabili. Curiosamente, anche le persone.
Guardrail che valgono la fatica
Se un agente può leggere file, scrivere codice ed eseguire comandi, va trattato come un processo potente. Non serve paranoia, serve igiene.
Usa 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.
Limita 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.
Riduci l'accesso alla rete quando non serve. Per molti task bastano documentazione ufficiale, package registry e servizi interni specifici. Meno superficie, meno sorprese.
Tieni 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.
Un modo semplice per iniziare in team
Se dovessi introdurre agenti in un team piccolo, partirei senza grandi rivoluzioni.
Creerei 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.
Dopo 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.
È un approccio meno spettacolare del "da oggi facciamo tutto con gli agenti", ma è quello che ti permette di arrivare alla terza settimana senza rimpianti.
La parte più umana
La 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.
Quindi 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.
Gli 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.