Dodici Accordi di Lavoro per il Codice Scritto dalle Macchine

La retro è stata la parte facile.

Il tuo team ha condotto la retro post-sbornia da vibe-coding. I dati sul churn erano sulla board, la stanza ha concordato che la coda di review si stava razionando silenziosamente, e tutti sono usciti con la rara sensazione post-retro di aver deciso qualcosa. Due sprint dopo, gli accordi vivono in un documento di riepilogo che nessuno apre, e il grafico del churn non ha notato nulla.

Quella modalità di fallimento è ben documentata: circa due terzi degli action item delle retrospettive muoiono senza cambiare nulla. Gli accordi di lavoro muoiono più velocemente, perché un accordo è una norma, e una norma non ottiene un numero di ticket né un owner a meno che tu non glieli assegni.

Questo è il regolamento della retro post-sbornia. Dodici accordi di lavoro per team che rilasciano codice scritto da macchine, costruiti dalla stessa ricerca pubblica che ha nominato il problema. I tre esempi del post originale sono qui, affiancati da altri nove, tutti nello stesso formato: una regola che il team può enunciare in una frase, il numero che si muove quando la regola viene seguita e il check-in in cui lo si guarda.

Cos'è un Accordo di Lavoro per Codice Scritto da Macchine?

Un accordo di lavoro per codice scritto da macchine è una regola che un team scrive per sé stesso su come le modifiche generate da AI vengono prodotte, revisionate e possedute. Differisce da una policy sia nell'origine che nell'applicazione: una policy viene calata dall'alto e verificata, mentre un accordo di lavoro viene negoziato in una retrospettiva, verificato rispetto ai dati di consegna del team stesso e riscritto quando quei dati dicono che non sta funzionando.

Il caso di ricerca a loro favore è diretto. Il report DORA 2025 ha rilevato che il 90% degli sviluppatori ora usa AI al lavoro, con l'adozione positivamente collegata al throughput e negativamente collegata alla stabilità della consegna. Il suo AI Capabilities Model identifica cosa separa i team che l'AI amplifica dai team che destabilizza, e ogni capacità nell'elenco è organizzativa: una posizione AI chiara e comunicata, batch piccoli, pratiche di controllo versione solide. Un accordo di lavoro è l'unità più piccola di posizione organizzativa — una frase a cui l'intero team ha accettato di essere tenuto.

Una Regola, un Numero, un Check-In

La maggior parte degli accordi di lavoro fallisce strutturalmente, non culturalmente. Mancano di una delle tre parti.

La regola deve stare in una frase che un compagno di team può enunciare a freddo. Se serve un paragrafo, è una linea guida, e le linee guida perdono contro una deadline ogni volta.

Il numero rende la regola falsificabile. La verifica è esattamente dove l'intuizione inganna: il sondaggio Stack Overflow 2025 su oltre 49.000 sviluppatori ha rilevato che la frustrazione principale con gli strumenti AI, citata dal 45%, è il codice "quasi giusto, ma non del tutto" — e il codice quasi-giusto sembra a posto finché la produzione non è in disaccordo. Le sensazioni non arbitrano questo. I numeri sì.

Il check-in dà al numero una data e un luogo, di solito i primi cinque minuti della retro successiva. Una regola senza un numero è un'opinione. Un numero senza un check-in è carta da parati.

I Dodici

Ruba liberamente. I numeri nelle regole (400 righe, 90 giorni, due task) sono punti di partenza da calibrare, non leggi.

La Review Si Sta Razionando da Sola. Razionala di Proposito.

La telemetria 2026 di Faros AI su 22.000 developer ha rilevato un tempo mediano alla prima review in aumento del 156,6% e PR merged senza alcuna review in aumento del 31,3%. Quando la capacità di review si esaurisce, i team non decidono di saltare la review — si decide da sola, un "sembra ok" alla volta.

1. "Niente merge senza un'approvazione umana, CI verde o no." L'accordo di base. Quasi un terzo in più di change ora raggiunge la produzione senza che un singolo umano li abbia letti, e il codice quasi-giusto è esattamente il tipo che passa la CI. Check: conteggio merge senza review, settimanale.

2. "PR scritte da macchine oltre 400 righe vanno divise prima della review." I batch piccoli sono la capability più portante nel modello DORA, e la dimensione del batch è l'input che un team controlla più direttamente. Un reviewer può gestire onestamente 400 righe; nessuno gestisce 2.000. Check: distribuzione dimensione PR, prossima retro.

3. "Change che toccano auth, pagamenti o migration richiedono un secondo reviewer, chiunque sia l'autore." Scala la verifica con il blast radius, non con la fiducia nello strumento. I percorsi hot sono dove i tuoi incident già si concentrano; nominali esplicitamente nell'accordo. Check: tasso approvazioni doppie su PR hot-path, prossima retro.

