Indice
Il codice arriva prima. Il valore potrebbe arrivare dopo
Uno sviluppatore completa in poche ore una modifica che, in precedenza, avrebbe richiesto diversi giorni. Il codice è pronto, la pull request viene aperta e il primo segnale sembra positivo: l’intelligenza artificiale ha accelerato il lavoro.
Poi comincia la revisione. Emergono un requisito interpretato male, una dipendenza trascurata, una scelta incoerente con il resto dell’applicazione. La modifica torna indietro. Lo sviluppatore riapre la conversazione con l’agente, chiede una correzione e produce una nuova versione. Seguono altre osservazioni, altri interventi e nuovi controlli.
Quanto tempo è stato davvero risparmiato?
È il problema al centro della conversazione tra Alex Pagnoni e Riccardo Tartaglia di Artiforge, ospite di Pionieri del Tech. La distinzione proposta da Tartaglia riguarda due risultati spesso sovrapposti: la rapidità con cui una persona genera codice e la capacità di un team di consegnare valore all’azienda e ai clienti.
Le due cose possono migliorare insieme, ma il collegamento va costruito. Una maggiore capacità di implementazione non risolve automaticamente i problemi che precedono o seguono la scrittura: comprensione della richiesta, decisioni tecniche, coordinamento, verifica e manutenzione.
Per chi guida un’organizzazione tecnologica, il punto è osservare il percorso completo del cambiamento. L’accelerazione locale è utile quando contribuisce a un risultato che il resto del sistema riesce ad assorbire.
Il collo di bottiglia può spostarsi verso la review
Nell’intervista, Tartaglia propone un esempio: una modifica realizzata rapidamente grazie all’AI può richiedere diversi cicli di revisione prima di essere accettata. Il tempo guadagnato durante l’implementazione viene così consumato a valle.
La pull request è il momento in cui molte scelte diventano visibili agli altri. A quel punto, però, sono già state tradotte in codice. Se il problema nasce da un’interpretazione sbagliata del requisito o da una decisione architetturale non condivisa, la review deve intervenire su qualcosa che è stato costruito su una premessa fragile.
Questo non rende la revisione meno importante. Evidenzia invece il costo di affidarle anche il compito di scoprire tardivamente errori che potevano essere discussi prima.
Un team che introduce strumenti di AI coding dovrebbe quindi chiedersi dove stia aumentando il lavoro. Più pull request possono indicare una maggiore capacità produttiva, ma possono anche creare una coda che richiede attenzione, chiarimenti e correzioni. Il numero di contributi aperti, da solo, non permette di distinguere le due situazioni.
La domanda utile diventa: quanto tempo passa dalla comprensione di una richiesta alla disponibilità di un cambiamento verificato? E quanta parte di quel tempo viene assorbita da attese o rilavorazioni?
La chat funziona. Il processo deve poterle sopravvivere
Una delle precisazioni più rilevanti dell’intervista riguarda l’interfaccia conversazionale. Tartaglia non considera la chat sbagliata in sé. Ne mette in discussione l’impiego come contenitore indistinto di tutte le fasi del lavoro.
Per un’attività circoscritta, una conversazione può essere efficace. Lo sviluppatore formula una richiesta, riceve una proposta, la valuta e procede. La difficoltà emerge quando la stessa conversazione incorpora analisi, requisiti, alternative, decisioni e tentativi di implementazione senza separare chiaramente ciò che è stato esplorato da ciò che è stato approvato.
Chi ha condotto la sessione può ricordare perché una strada è stata abbandonata. Un collega che arriva dopo vede invece una sequenza di messaggi, nella quale non è sempre immediato riconoscere la decisione ancora valida.
Il problema diventa più evidente quando il lavoro passa a un’altra persona, cambia il modello utilizzato o viene ripreso dopo settimane. La continuità dipende allora dalla capacità di ricostruire il ragionamento, spesso chiedendo spiegazioni al suo autore.
Una conversazione utile dovrebbe lasciare risultati riconoscibili: una specifica, una decisione tecnica, un piano, un elenco di vincoli o una verifica. Questi elementi permettono al lavoro di proseguire anche al di fuori della sessione che li ha prodotti.
Dieci sviluppatori, dieci processi impliciti
Tartaglia descrive il caso di un team in cui ogni sviluppatore utilizza l’AI secondo abitudini personali. Il problema non è il numero delle conversazioni. È la presenza di molti modi diversi, e poco visibili, di affrontare lo stesso tipo di attività.
Una persona può iniziare chiedendo un piano. Un’altra può passare direttamente all’implementazione. Una terza può usare istruzioni locali molto dettagliate, che i colleghi non conoscono. Tutte possono ottenere risultati individualmente validi, mentre il team fatica a capire quali passaggi siano stati eseguiti e quali informazioni siano state considerate.
Questo non implica che tutti debbano usare gli stessi prompt. Nell’intervista, Tartaglia difende uno spazio di libertà nell’esecuzione: competenze e preferenze personali hanno un ruolo nel modo in cui uno sviluppatore lavora con l’AI.
L’esigenza di coordinamento riguarda soprattutto ciò che deve essere comune. Qual è il problema da risolvere? Quali vincoli sono stati riconosciuti? Esiste una specifica? È stato concordato un piano? Quali decisioni sono già state prese?
La standardizzazione più utile è quella che rende queste risposte disponibili, lasciando libertà dove le differenze individuali non compromettono il lavoro degli altri.
Governance come disponibilità delle informazioni
La parola governance può evocare procedure, autorizzazioni e documenti lontani dal lavoro quotidiano. Nella puntata assume un significato operativo: disporre delle conoscenze necessarie nel momento in cui servono.
Per lo sviluppatore, significa capire il contesto della modifica prima di intervenire. Per il Tech Lead, significa sapere se il lavoro sta seguendo una direzione condivisa. Per il CTO, significa poter ricostruire come vengono utilizzati strumenti e modelli, e quali costi accompagnano le attività.
Questa impostazione sposta l’attenzione dalla quantità di regole alla qualità delle informazioni. Una procedura ha valore se rende più semplice decidere, verificare o coordinarsi. Se aggiunge un’approvazione senza migliorare nessuna di queste capacità, il suo costo resta da giustificare.
Tartaglia lega la governance alla riduzione del lavoro ripetuto. Quando ogni sviluppatore deve ricostruire il contesto, riformulare lo stesso problema o ottenere nuovamente una decisione già presa, il team paga più volte per produrre la stessa conoscenza.
La velocità sostenibile può quindi nascere dalla continuità: meno ripartenze, meno interpretazioni divergenti e meno correzioni dovute a informazioni che esistevano, ma non erano accessibili.
Gli artefatti condivisi collegano le fasi del lavoro
Nel raccontare l’approccio di Knotic, Tartaglia descrive strumenti distinti per brainstorming, pianificazione ed esecuzione. Il passaggio centrale è la produzione di output strutturati che possano essere conservati e condivisi nel repository.
L’interesse di questo modello va oltre il prodotto. Una specifica rende esplicito il risultato atteso. Un piano traduce quel risultato in attività e dipendenze. Una decisione architetturale conserva il motivo di una scelta. La verifica stabilisce quali evidenze permettono di considerare concluso il lavoro.
Quando questi elementi sono collegati, un collega può riprendere un’attività senza chiedere al proprio agente di ricostruire tutto da zero. Il punto di partenza diventa comune, anche se le persone e gli strumenti coinvolti cambiano.
Durante l’intervista, Tartaglia usa l’espressione “determinismo nell’indeterminismo” per descrivere questa ricerca di maggiore controllo. Il significato operativo è delimitare il processo: rendere espliciti i passaggi e ridurre la variabilità introdotta da pianificazioni indipendenti dello stesso problema.
Una base comune, tuttavia, non equivale a una garanzia di correttezza. Un piano condiviso può contenere errori e una specifica può essere incompleta. La governance deve prevedere anche come contestare e aggiornare quegli artefatti quando emergono nuove informazioni.
Conservare una decisione è utile se il team riesce anche a capire quando non è più valida.
La memoria del progetto deve spiegare il comportamento del software
Il codice racconta ciò che il sistema fa. Per chi deve modificarlo, è altrettanto importante comprendere come quel comportamento si colleghi alle regole di business e agli altri flussi dell’applicazione.
Tartaglia insiste su questa differenza quando parla della memoria del progetto. Sapere che un file contiene una funzione è un primo livello di conoscenza. Capire come quella funzione partecipi, per esempio, al login richiede una visione più ampia: dipendenze, condizioni, passaggi e conseguenze.
Questo tema diventa decisivo nell’onboarding. Un nuovo sviluppatore può orientarsi più facilmente quando trova una rappresentazione comprensibile dei flussi, invece di dover ricostruire ogni relazione inseguendo le persone più esperte.
Anche qui serve una distinzione. L’analisi del repository può aiutare a descrivere il comportamento esistente. Non può garantire, da sola, di recuperare tutte le motivazioni storiche che hanno portato a quel comportamento. Alcune possono dipendere da accordi, vincoli organizzativi o discussioni mai documentate.
Una memoria utile dovrebbe quindi distinguere ciò che è stato osservato nel codice, ciò che è stato inferito e ciò che è stato confermato dalle persone responsabili del progetto. Questa separazione evita che una spiegazione plausibile venga trattata come una decisione certa.
Human-in-the-loop: responsabilità prima e dopo l’implementazione
Tartaglia esprime una posizione netta sull’automazione completa: nella sua visione, lo sviluppatore deve conservare un ruolo centrale sia nel ragionamento tecnico sia nella revisione.
Il tema è più ampio della presenza di un’approvazione finale. Una persona può essere formalmente coinvolta e limitarsi comunque ad accettare le proposte dell’agente senza comprenderle. In quel caso il controllo esiste come gesto, ma perde sostanza.
La responsabilità umana richiede informazioni e tempo. Chi approva deve poter confrontare il risultato con l’esigenza iniziale, capire i compromessi e riconoscere gli aspetti che non sono stati verificati.
Nell’intervista, Tartaglia distingue la capacità di produrre codice dalla capacità di tradurre un bisogno aziendale in una soluzione. Attribuisce alle persone la responsabilità di questa traduzione e considera l’AI uno strumento per implementarla più rapidamente.
È una posizione dell’ospite, non una dimostrazione che ogni attività autonoma sia inappropriata. Per un’organizzazione, il problema concreto è stabilire quali deleghe siano compatibili con il rischio del cambiamento e quali decisioni richiedano un coinvolgimento esplicito.
Un intervento circoscritto e facilmente reversibile può richiedere controlli diversi rispetto a una modifica dei permessi o a una trasformazione dei dati. La governance rende queste differenze riconoscibili.
Passare i test non esaurisce la verifica
La conversazione affronta anche l’idea di affidare agli agenti la revisione del codice generato da altri agenti. Tartaglia manifesta cautela, soprattutto sul confronto tra implementazione e specifiche iniziali.
Il punto da preservare è la distinzione tra comportamento verificato e completezza della verifica. Un test che passa dimostra che, nelle condizioni previste da quel test, il risultato è quello atteso. Rimane da stabilire se quelle condizioni rappresentino davvero il problema.
Quando implementazione e controlli condividono la stessa interpretazione incompleta del requisito, possono risultare coerenti tra loro senza soddisfare l’esigenza aziendale.
Per questo i criteri di accettazione devono poter essere discussi indipendentemente dalla soluzione proposta. La review deve avere la possibilità di mettere in discussione le premesse, oltre a esaminare la correttezza locale del codice.
L’automazione può contribuire anche alla verifica. La decisione organizzativa riguarda quali evidenze siano sufficienti per accettare una modifica e chi abbia la responsabilità di valutarle. Nessuno strumento elimina la necessità di definire questa soglia.
Il legacy rende più evidente il valore del contesto
Nei progetti nuovi, molte decisioni sono ancora da prendere. Nei sistemi esistenti, una parte rilevante del lavoro consiste nel riconoscere decisioni e vincoli già incorporati nell’applicazione.
La distinzione emerge quando Pagnoni chiede a Tartaglia come cambi l’uso dell’AI tra sviluppo greenfield e codice legacy. L’ospite richiama la presenza di dipendenze storiche e di conoscenze che possono essersi disperse con l’uscita di persone dall’azienda.
In questi casi, un’implementazione localmente ragionevole può essere incompatibile con aspettative consolidate altrove. Il problema non è soltanto trovare i file da modificare, ma capire quali comportamenti debbano restare stabili.
Gli strumenti di analisi e memoria possono aiutare a esplorare il sistema e a rendere più accessibili le relazioni tra le sue parti. Il loro contributo va però accompagnato dalla verifica delle interpretazioni, soprattutto quando il codice rappresenta solo una parte della conoscenza necessaria.
La disponibilità di più contesto è utile quando riduce l’incertezza pertinente alla modifica. Accumulare documenti senza distinguere versioni, validità e responsabilità può invece introdurre nuove ambiguità.
Il costo dell’AI va ricostruito per attività
Tra le domande finali proposte da Tartaglia ce n’è una economica: il team sa ricostruire quanto costa svolgere un’attività con l’AI, includendo il tempo umano?
La spesa del modello è una componente visibile, ma non esaurisce il conto. Un’attività può richiedere preparazione del contesto, interazioni ripetute, revisione, correzioni e verifiche. Un output economico da generare può risultare costoso da rendere utilizzabile.
Nella puntata, Tartaglia suggerisce inoltre che un contesto ben strutturato possa consentire l’impiego di modelli meno costosi in alcune attività. È un’ipotesi operativa da verificare sul lavoro reale, evitando di assumere che valga allo stesso modo per ogni task.
Per valutare il beneficio complessivo, il team può osservare insieme tempo di implementazione, attesa in review, numero e natura delle rilavorazioni, qualità del risultato e spesa degli strumenti.
Questa è un’estensione pratica del ragionamento sviluppato nell’intervista: il confronto deve riguardare il costo di ottenere un cambiamento accettabile, non soltanto quello della sua prima generazione.
Prima dello strumento, tre domande sul proprio processo
Nella parte conclusiva, Tartaglia suggerisce di partire dalla conoscenza del lavoro già in corso.
La prima domanda riguarda le fasi dello sviluppo. Il team sa descrivere come una richiesta diventa un’analisi, una specifica, un piano e infine un’implementazione verificata? Senza questa mappa è difficile capire dove l’AI stia aiutando e dove stia introducendo attrito.
La seconda riguarda l’utilizzo effettivo degli strumenti. Quali istruzioni sono condivise? Quali restano personali? Quali differenze dipendono da scelte consapevoli e quali dalla semplice assenza di coordinamento?
La terza riguarda il costo dell’attività. Il team riesce a collegare l’uso dell’AI al lavoro umano necessario per completare un ticket?
Sono domande applicabili anche senza cambiare ambiente di sviluppo. Permettono di individuare il problema prima di valutare una soluzione.
Un punto di partenza concreto è ricostruire una feature recente: requisito iniziale, contesto fornito all’agente, decisioni prese, modifiche prodotte e verifiche effettuate. I passaggi difficili da ricostruire mostrano dove la conoscenza rimane implicita.
La velocità sostenibile lascia un progetto comprensibile
L’intervista con Riccardo Tartaglia porta il dibattito sull’AI coding dentro il lavoro quotidiano dei team. La capacità di generare codice acquista valore quando si collega a decisioni comprensibili, conoscenze trasferibili e verifiche adeguate.
Il risultato riguarda anche ciò che rimane dopo la consegna. Una feature che funziona ma che nessuno sa spiegare crea un problema per il cambiamento successivo. Un processo che conserva contesto e responsabilità rende invece più semplice continuare a lavorare.
Una domanda permette di mettere alla prova questa differenza: un’altra persona riuscirebbe a riprendere domani il lavoro svolto oggi con l’AI, comprendendo che cosa è stato deciso e perché?
La risposta dice molto sulla maturità del processo. E sul valore che il team riesce a trattenere quando la conversazione con l’agente è finita.
