Dall’uso individuale dell’AI a un processo di team governabile

Velocità locale e capacità di delivery non sono la stessa cosa

La software delivery dipende da molto più della velocità con cui viene prodotto il codice. Review, regressioni, debugging, rischio di integrazione, manutenibilità e readiness al rilascio fanno parte del costo reale di una modifica.

L’AI può ridurre il tempo di implementazione e aumentare il lavoro altrove. Una diff molto ampia può essere veloce da produrre e lenta da revisionare. Un refactoring esteso può sembrare efficiente localmente e introdurre rischio per il resto del team.

L’unità utile non è quindi il codice generato, ma il lavoro accettato e verificato che può avanzare nel progetto in sicurezza.

I team governano già la variabilità in molte parti dello sviluppo

Version control, test automatici, CI/CD, convenzioni di codice, issue tracking e pratiche Agile non hanno eliminato il giudizio del developer. Hanno ridotto la variabilità accidentale nei punti in cui un processo condiviso rende più semplice collaborare.

L’AI introduce un’esigenza simile. L’obiettivo non è imporre a tutti lo stesso modello, gli stessi prompt o la stessa percentuale di delega. Serve rendere abbastanza visibili le conseguenze del lavoro delegato da poterle gestire come parte della delivery.

Cosa deve diventare esplicito

Un workflow AI governabile parte dal rendere espliciti pochi elementi prima che l’esecuzione si allarghi.

• risultato atteso e criteri di accettazione
• area del repository autorizzata alla modifica
• comportamento esistente da preservare
• controlli richiesti ed evidenze di verifica
• condizioni che devono fermare o far escalare il task
• review del developer e accettazione finale

Questi vincoli non sostituiscono il giudizio tecnico. Creano un confine operativo comune attorno al lavoro delegato, mantenendo architettura, strategia di implementazione e responsabilità tecnica nelle mani del developer e del team.

Perché conta per stime e project management

Se ogni developer usa l’AI con un workflow diverso, il project management vede il risultato ma ha poche basi per capire quanto sia ripetibile. Un task può chiudersi rapidamente con quasi nessuna correzione; un altro può sembrare veloce finché non si includono review, regressioni e rilavorazioni.

Confini condivisi e verifica esplicita rendono questi risultati più confrontabili. Nel tempo il team può osservare dove l’AI riduce davvero l’effort e dove invece lo sposta dall’implementazione alla review o al recupero.

• cycle time per categoria di task
• effort di review e correzione
• verifiche fallite e regressioni
• frequenza dell’intervento umano
• rilavorazioni dopo l’integrazione
• categorie di task che beneficiano stabilmente della delega

Questo non rende le stime software una scienza esatta. Offre però una base di evidenze migliore ed evita che l’AI rimanga un moltiplicatore indefinito dentro il piano di progetto.

Lo spec-driven aiuta, ma la specifica da sola non basta

Una specifica chiara è un ottimo punto di partenza perché riduce l’ambiguità su ciò che deve essere costruito. Ma il controllo del progetto dipende anche da cosa l’AI è autorizzata a modificare, quale stato del repository fa fede, cosa deve essere preservato e come viene verificato il completamento.

Per questo considero lo Spec-Driven Development una parte di un problema più ampio di software delivery governance, non la soluzione completa.

TCAF trasforma questi principi in un framework operativo

TCAF — Task-Contract AI Development Framework — è il framework pubblico che ho costruito attorno a questo problema. Combina Spec-Driven Development, Harness Engineering e Software Delivery Governance.

Le evidenze del repository definiscono lo stato reale. Il Task Contract definisce obiettivo, perimetro autorizzato, vincoli e aspettative di verifica del task delegato. Le regole preservation-first riducono riscritture inutili, mentre review del developer e verifica esplicita restano parte dell’accettazione.

Il framework è volutamente model-agnostic: il team mantiene flessibilità sugli strumenti, condividendo però le regole operative che contano per la delivery.

L’obiettivo è una capacità di team, non usare più AI

Il punto non è massimizzare la delega o far scrivere meno codice ai developer. Un task che è più chiaro e sicuro da implementare direttamente va semplicemente implementato direttamente.

Il risultato utile è un team che sa dove l’AI porta valore, delega entro confini espliciti, produce evidenze revisionabili e usa ciò che impara per migliorare pianificazione, stime e decisioni di delivery.

L’AI diventa utile alla delivery quando il team riesce a governarne gli effetti

L’AI può aumentare la capacità di implementazione, ma il valore di progetto emerge soltanto quando il lavoro prodotto resta comprensibile, revisionabile, verificabile e rilasciabile.

Un metodo operativo comune riduce la distanza tra sperimentazione individuale e delivery di team. Lascia libertà tecnica dove serve, ma rende più coerenti perimetro, evidenze e accettazione all’interno del progetto.

L’obiettivo non è rendere uniformi i developer. È avere un sistema di delivery condiviso in cui il lavoro con AI sia delimitato, osservabile e attribuibile.