Vengo dal codice.

Sono stato DevOps, anche se all'epoca non lo chiamavamo per forza così. Sono stato sviluppatore. Sono stato architetto software. Poi, un po' alla volta, mi sono allontanato da quei mestieri per passare alla gestione di team di sviluppo, ai progetti, all'agilità, al product management.

Non ho smesso di colpo di scrivere codice. All'inizio mi scrivevo ancora da solo qualche script Python per automatizzare un'operazione, ordinare dei file, convertire un formato, mettere insieme un piccolo strumento. Poi ho iniziato a delegare una parte di quello sviluppo a ChatGPT, in chat. Poi sono passato via via a Claude Code. Ma in ogni caso restavano piccoli pezzi di codice per farsi degli strumenti, non sviluppo di prodotto in senso pieno.

Fino a qui era tutto molto delimitato. Uno script Python, una funzione. Un compito preciso. Una specie di delega pulita: invece di chiedere al LLM di ordinare lui stesso i file dentro il suo contesto, gli facevi scrivere uno script. Lui eseguiva un'operazione, si verificava, si andava avanti.

Ma da qualche giorno non è più così.

Da quattro giorni ho ripreso a sviluppare. O meglio: faccio sviluppare Claude Code. E stavolta non parlo di uno script di servizio. Parlo di un prodotto vero, nato dal nulla, con schermate, API interne, comportamenti avanzati, modifiche ai dati, scelte di architettura, test, documentazione generata a partire dal codice.

Questo testo non è una conclusione sul vibe coding. Non ho abbastanza distanza per permettermelo. Quattro giorni sono troppo pochi per costruire una dottrina. Anzi, forse è proprio questo il punto più importante: ci sono ancora dentro. Sto documentando una traversata.

La luna di miele

La prima cosa che colpisce è la velocità.

In quattro giorni ho prodotto qualcosa che, ai tempi in cui sviluppavo, mi avrebbe probabilmente preso un mese. Forse due. E non lo dico per fare scena. Sono partito da zero. Ho fatto più di 180 commit. Ho costruito, rotto, corretto, riorganizzato, testato, aggiunto comportamenti, presentato il prodotto, raccolto richieste di evoluzione, continuato.

Dà alla testa.

C'è un momento in cui ti dici: è incredibile. Posso avere un'idea, formularla, chiedere a Claude di implementarla, provare, aggiustare, ricominciare. Non sto più scrivendo una spec immaginandomi cosa verrà fuori dal prodotto più avanti. Ci sono già dentro.

E questo cambia parecchie cose.

Con un mockup si può già iterare. Vedi una schermata, un percorso, un'intenzione. Ti dici: in effetti il bottone non è nel posto giusto, questo caso d'uso non è chiaro, manca un'informazione. Ma con un prodotto che funziona, anche imperfetto, l'iterazione diventa ancora più diretta. Lo usi davvero. Vedi davvero. Senti sulla pelle gli attriti.

Nel mio caso il passaggio è avvenuto in modo abbastanza naturale. All'inizio assomigliava a un mockup. Poi il mockup ha cominciato a funzionare. Poi l'ho presentato. Poi mi hanno chiesto delle evoluzioni. Poi mi hanno chiesto quando si sarebbe potuto usare.

Ed è spesso lì che comincia il pericolo: quando l'usa e getta diventa utile.

La doccia fredda

La seconda cosa che colpisce è che Claude Code, se lo lasci da solo, può combinare letteralmente di tutto.

Non «di tutto» nel senso che niente funziona. È quasi il contrario. Spesso funziona. La schermata si apre. I dati arrivano. Il bottone fa qualcosa. La demo passa. Ed è esattamente per questo che è pericoloso.

Claude ha una tendenza naturale a buttarsi. Scrive codice. Aggiunge. Gonfia. Comincia con un file ragionevole, poi quel file si gonfia, si gonfia, si gonfia, fino a diventare un blocco che fa un po' tutto. Quando bisogna modificarlo, perde tempo. Quando bisogna capire l'intenzione, è più difficile. Quando salta fuori un bug, non sai più bene dove guardare.

Uno sviluppatore esperto pensa abbastanza in fretta alla separazione delle responsabilità. Si chiede dove mettere la logica di dominio, dove isolare il trasporto, dove mettere il rendering, come chiamare i concetti, come evitare che tutto sia accoppiato con tutto. Claude ci arriva, ma non lo fa spontaneamente e con costanza. Va guidato.

Stessa storia sui volumi.

