“Un artigiano solitario che taglia, leviga, rifinisce e imballa ogni sedia da solo ne consegna una al giorno. Un laboratorio dove quattro persone gestiscono ciascuna la propria postazione ne consegna quattro, e nessuno aspetta.”
La tassa del sequenziale
Una funzionalità in quattro parti (backend, frontend, test, revisione) fatta un pezzo alla volta richiede quasi una giornata intera. Peggio: la tua unica finestra di contesto si gonfia mentre passi da un'attività all'altra, così il modello si porta il disordine del frontend dentro il ragionamento sul backend.
Cosa cambia con un team
Esegui le quattro attività in parallelo e un agente lead le coordina. Ogni membro del team lavora nel proprio contesto pulito. La stessa funzionalità arriva in un paio d'ore, e tu passi il tempo a revisionare e fare merge invece di digitare ogni passaggio da solo.
SOLO TEAM
backend backend ┐
poi frontend frontend ├─ in parallelo
poi test test │
poi revisione revisione┘
~1 giorno, un contesto ~2 ore, contesti puliti
Cosa copre questo corso
- Capitolo 2, I tre livelli: subagent, Agent View e Agent Teams, e quale problema risolve ciascuno.
- Capitolo 3, Il tuo primo team: attiva la funzionalità, poi scrivi un prompt che permetta a un agente lead di scomporre il lavoro.
- Capitolo 4, Costi e modelli: instrada i membri del team su un modello più economico e capisci cosa limita davvero la spesa.
- Capitolo 5, Gestire e scegliere: pilota tutto da Agent View, più una regola per capire quando *non* serve un team.
- Capitolo 6, Guardrail e configurazione: regole di permesso più una configurazione da copiare e incollare.
Una riga per ciascuno
- Fatta in sequenza, una funzionalità in più parti divora una giornata e gonfia un'unica finestra di contesto.
- Un agente lead più membri in parallelo fanno lo stesso lavoro più in fretta, ciascuno nel proprio contesto pulito.
- Il cambiamento costa una variabile d'ambiente e un prompt che dice 'spawn separate agents', non un nuovo strumento o piano.
Dove andare ora