Dall’uso individuale dell’AI a un processo di team più prevedibile

A un team serve più della semplice velocità di coding

Un team software dipende da molto più della velocità con cui viene prodotto il codice. Conta anche quanto il lavoro è prevedibile, quanta review richiede, quante correzioni servono dopo le modifiche generate, quanto facilmente queste si integrano nel sistema esistente e con quale affidabilità il team riesce a trasformare un obiettivo in software realmente rilasciabile.

L’AI modifica alcune di queste variabili. Ma quando ogni developer la usa attraverso un processo completamente diverso può anche renderle più difficili da comprendere. Un team può produrre codice più velocemente e creare contemporaneamente un nuovo collo di bottiglia nella review, nei test, nel debugging o nell’integrazione.

Produrre più codice non significa automaticamente riuscire a rilasciare più software utile.

I team software hanno già ridotto questo tipo di variabilità in passato

Lo sviluppo software ha sempre richiesto giudizio individuale, ed è giusto che sia così. Quello che il settore ha progressivamente ridotto è la variabilità accidentale: differenze nel modo di lavorare che complicano la collaborazione senza portare un vantaggio reale.

I framework moderni hanno introdotto strutture e convenzioni condivise. Il controllo di versione ha creato un modo comune di gestire le modifiche. I test automatici hanno reso ripetibili alcune forme di verifica. CI/CD ha standardizzato molte attività di integrazione e deployment. Issue tracking, pratiche Agile, DevOps e metriche sul flusso di lavoro hanno aiutato i team a capire meglio come avanza un progetto.

Nessuno di questi strumenti ha reso uniforme lo sviluppo software. Lo ha reso più osservabile e più semplice da coordinare. Un developer che entra in un progetto deve comunque comprenderne dominio e architettura, ma idealmente non dovrebbe anche decifrare un sistema completamente personale per sviluppare, verificare e rilasciare software.

L’AI aggiunge una nuova fonte di variabilità nel lavoro del team

Lo stesso task di implementazione può oggi essere affrontato in modi molto differenti. Uno sviluppatore può delegare l’intera attività, un altro soltanto alcune parti. All’agente può essere consentito di modificare molti file oppure un’area precisamente delimitata. Il codice esistente può essere considerato qualcosa da preservare oppure qualcosa che il modello è libero di ristrutturare. La verifica può avvenire dopo ogni piccola modifica oppure soltanto al termine di un insieme molto più ampio di cambiamenti.

Dal punto di vista individuale, i developer possono adattare queste scelte alla propria esperienza e al proprio modo di lavorare. A livello di team, però, le conseguenze incidono su pianificazione, review, integrazione e quantità di lavoro necessaria prima che una modifica possa essere accettata.

• quantità di modifiche generate e lavoro di review
• correzioni, regressioni e debugging
• documentazione e rischio di integrazione
• quantità di intervento umano necessaria prima dell’accettazione

Standardizzare non significa obbligare tutti a usare gli stessi prompt o a delegare la stessa percentuale di lavoro. La domanda utile è se il team dispone di regole condivise sufficienti per sapere cosa viene delegato, cosa deve restare invariato, come verrà verificato il risultato e quando è necessario l’intervento umano.

Da strumento di produttività personale a capacità ripetibile del team

Questa distinzione diventa particolarmente importante quando si pianifica il lavoro. Se un team scopre ripetutamente che una determinata categoria di task ben delimitati beneficia davvero del supporto dell’AI, può iniziare a raccogliere dati su ciò che cambia concretamente.

• tempo di completamento per tipologia di task
• lavoro di review e correzione
• tasso di difetti e verifiche fallite
• frequenza dell’intervento umano
• attività che beneficiano stabilmente della delega
• attività nelle quali l’AI crea più lavoro aggiuntivo che valore

Queste misure non creeranno mai una formula perfetta per prevedere lo sviluppo software, e non devono farlo. Le stime sono previsioni costruite sulle informazioni disponibili e vanno aggiornate quando emergono nuovi dati. L’AI può diventare parte di queste informazioni, ma soltanto se il suo effetto è abbastanza osservabile. Altrimenti ‘usiamo l’AI’ rimane una variabile sconosciuta all’interno del progetto.

