La regola che ha fatto la differenza: comparti disgiunti
Il primo giro ha impegnato otto agenti in contemporanea. Nessuno di loro ha mai visto il lavoro degli altri mentre lo faceva. Ognuno aveva un elenco di file scritto nell'incarico: questi sono tuoi, tutto il resto è di qualcun altro e non lo tocchi.
Otto perimetri, otto elenchi. L'agente che rifaceva l'archivio dei progetti possedeva la pagina indice, i suoi componenti, il suo foglio di stile e il suo modulo di animazione. L'agente che scriveva i case study possedeva i contenuti e il template di dettaglio. L'agente delle pagine legali possedeva privacy, cookie, il footer e la pagina contatti. Nessuna sovrapposizione.
Sembra burocrazia. È invece la sola cosa che rende possibile il parallelismo: due agenti che modificano lo stesso file producono un conflitto che nessuno dei due sa risolvere, perché nessuno dei due sa cosa stava facendo l'altro. Con i confini scritti prima, il conflitto non può nascere.
Il coordinatore tocca per primo i file di tutti
C'è una categoria di file che tutti vorrebbero modificare: la configurazione del progetto, il menu, il foglio di stile globale, i componenti condivisi. Sono i file che rendono il parallelismo impossibile, perché ogni agente ha un motivo legittimo per metterci mano.
La soluzione è stata banale e ha retto: prima del fan out, un solo passaggio di coordinamento sistema quei file e li chiude. Nel nostro caso è stata la configurazione della build, il menu di navigazione, il foglio di stile globale, i sette componenti visivi condivisi e gli scaffold degli overlay per pagina. Da quel momento in poi quei file erano vietati a tutti, e il divieto era scritto nell'incarico di ognuno.
Il secondo giro, quello che ha cambiato cosa dice il sito invece di come è fatto, ha usato lo stesso schema: fondamenta condivise prima, comparti dopo.
Agenti che si rifiutano di inventare
La regola più difficile da far rispettare non è tecnica. È questa: se un dato non c'è, non lo inventi.
Un modello linguistico, messo davanti a una griglia di sei numeri da riempire, riempie sei celle. È esattamente quello che non volevamo. Quindi la regola è finita dentro i componenti, non solo dentro le istruzioni.
La griglia di metriche filtra le celle senza valore e, se non ne resta nessuna, sparisce del tutto: uno zero non è più rappresentabile per costruzione. Gli spazi per le immagini che non abbiamo ancora sono blocchi dichiarati, con le proporzioni finali e la commessa scritta dentro, non fotografie di repertorio. Nelle pagine legali i dati che mancano davvero restano nulli e in pagina diventano un segnaposto visibile. Sulla pagina di Cyber Security i tempi di risposta sono marcati come da definire in contratto, perché un tempo di risposta inventato è una promessa che non possiamo tenere.
Un vincolo scritto solo nel prompt si degrada. Un vincolo scritto nel codice resta.
Cosa si è rotto
- Due core. La macchina su cui giravano gli agenti aveva due core. Tredici agenti in parallelo su due core non sono tredici agenti in parallelo: sono tredici agenti che si aspettano. Abbiamo dovuto lanciarli a coppie, il che significa che il tempo totale non è stato il tempo dell'agente più lento, ma la somma di sette turni. La lezione è poco elegante e molto concreta: il parallelismo di un team di agenti è limitato dall'hardware prima che dal modello.
- Il container si è riavviato a metà lavoro. Nel mezzo di un giro, l'ambiente si è riavviato e ha ucciso il processo che orchestrava gli agenti. Il lavoro non è andato perso, perché ogni agente scriveva su disco mano a mano, ma il coordinamento sì: nessuno sapeva più chi aveva finito e chi no. Abbiamo ricostruito lo stato leggendo i file. Da lì una regola che oggi diamo per scontata: lo stato di un'orchestrazione non può vivere solo nella memoria del processo che la governa.
- I documenti invecchiano più in fretta del codice. Il piano di lavoro del primo giro conteneva una riga sbagliata su come il form contatti gestiva il consenso privacy. Era sbagliata perché descriveva un'intenzione, non il codice. L'abbiamo scoperta rileggendo il codice, e la correzione è finita nel documento con la sua storia accanto. Un piano che nessuno riscrive dopo l'esecuzione diventa una fonte di errori con l'autorevolezza di un documento ufficiale.
Il costo, detto per intero
Il costo di un lavoro così non è il consumo dei modelli, che è la voce di cui si parla sempre e non è la più pesante. Il costo vero ha tre voci.
La prima è il tempo umano di preparazione. Scrivere tredici incarichi con perimetri disgiunti e vincoli espliciti richiede di aver già capito l'architettura. Chi non sa dove passano i confini non può assegnarli.
La seconda è la verifica. Un agente produce codice che compila e sembra ragionevole. Sembrare ragionevole non è un criterio. Ogni giro si è chiuso con controllo dei tipi, build, suite di test e una verifica a mano sulle larghezze, e alcuni dei difetti più costosi sono emersi solo lì, guardando il sito dal vivo e non i log.
La terza è la riscrittura della documentazione, che nessuno mette a budget e che va fatta ogni volta.
Quello che ci portiamo dietro
Un team di agenti non rende il lavoro più economico. Lo rende più veloce, a una condizione: che qualcuno abbia disegnato i confini prima di aprire il rubinetto. Senza confini, tredici agenti producono tredici versioni incompatibili della stessa idea e il tempo risparmiato nella scrittura si paga tutto nella riconciliazione.
La domanda giusta da farsi prima di partire non è quale modello usare. È: so dividere questo lavoro in pezzi che non si toccano? Se la risposta è no, il problema non è l'AI. È l'architettura.
Raccontaci il tuo caso