Quattro giorni di vibe coding nei panni di un PM arrugginito

Vengo dal codice.

Sono stato DevOps, anche se all'epoca non si chiamava necessariamente così. Sono stato sviluppatore. Sono stato architetto software. Poi, progressivamente, mi sono allontanato da questi mestieri per spostarmi verso la gestione di team di sviluppo, il project management, l'agile, il product management.

Non ho smesso di codificare del tutto dall'oggi al domani. All'inizio scrivevo ancora qualche script Python per automatizzare un compito, ordinare file, trasformare un formato, creare un piccolo strumento. Poi ho cominciato a delegare parte di questo sviluppo a ChatGPT, in modalità chat. Poi sono passato progressivamente verso Claude Code. Ma in tutti i casi, restava roba di piccoli pezzi di codice per fare strumenti, non sviluppo prodotto nel senso pieno.

Fino a qui, era molto inquadrato. Uno script Python, una funzione. Un compito preciso. Una sorta di delega pulita: invece di chiedere al LLM di ordinare lui stesso i file nel suo contesto, gli si faceva scrivere uno script. Eseguiva un'operazione, si verificava, si andava avanti.

Ma da alcuni giorni, non è più così.

Da quattro giorni, ho ripreso a sviluppare. O meglio: faccio sviluppare Claude Code. E questa volta, non parlo di uno script utilitario. Parlo di un vero prodotto, partito da zero, con schermi, API interne, comportamenti avanzati, modifiche di dati, scelte di architettura, test, documentazione generata dal codice.

Questo testo non è una conclusione sul vibe coding. Non ho abbastanza distanza per questo. Quattro giorni sono troppo pochi per fabbricare una dottrina. È forse il punto più importante: sono ancora dentro. Documento una traversata.

La luna di miele

La prima cosa che colpisce è la velocità.

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

È esaltante.

C'è un momento in cui ci si dice: è incredibile. Posso avere un'idea, formularla, chiedere a Claude di implementarla, testare, aggiustare, ricominciare. Non sto più scrivendo una spec immaginando come sarà il prodotto più avanti. Sono già dentro.

E questo cambia molte cose.

Con un mockup, si può già iterare. Si vede uno schermo, un percorso, un'intenzione. Ci si dice: alla fine, 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. Si usa davvero. Si vede davvero. Si percepiscono le frizioni.

Nel mio caso, il basculamento è arrivato abbastanza naturalmente. All'inizio, assomigliava a un mockup. Poi il mockup ha cominciato a funzionare. Poi l'ho presentato. Poi mi hanno chiesto evoluzioni. Poi mi hanno chiesto quando si sarebbe potuto usare.

È spesso lì che il pericolo comincia: quando il jetable diventa utile.

La doccia fredda

La seconda cosa che colpisce è che Claude Code, lasciato da solo, può fare assolutamente qualsiasi cosa.

Non qualsiasi cosa nel senso che nulla funziona. È quasi l'opposto. Spesso funziona. Lo schermo si visualizza. I dati risalgono. Il bottone fa qualcosa. La demo passa. Ed è esattamente per questo che è pericoloso.

Claude ha una tendenza naturale ad andare di corsa. Codifica. Aggiunge. Si gonfia. Comincia con un file ragionevole, poi quel file cresce, cresce, cresce, fino a diventare un blocco che fa un po' di tutto. Quando bisogna modificarlo, perde tempo. Quando bisogna capire l'intenzione, è più difficile. Quando appare un bug, non si sa più esattamente dove guardare.

Uno sviluppatore esperto pensa abbastanza presto alla separazione delle responsabilità. Si chiede dove mettere la logica di business, dove isolare il trasporto, dove mettere il rendering, come denominare i concetti, come evitare che tutto sia accoppiato a tutto. Claude può farlo, ma non lo fa spontaneamente con costanza. Bisogna guidarlo.

Stesso discorso sulla volumetria.

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

Ma se non gli si dice nulla, Claude può benissimo caricare tutto, passare tutto alla pagina web, filtrare tutto lato front, e considerare che il problema è risolto. In test, con pochi dati, può dare l'impressione di funzionare. In uso reale, esplode. O peggio: non si rompe francamente, diventa lento, bloccato, incomprensibile.