Nel mio progetto certe API possono restituire qualche centinaio di elementi. Altre possono restituirne decine di migliaia. Non è affatto lo stesso mondo. Caricare 200 elementi per mostrarli in una pagina non è come caricarne 20.000 o 30.000 e poi sperare che il browser, l'utente e il backend restino di buon umore.

Ma se non gli dici niente, Claude può tranquillamente caricare tutto, passare tutto alla pagina web, filtrare tutto lato front, e considerare la questione risolta. In test, con pochi dati, può dare l'impressione di funzionare. Nell'uso reale esplode. O peggio: non si rompe apertamente, diventa lento, bloccato, incomprensibile.

Un bug non è sempre una riga rossa in console. A volte è semplicemente un prodotto che non risponde più perché sono stati caricati 5.000 elementi in silenzio, senza log, senza paginazione, senza una strategia chiara. E lì un PM non tecnico rischia di non capire cosa stia succedendo.

Guidare uno sviluppatore junior velocissimo

Il rapporto con Claude Code mi ha ricordato moltissimo la gestione di uno sviluppatore junior estremamente rapido.

Può produrre tantissimo. Può anche prendersi libertà assurde. Gli dai lo screenshot di un componente e non fa esattamente quello che gli è stato chiesto. Interpreta. Semplifica. Parte in una direzione sua. A volte gli devi rispiegare cose di base: perché quel file non deve contenere tutto, perché questo strato non deve conoscere quell'altro, perché non si caricano tutti i dati, perché bisogna scrivere i test, perché bisogna rilanciare i test.

E a volte non capisce subito.

Di per sé non è un dramma. Anche gli sviluppatori umani sbagliano. Cose scritte da sviluppatori ogni tanto vanno in produzione e non reggono il carico. Il debito tecnico non è nato con i PM che fanno vibe coding.

Ma l'IA aggiunge una velocità che cambia il problema. Permette di produrre in pochissimo tempo tanto codice mediocre. Se il quadro non è quello giusto, il debito arriva in fretta. Molto in fretta.

Dal canto mio, il mio passato tecnico mi aiuta. Capisco le grandi linee dell'architettura. Vedo quando un file comincia a diventare troppo grosso. Vedo quando gli strati si mescolano. Sento quando qualcosa creerà un problema di volumi o di manutenibilità.

Ma non padroneggio tutto. Ci sono parti di codice che non saprei spiegare su due piedi. Se mi prendo il tempo, riesco a capirle. Ma non posso pretendere di avere la stessa padronanza che avrei se avessi scritto io ogni riga.

Su questo prodotto lo accetto. Su altri prodotti non lo accetterei.

E questa sfumatura è fondamentale.

Il vero tema: competenza moltiplicata per rischio

Si potrebbe porre la domanda così: tutti i PM possono ormai sviluppare software con l'IA?

La mia risposta istintiva sarebbe: no.

O meglio: dipende.

Ma il «dipende» non è una scappatoia. Non è solo una questione di competenza individuale. È un rapporto tra il livello di competenza e il livello di rischio del prodotto.

È esattamente come per uno sviluppatore junior. A un junior apriamo subito il repository più complesso, più critico, quello con più impatto sul business? Non necessariamente. Gli diamo accesso a tutti i repository, a tutti i dati, a tutti i permessi? Nemmeno.

Per un PM che fa vibe coding vale lo stesso.

Non si tratta di dire: i PM hanno il diritto oppure non ce l'hanno. Si tratta di definire cosa possono fare, dentro quale perimetro, con quali limiti, in base al loro livello e in base al rischio.

Mi piace l'analogia della patente. Non si guida un veicolo qualsiasi senza patente, perché si può diventare pericolosi. E anche con la patente non si guida tutto. Magari un PM arrugginito può guidare una 125. Non vuol dire che debba salire su una moto di grossa cilindrata e partire in autostrada sotto la pioggia.

Quando dico «codice da PM», non è un insulto. Non sto dicendo che il codice di un PM sia per forza brutto. Sto dicendo che è codice prodotto da qualcuno che non padroneggia granché, o non più granché, il codice. Bisogna quindi accettare delle limitazioni. E soprattutto bisogna accettare di definirle.

Verde, arancione, rosso

Non credo a una griglia universale.

Ogni azienda dovrà definire la propria politica. Ma il principio mi sembra abbastanza chiaro: più il prodotto tocca dati sensibili, scritture, workflow critici, sicurezza, fatturazione, permessi, più le esigenze devono salire.

