Dev workflow di VM0: gestire gli agenti AI come un team

Nel team di sviluppo di VM0, ogni sviluppatore lavora contemporaneamente con più istanze di Claude Code. Di solito più di otto.

Trattiamo Claude Code esattamente come tratteremmo uno sviluppatore in carne e ossa. (Sì, la nostra azienda viene chiamata, mezzo per scherzo, AI Colleagues Co!)

Per questo motivo, la filosofia di progettazione alla base del dev workflow di VM0 ricalca le classiche pratiche di gestione dei team nell'ingegneria del software.

Usiamo GitHub Issues per tracciare il lavoro, le Pull Request per la revisione del codice e il merge, e GitHub Actions per gestire l'automazione. Nell'arco di due mesi, questa configurazione ci ha aiutato a rilasciare 404 release e a scrivere oltre 230.000 righe di codice.

Questo articolo spiega come abbiamo reso tutto questo realizzabile, e perché il problema centrale non è mai stato la capacità dell'AI, ma il coordinamento tra le persone.

Il dev workflow basato sull'AI nella pratica

Quando coordini molti agenti AI in parallelo, il collo di bottiglia non è se il modello sappia scrivere codice. Il vero collo di bottiglia è il carico cognitivo umano

Questo workflow è composto da 14 slash command, organizzati in tre livelli: Deep Dive, Issue Management e PR Management.

Vediamo prima come appare il mio workflow e come di solito viene costruita una funzionalità.

Allineamento sui requisiti

Una persona apre una sessione di Claude e inizia con /deep-research. Claude raccoglie informazioni dal codebase, dalla documentazione e dal contesto rilevante. Discutiamo i risultati e ci allineiamo su quale problema stiamo effettivamente risolvendo.
Esplorazione delle soluzioni

Con /deep-innovate, Claude propone diverse possibili direzioni, con i relativi compromessi. Discutiamo, restringiamo il campo e scegliamo una direzione.
Creazione dell'issue

Creiamo una issue su GitHub usando /issue-create. La persona rivede l'issue per assicurarsi che i requisiti siano stati catturati con chiarezza.
Pianificazione e approvazione

Usa /issue-plan per lasciare che Claude continui il lavoro. Claude eseguirà automaticamente l'intero workflow di deep-dive e pubblicherà i risultati sull'issue, tra cui:
1. i risultati di /deep-research
2. i confronti di /deep-innovate
3. un piano di implementazione concreto da /deep-plan
Implementazione

Dopo l'approvazione, /issue-action consente a Claude di implementare il piano, scrivere i test, aprire una PR e assicurarsi che la CI passi.
Revisione e merge

Usiamo /pr-review per una revisione strutturata, poi facciamo una revisione umana finale prima del merge.

La persona interviene in tre punti di controllo: requisiti, direzione e accettazione. Tutto il resto procede in autonomia.

Cambio di mentalità: stai guidando un team di sviluppatori AI

Il momento in cui ho capito che ci serviva un workflow strutturato è stato quando aggiungere altre sessioni di Claude peggiorava di fatto le cose. Più istanze eseguivo in parallelo, più diventava difficile tenere traccia di cosa stesse facendo ciascuna, in che stato fosse il lavoro e cosa fosse già stato deciso.

Senza strumenti esterni, semplicemente non riuscivo a gestire così tante istanze di Claude in una volta. È lì che ho avuto l'intuizione: non era un problema di AI, era un problema di gestione.

GitHub è già lo strumento naturale per la collaborazione nello sviluppo software, quindi invece di inventare qualcosa di nuovo, ho iniziato a trattare Claude esattamente come tratto un collega umano. Una volta fatto questo, la mia capacità di gestione è improvvisamente scalata.

Dieci anni di esperienza nella gestione di progetti e team hanno finalmente acquisito un senso in questo nuovo contesto. Trattando Claude come un membro del team e GitHub come il nostro spazio condiviso di comunicazione e gestione, l'intero sistema è tornato gestibile.