Un bug non è sempre un errore rosso in console. A volte è solo un prodotto che non risponde più perché si sono caricati 5.000 elementi in modo silenzioso, senza log, senza paginazione, senza strategia chiara. E lì, un PM non tecnico può non capire cosa sta succedendo.

Pilotare uno sviluppatore junior molto rapido

La relazione con Claude Code mi ha fatto molto pensare al pilotaggio di uno sviluppatore junior estremamente rapido.

Può produrre moltissimo. Può anche prendere libertà assurde. Gli si dà uno screenshot di un componente, non fa esattamente ciò che viene richiesto. Interpreta. Semplifica. Va in una direzione. A volte bisogna rispiegargli cose di base: perché questo file non deve contenere tutto, perché questo layer non deve conoscere quell'altro layer, perché non si carica tutta la data, perché bisogna scrivere i test, perché bisogna rilanciarli.

E a volte non capisce subito.

Non è grave in sé. Anche gli sviluppatori umani fanno errori. Cose sviluppate da sviluppatori passano a volte 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 molto velocemente molto codice mediocre. Se il contesto non è buono, il debito arriva in fretta. Molto in fretta.

Da parte mia, il mio passato tecnico mi aiuta. Capisco le grandi linee dell'architettura. Vedo quando un file comincia a diventare troppo grande. Vedo quando i layer si mescolano. Sento quando qualcosa creerà un problema di volumetria o di manutenibilità.

Ma non controllo tutto. Ci sono parti del codice che non sarei capace di spiegare immediatamente. Se prendo il tempo, posso capirle. Ma non posso pretendere di avere la stessa padronanza che se avessi scritto ogni riga io stesso.

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

E questa sfumatura è essenziale.

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 spontanea 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. Si apre immediatamente a un junior il repository più complesso, più critico, più impattante per il business? Non necessariamente. Gli si dà accesso a tutti i repository, a tutti i dati, a tutti i permessi? Neanche.

Per un PM che fa vibe coding, è uguale.

Non si tratta di dire: i PM hanno il diritto o non hanno il diritto. Si tratta di definire cosa possono fare, in quale perimetro, con quali limiti, secondo il loro livello e secondo il rischio.

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

Il «codice da PM», nella mia bocca, non è un insulto. Non significa che il codice di un PM sia necessariamente cattivo. Significa che è codice prodotto da qualcuno che non padroneggia molto bene, o non padroneggia più molto bene, il codice. Bisogna quindi accettare dei limiti. E soprattutto, bisogna accettare di definirli.

Verde, arancione, rosso

Non credo a una griglia universale.

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

Un piccolo strumento interno, personale, a vita breve, con un impatto limitato, può probabilmente vivere con poco formalismo. Se si rompe, non è grave. Si butta, si corregge, si va avanti.

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

E non appena si tocca la produzione critica, dati cliente sensibili, permessi, scritture irreversibili, workflow con un forte impatto cliente o di 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 jetable. Si può discutere della review. Si può discutere del livello di documentazione. Ma la sicurezza non dovrebbe dipendere dall'umore del momento.

Fortunatamente, gli sviluppatori hanno già molto strumentario per questo: integrazione continua, scanner, regole, pratiche, competenze, a volte persino prompt o skill interne. Il tema non è quindi reinventare tutto per i PM. È connettere i PM aumentati all'infrastruttura già esistente.

No, non credo alla review sistematica

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

Sono abbastanza diffidente nei confronti di questa risposta.

La review sistematica è diventata un riflesso, ma merita di essere discussa. Viene in particolare dal mondo open source, per ragioni molteplici: qualità, sicurezza, trasmissione, governance, fiducia tra contribuenti. Ma in un'azienda, per tutti i tipi di codice, in tutti i contesti, non sono convinto che tutto vada rivisto sistematicamente.

Se un PM si costruisce uno strumento personale, jetable, a basso rischio, bisogna davvero mobilizzare uno sviluppatore per rileggerlo? Forse no. Altrimenti si ricrea esattamente la dipendenza che si cercava di ridurre.