Un piccolo strumento interno, personale, con vita breve e impatto limitato, può probabilmente vivere con poco formalismo. Se si rompe, pazienza. Lo si butta, lo si corregge, si passa ad altro.

Uno strumento interno condiviso, con comportamenti avanzati, qualche scrittura, dipendenze di business, è già un'altra cosa. Lì bisogna porsi più domande.

E non appena si tocca la produzione critica, dati sensibili dei clienti, permessi, scritture irreversibili, workflow con un impatto forte sul cliente o sul business, si cambia ancora categoria.

La sicurezza, per esempio, mi sembra non negoziabile. Si può discutere del livello di test necessario per un piccolo strumento usa e getta. Si può discutere della review. Si può discutere del livello di documentazione. Ma la sicurezza non dovrebbe dipendere dall'umore del momento.

Per fortuna gli sviluppatori hanno già parecchi strumenti per questo: integrazione continua, scanner, regole, pratiche, competenze, a volte perfino prompt o skill interne. Il tema quindi non è reinventare tutto per i PM. È collegare i PM aumentati agli strumenti che già esistono.

No, non credo alla review sistematica

Si potrebbe rispondere: basta che tutto venga riletto dagli sviluppatori.

Su questa risposta sono piuttosto diffidente.

La review sistematica è diventata un riflesso, ma meriterebbe di essere discussa. Viene in particolare dal mondo open source, per ragioni molteplici: qualità, sicurezza, trasmissione, governance, fiducia tra contributori. Ma in un'azienda, per ogni tipo di codice, in ogni situazione, non sono convinto che vada rivisto tutto sistematicamente.

Se un PM si costruisce uno strumento personale, usa e getta, a basso rischio, serve davvero mobilitare uno sviluppatore per rileggerlo? Forse no. Altrimenti si ricrea esattamente la dipendenza che si stava cercando di ridurre.

La review può invece avere un ruolo all'inizio, per aiutare i PM a prendere buone abitudini. E può essere necessaria a seconda della posta in gioco. Di nuovo: non è sì oppure no. È una questione di rischio.

A un certo punto bisogna anche accettare la responsabilità. Se decido di costruirmi uno strumento, devo accettare di mangiare il mio stesso cibo. Se si rompe, tocca anche a me cavarmela. Ed è lì che può fare male, perché molti PM non sanno necessariamente risolvere i bug che hanno appena creato con l'IA.

I test come leva di controllo

In questa esperienza i test sono diventati centrali.

Non solo perché «i test sono una buona cosa». Ma perché sono uno dei pochi modi per mantenere il controllo su un codice che non hai scritto interamente tu.

Claude non scrive spontaneamente i test giusti se non glielo chiedi. Può dimenticarsene. Può scriverli a cose fatte. Può scrivere test che convalidano la sua implementazione invece dell'intenzione di business. Può dare l'impressione che il prodotto sia al sicuro perché ci sono dei test, quando in realtà manca una vera strategia di test.

Un PM non conosce per forza il TDD. Non conosce per forza la differenza tra un test unitario, un test di integrazione e un test end-to-end. Non conosce per forza la piramide dei test. Non sempre sa quando bisogna testare un comportamento prima di implementarlo, né come esprimere una regola di business sotto forma di test.

Eppure, in un progetto di vibe coding, è forse uno dei punti più importanti.

Nel mio progetto ci sono più di 500 test. Sono tanti per un progetto di queste dimensioni. Il più delle volte non si rompe nulla, proprio perché Claude rilancia i test molto spesso. Quando qualcosa si rompe, i test danno un appiglio. Permettono di capire dove il comportamento atteso non viene più rispettato.

Non sto dicendo che tutto vada testato con lo stesso livello di esigenza. Un piccolo strumento interno molto semplice, a basso rischio, non ha per forza bisogno di una strategia di test completa. Anche qui è una questione di portata.

Ma appena il prodotto diventa una cosa seria, i test non sono un bonus. Diventano una parte del volante.

I binari accelerano tanto quanto proteggono

Quando parlo di binari, non parlo solo di guardrail che impediscono ai PM di fare sciocchezze.

I binari servono anche ad andare più veloci.

Se lasci un PM e Claude Code da soli davanti al codice sorgente, l'IA può benissimo non prendere le API interne giuste. Può usare il punto d'ingresso sbagliato. Può ricostruire qualcosa che esiste già. Può produrre uno strumento che funziona male, o che non funziona affatto, o che perde un tempo infinito ad aggirare l'architettura esistente.

