Il nostro gruppo di lavoro

Da qualche tempo lavoriamo insieme a diversi progetti software, mettendo in comune competenze, esperienze e soprattutto la voglia di sperimentare. Nel gruppo ci sono persone che programmano da molti anni e altre che hanno iniziato da poco, sviluppatori junior che stanno ancora costruendo le proprie competenze e che partecipano concretamente allo sviluppo delle applicazioni.

Nell'ultimo anno abbiamo integrato nel nostro lavoro Claude Code e Codex CLI, arrivando ad automatizzare parti delle attività di analisi, implementazione, revisione e collaudo. Oggi un agente può esaminare un intero repository, individuare un problema, proporre una soluzione e realizzarla in tempi che fino a poco tempo fa sarebbero sembrati improbabili. Utilizzando più agenti contemporaneamente, il lavoro può procedere anche su diverse parti dello stesso progetto.

In questo contesto abbiamo scelto di continuare a programmare insieme, lasciando spazio anche a chi sta imparando. Gli sviluppatori junior scrivono codice, realizzano funzionalità, affrontano errori e partecipano alle decisioni tecniche, utilizzando  strumenti AI ma non abusandone.

Questa scelta ha conseguenze molto concrete sull'organizzazione del lavoro. Quando una funzionalità può essere sviluppata interamente da un agente, possiamo comunque decidere di affrontarla direttamente, magari facendoci aiutare nell'analisi o nella revisione. Chi sta imparando deve poter sperimentare, sbagliare, correggere e soprattutto comprendere le soluzioni che realizza. Se affidassimo sistematicamente agli agenti ogni attività di programmazione, finiremmo per eliminare proprio quelle occasioni attraverso cui si diventa sviluppatori più competenti.

Non significa rinunciare alla velocità o usare l'intelligenza artificiale soltanto per le attività marginali. Gli agenti sviluppano realmente, modificano codice ed eseguono test. Semplicemente, nel distribuire il lavoro teniamo conto anche delle competenze che vogliamo acquisire, non soltanto di quale strumento possa completare prima una determinata attività.

Lavorando in questo modo abbiamo iniziato a porci anche un problema organizzativo: come coordinare persone e agenti che intervengono sugli stessi progetti, come mantenere traccia delle decisioni e come permettere a Claude Code e Codex di confrontarsi senza perdere continuamente il contesto?

Una delle risposte è stata costruire insieme Planoro, il nostro software di project management. È nato dalle esigenze incontrate durante lo sviluppo dei nostri stessi progetti e continua a evolversi mentre lo utilizziamo. Attraverso MCP lo abbiamo integrato nel flusso degli agenti, creando un riferimento condiviso per le attività, le informazioni e l'avanzamento del lavoro.

Da qui si è sviluppato il metodo che racconto in questo articolo: un ambiente nel quale Claude Code e Codex analizzano e revisionano reciprocamente le soluzioni, Planoro ci aiuta a organizzare le attività e tutti continuiamo a partecipare allo sviluppo, ciascuno con la propria esperienza e con qualcosa di nuovo da imparare.

Come abbiamo organizzato il flusso

Il primo passo è stato preparare un ambiente di sviluppo che potesse essere compreso e utilizzato sia dalle persone sia dagli agenti. Abbiamo quindi iniziato a lavorare sulle istruzioni condivise del repository, sui collegamenti MCP, sulla descrizione delle attività in Planoro e su un processo di revisione che permettesse di verificare le proposte di Claude Code e Codex prima di integrarle nel progetto.

Il flusso che ne è derivato non è rigido: lo adattiamo alla complessità del lavoro, a chi decide di occuparsene e alle competenze che vogliamo approfondire. Alcune attività vengono sviluppate direttamente dagli agenti, altre da noi, altre ancora attraverso un lavoro congiunto. Le informazioni e le verifiche devono però rimanere accessibili, in modo che chi riprende una funzionalità possa capire cosa è stato fatto, perché e con quali risultati.

Partiamo quindi dalla configurazione degli strumenti, per arrivare a un esempio completo di sviluppo, confronto tra agenti e collaudo.

Preparare un progetto che possa essere compreso da più agenti