In compenso, la review può avere un ruolo all'inizio, per aiutare i PM ad acquisire buone pratiche. Può anche essere necessaria secondo le poste in gioco. Ancora una volta, non è sì o no. È una questione di rischio.

A un certo punto, bisogna anche accettare la responsabilità. Se decido di costruirmi uno strumento, bisogna accettare di mangiare la propria cucina. Se ci sono bug, tocca a me arrangiarmi. 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 mezzi per mantenere il controllo su codice che non si è interamente scritto da soli.

Claude non scrive spontaneamente i test giusti se non glielo si chiede. Può dimenticare. Può scrivere i test a posteriori. Può scrivere test che validano la sua implementazione piuttosto che l'intenzione di business. Può dare l'impressione che il prodotto sia sicuro perché ci sono test, mentre manca una vera strategia di test.

Un PM non conosce necessariamente il TDD. Non conosce necessariamente la differenza tra un test unitario, un test di integrazione, un test end-to-end. Non conosce necessariamente la piramide dei test. Non sa sempre quando testare un comportamento prima di codificarlo, 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. È molto per un progetto di questa dimensione. La maggior parte delle volte, non si rompe nulla, proprio perché Claude rilancia i test molto spesso. Quando si rompe qualcosa, i test danno un punto d'appoggio. Permettono di capire dove il comportamento atteso non è più rispettato.

Non dico che tutto debba essere testato con lo stesso livello di esigenza. Un piccolo strumento interno molto semplice, a basso rischio, non ha necessariamente bisogno di una strategia di test completa. Ancora una volta, è una questione di ampiezza.

Ma non appena il prodotto diventa più serio, i test non sono un bonus. Diventano parte del volante.

I rail accelerano tanto quanto proteggono

Quando parlo di rail, non parlo solo di guardrail che impediscono ai PM di fare stupidaggini.

I rail servono anche ad andare più veloce.

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

In compenso, se gli sviluppatori forniscono dei rail, il PM e l'IA sanno dove andare.

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

Si può immaginare, per esempio, un ambiente dove un PM può creare schermi interni, requester, liste, grafici, o scenari di business, appoggiandosi su API documentate e validate. Tutta l'infrastruttura tecnica è costruita dagli sviluppatori. Il PM non parte da una pagina bianca. Compone all'interno di un quadro.

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

Il punto importante è lì: i rail non rallentano solo. Accelerano, perché evitano all'IA di prendere la strada sbagliata.

Dal piccolo strumento interno al product builder

C'è forse un gradino supplementare.

Fino a qui, si potrebbe credere che stia parlando solo di piccoli strumenti interni: uno schermo di consultazione, un export, un dashboard, un requester, un'interfaccia temporanea per aiutare il prodotto. Questo caso esiste, ed è già interessante. Può alleggerire gli sviluppatori, accelerare il quotidiano, permettere a un team prodotto di rispondere da solo a certi bisogni.

Ma non è necessariamente l'unico orizzonte.

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

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

La differenza è importante.

Nel caso del piccolo strumento interno, il PM costruisce spesso a lato del prodotto. Consuma API, aggrega informazioni, produce un'interfaccia utile per lui o per il suo team.

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

Ed è proprio lì che la qualità della codebase diventa decisiva. Una codebase mal inquadrata rinchiude il PM e l'IA nel bricolage. Una codebase leggibile, documentata, orientata al business e dotata di strumenti può al contrario aprire uno spazio di contribuzione 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 questo terreno esiste, allora il tema diventa molto più interessante di «i PM possono farsi i loro piccoli strumenti?». La vera domanda diventa: fino a dove un'organizzazione può permettere a profili prodotto di costruire direttamente certe parti del prodotto, senza perdere il controllo tecnico, la coerenza e la sicurezza?

E le spec in tutto questo?

Questa esperienza mi ha anche fatto riporre una domanda quasi provocatoria: bisogna ancora scrivere spec?

Non dico che le spec spariranno ovunque. Per molti prodotti, contesti, argomenti regolamentari, decisioni strutturanti, bisognerà sempre scrivere, inquadrare, discutere, documentare il perché.

Ma per certi strumenti interni, mi chiedo se la spec non stia cambiando di statuto.

