Come creare un team di 4 agenti che sviluppa funzionalità mentre dormi (Configurazione completa inclusa)

Quattro agenti AI possono rilasciare una funzionalità mentre dormi. La maggior parte delle persone non li mette mai in collegamento.

Attivano un revisore qui, un generatore di test là, manualmente, uno alla volta, ognuno dimenticando cosa ha fatto il precedente. Tu rimani il collo di bottiglia.

La soluzione: Planner → Coder → Tester → Reviewer, collegati per il passaggio automatico. Un trigger, quattro fasi, una funzionalità completata entro mattina.

Ecco la pipeline completa, con codice copia-incolla 👇

Prima di immergerci, condivido appunti quotidiani su AI e vibe coding nel mio canale Telegram: https://t.me/zodchixquant 🧠

Perché una pipeline batte un mucchio di agenti

Un singolo agente che fa tutto riempie la sua finestra di contesto con pianificazione, codice, test e note di revisione finché la qualità non cala.

Quattro specialisti rimangono ciascuno in un contesto pulito e ristretto.

Il trucco è il file di passaggio. Ogni agente scrive il suo output dove il successivo può leggerlo: Planner deposita una specifica in .pipeline/spec.md, Coder la legge e scrive .pipeline/changes.md, e così via.

L'orchestratore che li esegue in ordine è un singolo comando slash. Questo è tutto: quattro sottoagenti, un comando, una cartella condivisa per i passaggi.

Agente 1: Il Planner (subagent, opus)

Il Planner non scrive mai codice. Trasforma una vaga richiesta di funzionalità in una specifica concreta che il Coder può seguire senza indovinare.

Crea .claude/agents/planner.md:

1---
2name: planner
3description: Trasforma una richiesta di funzionalità in una specifica di implementazione. Usalo come primo stadio della pipeline di funzionalità.
4tools: Read, Grep, Glob, Write
5model: opus
6---
7
8Sei uno specialista della pianificazione. NON scrivi codice di implementazione.
9
10Data una richiesta di funzionalità:
111. Leggi le parti rilevanti del codebase per comprendere i pattern attuali.
122. Scrivi una specifica in `.pipeline/spec.md` contenente:
13   - File da creare o modificare, con percorsi esatti
14   - Le interfacce o le firme delle funzioni necessarie
15   - Casi limite che l'implementazione deve gestire
16   - Quali pattern esistenti seguire (nomina il file da cui copiare)
173. Segnala qualsiasi ambiguità come DOMANDA APERTA all'inizio della specifica.
18
19Mantieni la specifica concisa. Il Coder legge solo questa e nient'altro, quindi non lasciare
20lacune e non inventare requisiti che non sono stati richiesti.

La pianificazione viene eseguita su opus perché questa fase stabilisce il tetto di qualità per tutto ciò che segue. Una specifica vaga produce codice vago, non importa quanto bravo sia il Coder.

Agente 2: Il Coder (subagent, sonnet)

Il Coder legge la specifica e scrive l'implementazione. Non pianifica e non rivede il proprio lavoro, costruisce solo ciò che dice la specifica.

Crea .claude/agents/coder.md:

1---
2name: coder
3description: Implementa la specifica in .pipeline/spec.md. Usalo come secondo stadio della pipeline di funzionalità, dopo il planner.
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8Sei uno specialista dell'implementazione.
9
101. Leggi completamente `.pipeline/spec.md`. Se ci sono DOMANDE APERTE, fermati e
11   segnalale invece di indovinare.
122. Implementa esattamente ciò che la specifica descrive. Segui i pattern che
13   nomina. Non aggiungere funzionalità che non sono state richieste.
143. Scrivi un breve riepilogo in `.pipeline/changes.md`: quali file sono cambiati,
15   cosa fa ogni modifica e qualsiasi cosa su cui il Tester dovrebbe concentrarsi.
16
17Scrivi codice che corrisponde al repository. Non rifattorizzare codice non correlato
18o "migliorare" cose al di fuori dell'ambito della specifica.

Sonnet è la scelta giusta qui: l'implementazione su una specifica chiara è esattamente il lavoro bilanciato costo-qualità che Sonnet gestisce meglio.

La nota di passaggio in .pipeline/changes.md è ciò che permette al Tester di colpire la superficie giusta invece di testare alla cieca.

Agente 3: Il Tester (subagent, sonnet)

Il Tester legge cosa è cambiato e scrive test che dimostrano che la funzionalità funziona, poi li esegue.

Crea .claude/agents/tester.md:

1---
2name: tester
3description: Scrive ed esegue test per le modifiche descritte in .pipeline/changes.md. Terzo stadio della pipeline di funzionalità.
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8Sei uno specialista dei test.
9
101. Leggi `.pipeline/changes.md` per vedere cosa è stato costruito e dove.
112. Leggi i file modificati e la specifica in `.pipeline/spec.md`.
123. Scrivi test che coprano: il percorso felice, i casi limite nominati nella specifica
13   e almeno un caso di fallimento. Usa il framework di test del repository.
144. Esegui i test. Se qualcuno fallisce, scrivi i fallimenti in
15   `.pipeline/test-results.md` e FERMATI. Non correggere il codice da solo.
165. Se tutti passano, annotalo in `.pipeline/test-results.md`.
17
18Testa il comportamento, non i dettagli di implementazione. Un test fallito significa
19che la pipeline si ferma per il Revisore, non che tu correggi in giro.

