Se apri Twitter (o X) oggi, sembra che il mondo dello sviluppo software sia finito. O meglio, che sia stato democratizzato al punto che chiunque, armato di un prompt e di un abbonamento a Claude o ChatGPT, possa costruire il prossimo unicorno nel weekend.
Si chiama "Vibe Coding". È bello. Dà soddisfazione immediata. Ti fa sentire un mago. Per la prima volta nella storia, crea un common ground reale tra il reparto marketing, i founder non tecnici e gli sviluppatori. Permette di prototipare alla velocità della luce e di validare idee che prima avrebbero richiesto mesi.
Ma c’è un problema. Un problema enorme che separa il "vibe" dalla realtà industriale. Costruire una demo che funziona sul tuo laptop il sabato sera è una cosa. Mantenere un’infrastruttura in produzione, con clienti paganti, SLA da rispettare e API che cambiano o si rompono, è un altro sport.
In Weirdoo lo vediamo ogni giorno: aziende che arrivano con un PoC (Proof of Concept) "funzionante" che crolla miseramente appena tocca il traffico reale.
In questo articolo non ti parlerò di quanto è magica l'AI. Ti parlerò di cosa serve per farla funzionare davvero quando il gioco si fa duro. Parleremo di architettura, di costi, di latenza e di quella cosa noiosa ma fondamentale che si chiama Ingegneria del Software.
Partiamo da un concetto scomodo: se non sei uno sviluppatore e non hai competenze tecniche reali, con il "vibe coding" non hai idea di cosa stai costruendo.
C'è un caso recente che ha fatto scuola: un team di ragazzi ha ricostruito Lovable (un unicorno) in un solo weekend. Fa scena sui social? Tantissimo. È una dimostrazione di potenza incredibile? Assolutamente sì. Ma quei ragazzi, per quanto bravi, non sono Lovable. E quel clone, per quanto fedele, non è un'azienda da un miliardo di dollari. Perché Lovable non è solo l'interfaccia che vedi: è infrastruttura, sicurezza, la gestione di milioni di utenti concorrenti, il supporto, la compliance. Ricostruire la UI e fare un clone è la parte facile. Scalare il servizio è la parte difficile.
E qui nasce la domanda che faccio sempre ai founder entusiasti del loro MVP fatto con l'AI:
"Come ci metti mano quando il modello si inceppa, si blocca in un loop o viene deprecato da OpenAI/Anthropic domani mattina?"
Hai mai provato a usare strumenti come Claude Code in modo strutturato? E no non parlo di far generare un file PRD prima e basta. Parlo di gestire un progetto complesso: impostare milestone, definire una roadmap tecnica, gestire lo stato (state management) dell'applicazione. Se sei un senior dev, sai guidare l'AI dentro questi binari. Se non lo sei, è l'AI che guida te. E l'AI, lasciata sola, tende al caos.
C'è poi un errore cognitivo non da poco: il confirmation bias. Quando l'AI genera codice, tendiamo a fidarci. "Se compila, funziona". Ma l'AI non si fa domande di sicurezza, di performance, di scalabilità. L'AI vuole solo completare il pattern.
La professionalità tecnica non si costruisce in un weekend. Il Vibe Coding è ottimo per l'inizio, per la traction, per l'entusiasmo. Ma non confondiamo la vibe con l'ingegneria.
Il take di Weirdoo: Usa l'AI per accelerare, per prototipare, per l'MVP. Ma non illuderti che possa sostituire l'architettura.
Parliamo di soldi. Quando fai girare la tua demo in locale, spendere 5$ di API in un pomeriggio sembra niente. Quando vai in produzione, la matematica cambia. E cambia in modo esponenziale.
In Weirdoo abbiamo gestito progetti MVP basati su Generative AI dove abbiamo visto i costi schizzare alle stelle in pochi giorni. La differenza? Non ci siamo sorpresi.
Sapevamo che sarebbe successo. Avevamo l'esperienza per prevederlo e, soprattutto, avevamo un sistema di controllo di gestione dei costi attivo fin dal giorno zero. Sapevamo che salvare dati analitici grezzi chiamando GPT-4 per ogni singola riga di log era un suicidio finanziario, ma una scelta consapevole per l'MVP. Appena validata l'idea, abbiamo spento il "rubinetto" e ottimizzato.
Quanti founder o CTO improvvisati hanno questo controllo? Spoiler, basato sulla nostra esperienza: molto pochi.
La maggior parte si accorge del problema solo quando arriva la fattura di OpenAI a fine mese, che spesso supera i ricavi stessi del SaaS. L'AI in produzione non è solo codice. Devi sapere quanto ti costa ogni token, ogni utente, ogni interazione e quanto costa il database e il suo scaling. Se non lo sai, non hai un business, hai un hobby costoso.
L'AI è lenta. Rispetto a una query SQL o a una funzione Python classica, un LLM è geologicamente lento. Un utente abituato alla reattività di Instagram o Google non aspetterà 10 secondi fissando uno spinner che gira mentre il tuo wrapper pensa.
Come si risolve? Non (solo) con modelli più veloci, ma con l'architettura e la UX.
La prima regola è: non chiedere all'AI cose che sai già. Bisogna "cachare" (memorizzare) tutto ciò che è possibile. E non parlo solo del caching classico del browser. Parlo di:
Questo è un principio di UX generale, ma vitale con l'AI. L'interfaccia deve reagire immediatamente, anche se il server sta ancora pensando. Mostra uno scheletro della risposta, fai vedere che stai "scrivendo", dai un feedback istantaneo. L'utente tollera l'attesa solo se percepisce progresso.
Non aspettare che tutta la risposta sia pronta. Invia i token man mano che vengono generati. Sembra banale, ma molti wrapper aspettano il pacchetto completo, creando un effetto "freezing" devastante per l'esperienza utente.
C'è questa credenza mistica che l'AI possa prendere dati spazzatura e trasformarli in oro colato. Flippiamo il discorso: il principio GIGO (Garbage In, Garbage Out) è sempre esistito nella storia dell'informatica e sempre esisterà. Valeva per i database SQL negli anni '90, valeva per gli algoritmi di Random Forest, e vale ancora di più per gli LLM oggi.
Anzi, per gli LLM è peggio. Perché un algoritmo classico se riceve dati sbagliati spesso va in errore. Un LLM no. Un LLM allucina. Ti risponde con estrema sicurezza dicendo una falsità totale, basata su quel dato sporco che gli hai fornito nel contesto.
Ecco perché non dovresti fidarti mai di dare "direttamente" i dati del cliente al modello. Usiamo strati intermedi:
L'AI è una "Black Box". Se non costruisci un'impalcatura di controllo attorno ad essa, stai affidando la reputazione della tua azienda al caso.
Nessun sistema IT serio può esistere senza ridondanza. Se il tuo intero business dipende da un'unica chiamata API verso OpenAI, sei in pericolo. Cosa succede se le API vanno in down (e succede)? Cosa succede se cambiano i modelli?
In produzione, il concetto di Fallback è vitale. Devi avere un sistema di Health Check continuo:
Infine, un segreto che poche agenzie ti dicono perché vendere API è più facile: non tutto deve essere real-time.
Molti task aziendali (analisi di documenti, categorizzazione, reportistica) possono essere fatti in Batch (durante la notte) e, soprattutto, in Locale. Far girare un piccolo modello (Small Language Model) sul proprio server per processare migliaia di documenti non solo abbatte i costi ricorrenti, ma ti dà un controllo totale sulla privacy e sulla stabilità.
L'Intelligenza Artificiale Generativa è una rivoluzione tecnologica, nessuno lo nega. Ma non ha abolito le leggi del software.
Scalabilità, costi, latenza, gestione degli errori e qualità dei dati sono problemi che non si risolvono con un prompt migliore. Si risolvono con l'architettura.
Se stai costruendo un prodotto per il weekend, divertiti con il Vibe Coding. Ma se stai costruendo un'azienda, smetti di trattare l'AI come magia e inizia a trattarla come ingegneria.
Noi in Weirdoo facciamo questo. Non vendiamo il prompt, vendiamo l'infrastruttura che lo fa funzionare.