L'Ownership Sopravvive all'Autocomplete

Il modulo che nessuno vuole toccare ha un autore che non può spiegarlo. Questi due accordi mantengono l'authorship significativa.

4. "Se non puoi spiegare il diff, non puoi fare merge." La spiegazione è la verifica più economica disponibile: costa dieci minuti e cattura la classe di bug che la review scorre via. Se spiegare un change richiede più tempo che rigenerarlo, è un'informazione sul change. Check: al demo prep, una PR merged scritta da macchina per engineer viene illustrata ad alta voce, ogni sprint.

5. "La descrizione PR registra cosa l'umano ha verificato, non cosa il modello ha generato." "Eseguita migration localmente, testato rollback, controllato query plan" dice a un reviewer dove è andata l'attenzione umana. Il report ROI 2026 di DORA chiama il costo del controllo dell'output macchina verification tax; questa voce rende la tassa visibile invece che ambientale. Check: quota di PR merged con nota di verifica, prossima retro.

Il Churn È la Metrica di Velocità Onesta

Il code churn è in aumento dell'861% nei dati Faros. Una feature che ha shippato due volte non è stata veloce la prima volta, qualunque cosa dicesse il report sprint.

6. "Una riscrittura entro 90 giorni è rework, e il rework ottiene un ticket." La finestra di 90 giorni viene dal pattern che Autonoma chiama 90-day reckoning: la velocità del mese uno che diventa debito del mese tre. Il rework che non appare mai nel tracker è un costo che il team paga ma non conta mai. Check: ticket rework e tasso churn per modulo, prossima retro.

7. "Il codice usa-e-getta è dichiarato tale alla nascita." Spike e prototipi sono un uso legittimo della velocità AI. Etichettali quando vengono creati, così le statistiche churn restano oneste e nessuno spike viene promosso a produzione perché tutti dimenticano cosa fosse. Check: quota di churn da spike etichettati, mensile.

Gli Incident Sono Dove la Tassa Viene Pagata

Rapporto incident-to-PR: in aumento del 242,7%. Bug per developer dall'adozione: in aumento del 54%. La verifica che salti al momento della review viene eseguita in produzione, alla peggiore tariffa oraria possibile.

8. "Ogni incident review chiede se il change scatenante era scritto da macchina, e tracciamo il rapporto." Non per colpa — il rapporto sostituisce l'aneddoto più rumoroso nella stanza con il numero del team stesso, ed è il numero che ti dice se gli accordi da 1 a 5 stanno funzionando. Check: campo template postmortem; rapporto rivisto mensilmente.

9. "Un umano possiede ogni asserzione di test." L'AI scrive test plausibili come scrive codice plausibile, e un test che non asserisce nulla è peggio di nessun test, perché compra fiducia senza comprare verifica. Abbozzare test è delegabile. Decidere cosa deve essere vero non lo è. Check: conteggio bug sfuggiti, prossima retro.

Non Inondare la Coda

10. "Due task agent in volo per persona, massimo." La velocità di digitazione era un limite naturale di work-in-progress; gli agent l'hanno rimosso. Un engineer ora può aprire PR più velocemente di quanto tre possano reviewarle, e l'overflow diventa o latenza di review o merge non reviewati — gli stessi due numeri già in movimento nella direzione sbagliata. Un limite WIP sulla delega mantiene solvente il budget di verifica umana. Check: PR aperte per autore, settimanale.

Accordi Sugli Accordi

Gli ultimi due esistono perché i primi dieci altrimenti si uniranno ai due terzi di action item che muoiono.

11. "Ogni accordo ha una data di scadenza." Tre sprint è un default sensato. Alla scadenza il team rivota: mantenere, riscrivere o ritirare. Un accordo che si rinnova automaticamente per sempre è una policy sotto mentite spoglie, e una lista piena di regole morte insegna al team che la lista è decorazione. Check: la lista attiva e le sue età, ogni retro.

12. "La retro si apre con la scorecard." Primi cinque minuti, prima dei nuovi topic: ogni accordo attivo, il suo numero e se si è mosso. Questo è il loop shipping and sticking invece di shipping and evaporating. Check: è il primo punto dell'agenda, ogni retro.

Etichetta il Codice, Mai il Programmatore

