Da developer a product owner: la trasformazione necessaria nell'era dell'ai
Riflessioni personali su cosa significa davvero restare rilevanti quando il codice lo scrive qualcun altro
Qualche giorno fa un collega del mio team che usa Claude Code ha implementato una feature che, quando facevo il suo lavoro, mi avrebbe richiesto più di mezza giornata. Lui l’ha completata in quaranta minuti, con qualità e sicurezza. E mentre ci pensavo, non stavo pensando a quanto fosse forte lo strumento. Stavo pensando a quanto il mio percorso professionale, quella transizione da developer a ruoli di product ownership e maggiore leadership che ho fatto negli ultimi anni, si stia rivelando più preveggente di quanto avessi immaginato.
Non l’ho fatto per lungimiranza, sia chiaro. L’ho fatto perché a un certo punto scrivere codice tutto il giorno aveva smesso di darmi quello che cercavo. Volevo capire il perché delle cose, non solo il come. Volevo essere nella stanza quando si decideva cosa costruire, non solo ricevere ticket da implementare. È stata una scelta istintiva, in parte egoistica. Ma col senno di poi, mi ha posizionato in un punto interessante per osservare quello che sta succedendo in questo periodo.
Il punto di inflessione in cui ci troviamo non riguarda l’ai che “ruba il lavoro ai programmatori”, come si legge nei titoli sensazionalistici. Riguarda qualcosa di più sottile: il valore si sta spostando. Sta migrando dal come al cosa e al perché. E io lo vedo ogni giorno, nelle conversazioni con gli altri professionisti e manager che conosco, nelle scelte di hiring che sono già cambiate, nel modo in cui ormai è necessario strutturare i team.
Le aziende non si chiedono più “quanti developer posso assumere”. Si chiedono “come massimizziamo la produttività con team più piccoli e strumenti migliori”. È un cambio di prospettiva radicale. Nel mio ruolo, mi trovo sempre più spesso a ragionare su come integrare agenti ai nei workflow esistenti piuttosto che su come scalare il team. E questo ha implicazioni enormi per chi oggi scrive codice come attività principale.
Gli agenti ai autonomi che si usano quotidianamente non sono autocomplete glorificati. Fanno cose che fino a due anni fa sembravano fantascienza: prendono un problema mal definito, lo scompongono, cercano contesto nel codebase, implementano, testano, iterano. Li supervisioniamo, certo. Li correggiamo, spesso. Ma la quantità di lavoro che riescono a produrre, con la giusta guida, è impressionante. E questo cambia tutto.
Nel selezionare candidati o valutare le performance del team, dobbiamo cambiare radicalmente le domande che ci facciamo. Non mi interessa più tanto quanto velocemente qualcuno scrive codice. Mi interessa quanto bene capisce il problema che stiamo risolvendo. Mi interessa se fa le domande giuste prima di iniziare, se anticipa i casi limite, se riesce a spiegarmi le sue scelte in termini che hanno senso per il business. Queste sono le cose che l’ai non sa ancora fare bene.
Conosco professionisti che si rifiutano di usare Copilot o Claude Code perché “preferiscono scrivere tutto da soli”. Li capisco, davvero. Vengo da lì, conosco quella sensazione di controllo totale, quell’appagamento nel vedere il codice nascere dalle tue dita. Ma da dove sto adesso, vedo anche il rischio. È un po’ come i tipografi che rifiutavano il desktop publishing perché amavano il piombo. Romantico, certo. Sostenibile economicamente, molto meno.
La transizione da developer a product owner, o comunque a ruoli dove definisci il cosa invece di implementare il come, non significa smettere di essere tecnici. Anzi, nella mia esperienza richiede più competenza tecnica, non meno. Ma una competenza diversa: devo sapere cosa è possibile, cosa è costoso, cosa è rischioso, senza necessariamente essere io a implementarlo. Bisogna guidare l’ai e gli agent come un direttore d’orchestra guida i musicisti: non suoni ogni strumento, ma devi sapere come dovrebbe suonare ogni strumento.
I developer che vedo fare meglio questa transizione hanno caratteristiche che riconosco in me stesso. Non sono necessariamente i più brillanti tecnicamente. Sono quelli che hanno sempre fatto tante domande, quelli che volevano capire il perché dietro ogni feature, quelli che si irritavano quando ricevevano spec vaghe. Sono quelli che hanno sempre pensato al prodotto, anche quando il loro ruolo ufficiale era solo scrivere codice. Se ti riconosci in questa descrizione, probabilmente hai già metà del lavoro fatto.
C’è poi la questione delle competenze relazionali, e qui devo ammettere che il passaggio è stato duro anche per me. Per anni ho evitato le riunioni con gli stakeholder business, le ho viste come interruzioni del “vero lavoro”. Adesso sono il mio lavoro. Tradurre il linguaggio tecnico in termini che un cfo possa capire, negoziare priorità con un team di marketing/commerciale che vuole tutto per ieri, spiegare a un amministratore perché quella feature “semplice” richiede tre mesi: queste sono competenze che nessuna ai sa ancora fare, e forse non saprà fare mai. E sono quelle che mi rendono di grande valore oggi.
Una cosa che ho imparato sul campo è che la qualità dei requisiti che dai all’ai determina la qualità dell’output che ottieni. Sembra ovvio, ma le implicazioni sono profonde. Quando scrivo spec precise, contestualizzate, con i giusti vincoli e le giuste libertà, ottengo codice che funziona. Quando sono vago, incompleto, contraddittorio, ottengo spazzatura. Questo significa che la competenza critica non è più “saper codare”, è “saper specificare”. E specificare bene richiede una comprensione profonda sia del dominio tecnico che di quello business.
Ho già visto team piccoli, cinque persone al massimo, produrre output equivalente a team di dodici semplicemente perché avevano qualcuno che sapeva definire i task nel modo giusto. Non parlo di documentazione formale, di diagrammi uml o specifiche tecniche di cento pagine. Parlo di quella capacità di articolare cosa serve davvero, di fare le domande giuste prima di iniziare, di anticipare i problemi. È una skill che si può imparare, ma richiede un cambio di mindset.
Detto questo, non voglio dipingere un quadro troppo roseo. La transizione che ho fatto io non è stata lineare, e vedo colleghi che faticano enormemente. Richiede umiltà: accettare che qualcosa che sapevi fare bene sta perdendo valore relativo, e che devi investire in competenze diverse. Richiede anche coraggio: uscire dalla comfort zone del codice, dove le cose sono deterministiche e controllabili, per entrare nel mondo ambiguo delle decisioni di prodotto, dove hai sempre informazioni incomplete e stakeholder con agende contrastanti.
C’è anche una dimensione etica in tutto questo che mi preoccupa e mi affascina. Usare l’ai per accelerare lo sviluppo non è neutrale. Ci sono bias nei modelli, ci sono implicazioni sulla qualità del codice prodotto, sulla sicurezza, sulla manutenibilità. Bisogna essere anche un po’ paranoici, bisogna sapere quando l’ai sta facendo qualcosa di sbagliato anche se tecnicamente funziona. È una responsabilità nuova, che richiede consapevolezza e intenzionalità. Non puoi delegare tutto e sperare che vada bene.
Quello che vedo dal mio punto di osservazione è che i ruoli di leadership tecnica, product management, tech strategy saranno sempre più richiesti e sempre più difficili da riempire. Chi viene dal coding ha un vantaggio competitivo enorme rispetto a chi arriva dal business puro: capisce cosa è possibile, cosa è costoso, cosa è rischioso. Ma deve fare il salto. Deve smettere di identificarsi con le righe di codice che scrive e iniziare a identificarsi con i problemi che risolve.
Il falso mito che sento più spesso dai developer con cui parlo è “non ho tempo per imparare queste cose”. Ma il tempo che risparmi usando l’ai per scrivere codice, dove va? Se lo reinvesti nel perfezionare ulteriormente le tue skill di coding, stai ottimizzando qualcosa che sta diventando una commodity. Se lo reinvesti nell’imparare a pensare come un product owner, stai costruendo la tua rilevanza futura.
La domanda che mi facevo anni fa, quando ho iniziato questa transizione, era “cosa voglio fare tra cinque anni?”. La risposta non era “scrivere codice ancora più velocemente”. Era “avere più impatto, capire meglio il business, essere nella stanza dove si prendono le decisioni”. Quella domanda oggi è ancora più urgente per chi è all’inizio del percorso.
Il futuro appartiene a chi sa definire cosa costruire, non solo a chi sa costruirlo. Io ho fatto questa scommessa qualche anno fa, senza sapere quanto sarebbe diventata rilevante. Per chi legge oggi, il vantaggio è che può farla con più consapevolezza. Ma deve farla.