Il primo problema che abbiamo affrontato è stato quello del contesto. Claude Code e Codex possono lavorare sullo stesso repository, ma ciascuno mantiene la propria sessione e le proprie informazioni. Il fatto che entrambi vedano gli stessi file non significa che conoscano le decisioni prese durante una conversazione precedente.

Per questo cerchiamo di conservare nel progetto le informazioni che devono sopravvivere alle singole sessioni. Git rimane il riferimento per il codice e per la sua evoluzione, mentre alcuni file Markdown descrivono l'architettura, le convenzioni e le decisioni che sarebbe scomodo spiegare nuovamente ogni volta.

Un progetto può avere una struttura di questo tipo:

progetto/
├── AGENTS.md
├── CLAUDE.md
├── README.md
├── docs/
│   ├── ARCHITECTURE.md
│   ├── DECISIONS.md
│   └── TESTING.md
├── src/
└── tests/

AGENTS.md è il file di istruzioni riconosciuto da Codex, mentre CLAUDE.md viene utilizzato da Claude Code. In quest'ultimo possiamo richiamare le regole condivise, evitando di mantenerne due copie differenti. Gli altri documenti non sono obbligatori per i due strumenti, ma diventano utili quando il progetto cresce e soprattutto quando più persone e agenti devono riprendere un lavoro iniziato da altri.

Un esempio delle regole che inserirei nel progetto è il seguente:

# Istruzioni di progetto

Prima di proporre modifiche, analizza
l'implementazione esistente.

Rispetta l'architettura e le convenzioni
del repository.

Non modificare file durante una fase
di sola analisi.

Quando proponi una soluzione, indica
anche le alternative considerate.

Per ogni modifica esegui i test pertinenti
e distingui quelli superati da quelli
non eseguiti.

Non effettuare commit, push o deploy
senza una richiesta esplicita.

Documenta le decisioni tecniche che
potrebbero influenzare attività future.

Quando revisioni il lavoro di un altro
agente, verifica il codice e le evidenze
senza considerare corretta una soluzione
solo perché è già stata proposta.

La qualità delle istruzioni incide parecchio sul comportamento degli agenti. Un file enorme, pieno di regole ridondanti, può essere meno utile di poche indicazioni precise. Cerchiamo quindi di mantenere queste istruzioni vicine al funzionamento reale dell'applicazione, aggiornandole quando cambiano le convenzioni del progetto.

Collegare Planoro a Claude Code e Codex attraverso MCP

Planoro è nato anche dall'esigenza di rendere più semplice il coordinamento di un lavoro che ormai coinvolge numerose sessioni AI. Quando una modifica viene discussa in Claude, verificata con Codex e successivamente ripresa da uno di noi, diventa importante poter recuperare l'attività originale, capire quali decisioni sono state prese e distinguere quello che resta da fare da quello che è già stato verificato.

Il Model Context Protocol permette di mettere a disposizione degli agenti strumenti esterni con un'interfaccia standardizzata. Nel nostro caso il collegamento riguarda Planoro e le operazioni che il suo server MCP espone.

Per mostrare come funziona la configurazione, ipotizziamo che l'istanza di Planoro metta a disposizione un endpoint MCP HTTP. I comandi seguenti sono esempi da adattare all'indirizzo e all'autenticazione della propria installazione.

Con Claude Code possiamo registrare il server nel progetto:

claude mcp add --transport http \
  --scope project \
  planoro <URL_MCP_PLANORO>

Con Codex CLI la configurazione equivalente è:

codex mcp add planoro \
  --url <URL_MCP_PLANORO>

Una volta configurato il collegamento, possiamo verificarne la presenza:

claude mcp list
codex mcp list

In Claude Code utilizziamo anche /mcp per controllare la connessione e l'eventuale autenticazione. Le credenziali devono essere gestite attraverso i meccanismi previsti dai client e dal server, evitando di inserirle nei documenti del repository.

A questo punto possiamo chiedere agli agenti di recuperare il contesto delle attività attraverso gli strumenti messi a disposizione da Planoro. È importante chiarire che il collegamento MCP, da solo, non crea una conversazione automatica tra Claude e Codex. Consente però di utilizzare un sistema comune per leggere e, dove previsto, aggiornare le informazioni. La sequenza con cui i due agenti devono confrontarsi rimane una parte del nostro flusso operativo.