Un buon team leader sa quando intervenire e quando fare un passo indietro:

Punto di controllo	Cosa faccio io	Cosa fa l'AI
Requisiti	Mi allineo sul problema, chiarisco lo scope	Studia il codebase, raccoglie il contesto
Direzione	Rivedo i risultati, approvo l'approccio	Propone 2-3 approcci, valuta i compromessi
Accettazione	Rivedo la PR, verifico la qualità	Implementa, testa, sistema la CI

Questo rispecchia il modo in cui operano i team di sviluppo efficaci. Non faccio micromanagement sugli sviluppatori, ma fisso requisiti chiari, rivedo le decisioni chiave e verifico il risultato finale. Lo stesso principio si applica nella gestione degli agenti AI.

Il flusso di deep dive impone un pensiero strutturato e lento

Il workflow di deep dive impone un pensiero deliberato prima dell'implementazione. A volte Claude finisce in un vicolo cieco. Quando succede, costringiamo Claude a fermarsi e a riflettere, e poi ne discutiamo insieme. Si articola in tre fasi:

Fase	Comando	Scopo	Output
Research	/deep-research	Raccogliere informazioni, comprendere il contesto	research.md
Innovate	/deep-innovation	Esplorare più approcci	innovate.md
Plan	/deep-plan	Definire passi concreti	plan.md

Ogni fase ha confini rigidi.

Research: nessun suggerimento
Innovate: nessun dettaglio
Plan: nessuna implementazione

Questi vincoli costringono Claude a un ragionamento lento e deliberato invece di buttarsi subito sul codice. Senza di essi, i casi limite e le questioni architetturali spesso vengono trascurati!

Esempio di utilizzo

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

Per i task semplici, puoi saltare il deep dive e andare direttamente a /issue-create.

Per i task complessi con incertezza tecnica, le fasi di deep dive aiutano a garantire che tu e Claude siate allineati prima che inizi l'implementazione.

Usa GitHub come memoria condivisa

La maggior parte degli strumenti AI tratta il contesto come qualcosa di temporaneo. Quando la sessione finisce, la memoria scompare.

VM0 usa GitHub come memoria persistente:

Funzionalità di GitHub	Cosa memorizza
Corpo dell'issue	Requisiti e decisioni
Commenti dell'issue	Ricerche, opzioni, piani
Commenti della PR	Revisioni e riepiloghi
Etichette	Stato del workflow

Questo risolve anche un problema umano: il recupero del contesto.

Quando gestisco oltre 8 istanze di Claude, ricevo notifiche che il lavoro è completato. Ma non riesco a ricostruire dalla conversazione di Claude cosa stesse facendo, quali decisioni siano state prese o quale sia lo stato attuale.

Le issue di GitHub risolvono questo. Ogni issue mostra:

I requisiti originali
I risultati della ricerca (cosa è stato scoperto)
La fase di innovazione (quali opzioni sono state considerate)
Il piano approvato (cosa verrà implementato)

Questo formato strutturato rende la revisione efficiente. Così posso scorrere rapidamente le fasi, capire l'approccio e approvare o richiedere modifiche, il tutto senza dover ricordare la conversazione originale.

Quando il lavoro è finito, non ho bisogno di ricordare cosa è successo in una finestra di chat. Posso aprire l'issue e vedere l'intera storia, strutturata e messa per iscritto.

Passaggio di consegne tra agenti

Poiché tutto il contesto vive in GitHub, il lavoro può spostarsi tra gli agenti senza intoppi:

Un agente crea una issue o una PR
Un altro continua in seguito usando /deep-research issue 123 o /issue-plan 123 o /deep-research PR 124

Per le discussioni lunghe, /issue-compact consolida tutto in un corpo dell'issue ordinato. Questo rende i passaggi di consegne semplici sia per le persone sia per l'AI.

Riepiloghiamo i pattern del workflow

Dopo tutto questo, lasciatemi riassumere qualche consiglio pratico.