Nel mio caso, non ho scritto spec. Mi sono lanciato. Ho costruito. Ho mostrato. Mi è stato detto: manca questo, servirebbe questo, per tale e tale 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 nel prodotto, poi generare dopo la documentazione funzionale dal codice?

Avevo scritto recentemente che la questione prodotto doveva 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 da esso. La spec non scompare necessariamente, ma non può più pretendere di essere durevolmente la verità del prodotto.

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

Forzo un po' il tratto, ovviamente. Ma non poi così tanto.

Il rischio organizzativo

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

Se tutti cominciano a costruire i propri piccoli strumenti nel proprio angolo, può andare velocemente in tutte le direzioni. Strumenti interni non mantenuti possono diventare importanti. Script jetable possono finire usati tutte le settimane. Uno schermo improvvisato per un team può diventare un passaggio obbligato. Uno strumento senza governance può diventare critico senza che nessuno lo 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, i dashboard costruiti in un angolo. Il vibe coding non crea il problema. Lo accelera, perché rende la produzione di strumenti più facile.

Ancora una volta, la risposta non è proibire. È definire le zone, i permessi, le responsabilità, i limiti, i rail.

Cosa cambia per gli sviluppatori

Non credo che i PM sostituiranno gli sviluppatori.

In compenso, penso che certi piccoli strumenti interni che si chiedeva agli sviluppatori potranno essere prodotti direttamente dai team 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 lasciare il cuore del prodotto per fare un piccolo strumento interno, un export, uno schermo di consultazione, un dashboard, un'interfaccia temporanea? Se una parte di queste richieste può essere assorbita altrove, non è necessariamente una cattiva notizia.

Ma questo non fa sparire il ruolo degli sviluppatori. Al contrario, può spostarlo. Diventano anche coloro che costruiscono i rail, le piattaforme, le API pulite, le convenzioni, gli ambienti sicuri in cui altri possono produrre senza rompere tutto.

Non è meno tecnico. È forse ancora più architetturale.

La fatica

Non voglio vendere questa esperienza come un momento solo euforico.

È stancante.

Fare più di 180 commit in quattro giorni, anche con un'IA, non è neutro. Non si batte tutto il codice, ma si pilota, si rilegge, si testa, si corregge, si decide, si riprende, si sorveglia, si rispiega. Si avanza molto velocemente, ma bisogna seguire la velocità.

Il vibe coding dà una sensazione di potenza, ma non è una potenza gratuita. Il PM diventa una sorta di pilota, architetto di prossimità, tester, reviewer, donatore di intenzione, guardrail. E se non ha abbastanza cultura tecnica, può ritrovarsi a pilotare qualcosa che non capisce davvero.

È qui che l'illusione di competenza è pericolosa.

Abbiamo già conosciuto questo con il no-code. Persone pensavano di non aver più bisogno di sviluppatori, poi scoprivano tre giorni dopo che un sito senza sicurezza, senza protezione contro gli attacchi brute force, senza circuit breaker, poteva molto rapidamente diventare un problema. Non era che lo strumento fosse cattivo. È che dava accesso a una potenza senza trasmettere automaticamente la cultura di sicurezza e di architettura che va con essa.

Il vibe coding pone lo stesso tipo di domanda.

Documento una traversata

Non ho una conclusione definitiva.

Ed è forse la sola conclusione seria possibile dopo quattro giorni.

Sono ancora nel mezzo del vibe coding. Continuo ad imparare. Continuo a vedere cosa funziona, cosa si rompe, cosa mi sfugge, cosa i test recuperano, cosa i rail accelerano, cosa il mio vecchio background tecnico mi permette ancora di sentire.

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

Per ora, ciò che vedo è una capacità nuova, molto potente, ma che non elimina le vecchie domande del software. Le rende a volte 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 va, né sapere cosa si rischia di rompere.

Allora continuo.

Documento una traversata.

Per saperne di più

La domanda prodotto deve partire dal codice sorgente In 8 giorni ho capito che il mestiere di Product Manager stava per cambiare completamente L'IA non dovrebbe servire solo a produrre dieci volte di più. Dovrebbe anche obbligarci a capire dieci volte meglio ciò che produciamo Code centric