La differenza rispetto al semplice utilizzo del terminale è notevole. Una sessione non deve partire necessariamente da una spiegazione manuale del problema: può partire da un'attività già descritta, con i riferimenti necessari per orientarsi nel repository.

Dall'attività di Planoro al confronto tra Claude e Codex

Prendiamo un caso pratico. In un'applicazione ASP.NET Core MVC emerge un problema nella gestione delle prenotazioni: in determinate condizioni due richieste contemporanee possono occupare la stessa disponibilità.

Il problema viene descritto in Planoro, insieme al comportamento atteso e alle condizioni che permetteranno di verificarne la soluzione. Cerchiamo di scrivere le attività in modo che siano comprensibili anche da chi non ha seguito la discussione iniziale.

Per questa attività il risultato richiesto sarà impedire le prenotazioni duplicate, senza introdurre regressioni negli altri percorsi di prenotazione. Non definiamo subito come risolverla, perché è proprio su questo che vogliamo utilizzare il confronto tecnico.

Inizio con Claude Code, chiedendogli una valutazione senza autorizzare modifiche:

Recupera da Planoro l'attività relativa alle prenotazioni duplicate e analizza il codice interessato. Ricostruisci il funzionamento attuale, individua le possibili cause e proponi una soluzione. Non modificare alcun file. Descrivi anche le alternative, i rischi e le verifiche necessarie, separando ciò che hai osservato nel codice dalle ipotesi che devono ancora essere dimostrate.

Una volta ottenuta la proposta, passo a Codex. Preferisco che in questa fase elabori una propria analisi, senza ricevere immediatamente le conclusioni di Claude. In questo modo possiamo confrontare due percorsi di valutazione e non soltanto ottenere una conferma della prima risposta.

Analizza indipendentemente il problema descritto nella task di Planoro. Esamina il repository e proponi una soluzione tecnica, indicando eventuali condizioni di concorrenza, problemi di integrità dei dati e possibili regressioni. Non modificare il codice e non assumere che esista già una soluzione corretta.

Supponiamo che Claude suggerisca di verificare la disponibilità prima del salvataggio e che Codex proponga di aggiungere anche una protezione a livello di database. A questo punto possiamo avviare la revisione incrociata.

Il passaggio delle informazioni può avvenire attraverso gli artefatti associati all'attività, se le relative operazioni sono disponibili nel server MCP di Planoro, oppure attraverso documenti condivisi nel repository. In quest'ultimo caso possiamo utilizzare, per esempio, una directory docs/reviews/ con un documento per ciascuna analisi. Il requisito è che ogni agente possa leggere la proposta dell'altro senza perdere i riferimenti al problema originale.

Il prompt di revisione che utilizziamo come modello è questo:

Esamina la soluzione proposta dall'altro agente confrontandola con il codice esistente e con i requisiti dell'attività. Individua eventuali errori, condizioni non considerate o alternative tecnicamente migliori. Per ogni osservazione fornisci una motivazione verificabile. Se condividi una scelta, spiegane le ragioni; se non la condividi, indica quale evidenza potrebbe aiutare a decidere.

Questo approccio ci consente di utilizzare Claude e Codex come revisori reciproci. Non è importante che trovino sempre una soluzione differente: se arrivano autonomamente alle stesse conclusioni e riescono a giustificarle, il confronto ha comunque un valore.

Come gestiamo il confronto quando le soluzioni sono diverse

La parte più delicata è capire quando proseguire il confronto e quando invece passare alla verifica pratica. Due agenti possono produrre argomentazioni convincenti senza che nessuna delle due dimostri davvero la correttezza della soluzione.

Per evitare di consumare tempo in discussioni ripetitive, preferisco limitare il confronto a un primo giro di analisi, una revisione incrociata e, quando è utile, una replica sulle questioni tecniche ancora aperte.

Possiamo usare un'istruzione di questo tipo:

Riconsidera la tua proposta alla luce delle osservazioni ricevute. Accogli le correzioni supportate dal codice o da evidenze tecniche, spiega le eventuali divergenze rimaste e individua un test capace di chiarirle. Non ripetere argomentazioni già esaminate e non cercare un accordo soltanto formale. Concludi con una proposta aggiornata e con le questioni che richiedono ancora una verifica.

