Agenti specializzati e collaborazione
Più agenti non significano automaticamente un risultato migliore. La qualità nasce da incarichi indipendenti, confini di scrittura, prove comparabili e una sintesi che risolve le contraddizioni.
Cosa affronti, passo dopo passo
Decomporre per risultato, non per etichetta
Aggiungere agenti non rende automaticamente il lavoro più intelligente. Spesso lo rende soltanto più difficile da seguire. La domanda giusta non è «quanti agenti posso usare?», ma «quale risultato autonomo posso affidare senza creare sovrapposizioni?». Da qui parte una delega fatta bene.
Un subagente nominato parte normalmente con un contesto isolato: non vede automaticamente l’intera conversazione né tutti i file già letti dal coordinatore. Un fork esplicito può ereditare più contesto, ma non sostituisce un incarico chiaro. Per questo deve ricevere un risultato autonomo, come una mappa dei file o una review di sicurezza, non «occupati del backend».
Ogni incarico dichiara fonti, output, limiti e prova. Se il coordinatore non può verificare l’output senza ripetere tutto il lavoro, il contratto è troppo debole.
Task Notes importa due volte la stessa attività. Vuoi usare più agenti, ma il bug non è ancora localizzato e non vuoi che tutti modifichino il repository.
- Affida a un Explorer una missione di sola lettura: riprodurre il difetto, seguire il dato e consegnare file, simboli e test collegati.
- Dopo la mappa, assegna all’Implementer un solo risultato: correggere la causa nel file individuato, senza ripulire altro codice.
- Chiedi al Tester di aggiungere il caso duplicato alla suite, lavorando sul file di test concordato e partendo dal contratto della patch.
- Fai leggere diff e risultati a un Reviewer che non modifica nulla e deve citare ogni finding con file, riga e impatto.
Risultato: Hai quattro contributi diversi, ma una sola storia verificabile: riproduzione, causa, patch, prova. Ogni passaggio ha un output e nessuno riceve un generico «fai quello che serve».
Dipendenze e parallelismo reale
Parallelizzare è utile solo quando due lavori possono davvero avanzare senza aspettarsi. Aprire più agenti per poi lasciarli fermi sullo stesso prerequisito è parallelismo sulla carta. Prima disegna le dipendenze; dopo decidi che cosa può partire insieme.
Due ricerche indipendenti possono partire insieme. I test che dipendono da una nuova API devono attendere almeno il contratto dell’implementazione. Disegnare il grafo delle dipendenze evita parallelismo finto e attese nascoste.
Il parallelismo ha un costo: avvio, contesto duplicato, sintesi e possibili conflitti. Se due rami devono davvero scrivere in parallelo, worktree separati possono isolarne i file; restano comunque da integrare e verificare. Per un compito piccolo, un solo agente con un piano chiaro è spesso più veloce.
- Scomponi il risultato in artefatti verificabili, non in titoli generici.
- Disegna le dipendenze e separa i lavori realmente indipendenti.
- Assegna un solo proprietario di scrittura per ogni file.
- Avvia in parallelo soltanto i rami senza dipendenze o conflitti.
- Riunisci prove e divergenze in una sintesi controllata.
Devi aggiungere una priorità alle attività di Task Notes. Servono una scelta sul formato dati, una modifica al parser, test e una verifica dell’interfaccia.
- Fai partire insieme la mappa del formato salvato e la ricerca dei punti in cui la priorità viene mostrata: sono due letture indipendenti.
- Blocca l’implementazione finché il formato non è deciso, perché parser e migrazione devono condividere lo stesso contratto.
- Avvia i test del parser dopo il contratto ma in parallelo alla modifica della vista, assegnando file distinti.
- Riunisci i rami in un controllo end-to-end soltanto quando dati, parser e interfaccia hanno prodotto artefatti compatibili.
Risultato: Il tempo si riduce dove esiste indipendenza reale. Nei punti di raccordo non indovini: attendi l’artefatto che definisce il contratto e poi verifichi l’integrazione.
Ownership dei file e conflitti
Il conflitto peggiore non è quello che Git segnala in rosso. È quello che passa inosservato perché due agenti riscrivono lo stesso file con idee diverse e l’ultima versione sembra comunque valida. L’ownership serve a sapere chi può scrivere, chi propone e chi controlla.
Se due agenti modificano lo stesso file, l’ultimo risultato può cancellare o reinterpretare il primo. Assegna ownership di scrittura, serializza i cambi o fai produrre a uno dei due soltanto una proposta.
La lettura può essere condivisa più facilmente della scrittura. Un reviewer analizza il diff senza modificarlo; l’implementatore conserva la responsabilità della patch finché i finding non vengono accettati.
L’Implementer sta correggendo `importer.py`; il Reviewer nota che il nome del file caricato non viene normalizzato. Entrambi vorrebbero intervenire subito.
- Mantieni `importer.py` sotto ownership dell’Implementer fino alla chiusura della patch corrente.
- Chiedi al Reviewer un finding di sola lettura con input pericoloso, funzione coinvolta, impatto e comportamento atteso.
- Fai integrare il finding all’Implementer in un secondo diff distinguibile, aggiungendo il test proposto.
- Restituisci il diff completo al Reviewer per controllare che il rischio sia coperto senza introdurre regressioni.
Risultato: La segnalazione di sicurezza non viene ignorata, ma nemmeno trasformata in una modifica concorrente. Rimangono leggibili autore, intenzione e prova di ogni passaggio.
Sintesi basata su prove
Una sintesi non è un collage di rapporti. Il coordinatore deve fare il lavoro più delicato: capire dove le prove concordano, dove le conclusioni divergono e quale affermazione può essere sostenuta davvero. Quattro agenti sicuri di sé possono condividere la stessa supposizione sbagliata.
Il coordinatore non concatena semplicemente i rapporti. Confronta file citati, test, supposizioni e limiti; segnala divergenze e decide quale evidenza è più pertinente.
Una buona consegna finale separa ciò che è implementato, ciò che è verificato e ciò che resta aperto. I subagenti riportano al coordinatore; in un agent team sperimentale, invece, i teammate possono anche comunicare fra loro e condividere task. Sono modelli di coordinamento diversi, e in entrambi la sicurezza del tono vale meno delle prove.
L’Explorer attribuisce il doppio import al parser; il Reviewer pensa che il problema sia nel salvataggio. Entrambi citano codice reale, ma nessuno ha una prova conclusiva.
- Metti in tabella le due ipotesi con file citati, input usato e osservazione prevista se ciascuna fosse vera.
- Cerca il primo punto del flusso in cui il duplicato è osservabile: output del parser oppure contenuto dello store.
- Esegui un test mirato a quel confine, senza modificare il codice per favorire una delle ipotesi.
- Aggiorna la sintesi con l’esito, scarta l’ipotesi smentita e conserva il limite delle verifiche non ancora svolte.
Risultato: La divergenza diventa un esperimento, non una votazione. La conclusione finale nasce dal confine osservato e resta proporzionata alle prove disponibili.
Squadra per Task Notes
La nuova importazione richiede comprensione, patch, casi limite e controllo finale.
Explorer → mappa parser, store e test (sola lettura)
Implementer → possiede parser.py
Tester → possiede test_parser.py dopo il contratto
Reviewer → legge il diff e cita finding
Coordinator → confronta test, diff e rischi; non inventa consenso