Se invece gli sviluppatori forniscono dei binari, il PM e l'IA sanno dove andare.

Questi binari possono prendere forme diverse: un catalogo delle API interne utilizzabili, una documentazione funzionale generata dal codice, una mappa tra i concetti di business e i punti d'ingresso tecnici, esempi di richieste, componenti di interfaccia riutilizzabili, convenzioni, accessi delimitati, una CI di sicurezza, file Claude, prompt, skill.

Si può immaginare, per esempio, un ambiente in cui un PM può creare schermate interne, strumenti di interrogazione, liste, grafici o scenari di business, appoggiandosi ad API documentate e validate. Tutto lo strato operativo è costruito dai dev. Il PM non parte da una pagina bianca. Compone dentro un quadro.

È già quello che fanno da tempo certi strumenti con linguaggi di query, dashboard o piattaforme interne. L'IA non fa che rendere questa logica più potente.

Il punto importante è questo: i binari non rallentano soltanto. Accelerano, perché evitano all'IA di sbagliare strada.

Dal piccolo strumento interno al product builder

C'è forse un gradino in più.

Fin qui si potrebbe pensare che io parli soltanto di piccoli strumenti interni: una schermata di consultazione, un export, una dashboard, uno strumento di interrogazione, un'interfaccia temporanea per aiutare il team di prodotto. Questo caso esiste, ed è già interessante. Può alleggerire gli sviluppatori, velocizzare il quotidiano, permettere a un team di prodotto di rispondere da solo a certi bisogni.

Ma non è detto che sia l'unico orizzonte.

Se la codebase dell'azienda è ben strutturata, se le API interne sono documentate, se i concetti di business sono leggibili, se componenti e convenzioni sono stabili, allora il PM può forse andare oltre il semplice strumento interno. Può diventare una specie di product builder.

Non uno sviluppatore autonomo su qualunque argomento. Non qualcuno a cui si affidano senza limiti le zone critiche del prodotto. Ma qualcuno capace di creare un modulo, una schermata, un percorso o una variante funzionale appoggiandosi alla codebase esistente.

La differenza è importante.

Nel caso del piccolo strumento interno, il PM costruisce spesso accanto al prodotto. Consuma API, aggrega informazioni, produce un'interfaccia utile per sé o per il suo team.

Nel caso del product builder, costruisce piuttosto nel prolungamento del prodotto. Usa i blocchi esistenti, il linguaggio di business del codice, i componenti dell'azienda, i binari posati dagli sviluppatori. Non parte da una pagina bianca. Compone con qualcosa di già strutturato.

Ed è esattamente qui che la qualità della codebase diventa decisiva. Una codebase mal strutturata chiude il PM e l'IA nell'arrangiarsi alla meglio. Una codebase leggibile, documentata, orientata al business e ben attrezzata può invece aprire uno spazio di contributo molto più ampio.

Il vibe coding non trasforma quindi automaticamente un PM in product builder. Non basta dargli Claude Code e un repository Git. Serve un terreno praticabile.

Se quel terreno esiste, allora il tema diventa molto più interessante di «i PM possono farsi i loro piccoli strumenti?». La vera domanda diventa: fin dove un'organizzazione può permettere a profili di prodotto di costruire direttamente certe parti del prodotto, senza perdere il controllo tecnico, la coerenza e la sicurezza?

E le specifiche, in tutto questo?

Questa esperienza mi ha anche fatto riaprire una domanda quasi provocatoria: bisogna ancora scrivere le specifiche?

Non sto dicendo che le specifiche spariranno dappertutto. Per molti prodotti, molti contesti, molti temi regolamentari, molte decisioni strutturanti, bisognerà sempre scrivere, delimitare, discutere, documentare il perché.

Ma per certi strumenti interni mi chiedo se la spec non stia cambiando natura.

Nel mio caso non ho scritto nessuna spec. Mi sono buttato. Ho costruito. Ho mostrato. Mi hanno detto: manca questo, servirebbe quello, per questa e quest'altra ragione. Ho aggiunto. Ho iterato.

Perché fare un mockup se posso costruire direttamente una prima versione utilizzabile? Perché scrivere una spec descrittiva se posso far emergere il comportamento dentro il prodotto, e poi generare la documentazione funzionale a partire dal codice?