Diversi di questi accordi tracciano se una modifica è stata scritta da una macchina. Nessuno di essi traccia chi si è appoggiato al modello, e questa distinzione sostiene l'intero sistema. I dati a livello di modifica descrivono come il processo del team gestisce un nuovo tipo di codice. I dati a livello di persona diventano una classifica, e una classifica corrompe ogni numero che mostra: nel momento in cui gli ingegneri sospettano che il rapporto degli incident alimenti una valutazione delle prestazioni, smettono di etichettare onestamente, e la retro torna a funzionare a sensazioni.

Questo è lo stesso argomento che abbiamo fatto riguardo alla misurazione dell'impatto dell'AI in generale: misura i risultati a livello di team, mai l'attività a livello di persona. Gli accordi sopra funzionano solo perché tutti nella stanza sanno che i numeri giudicano il processo, non le persone.

Come Adottarli Senza Ucciderli

Adottane due o tre, non dodici. Un team che mantiene dodici nuove regole non ne controlla nessuna; il menu esiste perché tu possa abbinare gli accordi ai tuoi numeri peggiori.

• Parti dai tuoi dati, non da questo post. Se il churn è stabile ma gli incident stanno aumentando, vuoi l'8 e il 9, non il 6 e il 7. Estrai i numeri prima della retro e lascia che scelgano loro.
• Vota nella retro. Un accordo imposto da un manager è una policy travestita — ottiene conformità, non ownership. Il team che ha scritto la regola è il team che la difende sotto scadenza.
• Registra la baseline all'adozione. "Merge senza review: 14 nello sprint scorso" trasforma il primo check-in in un confronto invece che in un dibattito. Nessuna baseline? Allora trovarla è il primo action item.
• Assegna a ogni accordo un owner. Non un esecutore — un reporter. Una persona porta il numero alla retro così lo scorecard non dipende mai dalla memoria collettiva.

FAQ

Quanti working agreement dovrebbe avere un team alla volta?

Due o tre accordi attivi alla volta. Ognuno richiede un numero estratto, un check-in tenuto e un owner che riporta, e quel budget di attenzione si esaurisce velocemente. I team che adottano una lunga lista non ne controllano nessuno; i team che ne adottano tre e li ritirano o sostituiscono alla scadenza costruiscono l'abitudine che rende i prossimi tre economici.

Le pull request dovrebbero essere etichettate come generate dall'AI?

Sì, a livello di modifica — un'etichetta o una nota nella descrizione della PR è sufficiente per rendere calcolabili i rapporti di churn e incident. Mai a livello di persona: il tracciamento dell'uso dell'AI per ingegnere corrompe i dati che raccoglie, perché le persone manipolano qualsiasi cosa venga osservata. La domanda utile è come il processo gestisce le modifiche scritte da macchine, non chi le ha prodotte.

E se il numero non si muove?

Allora il check-in ha funzionato. O la regola non è stata seguita, il che di solito significa che era troppo costosa come scritta e necessita di rinegoziazione, oppure è stata seguita e non ha aiutato, il che significa ritirarla e spendere l'attenzione altrove. Un accordo che può fallire visibilmente è l'unico tipo che può avere successo in modo credibile.

Funzionano senza sprint?

Sì. I check-in si collegano a qualsiasi ritmo di riflessione abbia il team — settimanale, per release o guidato da eventi. La cadenza conta meno del luogo: un momento ricorrente in cui i numeri sono sulla lavagna e al team è permesso cambiare le regole.

Il Punto Fondamentale

L'argomento della retro post-sbornia era che il debito tecnico da vibe-coding è un fallimento del processo, e la retrospettiva è dove il processo viene rinegoziato. Questa è l'altra metà: ciò che esce da quella stanza deve essere falsificabile, o la prossima retro lo ridiscute da zero. I team che superano la sbornia non sono quelli con le regole AI più rigide o più permissive. Sono quelli che scrivono regole che possono perdere un dibattito con i dati — e le lasciano perdere.

Rubane tre. Imposta la scadenza. Apri la prossima retro con lo scorecard.

Fonti

• Faros AI — "Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (aprile 2026)
• DORA — State of AI-assisted Software Development 2025 (settembre 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — "New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment" (maggio 2026)
• Stack Overflow — 2025 Developer Survey results (dicembre 2025)
• Autonoma — "Vibe Coding Technical Debt: The 90-Day Reckoning" (aprile 2026)

Letture Consigliate

• The Retro for the Vibe-Coding Hangover — la retrospettiva da cui proviene questo regolamento.
• Why 2/3 of Retrospective Action Items Die (And How to Fix It) — le meccaniche di follow-through dietro gli accordi 11 e 12.
• Measuring What AI Actually Does to Your Team — l'argomento di misurazione a livello di team, neutrale rispetto all'AI, nella sua interezza.
• Ship and Stick: How to Measure Whether AI Is Actually Working — lo standard di risultato su cui lo scorecard si chiude.