Nel nostro esempio, il test potrebbe consistere nell'inviare due richieste di prenotazione contemporanee per la stessa risorsa e verificare il comportamento del sistema. È molto più utile osservare come vengono gestite le transazioni e i vincoli del database che continuare a discutere astrattamente su quale approccio sia preferibile.

Quando il confronto riguarda una decisione architetturale, ne parliamo anche tra noi. Le proposte degli agenti rimangono materiale tecnico da esaminare e le decisioni vengono riportate nel contesto del progetto, così da poterle recuperare durante le attività successive.

Come ci dividiamo il lavoro senza lasciare tutto agli agenti

Una volta chiarita la soluzione, l'attività può essere suddivisa in interventi più piccoli. Per la gestione delle prenotazioni, ad esempio, possiamo separare l'adeguamento della logica applicativa, la gestione degli errori, l'eventuale intervento sul database e la preparazione dei test.

Queste attività rimangono visibili in Planoro e possiamo decidere insieme quali affrontare direttamente e quali affidare agli agenti. Chi ha meno esperienza può occuparsi di una parte dell'implementazione, magari lavorando con Claude Code aperto accanto all'editor per comprendere una classe o con Codex per esaminare il codice appena scritto.

Non credo sia particolarmente utile chiedere a qualcuno di realizzare manualmente ogni singola riga quando abbiamo strumenti capaci di aiutarci. Allo stesso tempo, se un agente completa sistematicamente tutte le funzionalità prima che chi sta imparando abbia avuto occasione di affrontarle, finiamo per togliere spazio proprio alle esperienze che permettono di crescere.

Per questo cerchiamo di distribuire il lavoro anche in funzione di ciò che vogliamo imparare. A volte l'agente prepara una prima implementazione che poi esaminiamo e modifichiamo; altre volte siamo noi a scrivere il codice e chiediamo a Codex o Claude di cercare problemi. In altri casi ancora lavoriamo insieme sulla stessa soluzione, discutendo le alternative mentre sviluppiamo.

Un aspetto che considero importante è poter spiegare le modifiche effettuate. Se un componente è stato generato dall'AI, chi lo integra dovrebbe comunque comprenderne il funzionamento, sapere quali dipendenze introduce e poter intervenire quando qualcosa non va.

Evitare interferenze quando lavoriamo in parallelo

La possibilità di lavorare contemporaneamente richiede qualche accorgimento. Se due agenti modificano gli stessi file nella stessa directory, il rischio di sovrascrivere modifiche o confondere gli stati del progetto è concreto.

Quando le attività devono procedere in parallelo, possiamo utilizzare branch Git distinti e, se necessario, working tree separati.

Per esempio, partendo dal repository principale:

git worktree add \
  -b task/prenotazioni-claude \
  ../progetto-claude HEAD

git worktree add \
  -b task/prenotazioni-codex \
  ../progetto-codex HEAD

In questo modo ogni agente dispone di una propria directory di lavoro e le modifiche possono essere confrontate successivamente attraverso Git. Lo stesso meccanismo è utile quando uno di noi sta programmando una funzionalità e un agente deve eseguire un intervento differente.

Non è necessario creare un worktree per ogni analisi. Se stiamo soltanto esaminando il codice senza modificarlo, può bastare lo stesso repository. La separazione diventa particolarmente utile quando vengono eseguite modifiche concorrenti.

Il momento dell'integrazione rimane importante: le modifiche devono essere riesaminate, confrontate e verificate prima di essere inserite nel ramo condiviso.

La revisione del codice e il nostro modo di collaudare

Nel tempo abbiamo iniziato a utilizzare gli agenti anche per il collaudo, combinando revisione del codice, test automatici funzionali e UX/UI e verifiche eseguite direttamente da noi.

Un metodo che utilizziamo è far esaminare a un agente il lavoro dell'altro, oppure far verificare a Codex una funzionalità sviluppata manualmente. La revisione parte dalle differenze Git e prosegue con i test pertinenti, senza considerare automaticamente completata un'attività perché la compilazione è riuscita.