Task semplici

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

Usalo quando i requisiti sono chiari e il lavoro è lineare.

Task complessi

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

Questo evita di sprecare sforzi sull'approccio sbagliato.

Lavoro in parallelo

Più agenti possono lavorare contemporaneamente mentre la persona rivede i punti di controllo completati. È qui che il workflow scala meglio.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

Riferimento dei comandi

Comandi di deep dive

Comando	Scopo
`/deep-research`	Raccoglie informazioni, comprende il codebase. Nessun suggerimento ammesso.
`/deep-innovate`	Esplora 2-3 approcci, valuta i compromessi. Nessun codice ammesso.
`/deep-plan`	Crea passi di implementazione concreti. Nessuna implementazione ammessa.

Comandi per le issue

Comando	Scopo
`/issue-create`	Crea un'issue dal contesto della conversazione
`/issue-bug`	Crea una segnalazione di bug con i passi per riprodurlo
`/issue-feature`	Crea una richiesta di funzionalità focalizzata sui requisiti
`/issue-plan`	Esegue l'intero workflow di deep-dive, pubblica i risultati sull'issue
`/issue-action`	Continua l'implementazione dopo l'approvazione umana
`/issue-compact`	Consolida il corpo dell'issue e i commenti per il passaggio di consegne

Comandi per le PR

Comando	Scopo
`/pr-check`	Monitora la pipeline di CI, corregge automaticamente, riprova fino a 3 volte
`/pr-review`	Rivede la PR commit per commit rispetto agli standard del progetto
`/pr-comment`	Riepiloga la discussione della conversazione in un commento sulla PR

Per iniziare

Parti semplice: usa /issue-create → /issue-plan → /issue-action per il tuo primo task
Aggiungi il deep dive per i task complessi: quando i requisiti non sono chiari o sono tecnicamente complessi, inizia con /deep-research
Scala gradualmente: aggiungi altre istanze di Claude man mano che prendi confidenza con il ritmo delle revisioni
Fidati del processo: lascia che Claude lavori in autonomia tra un punto di controllo e l'altro

Il workflow è pensato per essere adottato in modo incrementale. Non devi usare tutti i 14 comandi dal primo giorno. Inizia con il flusso base delle issue, poi aggiungi le fasi di deep dive e il lavoro in parallelo man mano che acquisisci sicurezza.

Considerazioni sulla scalabilità: cosa fare quando hai più agenti

Il workflow è stato testato con oltre 10 istanze di Claude in contemporanea. Il nostro consiglio:

Fino a 10 agenti: comodo per una collaborazione approfondita con ciascuno
Oltre 10: sconsigliato

Il fattore limitante non è il workflow, è l'attenzione umana e la qualità delle decisioni. Quando gestisci più di 10 agenti, rischi di diventare tu stesso il collo di bottiglia ai punti di controllo della revisione, e la qualità delle decisioni inizia a degradare.

Qui si applica il classico principio della "two pizza team". Gli stessi vincoli che limitano la dimensione di un team umano limitano anche quanti agenti AI una sola persona può gestire in modo efficace.

Al momento sto esplorando una struttura di team a due livelli 8×8 per scalare oltre i 10 agenti, ma non ho ancora sviluppato pratiche efficaci. Condividerò di più quando ci saranno risultati concreti…

Il dev workflow di VM0 cambia il modo in cui pensiamo allo sviluppo software quando l'AI entra a far parte del team.

Quando tratti gli agenti AI come membri del team anziché come strumenti, tutto va al suo posto. GitHub diventa la memoria condivisa del tuo team. Le issue diventano elementi di lavoro. Le PR diventano deliverable. E tu diventi il team leader, concentrandoti su architettura, direzione e qualità mentre il tuo team AI si occupa dell'implementazione.

Ecco come abbiamo rilasciato 404 release in 2 mesi. Ed ecco come anche tu puoi scalare il tuo sviluppo con l'AI.