La Retro per i Postumi della Programmazione a Sensazione

Da qualche parte nel tuo codebase c'è un modulo che nessuno vuole toccare. È stato rilasciato a marzo, velocemente, con un assistente AI che ha fatto la maggior parte della digitazione. Funzionava nella demo. È stato riscritto due volte da allora, compare nelle timeline degli incident e l'ingegnere che lo ha "scritto" non riesce a spiegarlo completamente.

Quel modulo ora ha un nome. L'industria ha passato il 2025 a discutere se gli strumenti di coding AI rendano i team più veloci. Nel 2026 la discussione è finita e la fattura è arrivata — non in dollari, ma in churn, code di review e canali di incident. Autonoma lo chiama il "reckoning dei 90 giorni": il punto in cui la velocità del primo mese diventa il debito del terzo mese. Gizmodo ha riportato lo scorso settembre che le aziende stanno assumendo ingegneri specificamente per correggere i pasticci del vibe-coding. Un'intera economia di pulizia si sta formando attorno a un problema che la maggior parte dei team potrebbe intercettare da sola, quattro sprint prima, in una cerimonia che hanno già in calendario.

Questo post riguarda come eseguire quella cerimonia correttamente.

Il Postumi È Misurabile

Il contraccolpo non è una sensazione. L'AI Engineering Report 2026 di Faros AI — due anni di telemetria da 22.000 sviluppatori in oltre 4.000 team — ha messo numeri su entrambe le metà: l'accelerazione che tutti hanno celebrato e il deterioramento che l'ha seguita a valle.

Fonte: Faros AI, "AI Engineering Report 2026," aprile 2026.

Leggi le prime due righe e l'AI sta funzionando. Leggi le ultime cinque e puoi vedere il postumi formarsi in tempo reale: il codice viene buttato via quasi nove volte più spesso, gli incident per PR sono più che triplicati e quasi un terzo in più di modifiche raggiunge la produzione senza che un singolo umano le legga.

Il report DORA 2025, ora rinominato "State of AI-Assisted Software Development," ha trovato la stessa forma su scala di survey: il 90% degli sviluppatori usa l'AI al lavoro, in aumento dal 76% dell'anno precedente, e l'adozione dell'AI è ora positivamente collegata al throughput. Ma "continua ad avere una relazione negativa con la stabilità della consegna del software." Più veloce e più instabile, allo stesso tempo, in tutta l'industria.

Questo È un Fallimento di Processo, Non di Strumento

L'AI ha fatto esattamente ciò che le è stato chiesto di fare. Ha prodotto codice plausibile a una velocità per cui nessun processo di review era progettato. Ciò che è fallito è stato tutto ciò che lo circondava: nessuno ha deciso quanta verifica merita un diff scritto da una macchina, quale dimensione di batch mantiene onesta la review o chi possiede il codice che nessun umano ha scritto.

Questi sono accordi di lavoro. Gli accordi di lavoro sono processo. E le evidenze dicono che il processo è precisamente dove si trova la leva. Il Modello di Capacità AI di DORA identifica sette condizioni che determinano se l'AI amplifica un team o amplifica la sua disfunzione — e sono tutte organizzative: una posizione AI chiara e comunicata, pratiche solide di controllo versione, lavorare in piccoli batch, ecosistemi di dati sani. Nessuna di esse è "compra un modello migliore."

Il report ROI 2026 di DORA ha aggiunto il lato dei costi. I team che adottano l'AI incontrano una curva a J (la produttività cala prima di salire), e un fattore principale è ciò che il report chiama la tassa di verifica: le ore umane spese a controllare l'output della macchina. Il survey 2025 di Stack Overflow su oltre 49.000 sviluppatori spiega perché quella tassa è così alta. La fiducia nell'accuratezza dell'AI è scesa dal 40% al 29% in un anno, e la frustrazione numero uno, citata dal 45% dei rispondenti, è "soluzioni AI che sono quasi giuste, ma non del tutto." Il codice quasi-giusto è il tipo più costoso. Il codice sbagliato fallisce velocemente; il codice quasi-giusto passa la review e fallisce in produzione.

Un problema di strumento avrebbe una soluzione di strumento. Un problema di accordi di lavoro ha esattamente una sede dove i team rinegoziare come lavorano.

Cos'È una Retro del Postumi del Vibe-Coding?

Una retro del postumi del vibe-coding è una retrospettiva che esamina come il tuo team produce codice con l'AI, non solo cosa ha rilasciato. Sostituisce le opinioni con i dati di consegna del team stesso — churn del codice, latenza di review, collegamenti a incident, merge non revisionati — e il suo output è un piccolo insieme di accordi di lavoro per le modifiche scritte da macchine, ciascuno misurabile nello sprint successivo.

Differisce dalla tua retro regolare per ambito, non per formato. Una retro normale chiede "com'è andato lo sprint?" Questa pone una domanda più precisa: "qual è la nostra relazione effettiva con il codice che non abbiamo scritto?" Stessi template, stesso voto, stesso timebox. Evidenze diverse sul tavolo.

