C’è una conseguenza del vibe coding di cui parliamo ancora troppo poco: scrivere software non è mai stato così economico. O, più precisamente: non è mai stato così economico produrre la prima versione funzionante di un software.
Oggi basta descrivere un’esigenza, iterare un paio di volte con un’IA e trovarsi davanti a una UI credibile, un database, le API e l’autenticazione già configurata. È straordinario, ma rischia di farci trarre la conclusione sbagliata: se è stato facile costruirlo, allora il problema doveva essere semplice.
Non è così. È diventato economico scrivere il primo codice, non possedere il software nel tempo.
Il costo visibile e l’illusione della demo
Quando nasce un bisogno, il costo dell’implementazione iniziale è subito evidente. In poche ore puoi impostare un piccolo CRM o un sistema di ticketing pronto prima ancora di finire la riunione in cui si è deciso di farlo.
Ed è qui che confondiamo il costo di creare una soluzione con il costo di assumerne la responsabilità. Passata l’euforia della demo, emergono tutti i vincoli che la prima schermata non mostra:
Queste responsabilità non compaiono nei prompt, ma fanno parte del software tanto quanto il codice.
La domanda che conta davvero
Per anni la competenza distintiva di uno sviluppatore esperto è stata rispondere a: “Come possiamo costruire questa cosa?”
Oggi gli strumenti di AI coding propongono architetture e codice in pochissimo tempo. Di conseguenza, la domanda fondamentale si sposta un passo indietro:
“Dobbiamo davvero costruirla?”
E prima ancora: “Qual è esattamente il problema che stiamo cercando di risolvere?”
Sono domande meno spettacolari di una demo e non producono schermate da mostrare ai clienti, ma fanno risparmiare settimane — o mesi — di lavoro inutile.
Oltre il “Build vs Buy”: Possedere o Delegare?
Di fronte a un nuovo bisogno, il primo passo dovrebbe essere un’analisi di mercato mirata: capire se qualcuno ha già affrontato il problema tramite un SaaS, un modulo open source maturo o una funzionalità già presente negli strumenti aziendali. Il fatto che l’IA renda facile creare un’alternativa custom non rende quest’analisi superfluo: la rende indispensabile, proprio perché saltarla è diventato fin troppo semplice.
Tradizionalmente questo dilemma si riduce a build vs buy. Oggi la formulazione più utile è un’altra:
Questo problema voglio risolverlo o voglio possederlo?
Ogni volta che sviluppiamo software custom, stiamo decidendo di prendere in carico la gestione permanente di quel dominio. Costruire un’autenticazione significa possedere un problema di sicurezza; costruire un workflow engine significa possedere un problema di orchestrarlo nel tempo.
Questo non significa non dover mai sviluppare da zero. Ha senso farlo sui problemi che custodiscono il know-how aziendale e il fattore differenziante di prodotto. Ma la decisione deve essere consapevole, mossa dal valore strategico e non dalla falsa scorciatoia del “tanto ci mettiamo due giorni a farlo”.
Il vero ruolo della seniority
Il vibe coding non produce inevitabilmente codice di bassa qualità: con la giusta supervisione si possono creare ottime architetture in tempi record. Il vero rischio è un altro: quando il costo percepito dello sviluppo tende a zero, aumenta la tentazione di trasformare qualsiasi problema in software.
L’analisi iniziale serve proprio a evitare di accelerare nella direzione sbagliata. Prima di aprire l’IDE o il prompt, occorre mettere a fuoco i bisogni reali, i vincoli dei sistemi esistenti e le responsabilità operative che ci stiamo prendendo.
Un mio mentore una volta mi disse:
“Il vero senior non è quello che sa scrivere bene il codice. È quello che sa quando non scriverlo.”
In un’era in cui generare codice è diventato immediato, il valore si sposta sulla capacità di comprendere il contesto, valutare le conseguenze e decidere quali cose non dovremmo costruire affatto.