L’esatto Stack di Consegna AI che un CPO Usa per Ridurre il Rework del 25%
L’IA può generare codice in pochi secondi. Ma senza un’architettura, ti aiuta solo a spedire più velocemente la cosa sbagliata. In questa intervista, un CPO e Direttore dell’Ingegneria condivide il sistema AI orientato all’architettura che usa per dimezzare i tempi del prototipo, ridurre il rework del 25% e progettare barriere di sicurezza per un SDLC potenziato dall’IA.
Yurii Lozinskyi
Il CPO e Direttore dell’Ingegneria di Verysell
Leadership IA: L’IA sposta la gestione dei progetti dalla coordinazione alla progettazione dei sistemi, riducendo i compiti manuali grazie all’integrazione dell’IA.
Ruolo dell’architettura: Un’architettura solida previene il caos nella consegna dell’IA, allineando il lavoro generato dall’IA agli standard qualitativi e agli obiettivi.
Efficienza nei prototipi: Un’IA guidata dall’architettura riduce i costi, accelerando il passaggio dall’idea al prototipo funzionante in pochi giorni.
Valore dell’ingegnere: L’IA aumenta il valore degli ingegneri senior migliorando la progettazione architetturale e riducendo il coding casuale.
Cambiamento nel Project Management: I futuri ruoli di project manager sfrutteranno l’IA per la coordinazione, concentrandosi più su design, strategia e governance.
Yurii Lozinskyi è il CPO e Direttore dell'Ingegneria presso Verysell AI, dove guida la delivery di AI. Con 25 anni di esperienza, trasformare iniziative software e di intelligenza artificiale in risultati di business misurabili è il suo pane quotidiano.
Così ci siamo seduti con lui per capire come ci riesce. Ecco cosa ci ha raccontato.
Assicurarsi che l’IA non sia solo un giocattolo luccicante
Sono un leader di prodotto e ingegneria che vive all’incrocio tra sistemi di intelligenza artificiale, delivery software e realtà aziendale. Ho passato oltre 15 anni a portare progetti a termine nei settori bancario, assicurativo, piattaforme ITSM/MSP, retail e sanitario. E, in qualche modo, torno sempre al settore assicurativo perché lì la complessità e l’impatto sono entrambi elevati.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Attualmente, non gestisco progetti nel senso tradizionale. Progetto come dovrebbero funzionare i progetti e cerco di restare operativo durante la delivery. Questo significa modelli operativi, schemi di delivery guidati da AI e roadmap di validazione delle ipotesi su più team e clienti.
In breve, il mio lavoro quotidiano consiste nell’assicurarmi che l’IA non sia un giocattolo luccicante a lato, ma una parte integrante di come il lavoro viene definito, eseguito e governato dall’inizio alla fine.
Come l’IA sposta la gestione progetti dalla coordinazione al design di sistema
La leadership della delivery sta passando dalla gestione dei calendari al design dei sistemi. Trascorro molto meno tempo in riunioni di stato o a redigere manualmente documenti che le macchine ora producono in pochi secondi. Se l’IA può aiutarmi a scrivere la prima versione di un piano o di un riepilogo, sono ben contento di lasciarglielo fare.
Molti project manager oggi spendono ancora il 40–60% del loro tempo a rincorrere aggiornamenti di stato, fare report manuali, identificare rischi di base e spostare informazioni tra strumenti e persone. In un ambiente potenziato da IA, questa percentuale scende sotto il 10–15%, grazie ad agenti integrati che gestiscono aggiornamenti, riepiloghi, promemoria e semplici escalation tra Jira/Linear, Slack/Teams e documenti.
La contropartita è che il mio lavoro si è spostato su un altro livello: ora mi preoccupo di vincoli, criteri di accettazione, paletti e cicli di feedback. In altre parole, disegno i "binari" su cui corrono persone e agenti AI.
Ho un’impostazione orientata all’architettura: uso il C4 model e ISO/IEC 25010 come quadro di riferimento per i Documenti di Visione Architetturale, che poi utilizzo come prompt. Questa è la parte divertente: trattare l’architettura come un’API per l’IA. I tuoi documenti di architettura non sono archivi polverosi, ma carburante per un ciclo di sviluppo software (SDLC) potenziato dall’IA. Ne parlerò meglio tra poco.
L’IA rende banale andare veloce, quindi il mio ruolo è assicurarmi che si vada veloci nella direzione giusta. Perciò, invece di chiedere, “Chi fa cosa questa settimana?”, mi chiedo, “Il nostro sistema rende difficile spedire velocemente la cosa sbagliata?”
L’IA rende banale andare veloce, quindi il mio ruolo è assicurarmi che si vada veloci nella direzione giusta.
Perché l’architettura previene il caos nella delivery indotto dall’IA
Mi piacciono C4, ISO 25010 e i Documenti di Visione Architetturale perché costituiscono una spina dorsale per integrare l’IA nella delivery. Senza questa struttura portante, l’IA può rapidamente diventare un’ulteriore fonte di caos nella consegna dei progetti.
Nello specifico:
- C4 fornisce all’IA una mappa del sistema. Invece di “Scrivi del codice”, possiamo dire: “In questo contesto e container, rispetto a queste interfacce, implementa questa modifica.” Questo tiene il lavoro generato dall’IA all’interno di chiari confini architetturali.
- ISO 25010 definisce cosa vuol dire “buono” oltre a “compila”. Traduciamo i suoi attributi di qualità in scenari concreti — performance, sicurezza, manutenibilità, affidabilità — e li includiamo nei prompt e nei criteri di accettazione. L’IA così genera prototipi e test che rispettano aspettative di qualità esplicite, non solo la funzionalità.
- I Documenti di Visione Architetturale integrano tutto. Collegano gli obiettivi di business, le viste C4 e gli scenari qualitativi in stile ISO in una narrazione unica sia per gli umani sia per l’IA. Per gli umani, sono l’artefatto di allineamento. Per l’IA, rappresentano la principale sorgente di contesto per generare codice, test e documentazione.
Insieme, trasformano l’IA da un superpotere casuale a un componente controllato di un SDLC alimentato dall’IA, con confini chiari, tracciabilità e una comprensione condivisa di cosa vogliamo costruire.
Come abbattere il costo dell’errore con prototipi AI guidati dall’architettura
Ecco un esempio. Avevamo una funzionalità di AI-matching che, nel “vecchio mondo”, avrebbe richiesto circa due settimane per passare dall’idea a un prototipo cliccabile.
Invece di iniziare con ticket Jira e prompt ad hoc, abbiamo prima scritto un breve Architecture Vision Document. Abbiamo disegnato diagrammi in stile C4: contesto del sistema, container coinvolti, componenti chiave, oltre a una manciata di scenari di qualità ispirati a ISO-25010 (es. latenza, auditabilità, gestione degli errori).
Poi abbiamo trattato quell’architettura come un’API per l’IA:
- Abbiamo fornito al nostro assistente di codifica il Vision Document e gli estratti C4 come unica fonte di verità per i prompt.
- Gli abbiamo chiesto di generare impalcature, logica di flusso core e primi test all’interno dei container e delle interfacce specificate.
Non stai chiedendo all’IA “Scrivimi del codice”, ma “Implementa questa interazione specifica con questi vincoli e queste caratteristiche di qualità”. È tutta un’altra partita. E ha prodotto un PoC coerente in un paio di giorni invece di farci scrivere tutto da zero a mano.
Gli ingegneri hanno comunque revisionato e sistemato le cose, ma:
- Il tempo da “dovremmo provarci” a “gli stakeholder possono cliccare su un prototipo funzionante” è sceso da circa dieci giorni lavorativi a tre o quattro. Sembra quasi ingiusto quanto velocemente si ottiene un prototipo credibile quando è l’architettura a guidare i prompt invece di vaghi desideri.
- Abbiamo registrato il 20-25% in meno di cicli di rifacimento, perché il codice generato dall’IA rispettava già i confini e i pattern definiti nell’architettura.
- Gli ingegneri hanno dichiarato di impiegare circa il 20% di tempo in meno su boilerplate e codice “collante”, eliminando di fatto il ruolo separato di “ingegnere d’integrazione”.
- La copertura dei test per quella parte è risultata superiore al primo tentativo, dato che l’assistente ha usato gli scenari di qualità documentati per suggerire test sui casi limite che probabilmente non avremmo scritto così presto.
In altre parole, una volta che abbiamo reso esplicita e strutturata l’architettura, l’IA ha smesso di comportarsi come un semplice completamento automatico intelligente e ha iniziato ad agire più come un giovane ingegnere che conosce davvero la mappa del sistema, scrive ottima documentazione e non dorme mai.
E soprattutto, ha abbattuto il costo dell’errore, che è esattamente ciò che desideri in contesti complessi.
Perché l’IA rende gli ingegneri senior più preziosi, non meno
Nonostante quello che si potrebbe pensare, l’IA rende gli ingegneri senior più preziosi, non meno.
Se colleghi l’IA a un’architettura debole e giudizio debole, ottieni solo un caos più veloce. Mettila nelle mani di un architetto capace e improvvisamente un senior può esplorare cinque design diversi prima di pranzo e avere ancora tempo per parlare con gli stakeholder.
L’IA colma alcune lacune di competenze ma amplifica il divario tra codice casuale e progettazione intenzionale.
Se colleghi l’IA a un’architettura debole e giudizio debole, ottieni solo un caos più veloce. Mettila nelle mani di un architetto capace e improvvisamente un senior può esplorare cinque design diversi prima di pranzo e avere ancora tempo per parlare con gli stakeholder.
Addio, business analyst — benvenuto, subject matter expert.
Quali task di delivery automatizzare per primi con l’IA
Al momento, le parti del lavoro di delivery più mature per l’automazione sono le attività “a forte contesto, ricche di pattern e a basso ego”:
- Come accennato, generazione di codice PoC e test da Architecture Vision Documents e specifiche C4/ISO 25010
- Stesura di log delle decisioni, opzioni di progettazione e liste dei rischi
- Trasformare thread disordinati su Slack in qualcosa che il tuo futuro te stesso possa leggere senza mettersi a piangere
L’IA è eccellente nel suggerire; è pessima nel prendersi la responsabilità. Ecco dove gli umani possiedono ancora completamente lo spazio:
- Definire il problema
- Soppesare rischio contro velocità
- Gestire i confini normativi ed etici
- Decidere quando "tecnicamente corretto" è comunque la scelta sbagliata da rilasciare
Il punto di massimo valore, al momento, è comprimere i cicli iniziali di scoperta e design. Gli agenti sono bravi a trasformare una specifica coerente in percorsi plausibili. Non capiscono ancora quando un percorso è politicamente, eticamente o strategicamente sbagliato, quindi il controllo rimane saldo in mano agli umani.
Perché i PM dovrebbero dare priorità ai cicli di feedback rispetto alla cerimonia
La gestione tradizionale dei progetti spesso contiene molti rituali senza uno scopo chiaro. Sto abbandonando questo approccio a favore di sistemi che privilegiano il feedback rispetto alle cerimonie.
In pratica, significa:
- Meno piani monolitici; più ipotesi piccole e verificabili
- Meno grandi riunioni di aggiornamento; più aggiornamenti asincroni auto-sintetizzati dall’IA
- Meno documenti di requisiti prolissi; più Architecture Vision Documents vivi su cui sia umani sia IA possono agire
Continuiamo a preoccuparci di date, budget e rischi. Ma lasciamo che l’IA gestisca la contabilità, così gli umani possono concentrarsi su design, decisioni e realtà degli stakeholder.
L'ironia è che, rimuovendo metà dei rituali, le persone rispettano di più la struttura che resta.
L’ironia è che, rimuovendo metà dei rituali, le persone rispettano di più la struttura che resta.
Come le integrazioni IA semplificano la delivery dei progetti in GitHub e CI/CD
Dal punto di vista tecnico, “andare leggeri” ha significato collegare l’IA direttamente al repository e agli ambienti, non semplicemente aggiungere un altro cruscotto.
Nello specifico, abbiamo integrato un assistente di codifica IA chiamato Codex nei nostri repository GitHub e nella pipeline CI/CD. Gli ingegneri lavorano nel loro IDE abituale, ma l’assistente può vedere la struttura del repository e fare tutto ciò che ho descritto sopra a partire da diagrammi architetturali in stile C4 e da un Architecture Vision Document. A circa $20 USD per ingegnere al mese, è più economico di quasi ogni altra leva di produttività che si possa attivare.
Inoltre, utilizziamo una semplice automazione per la distribuzione (pipeline basate su GitHub) per poter rilasciare cambiamenti supportati dall’IA in un ambiente prototipo dedicato con un solo click.
Anche la generazione di prompt è in parte automatizzata: un modello GPT di ultima generazione (GPT-5.2) può generare prompt strutturati per strumenti come Eraser a partire dai nostri Architecture Vision Documents.
La chiave è che tutto questo rientra nei vincoli standard: gli ingegneri revisionano ancora ogni pull request, la CI/CD viene comunque eseguita e nulla va in produzione senza l’approvazione umana. L’IA accelera le parti noiose; gli umani restano responsabili di design, rischio e decisione finale.
Perché i prototipi IA ridefiniscono i rituali di delivery
Tutto questo ha avuto un grande impatto sui nostri rituali di delivery.
Definire il perimetro prima significava: “Parliamone per ore e poi scriviamo un documento che ignoreremo tutti.” Ora invece è: “Arriviamo rapidamente a un prototipo e discutiamo su qualcosa di interattivo.”
Partiamo da un obiettivo di alto livello, lo catturiamo in un Architecture Vision Document, disegnamo viste C4 e poi usiamo l’IA per generare un PoC o almeno un mock-up realistico. Improvvisamente tutti hanno un’opinione — perché c’è qualcosa di concreto su cui reagire.
In altre parole, raggiungiamo l’allineamento sul comportamento, non sui punti elenco.
Validiamo utilizzando un mix di test generati dall’IA (ottimi per copertura e regressione) e scenari progettati dagli umani (ottimi per giudizio e casi limite particolari).
E spostiamo la gestione dell’esecuzione dall’“assegnare compiti” al “progettare flussi”: chi o cosa dovrebbe vedere questo lavoro per primo, e con quale contesto?
Com’è fatta una filiera AI di delivery semplice
Il mio stack è di parte, ma semplice.
Per architettura e allineamento, uso diagrammi in stile C4 e Documenti di Visione Architetturale, realizzati con strumenti come Eraser. Così li si può iterare facilmente davanti alle persone e poi passarli all’AI.
Per le specifiche, preferisco documenti incentrati sul testo che descrivono intenzioni, vincoli e attributi di qualità in modo che un LLM possa comprendere.
Sul fronte ingegneristico, utilizzo moderni IDE con forte assistenza AI e strumenti come Claude Code e Codex per generare implementazioni di PoC e test direttamente da quei materiali architetturali. Deliberatamente non ho delegato all’AI la realizzazione completa di funzionalità di produzione. L’AI scrive bozze, imposta l’ossatura, fa proposte. Gli ingegneri — quelli veri — decidono ancora cosa va in produzione.
Importante: ognuno di questi strumenti ha smesso di essere un’isola. Ora è collegato in un SDLC potenziato dall’AI: requisiti, architettura, sviluppo codice, test ed anche governance hanno tutti uno strato assistivo.
In pratica, mi aspetto che questo cambiamento liberi circa il 18-25% di incremento produttivo lungo la catena di delivery. Ma attenzione: questa percentuale dipende molto dai presupposti della singola organizzazione — maturità, processi esistenti e disciplina architetturale.
Come l’adozione selettiva degli strumenti migliora il delivery AI
Nell’ultimo anno abbiamo iniziato a sostituire e sperimentare strumenti in modo mirato, piuttosto che “AI-abilitare” tutto subito.
Per il delivery abbiamo introdotto Miro per la roadmap agile e workshop architetturali, ma solo in prova su pochi piccoli progetti. Volevamo valutare se le board Miro, insieme a sintesi generate dall’AI, potessero sostituire lunghe presentazioni e documenti manuali di allineamento. I primi segnali sono buoni, ma dobbiamo ancora finalizzare e industrializzare la soluzione prima che diventi la prassi.
Per la documentazione e le specifiche, abbiamo mantenuto uno strumento testuale per i Documenti di Visione Architetturale. Sopra vi abbiamo aggiunto un’assistenza AI con Custom GPT molto leggeri — mandando lentamente in pensione i grossi documenti statici di specifiche che nessuno aggiorna e che non si adattano bene ai prompt.
L’ho appena accennato sopra, ma dal lato tecnico abbiamo aggiunto Codex come assistente al coding AI integrato col nostro repository Git e la CI pipeline per la scaffalatura di PoC e la generazione di test, mantenendo però i nostri IDE e strumenti di deployment attuali. In altre parole: non abbiamo ancora smantellato la nostra stack. Sopra sovrapponiamo l’AI, solo dove porta davvero risparmio di tempo e sempre partendo da pilot controllati prima di estendere tutto all’azienda.
Non stiamo ancora smantellando la nostra stack. Sopra sovrapponiamo l’AI, dove porta effettivo risparmio di tempo, partendo da progetti pilota controllati prima di estenderlo all’intera azienda.
Dove sta andando il project management nei prossimi cinque anni
Tra cinque anni, il “project manager” come ruolo puramente di coordinamento sarà quasi scomparso dal tech. Il lavoro esisterà ancora, ma agenti AI integrati gestiranno la maggior parte del coordinamento, tracciamento e reporting all’interno degli strumenti.
Le persone che prima erano i PM si sposteranno verso la progettazione di SDLC potenziati dall’AI e modelli di governance, oppure verso i ruoli di prodotto e strategia.
I dashboard di performance dei PM non misureranno più “a tempo/su budget”, ma un piccolo set di metriche del sistema che possono davvero influenzare: lead time per i cambiamenti, tasso di difetti in fuga, latenza nelle decisioni, throughput degli esperimenti, e l’indice di fiducia degli stakeholder. L’AI farà la maggior parte dei conteggi. I PM saranno responsabili del fatto che quei numeri si muovano nella direzione giusta — non perché abbiano rincorso più ticket, ma perché hanno ideato modi migliori di lavorare.
I PM che resteranno a “far da pastori allo status” verranno silenziosamente sostituiti da bot che lo fanno 24/7 e non si lamentano di dover aggiornare sei dashboard contemporaneamente.
Perché i PM dovrebbero trattare l’AI come un collega, non come un argomento da studiare
Il mio consiglio: smettete di cercare di “imparare l’AI” come se fosse un nuovo framework e iniziate a considerarla come un nuovo tipo di collega con punti di forza e punti ciechi specifici. Noi scherzosamente chiamiamo la nostra "gptBuddy".
Scegli un flusso di lavoro, un team e una metrica che conta davvero, e conduci un esperimento spietato. Se non vedi un miglioramento significativo, cambia la configurazione o interrompi.
Il vero valore dell’AI sembra noioso dall’esterno. Non è la roba da fantascienza che la gente si aspetta. Sono le vittorie poco appariscenti ma che si accumulano: generazione di test, pulizia della documentazione, impalcature, esplorazione di varianti e così via.
Allo stesso tempo, alza lo sguardo dagli strumenti e abbozza come potrebbe essere un SDLC (Software Development Life Cycle) potenziato dall’AI per la tua organizzazione. Se non lo farai tu, lo farà qualcun altro — e i loro team si muoveranno più velocemente, con meno riunioni e meno problemi.
Smetti di cercare di “imparare l’AI” come se fosse un nuovo framework e trattala invece come un nuovo tipo di collega con punti di forza e punti ciechi specifici.
Segui gli aggiornamenti
Puoi seguire Yurii Lozinskyi su LinkedIn e Dev.to mentre condivide le sue competenze tecniche su AI, ingegneria, prodotto e delivery. E dai un’occhiata a Verysell AI.
Presto altre interviste a esperti su The Digital Project Manager!