Avevo scritto di recente che la domanda di prodotto dovesse partire dal codice sorgente. Questa esperienza va nella stessa direzione, ma dall'altro lato. Se il codice diventa la verità del comportamento, allora una parte della documentazione può essere rigenerata a partire da esso. La spec non sparisce per forza, ma non può più pretendere di essere durevolmente la verità del prodotto.

Per certi perimetri si potrebbe quasi dire: la spec non la si scrive più prima. Si costruisce, si valida, e poi si genera la documentazione di business a partire da ciò che gira.

Sto calcando la mano, ovviamente. Ma non poi così tanto.

Il rischio organizzativo

C'è anche un rischio meno tecnico, più organizzativo.

Se tutti cominciano a fabbricarsi i loro piccoli strumenti per conto proprio, la cosa può sfuggire di mano in fretta. Strumenti interni senza manutenzione possono diventare importanti. Script usa e getta possono finire usati ogni settimana. Una schermata messa insieme alla buona per un team può diventare un passaggio obbligato. Uno strumento senza governance può diventare critico senza che nessuno l'abbia deciso.

Ma questo rischio non è proprio del vibe coding. Le aziende lo conoscono già con i file Excel, le macro, gli script, gli strumenti no-code, le dashboard costruite in un angolo. Il vibe coding non crea il problema. Lo accelera, perché rende più facile produrre strumenti.

Anche qui la risposta non è vietare. È definire le zone, i permessi, le responsabilità, i limiti, i binari.

Cosa cambia per gli sviluppatori

Non credo che i PM sostituiranno gli sviluppatori.

Penso invece che certi piccoli strumenti interni che si chiedevano agli sviluppatori potranno essere prodotti direttamente dai team di prodotto, supporto, ops o business, a condizione di essere ben inquadrati. E questo può alleggerire gli sviluppatori.

Quante volte si chiede a un team dev di uscire dal cuore del prodotto per fare un piccolo strumento interno, un export, una schermata di consultazione, una dashboard, un'interfaccia temporanea? Se una parte di queste richieste può essere assorbita altrove, non è detto che sia una brutta notizia.

Ma questo non fa sparire il ruolo dei dev. Al contrario, può spostarlo. Diventano anche quelli che costruiscono i binari, le piattaforme, le API pulite, le convenzioni, gli ambienti sicuri dentro cui altri possono produrre senza rompere tutto.

Non è meno tecnico. Forse è perfino più architetturale.

La stanchezza

Non voglio vendere questa esperienza come un momento solo euforico.

È faticoso.

Fare più di 180 commit in quattro giorni, anche con un'IA, non è una cosa neutra. Non batti tu tutto il codice, ma guidi, rileggi, provi, correggi, decidi, riprendi, sorvegli, rispieghi. Si avanza velocissimi, ma quella velocità bisogna starle dietro.

Il vibe coding dà una sensazione di potenza, ma non è una potenza gratis. Il PM diventa una specie di pilota, di architetto di prossimità, di tester, di reviewer, di portatore d'intenzione, di guardrail. E se non ha abbastanza cultura tecnica, rischia di ritrovarsi a guidare qualcosa che non capisce davvero.

Ed è lì che l'illusione di competenza è pericolosa.

L'abbiamo già vissuto con il no-code. C'era chi pensava di non aver più bisogno di sviluppatori, e tre giorni dopo scopriva che un sito senza sicurezza, senza protezione contro gli attacchi a forza bruta, senza circuit breaker, poteva diventare un problema molto in fretta. Non è che lo strumento fosse scadente. È che dava accesso a una potenza senza trasmettere automaticamente la cultura di sicurezza e di architettura che ci va insieme.

Il vibe coding pone lo stesso genere di domanda.

Sto documentando una traversata

Non ho una conclusione definitiva.

Ed è forse l'unica conclusione seria possibile dopo quattro giorni.

Sto ancora facendo vibe coding. Continuo a imparare. Continuo a vedere cosa funziona, cosa si rompe, cosa mi sfugge, cosa recuperano i test, cosa accelerano i binari, cosa il mio vecchio bagaglio tecnico mi permette ancora di fiutare.

Non voglio costruirmi un'opinione dalla tribuna. Voglio costruirmela con la pratica.

Per ora quello che vedo è una capacità nuova, molto potente, che però non cancella le vecchie domande del software. A volte le rende più visibili. Le accelera. Le sposta.

Il vibe coding permette di andare molto veloci. Ma andare veloci non è la stessa cosa che sapere dove si sta andando, né sapere cosa si rischia di rompere.

Quindi vado avanti.

Sto documentando una traversata.