Standardizzare il processo, non il developer

I team avranno probabilmente sempre più bisogno di alcune regole condivise per lo sviluppo assistito dall’AI. Questo non significa che ogni developer debba lavorare nello stesso modo e certamente non significa che ogni task di implementazione debba essere delegato all’AI.

Un processo utile dovrebbe invece rendere espliciti alcuni elementi: il risultato atteso, la parte del codice che può cambiare, il comportamento esistente che deve rimanere intatto, i controlli richiesti prima di considerare il lavoro completato, le situazioni nelle quali l’AI deve fermarsi e le attività che è più sensato svolgere direttamente.

Questi confini rendono il lavoro assistito dall’AI più semplice da revisionare e permettono al team di imparare nel tempo. E soprattutto mantengono una responsabilità chiara: requisiti, architettura, strategia di implementazione, decisioni tecniche, qualità e accettazione finale restano nelle mani delle persone che costruiscono il sistema. L’AI è uno strumento a disposizione del team, non la proprietaria del progetto.

Perché riguarda anche il Technical Project Management

Un nuovo progetto software viene normalmente analizzato prima che inizi l’implementazione. Si chiariscono obiettivi e vincoli, si discutono i requisiti, le figure tecniche contribuiscono alle decisioni su stack e architettura, il lavoro viene suddiviso, si individuano le dipendenze e iniziano a prendere forma piani e previsioni di rilascio mantenendo esplicito il margine di incertezza.

Se l’AI cambia la capacità reale del team di sviluppo, prima o poi deve entrare anche in questa conversazione. Ma non basta ragionare dicendo semplicemente che ‘adesso gli sviluppatori sono più veloci’.

La domanda più utile è: dove l’AI produce un vantaggio ripetibile e cosa cambia per implementazione, review, verifica, coordinamento, manutenzione e debito tecnico? Solo a quel punto il suo effetto può iniziare a informare stime e pianificazione del progetto.

L’obiettivo non è massimizzare il codice prodotto. L’obiettivo è avanzare in modo sostenibile verso software che possa davvero essere revisionato, integrato e rilasciato.

Perché ho iniziato a lavorare su TCAF

Questo problema è uno dei motivi per cui ho iniziato a sviluppare TCAF — Task-Contract AI Development Framework.

TCAF fornisce regole condivise per delegare all’AI attività selezionate all’interno del normale lavoro di sviluppo software. L’idea non è affidare l’intero progetto a un agente autonomo. Developer e team continuano a decidere cosa costruire, come deve evolvere il sistema e quali attività abbia realmente senso delegare.

Quando un’attività viene delegata, il Task Contract rende espliciti risultato atteso, area autorizzata alla modifica, comportamento da preservare, controlli richiesti e condizioni nelle quali lo strumento deve fermarsi. Alcune attività continueranno ad avere più senso se realizzate direttamente; anche questo fa parte dell’approccio.

L’obiettivo non è fare in modo che gli sviluppatori scrivano meno codice. È rendere il lavoro assistito dall’AI abbastanza controllato da poter essere revisionato, misurato, compreso nel tempo e progressivamente incluso nella normale pianificazione e nello sviluppo professionale.

Sviluppare più velocemente serve soltanto se il team riesce comunque a revisionare, integrare e rilasciare in sicurezza

L’AI sta già cambiando lo sviluppo software. Il prossimo passo importante non consiste semplicemente nell’aumentare la quantità di codice generato dall’AI. La sfida più interessante è integrare questa capacità nel modo in cui i team pianificano, sviluppano, verificano, coordinano e mantengono il software.

Se lo sviluppo assistito dall’AI diventa abbastanza osservabile e coerente, i team possono iniziare a capire dove produce davvero un vantaggio e dove invece non lo produce. Questa conoscenza può migliorare pianificazione, stime, coordinamento e decisioni future di progetto.

È a quel punto che l’AI smette di essere soltanto uno strumento di produttività individuale e diventa una parte più prevedibile del processo di sviluppo del team.