E dovrebbe accadere presto, non eventualmente. I dati di Faros dicono che il deterioramento si accumula: il churn alimenta gli incident, gli incident alimentano il carico di review, il carico di review alimenta la tentazione di unire senza review. Ogni sprint senza una correzione di rotta rende la correzione più grande.

Basarsi sui Dati, Non sulle Sensazioni

C'è una vera ironia nel tenere una retrospettiva sul vibe coding basandosi sulle sensazioni. Se la modalità di fallimento era "ci siamo fidati di output plausibili senza verifica," la cerimonia che la risolve non può a sua volta basarsi su impressioni plausibili. Le tue integrazioni contengono già le prove — i tuoi repository conoscono il churn, il tuo tracker conosce il rework, il tuo canale degli incident conosce la traccia.

Metti cinque domande sulla board, ciascuna ancorata a un numero che puoi recuperare prima del meeting:

1. Quali PR degli ultimi 90 giorni abbiamo già riscritto? Il churn è la misura onesta della velocità. Una feature che hai rilasciato due volte non è stata rilasciata velocemente.
2. Dove sta andando effettivamente la review? Se il tempo-alla-prima-review sta aumentando mentre i merge senza review aumentano con esso, il tuo processo di review si sta razionando silenziosamente. Decidi il razionamento intenzionalmente.
3. Quali incident risalgono a modifiche che nessuno ha letto completamente? Non per colpevolizzare: per dimensionare la tassa di verifica che stai già pagando nel momento peggiore possibile, in produzione.
4. Qual è il nostro accordo di lavoro per i diff scritti da macchine? Se la stanza non può esprimerlo in una frase, non ne hai uno. Hai una sensazione.
5. L'ultimo set di action item è rimasto? Due terzi degli action item delle retro muoiono. Se i tuoi lo hanno fatto, quella è la prima correzione. Nient'altro che decidi oggi conta se evapora entro giovedì.

Far Sopravvivere le Correzioni al Contatto con il Prossimo Sprint

L'output di questa retro non è un riassunto di sensazioni. Sono due o tre accordi di lavoro, ciascuno formulato in modo che i dati del prossimo sprint possano confermarlo o negarlo. Il pattern che funziona: una regola concreta, un numero che si muove se viene seguita, e un check-in nominato.

• "Le PR generate da agenti oltre 400 righe vengono divise prima della review." Check: distribuzione dimensione PR, prossima retro.
• "Niente merge senza un'approvazione umana, CI verde o no." Check: conteggio merge senza review, settimanale.
• "Ogni incident review chiede se la modifica scatenante era scritta da AI, e tracciamo il rapporto." Check: template postmortem incident, questa settimana.

Batch piccoli, review obbligatoria, tracciabilità degli incident — noterai che queste sono le capacità AI di DORA, tradotte in frasi su cui un team può effettivamente accordarsi di martedì. Questo è il punto. La ricerca nomina le capacità; la retro è dove un team le installa.

Poi il ciclo si chiude nel modo in cui abbiamo sempre sostenuto dovrebbe: la prossima retro si apre verificando se gli accordi hanno tenuto e se i numeri si sono mossi. Il churn è diminuito? La latenza di review si è ripresa? È rimasto? Il miglioramento che non puoi verificare è solo un'altra sensazione.

La Conclusione

I postumi non sono mai stati il prezzo dell'uso dell'AI. Sono il prezzo dell'adozione di un nuovo modo di costruire software senza mai sedersi come team a rinegoziare come si costruisce software. I team che stanno avanzando nel 2026 non sono quelli che usano più AI o meno. Sono quelli che hanno notato il colpo di frusta nei propri dati, hanno convocato il meeting e hanno scritto le regole — mentre tutti gli altri stavano ancora discutendo su quale sensazione fosse giusta.

Non hai bisogno di uno specialista della pulizia. Hai bisogno di novanta minuti e dei tuoi numeri.

Non meno AI. Più riflessione.

Fonti

• Faros AI — "Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash" (aprile 2026)
• DORA — State of AI-assisted Software Development 2025 e annuncio di Google Cloud (settembre 2025)
• DORA AI Capabilities Model (2025)
• InfoQ — "New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment" (maggio 2026)
• Stack Overflow — risultati del Developer Survey 2025 (dicembre 2025)
• Gizmodo — "After AI Led to Layoffs, Coders Are Being Hired to Fix 'Vibe-Coded' Screwups" (settembre 2025)
• Autonoma — "Vibe Coding Technical Debt: The 90-Day Reckoning" (aprile 2026)

Ulteriori Letture

• Why 2/3 of Retrospective Action Items Die (And How to Fix It) — il problema del follow-through da cui dipende questa retro.
• Measuring What AI Actually Does to Your Team — come vedere l'impatto reale dell'AI sul tuo team senza sorveglianza.
• Ship and Stick: How to Measure Whether AI Is Actually Working — il framework di risultato dietro "è rimasto?"
• Beyond Sprints: Continuous Improvement for AI-Native Teams — perché la cadenza di riflessione conta di più quando il deployment è continuo.