Una richiesta di revisione potrebbe essere:

Esamina le modifiche relative all'attività di Planoro e confrontale con i criteri di accettazione. Esegui i test funzionali disponibili e verifica attraverso il browser i principali percorsi utente, includendo navigazione, moduli, comportamento responsive e aspetti UX/UI. Individua eventuali regressioni e documenta le anomalie, distinguendo problemi confermati da rischi ancora da verificare.

Per le applicazioni web utilizziamo anche strumenti di automazione del browser, per simulare le operazioni degli utenti, verificare il comportamento delle interfacce e ripetere i test dopo ogni modifica significativa.

Accanto all'automazione manteniamo il collaudo umano, al quale partecipiamo tutti. Utilizzare direttamente l'applicazione ci permette di individuare difficoltà di navigazione, scelte poco intuitive e problemi di esperienza utente che i controlli automatici potrebbero non rilevare. Le anomalie riscontrate possono diventare nuovi test automatizzati, migliorando progressivamente il processo.

I risultati delle verifiche vengono ricondotti alle attività di Planoro, mentre Git conserva la storia delle modifiche. In questo modo manteniamo traccia non soltanto del codice sviluppato, ma anche delle verifiche effettuate prima di considerare concluso un intervento.

Anche Planoro è cresciuto con questo metodo

Una parte interessante di questa esperienza è che Planoro stesso è stato sviluppato attraverso il lavoro condiviso che oggi ci aiuta a organizzare.

Costruire uno strumento che utilizziamo quotidianamente ci permette di riconoscere abbastanza rapidamente i limiti del nostro flusso. Quando un passaggio richiede troppe operazioni manuali o quando una certa informazione viene continuamente persa nel cambio di sessione, possiamo ragionare su come migliorare il sistema.

Non ogni problema richiede una nuova funzionalità. A volte basta modificare il modo in cui descriviamo una task, migliorare le istruzioni degli agenti o evitare di duplicare informazioni già presenti nel repository.

Anche qui Claude Code e Codex possono contribuire in maniera differente: uno analizza una possibile modifica, l'altro ne verifica le implicazioni, mentre noi sperimentiamo il risultato e continuiamo a migliorarlo. Il vantaggio di lavorare su uno strumento che conosciamo così bene è poter confrontare immediatamente le proposte dell'AI con le necessità che incontriamo durante lo sviluppo.

La parte che non voglio automatizzare completamente

Con questo flusso potremmo probabilmente spingere ancora di più sull'automazione. Potremmo far analizzare agli agenti una quantità maggiore di attività, lasciare che implementino intere funzionalità e intervenire soltanto durante la revisione finale.

In molti casi sarebbe più veloce, almeno nell'immediato. Ma lavoriamo insieme anche perché ci piace programmare, sperimentare e imparare cose nuove, e non tutti abbiamo necessariamente la stessa esperienza.

Quando una persona incontra una difficoltà che un agente potrebbe risolvere in pochi secondi, non considero automaticamente quel tempo come perso. Comprendere un errore, seguire una chiamata attraverso diversi livelli dell'applicazione o scoprire perché una soluzione apparentemente corretta non funziona sono esperienze che contribuiscono a costruire competenza.

L'intelligenza artificiale ha imparato da un patrimonio enorme di conoscenze prodotte da persone. I modelli di domani non impareranno automaticamente da ogni riga che scriviamo oggi, ma avranno comunque bisogno di nuove conoscenze, problemi risolti, verifiche e capacità critica. Se smettessimo di creare occasioni in cui nuovi sviluppatori possono fare esperienza, rischieremmo di impoverire proprio quella competenza umana che ci consente di utilizzare e migliorare questi strumenti.

Per adesso il nostro metodo continua a evolversi insieme ai progetti. Claude Code, Codex e Planoro ci permettono di lavorare in modo più organizzato e di sperimentare soluzioni che qualche anno fa sarebbero state molto più impegnative. Ci interessa sfruttare questa possibilità senza trasformare ogni attività in una corsa a chi termina per primo.

La pazienza, anche nello sviluppo software, continua a essere una virtù. E lasciare spazio a chi vuole imparare, senza fretta, è un buon modo per non dimenticarlo.