Agente 4: Il Revisore (subagent, opus)

L'ultimo gate. Il Revisore legge tutto ciò che la pipeline ha prodotto e dà un verdetto prima che qualsiasi cosa raggiunga il tuo branch principale.

Crea .claude/agents/reviewer.md:

1---
2name: reviewer
3description: Revisione finale dell'output completo della pipeline. Quarto e ultimo stadio prima dell'approvazione umana.
4tools: Read, Grep, Glob, Bash
5model: opus
6---
7
8Sei un revisore senior. Sei in sola lettura. Non modifichi il codice.
9
101. Leggi la specifica, il riepilogo delle modifiche e i risultati dei test da
11   `.pipeline/`.
122. Esegui `git diff` per vedere le modifiche effettive.
133. Valuta: il codice corrisponde alla specifica? I test sono significativi o
14   superficiali? Ci sono problemi di sicurezza, prestazioni o correttezza?
154. Scrivi un verdetto in `.pipeline/review.md`:
16   - VERDETTO: SHIP / NEEDS WORK / BLOCK
17   - Per NEEDS WORK o BLOCK, elenca esattamente cosa correggere e dove.
18
19Sii l'ultima linea di difesa. Se i test sono verdi ma il codice è sbagliato,
20dì BLOCK. Test verdi non equivalgono a comportamento corretto.

Gli strumenti di sola lettura significano che il Revisore non può nascondere i problemi modificando, può solo giudicare.

L'orchestratore: un comando per eseguirli tutti e quattro

Ora il pezzo che trasforma quattro agenti separati in una pipeline. Un comando slash che li invoca in ordine, ognuno che riprende il file di passaggio scritto dal precedente.

Crea .claude/commands/ship.md:

1Esegui la pipeline completa per: $ARGUMENTS
2
3Esegui queste fasi in ordine. Non saltare avanti. Dopo ogni fase,
4conferma che il file di passaggio esista prima di iniziare la successiva.
5
61. Delega al sottoagente `planner` con la richiesta di funzionalità sopra.
7   Attendi `.pipeline/spec.md`.
82. Se la specifica ha DOMANDE APERTE, fermati e mostramele. Altrimenti
9   delega al sottoagente `coder`. Attendi `.pipeline/changes.md`.
103. Delega al sottoagente `tester`. Attendi `.pipeline/test-results.md`.
11   Se i test falliscono, fermati e mostrami i fallimenti.
124. Delega al sottoagente `reviewer`. Mostrami `.pipeline/review.md`.
13
14Riporta il verdetto finale. Non fare merge di nulla. Lascia il branch per
15la mia revisione mattutina.

Poi una singola linea avvia l'intera catena: /ship aggiungi limitazione di velocità all'endpoint di login.

Dove eseguo la versione notturna

Ecco a cosa mi serve Teamly: hosting cloud gestito costruito specificamente per agenti AI.

Il motivo per cui @Teamly si adatta specificamente a questo articolo: il problema del passaggio è già risolto per te.

Tutto ciò che abbiamo costruito manualmente sopra (il file delle specifiche, il file delle modifiche, l'orchestratore che collega un agente al successivo) Teamly lo fa con un Coordinatore.

Instrada il lavoro tra gli agenti, passa il contesto da uno al successivo e mantiene un brief condiviso che tutti leggono.

Lo stesso flusso Planner-to-Coder-to-Tester, tranne per il fatto che non devi cablare tu i passaggi.

La differenza è che @Teamly non è solo codice. La stessa identica orchestrazione gestisce un team di marketing, un team di ricerca o un team di supporto.

La tua pipeline di Claude Code rilascia funzionalità durante la notte; un team di marketing di Teamly rilascia contenuti allo stesso modo, con la stessa logica di passaggio sottostante.

Costruisci il team esatto di cui hai bisogno

Nuova funzionalità, quel team ha appena lanciato: My Team

Ora puoi costruire il tuo team con solo 3 domande.

Puoi anche controllare: regole di voce, frasi vietate, integrazioni, stile del team (Strict / Casual / Creative) e dimensione del team (2-4 agenti).

@Teamly restituisce un team con una reale motivazione del perché ogni specialista è presente, non un boilerplate. Scambia qualsiasi agente con un clic. Modifica il brief se è sbagliato.

Il punto è un brief strutturato che impone chiarezza, poi compone un team che puoi verificare prima di assumere.

Stessa architettura di passaggio dei team predefiniti, adattata al tuo problema specifico.

Provalo prima gratuitamente

Puoi testare il tutto gratuitamente per 3 giorni su Teamly 5, nessun addebito fino al giorno 4.

Se rimani, il prezzo è $29/mese per 5 agenti.

Abbastanza economico che una funzionalità rilasciata paga il mese.

Il punto cruciale

La differenza tra un mucchio di agenti e una pipeline è il passaggio.

Quattro specialisti che scrivono su file condivisi, un orchestratore che li esegue in ordine, ogni fase che costruisce sulla precedente invece di partire da zero.

Costruisci prima Planner e Coder ed eseguili come una catena a due fasi. Una volta che il flusso sembra solido, aggiungi Tester e Revisore.

Quando tutti e quattro saranno collegati, avvierai una funzionalità prima di andare a letto e leggerai un verdetto con il tuo caffè.

Per appunti quotidiani su agenti AI, vibe coding e configurazioni di Claude Code: https://t.me/zodchixquant 🧠