Le undici di sera, un foglio Excel che scoppia, e una frase scritta in una chat
Capita quasi sempre di sera, questa scoperta. Chi gestisce un piccolo bed & breakfast, un agriturismo di sei-otto camere, una guesthouse a conduzione familiare, arriva a un certo punto della stagione — spesso è giugno, a volte è la settimana prima di Ferragosto — in cui il foglio Excel costruito nel tempo libero, aggiornato a colpi di “aggiungo una colonna”, “metto una formula qui”, semplicemente smette di reggere. Un #REF! rosso compare dove prima c’era un numero. Una formula di sconto che funzionava per le prenotazioni singole va in tilt quando arrivano tre camere insieme. Il calcolo del prezzo di bassa stagione si sovrappone, per un errore di data mai notato, a un weekend di alta stagione. Un disastro silenzioso.
Non è un problema nuovo. È vecchio quanto il turismo che tiene i conti da solo, senza un gestionale professionale alle spalle — che costa, che richiede formazione, che spesso è pensato per strutture più grandi. La novità, arrivata negli ultimi due anni con una velocità che ha sorpreso pure chi la studia da vicino, è cosa succede quando quella stessa persona, invece di richiudere il portatile e rimandare tutto al giorno dopo, apre una finestra di chat con un modello di intelligenza artificiale generativa e scrive, in italiano semplice, qualcosa del tipo: “Ho un B&B con quattro camere. Vorrei un calcolatore che mi dica il prezzo giusto in base al giorno della settimana, alla stagione e a quanti giorni mancano all’arrivo. Puoi farmelo?”
Risposta in trenta secondi. Uno strumento che, spesso, funziona davvero.
Questo articolo parla di quel momento — e di tutto ciò che viene dopo, che è la parte che quasi nessuno racconta quando mostra con entusiasmo lo screenshot del suo nuovo “gestionale fatto in casa” nel gruppo Facebook di categoria. Parla del vibe coding, l’espressione con cui da poco più di un anno si descrive la pratica di generare software funzionante descrivendo a parole cosa si vuole ottenere, lasciando che sia il modello a scrivere il codice — senza che chi lo chiede sappia leggerlo, tantomeno correggerlo se qualcosa va storto. Una pratica nata negli ambienti degli sviluppatori professionisti come scorciatoia veloce per prototipare, e migrata in fretta — troppo in fretta, secondo alcuni — verso un pubblico che di programmazione non sa nulla e non ha nessuna intenzione di impararla. Piccoli imprenditori turistici compresi.
Proveremo a tenere insieme due cose che raramente vengono raccontate nello stesso pezzo: la portata reale di questa possibilità — creare un calcolatore di preventivi, un modulo di prenotazione su misura, un piccolo cruscotto di controllo, senza pagare mesi di sviluppo software — e il rischio, altrettanto reale, che si annida proprio nella facilità con cui questi strumenti nascono. Un rischio che ha un nome tecnico, debito tecnico, e una caratteristica che lo rende particolarmente insidioso in questo contesto specifico: resta invisibile a chi non ha gli strumenti concettuali per vederlo. Useremo un caso costruito apposta per essere fittizio — lo dichiariamo da subito, senza trucchi — per mostrare come questo rischio smetta di essere un’astrazione da manuale e diventi, in una notte di fine mese, un problema di conto in banca. Concreto, non teorico.
Inquadramento Teorico: cosa significa davvero “parlare” a una macchina invece di programmarla
Vibe coding: una definizione che non è solo moda linguistica
Il termine vibe coding lo ha coniato, o meglio: lo ha reso improvvisamente popolare con un post diventato virale nel febbraio 2025, Andrej Karpathy — informatico, tra i fondatori di OpenAI, per anni direttore dell’intelligenza artificiale presso Tesla, prima ancora ricercatore di punta nei laboratori di visione artificiale di Stanford. Non un blogger qualunque che gioca a inventare parole nuove per farsi notare: una delle voci più ascoltate al mondo su dove sta andando l’AI applicata al software. Una voce pesante.
Nella sua descrizione originale, Karpathy racconta di essersi trovato a scrivere codice “abbandonandosi completamente alle vibrazioni, abbracciando gli esponenziali, dimenticando che il codice esiste anche” — la traduzione perde volutamente un po’ di ironia dell’originale inglese, ma il senso resta chiaro: si descrive a parole, in linguaggio naturale, cosa si vuole che il software faccia, si lascia che il modello scriva il codice, e si smette — questo è il punto — di leggere ogni riga, di controllare ogni funzione, di capire cosa succede sotto. Si guarda solo se il risultato, alla fine, sembra funzionare. Karpathy lo descriveva, va detto con onestà, come un modo di lavorare per prototipi personali, per weekend hackathon, per “progetti usa e getta” su cui non contava nessun altro. Non lo proponeva come metodo per costruire strumenti che maneggiano soldi veri di clienti veri. Lui lo sapeva.
Eppure è esattamente lì che il vibe coding sta arrivando oggi. Nelle mani di chi gestisce una piccola struttura ricettiva e ha scoperto che un modello linguistico può scrivere, in pochi minuti, uno script che calcola un preventivo, un modulo HTML che raccoglie una prenotazione, una piccola pagina che mostra quante camere restano libere questo weekend. Cose che fino a poco tempo fa richiedevano un preventivo da un’agenzia web, settimane di attesa, qualche migliaio di euro. Oggi richiedono una conversazione. A volte due.
Concretamente, di cosa parliamo quando parliamo di piccoli strumenti nati dal vibe coding dentro una struttura ricettiva? Tre esempi bastano a rendere l’idea, perché sono quelli che tornano più spesso nelle conversazioni tra colleghi durante i corsi serali di formazione. Il primo è il calcolatore di preventivi: una pagina, spesso incorporata nel sito già esistente, che chiede al visitatore le date, il numero di ospiti, magari qualche servizio accessorio — colazione, parcheggio, animale ammesso — e restituisce un prezzo finale calcolato secondo regole che il proprietario ha semplicemente raccontato a voce, senza dover commissionare un modulo su misura a un’agenzia web e attendere settimane. Il secondo è il modulo di prenotazione personalizzato: non il solito widget generico preso in affitto da una piattaforma terza, uguale per tutti, ma un form costruito apposta per le esigenze specifiche di quella struttura — una domanda in più sull’orario di arrivo previsto, un campo dedicato alle intolleranze alimentari per chi include la mezza pensione, una casella per segnalare un animale al seguito. Il terzo, forse il più diffuso tra chi gestisce più canali di vendita insieme, è il cruscotto semplice: una schermata che raccoglie in un unico colpo d’occhio occupazione, incassi previsti, recensioni recenti — dati che altrimenti restano sparsi tra tre o quattro pannelli diversi di altrettante piattaforme, ciascuna con il proprio login, la propria interfaccia, il proprio linguaggio da imparare daccapo.
Vale la pena distinguere, con un minimo di precisione, il vibe coding dagli strumenti no-code che il turismo usa già da anni — i costruttori di siti a blocchi, i moduli di prenotazione preconfezionati, le piattaforme di email marketing con l’automazione a schemino. Il no-code offre blocchi predefiniti, testati da chi li ha costruiti, dentro i quali ci si muove con margini limitati ma sicuri: non si può rompere ciò che non si può toccare. Il vibe coding è un’altra cosa. Genera codice vero, originale, scritto su misura per quella singola richiesta — flessibile quanto si vuole, ma anche fragile quanto lo è qualunque software scritto in fretta, senza un secondo paio d’occhi che lo controlli, senza nessuno che lo abbia mai davvero testato prima che tocchi un cliente reale. Nessun freno incorporato.
Gli strumenti concreti con cui questo accade oggi sono già familiari a chi segue anche solo per curiosità il dibattito tecnologico: assistenti conversazionali generalisti come Claude o ChatGPT, capaci di scrivere ed eseguire codice dentro la stessa finestra di chat; ambienti di sviluppo assistito come Replit o Cursor, pensati in origine per programmatori professionisti e sempre più usati anche da chi non lo è affatto; piattaforme che generano intere applicazioni web a partire da una singola descrizione in linguaggio naturale, come Lovable o Bolt. Cambia il nome, cambia l’interfaccia grafica. Il meccanismo di fondo resta identico: parole in ingresso, software funzionante in uscita, nessun passaggio intermedio in cui un essere umano competente rilegga il codice riga per riga prima che vada online.
McCarthy, Simon e la lunga rincorsa verso una macchina che colma i nostri limiti
Per capire dove si colloca storicamente questo momento — perché non è un fulmine a ciel sereno, è piuttosto l’ultimo anello di una catena lunga settant’anni — bisogna tornare all’estate del 1956, al Dartmouth College, dove un giovane matematico di nome John McCarthy organizza, insieme a Marvin Minsky, Nathaniel Rochester e Claude Shannon, un seminario di due mesi che nella proposta di finanziamento porta per la prima volta, nero su bianco, l’espressione “intelligenza artificiale”. La proposta parte da un’ipotesi ambiziosa quanto vaga: “ogni aspetto dell’apprendimento, o qualsiasi altra caratteristica dell’intelligenza, può in linea di principio essere descritto con tale precisione che una macchina può essere costruita per simularlo”. Una scommessa, allora.
Settant’anni. Ci sono voluti settant’anni perché quella frase, allora poco più di una scommessa intellettuale, diventasse la conversazione serale tra il gestore di un agriturismo in Val di Cecina e un modello linguistico che gli scrive un calcolatore di preventivi mentre lui beve un bicchiere di vino in cucina. McCarthy non avrebbe potuto immaginare la forma precisa. Avrebbe però riconosciuto, quasi certamente, l’idea di fondo: una macchina a cui si descrive un problema, e che restituisce una soluzione operativa, senza che l’utente debba conoscere la meccanica interna che la produce.
C’è un secondo nome, meno citato nel dibattito pubblico ma altrettanto centrale, che aiuta a leggere questa storia — la promessa, certo, ma soprattutto il rischio che ci si porta dietro: Herbert Simon, psicologo cognitivo, economista, tra i padri fondatori dell’intelligenza artificiale insieme al collega Allen Newell — con cui costruisce già nel 1956 il Logic Theorist, spesso indicato come il primo vero programma di AI della storia. Simon vince il Premio Nobel per l’economia nel 1978, non per un lavoro sui computer, ma per una teoria che aveva formulato già negli anni Cinquanta: la bounded rationality, la razionalità limitata. L’idea, spogliata del linguaggio accademico, è semplice da enunciare e scomoda da accettare: nessun essere umano decide in modo perfettamente razionale, perché nessuno ha mai tempo illimitato, informazione completa, capacità di calcolo infinita per valutare ogni alternativa possibile. Si soddisfa, dice Simon con un verbo che ha coniato apposta — satisfice, crasi tra satisfy e suffice — cioè ci si accontenta della prima soluzione abbastanza buona, non della migliore in assoluto, perché cercare la migliore costerebbe più di quanto valga il guadagno marginale. Semplice, in teoria.
Chi gestisce da solo un piccolo B&B, senza un ufficio amministrativo, senza un reparto IT, senza le ore per studiare un corso di programmazione, è il ritratto da manuale della razionalità limitata di Simon. Non ha tempo per imparare Python. Non ha budget per uno sviluppatore su commissione. Ha, però, ora, uno strumento che promette di colmare esattamente quel divario cognitivo e organizzativo — descrivere il problema a parole, ottenere una soluzione funzionante, senza dover acquisire la competenza tecnica sottostante. È la promessa dell’intelligenza artificiale applicata alla piccola impresa nella sua forma più seducente: non serve capire il motore, basta sapere dove si vuole andare. Suona bene, no?
Il punto scomodo, quello su cui Simon stesso — se potesse osservare la scena — probabilmente insisterebbe, è che il satisficing non sparisce quando si delega a un’intelligenza artificiale. Si sposta. Chi ha generato il proprio calcolatore di preventivi parlandone con un chatbot smette di valutare la qualità dello strumento nel momento esatto in cui questo “sembra funzionare abbastanza bene”. Non lo testa oltre. Non chiede: cosa succede se manca un dato? Cosa succede in un caso limite che non ho pensato di descrivere? La stessa scorciatoia cognitiva che rende utile l’AI generativa nel turismo è quella che, un paio di pagine più avanti in questo articolo, produce il conto salato.
Analisi Critica e Sfide: la fragilità che non si vede a occhio nudo
Il debito tecnico invisibile: quando nessuno sa leggere la cambiale che ha firmato
Nel gergo degli sviluppatori professionisti, debito tecnico indica una scorciatoia presa consapevolmente sotto pressione di scadenza: si scrive del codice che funziona ma non è pulito, sapendo che andrà rifatto meglio più avanti, e nel frattempo si paga un interesse — più tempo per ogni modifica successiva, più rischio di errori nascosti. È un concetto nato per squadre che sanno di avere contratto un debito, lo tracciano, decidono quando e come ripagarlo. Scelta consapevole, quella.
Nel vibe coding applicato da un non programmatore la situazione cambia natura, non solo intensità. Non è una scorciatoia presa consapevolmente. È un debito contratto senza che nessuno, nella stanza, sappia leggere il contratto. Chi ha generato il proprio modulo di prenotazione parlando con un modello AI non ha preso una decisione informata di accettare del codice “non perfetto ma funzionante” — semplicemente non ha gli strumenti per distinguere il codice pulito da quello fragile. Vede un’interfaccia che sembra a posto. Vede numeri plausibili. Per lui, quello è tutto quello che esiste da vedere. Punto cieco totale.
Qui si annida il primo problema serio, quello che la letteratura sull’ingegneria del software chiama assenza di test: procedure — automatiche o manuali — pensate apposta per verificare che il programma si comporti correttamente anche nei casi limite. Cosa succede se una prenotazione arriva esattamente a mezzanotte tra due tariffe stagionali diverse? Se un cliente prenota per il 29 febbraio di un anno bisestile? Se due prenotazioni arrivano nello stesso identico secondo per l’ultima camera disponibile? Uno sviluppatore professionista, per mestiere, si pone queste domande prima che il codice vada online, e scrive test specifici per ciascun caso. Chi fa vibe coding senza background tecnico non sa nemmeno che questa categoria di domande esista. Non per pigrizia. Per ignoranza incolpevole di un mestiere che non è il suo.
Il risultato è uno strumento che sembra finito. L’interfaccia è pulita, magari persino gradevole — i modelli generativi sono ormai piuttosto bravi anche nell’estetica. I numeri escono. Tutto sembra a posto, per settimane, a volte per mesi, esattamente come un ponte può reggere il traffico quotidiano per anni prima che un carico anomalo, mai previsto in fase di progetto, ne riveli la crepa strutturale. La differenza è che un ponte lo progetta, lo verifica e lo firma un ingegnere abilitato, con una responsabilità professionale precisa. Un calcolatore di prezzi generato in una chat serale non passa da nessuna firma, da nessuna verifica, da nessuna assicurazione professionale. Passa direttamente in produzione. Cioè: direttamente a contatto con i soldi veri di clienti veri.
C’è poi un effetto psicologico che merita di essere nominato con precisione, perché aggrava tutto il resto: un’intelligenza artificiale generativa produce testo e numeri con la stessa fluidità, sbagli o non sbagli. Non esita, non balbetta, non mostra incertezza nel tono — un prezzo calcolato male esce con la stessa sicurezza grafica, lo stesso carattere tipografico pulito, la stessa immediata leggibilità di un prezzo calcolato bene. Chi legge un numero ben impaginato tende, per un riflesso cognitivo tutt’altro che stupido — è lo stesso meccanismo di fiducia che si applica a un referto medico scritto in un linguaggio tecnico rassicurante, a un contratto stampato in un carattere professionale — ad attribuirgli più credibilità di quanta ne meriti davvero. La fluidità della forma diventa, per chi non ha modo di verificare la sostanza, una prova surrogata di correttezza. Non lo è. Non lo è mai stata, nemmeno prima che arrivasse l’AI a rendere questa illusione più elegante di un tempo.
Il calcolatore di preventivi è solo l’esempio più facile da raccontare, non l’unico. Nei gruppi Facebook di categoria, nelle chat WhatsApp tra colleghi albergatori, circolano ormai da mesi screenshot di strumenti nati nello stesso identico modo: un modulo di prenotazione personalizzato che raccoglie richieste speciali e le smista via email senza passare dal gestionale ufficiale; un piccolo chatbot che risponde alle domande frequenti sul sito, addestrato incollando le vecchie mail di richiesta informazioni; un cruscotto che aggrega in un’unica schermata occupazione, incassi e recensioni prese da tre portali diversi. Tutti costruiti con lo stesso metodo — descrivere, generare, pubblicare — e tutti esposti, in misura diversa, allo stesso rischio strutturale. L’automazione turistica fai-da-te, quella nata da una conversazione e non da un capitolato tecnico, si è diffusa più in fretta della cultura necessaria a maneggiarla con prudenza. Sempre più veloce. Lo vedo spesso nei corsi che tengo sull’intelligenza artificiale applicata al turismo: l’entusiasmo per la rapidità dello strumento supera quasi sempre, nei primi mesi, la prudenza necessaria a maneggiarlo bene.
Il prompt che si accumula: come la complessità cresce senza che nessuno se ne accorga
C’è una seconda dinamica, più lenta e più subdola della prima, che merita attenzione a parte: quello che in gergo informale si potrebbe chiamare l’accumulo silenzioso di richieste. Lo strumento nasce semplice: “calcolami il prezzo in base al giorno della settimana”. Poi, con il tempo, cresce a piccoli passi, ciascuno ragionevole preso da solo. “Aggiungi uno sconto per chi prenota con più di trenta giorni di anticipo.” “Aggiungi una maggiorazione per il weekend.” “Aggiungi uno sconto last minute se mancano meno di sette giorni e le camere sono ancora vuote.” “Aggiungi un moltiplicatore per agosto.” Ogni richiesta, isolata, è comprensibile a chi la formula. La somma di dieci richieste fatte in dieci sere diverse, in dieci mesi diversi, diventa un sistema di regole intrecciate che nessuno — nemmeno chi lo ha commissionato pezzo per pezzo — riesce più a ricostruire mentalmente nella sua interezza.
Un team di sviluppo professionale gestisce questa crescita con strumenti precisi: un sistema di controllo di versione che tiene traccia di ogni modifica, un ambiente di prova separato da quello reale dove si testano i cambiamenti prima di pubblicarli, una procedura per tornare indietro rapidamente se qualcosa si rompe. Il vibe coding artigianale, quello fatto in una chat aperta sul portatile di casa, quasi mai replica questi presidi. Si modifica direttamente lo strumento che i clienti stanno già usando. Non esiste un “prima lo provo in laboratorio”. Esiste solo “lo cambio e vediamo”. Rischioso, ma comodo.
Non serve altro, a questo punto, se non un caso concreto per vedere come questi due problemi — assenza di test, accumulo silenzioso di regole — smettano di essere teoria e diventino una faccenda di bonifici bancari e recensioni da gestire.
Case Study: “Prezzo Vivo”, il calcolatore dinamico del Podere di Mezzavia
Come nasce lo strumento — un caso interamente inventato, per essere chiari fin da subito
Quanto segue è una ricostruzione di fantasia, costruita apposta per illustrare un meccanismo ricorrente. Nomi, luogo, cifre: tutto inventato. Nessun agriturismo reale, nessun proprietario in carne e ossa, nessuna cifra tratta da un bilancio vero. Serve a mostrare un pattern — quello del bug silenzioso in uno strumento di pricing generato con il vibe coding — non a raccontare un episodio realmente accaduto a qualcuno di identificabile.
Il Podere di Mezzavia, otto camere tra le colline dell’entroterra volterrano, lo gestisce da dodici anni Michele Pardini, quarantasette anni, insieme alla moglie e a una collaboratrice stagionale che arriva da maggio a settembre. Per anni il prezzo delle camere lo ha deciso a occhio, con un foglio Excel diviso per stagioni e un pizzico di intuito accumulato in oltre un decennio di prenotazioni. Funziona, più o meno. Quasi sempre. Ma Michele nota, negli ultimi due anni, che le strutture vicine — quelle con budget più ampi — usano software di pricing dinamico che aggiustano il prezzo giorno per giorno in base all’occupazione, e sembrano riempire le camere meglio di lui proprio nei weekend in cui lui, con il suo prezzo fisso stagionale, o lascia soldi sul tavolo o resta vuoto.
Un abbonamento a uno di questi software professionali costa, tra i duecento e i quattrocento euro al mese secondo i preventivi che ha raccolto. Troppo, per otto camere. Durante un corso serale organizzato dall’associazione di categoria della sua zona — un corso su come usare l’intelligenza artificiale nella piccola impresa turistica, di quelli che negli ultimi due anni si moltiplicano in tutta Italia — sente parlare per la prima volta della possibilità di costruirsi da solo uno strumento simile, semplicemente descrivendolo a un’AI generativa. Torna a casa quella sera con un’idea che gli sembra, testuali parole raccontate poi a un amico, “troppo bella per essere vera”. Non lo era.
Nell’arco di quattro sere, dopo cena, portatile in cucina, Michele costruisce — parlando, correggendo, riprovando — quello che comincia a chiamare in famiglia “Prezzo Vivo”. Descrive al modello: un prezzo base per ogni tipo di camera; una maggiorazione del venti per cento per i weekend; un moltiplicatore dell’uno virgola quattro per il mese di agosto e per le settimane a cavallo di eventi locali; uno sconto crescente quando l’occupazione futura, letta da un foglio Google condiviso con il suo sistema di prenotazione, risulta bassa — l’obiettivo dichiarato è “riempire comunque le camere piuttosto che tenerle vuote”; uno sconto last minute aggiuntivo per le date entro sette giorni dall’arrivo, se ci sono ancora camere libere. Il modello scrive uno script che legge il foglio Google, calcola il prezzo del giorno, e lo invia — tramite un plugin già installato sul sito — al motore di prenotazione diretta e ai due portali OTA collegati.
Funziona. Michele lo testa per due settimane guardando i prezzi comparire sul cruscotto, li confronta a mano con quello che avrebbe deciso lui, li trova ragionevoli, a volte persino più intelligenti di quanto avrebbe fatto lui stesso. Lo mostra, orgoglioso, a due colleghi durante una riunione dell’associazione. Uno gli chiede chi glielo ha programmato. “Nessuno”, risponde Michele. “L’ho scritto io. O meglio: gliel’ho raccontato io, e lui l’ha scritto.” Ride, mentre lo dice. Non sa ancora che quella frase, tra qualche mese, gli tornerà in mente in tutt’altro tono.
Il dettaglio sporco: una cella vuota, uno sconto che si somma a un altro sconto, e due settimane di camere quasi regalate
Passano sei mesi. Lo strumento gira senza intoppi apparenti, aggiornando i prezzi ogni notte alle tre, in automatico. Poi, un martedì di fine mese che coincide — pura sfortuna del calendario — con la settimana della sagra paesana, l’evento che porta ogni anno il tutto esaurito nel raggio di quindici chilometri, qualcosa si rompe senza fare rumore.
Un aggiornamento del plugin del sito, installato in automatico durante la notte per una patch di sicurezza, cambia leggermente il modo in cui il sistema di prenotazione esporta i dati di occupazione verso il foglio Google che “Prezzo Vivo” legge ogni notte. Per dodici giorni consecutivi, le celle che dovrebbero contenere la percentuale di occupazione futura restano vuote. Non con un errore visibile. Semplicemente vuote. Bianche.
Lo script, mai istruito a gestire esplicitamente una cella vuota — perché nessuno, in fase di “conversazione con l’AI”, aveva mai pensato di dire “e se il dato manca?” — interpreta il vuoto come uno zero. Zero per cento di occupazione futura. Il valore più basso possibile. E la regola dello sconto crescente, quella pensata per “riempire comunque le camere”, si attiva alla sua massima intensità: sconto pieno. Nello stesso momento, per quelle stesse date — a meno di sette giorni dall’arrivo — si attiva anche lo sconto last minute. I due sconti, mai pensati per sommarsi (nessuno lo aveva chiesto esplicitamente, ma nessuno aveva nemmeno chiesto il contrario), si moltiplicano l’uno sull’altro. Nessun limite minimo era stato previsto nel codice. Nessun “il prezzo non può mai scendere sotto i quaranta euro a notte”. Il risultato: quattro euro e novanta centesimi a notte per una doppia che normalmente, in quella settimana di sagra, ne varrebbe centoventi.
Il prezzo, sincronizzato automaticamente ogni notte verso i portali OTA, viene visto — e prenotato, in tempo reale, senza nessuna revisione umana di mezzo — da chiunque stesse cercando una camera in quella zona in quei giorni. In trentasei ore, sei delle otto camere del Podere di Mezzavia risultano prenotate per l’intera settimana della sagra al prezzo simbolico generato dal bug. Gli ospiti, va detto per onestà, non hanno fatto nulla di scorretto: hanno prenotato a un prezzo pubblicato, in buona fede, come farebbe chiunque.
Michele se ne accorge — questo è forse il dettaglio più scomodo dell’intera vicenda — solo a fine mese, mentre riconcilia gli estratti dei pagamenti OTA con quello che si aspettava di incassare. Numeri che non tornano. Li rilegge. Non tornano lo stesso. Ha la sensazione fisica, lo racconterà più tardi, di uno stomaco che si stringe di colpo, la stessa contrazione improvvisa che si prova quando si scende un gradino che non c’era. Le dita, sulla tastiera, scorrono la stessa riga tre volte, come se la quarta lettura potesse restituire un numero diverso da quello già visto tre volte identico. Non lo restituisce. Chiama la moglie in cucina senza dire perché, le mostra lo schermo in silenzio. Quella sera cenano tardi, e parlano poco. Il calcolo, fatto la mattina dopo con più freddezza — o quella che riesce a simulare — porta a una perdita netta stimata in poco più di tremilaquattrocento euro rispetto al prezzo che avrebbe dovuto applicare in una settimana già tutta prenotata. Soldi che, semplicemente, non arriveranno mai, perché le prenotazioni sono già confermate, gli ospiti in parte già arrivati, e cancellarle a ritroso avrebbe un costo reputazionale che Michele giudica — a ragione — persino peggiore del danno economico diretto.
La correzione: non si torna a Excel, si mettono paletti e occhi umani nel sistema
La reazione di Michele, nelle settimane successive, non è buttare via lo strumento. È — con l’aiuto stavolta di un amico, non un programmatore di professione ma un commercialista con qualche infarinatura di fogli di calcolo avanzati e macro — tornare dallo stesso modello AI e chiedere, questa volta con la lezione ben chiara in testa, tre correzioni precise.
Primo: un prezzo minimo assoluto, sotto il quale lo script non può scendere qualunque combinazione di sconti si attivi — Michele lo fissa, dopo qualche discussione con la moglie, a cinquantacinque euro a notte per la doppia standard, indipendentemente da quanti sconti si sommino tra loro. Secondo: un controllo esplicito sui dati mancanti — se la cella di occupazione futura risulta vuota, lo script non deve più interpretarlo come zero, deve bloccare l’aggiornamento automatico di quella singola data e mandare un messaggio WhatsApp a Michele, generato in automatico, con scritto “dato mancante per il giorno X, prezzo non aggiornato, controlla a mano”. Terzo, il più faticoso da accettare per chi si era abituato alla comodità della piena automazione: una revisione umana quindicinale, ogni due settimane, in cui Michele si siede quindici minuti — non di più, si è imposto un limite anche a questo, per non trasformarla in un secondo lavoro — e confronta a occhio i prezzi che lo strumento propone per le settimane successive con quello che si aspetterebbe lui stesso, segnalando qualunque numero che “non gli torna” prima ancora di capire tecnicamente perché.
Non è tornato a Excel. Ha aggiunto ciò che uno sviluppatore professionista avrebbe messo fin dall’inizio: un limite, un allarme, un controllo periodico. Cose minime. Non richiedono di saper programmare. Richiedono di aver capito, una volta, sulla propria pelle — o meglio: sul proprio conto in banca — che uno strumento funzionante non è la stessa cosa di uno strumento sicuro.
Vale la pena aggiungere un ultimo tassello a questa vicenda inventata, perché è quello che la rende utile oltre il singolo caso. Nei mesi successivi, Michele racconta l’episodio — depurato dai dettagli più imbarazzanti, ma non dalla sostanza — durante un incontro dell’associazione di categoria a cui partecipa da anni. Non lo fa per vanità, né in cerca di compassione. Lo fa, spiega, perché “se è successo a me con la poca esperienza che ho, può succedere a chiunque stia facendo la stessa cosa senza saperlo”. Due colleghi presenti in sala ammettono, con qualche imbarazzo, di avere già strumenti simili attivi da mesi, costruiti nello stesso identico modo, mai dotati né di un prezzo minimo né di un controllo periodico. Tornano a casa quella sera con l’intenzione — sulla carta più semplice di quanto si creda — di aggiungere anche loro gli stessi tre presidi. Non tutti lo fanno davvero, va detto senza indorare la pillola: l’inerzia organizzativa, in una piccola impresa gestita da due o tre persone che fanno già mille cose insieme, resta un ostacolo concreto quanto il bug che lo ha reso necessario.
Implicazioni Etiche e Normative: chi paga quando lo strumento fatto in casa sbaglia
La responsabilità non sparisce solo perché “l’ha scritto l’intelligenza artificiale”
Il caso del Podere di Mezzavia, per quanto costruito a tavolino, tocca una domanda che diventerà via via più concreta man mano che il vibe coding si diffonde tra chi gestisce piccole strutture: chi risponde, giuridicamente, quando uno strumento generato con l’AI produce un danno economico? La risposta, allo stato attuale della normativa italiana ed europea, non lascia molto spazio a interpretazioni consolatorie: risponde chi lo usa nella propria attività d’impresa, esattamente come risponderebbe se l’errore fosse nato da un foglio Excel scritto male o da un dipendente che ha sbagliato un calcolo a mano. Il fatto che il codice sia stato scritto da un modello linguistico non sposta la responsabilità verso il fornitore dell’AI, e non la sospende in un vuoto di nessuno.
Nel caso specifico — un errore che ha danneggiato economicamente la struttura stessa, senza ledere direttamente i clienti (che anzi hanno beneficiato, loro malgrado, del prezzo troppo basso) — il danno resta interno, assorbito da chi lo ha generato. Ma lo scenario cambia sostanza quando l’errore di uno strumento vibe-coded colpisce il cliente: un modulo di prenotazione che, per un bug di concorrenza mai testato, conferma due prenotazioni diverse per la stessa camera nella stessa notte; un calcolatore che mostra condizioni di cancellazione scorrette rispetto a quanto poi applicato in fattura; un cruscotto che comunica per errore una disponibilità che non esiste realmente. In tutti questi casi si applicano, senza sconti né eccezioni per la piccola dimensione dell’impresa, le regole ordinarie del diritto italiano dei contratti e del Codice del Consumo: la responsabilità precontrattuale per informazioni scorrette fornite in buona fede ma comunque errate (articoli 1337 e 1338 del Codice Civile), la responsabilità extracontrattuale per il danno ingiusto causato a un terzo (articolo 2043), le tutele specifiche del consumatore quando la controparte è un’impresa e non un altro privato.
Le condizioni d’uso dei principali fornitori di modelli AI generativi — che si tratti di un’azienda americana o di un’altra — escludono esplicitamente, quasi senza eccezione, ogni responsabilità per l’uso in produzione del codice generato senza revisione umana. Chi accetta quei termini al momento dell’iscrizione, spesso senza leggerli, accetta anche questa clausola. Significa, tradotto in pratica: se lo strumento generato con il vibe coding sbaglia e danneggia un cliente, l’azienda che ha fornito il modello AI non risponde. Risponde l’imprenditore turistico che lo ha adottato nella propria attività, allo stesso identico titolo con cui risponderebbe se avesse assunto un fornitore esterno che ha consegnato un lavoro difettoso senza controllarlo. Nessuna scorciatoia legale.
Un dettaglio pratico, spesso ignorato finché non serve davvero: la polizza di responsabilità civile che molte strutture ricettive sottoscrivono per i danni ai clienti — una caduta sulle scale, un’intossicazione alimentare — quasi mai copre esplicitamente un danno economico generato da un errore di calcolo di uno strumento software interno, tantomeno uno costruito senza alcun rapporto contrattuale con uno sviluppatore terzo che possa, a propria volta, essere chiamato a risponderne. Vale la pena, per chi adotta seriamente il vibe coding come pratica gestionale, chiedere espressamente al proprio broker assicurativo se questa fattispecie rientra nella copertura esistente o se serve un’integrazione — una domanda che oggi quasi nessun piccolo operatore pensa di porre, semplicemente perché il problema non gli si è ancora presentato.
C’è un secondo profilo normativo, più tecnico ma non meno concreto, che riguarda il trattamento dei dati personali dei clienti che passano attraverso questi strumenti. Un modulo di prenotazione costruito con il vibe coding invia spesso, senza che chi lo ha commissionato se ne renda pienamente conto, nome, email, numero di telefono e talvolta dati di pagamento verso il servizio cloud del fornitore del modello AI usato per generarlo o per farlo funzionare in tempo reale — un passaggio che, ai sensi del Regolamento Generale sulla Protezione dei Dati (GDPR, Regolamento UE 2016/679), richiederebbe una base giuridica precisa, un accordo di trattamento dati con il fornitore terzo, un’informativa aggiornata verso l’ospite che lo descriva con onestà. Quanti piccoli operatori, generando in una serata il proprio modulo di prenotazione, si sono fermati a verificare dove finiscono davvero i dati dei loro clienti? Suona quasi retorica, questa domanda. Nella pratica quotidiana osservata da chi fa formazione su questi temi, la risposta è quasi sempre la stessa: pochissimi, se non nessuno.
Un vuoto normativo che si allarga più in fretta di quanto la legge riesca a colmarlo
Il Regolamento europeo sull’intelligenza artificiale, il cosiddetto AI Act (Regolamento UE 2024/1689), entrato progressivamente in vigore proprio in questi mesi, disciplina con attenzione crescente i sistemi di AI ad alto rischio — quelli usati, per fare un esempio lontano dal turismo, nella selezione del personale o nella valutazione del credito. Uno script di pricing costruito in casa da un singolo agriturismo, per quanto possa fare danni concreti come si è visto, difficilmente rientra in queste categorie ad alto rischio definite dal Regolamento. Resta, in pratica, in una zona grigia: non vietato, non specificamente regolato, lasciato alle regole generali del diritto contrattuale e della responsabilità civile che esistevano già prima che l’AI generativa entrasse nelle cucine degli agriturismi toscani. Zona grigia, appunto.
Questo vuoto — normativo, ma prima ancora culturale — pesa in modo particolare su chi, per mestiere, introduce questi strumenti presso operatori senza formazione tecnica: consulenti, formatori, associazioni di categoria, camere di commercio che organizzano corsi su “come usare l’AI nella tua impresa turistica”. Mostrare a un pubblico di piccoli imprenditori quanto sia facile generare un calcolatore di preventivi in mezz’ora, senza accompagnare quella dimostrazione con un’indicazione altrettanto esplicita dei limiti — un prezzo minimo da fissare sempre, un controllo periodico da programmare, un piano per quando i dati mancano — significa lasciare la parte più debole della filiera, il piccolo operatore senza reparto IT, esposta a un rischio che chi insegna quella tecnica, quasi sempre, non corre in prima persona. È un rischio che sento mio, quando tengo corsi di alfabetizzazione digitale e intelligenza artificiale per piccoli operatori turistici: mostrare la scorciatoia senza dire chiaramente dove si può rompere sarebbe, ai miei occhi, una forma di scorrettezza professionale.
Non serve trasformare un corso di alfabetizzazione digitale in un corso di ingegneria del software. Serve — e questo è già alla portata di chiunque insegni queste materie oggi — una lista minima di domande di buon senso da porre prima di mettere in produzione qualunque strumento nato da una conversazione con un’AI: cosa succede se un dato manca? C’è un limite minimo e uno massimo oltre il quale l’automazione si ferma e chiede conferma umana? Chi, e con quale frequenza, guarda i numeri prodotti dallo strumento prima che tocchino un cliente vero? Non servono competenze da programmatore per rispondere a queste tre domande. Serve solo l’abitudine a porsele. Poco, ma essenziale.
Conclusioni e Takeaways: la vibrazione giusta è quella che sa fermarsi
Settant’anni dopo la scommessa di McCarthy a Dartmouth, la macchina capace di “simulare aspetti dell’apprendimento umano” si è materializzata in una forma che nessuno dei presenti a quel seminario avrebbe probabilmente previsto: una chat, aperta la sera in cucina, a cui un imprenditore turistico senza background tecnico racconta un problema di prezzi e riceve, in cambio, uno strumento che funziona. Herbert Simon aveva già scritto, decenni prima che questo diventasse possibile, la chiave per capire sia la promessa sia il rischio di questa scena: la razionalità umana è limitata, ci si accontenta della prima soluzione abbastanza buona, e questo vale tanto per chi costruisce lo strumento quanto — un dettaglio che si dimentica facilmente — per chi decide quando fermarsi a controllarlo. Semplice a dirsi.
Karpathy stesso, quando ha coniato l’espressione che dà il titolo a questo articolo, parlava di prototipi personali, non di prezzi reali venduti a clienti reali. Il vibe coding applicato al turismo di piccola dimensione porta con sé una promessa concreta — democratizzare strumenti che fino a ieri costavano migliaia di euro e settimane di attesa — e un rischio altrettanto concreto, quello di scambiare “funziona” per “è sicuro”. Non sono la stessa cosa. Non lo sono mai state, nemmeno prima che arrivasse l’AI generativa a rendere la distanza tra le due meno visibile che mai.
Nessuno, in questo percorso, chiede a un piccolo albergatore di diventare programmatore. Sarebbe una richiesta assurda, oltre che inutile: il valore del vibe coding sta esattamente nel fatto che elimina quella barriera. Ma eliminare la barriera per scrivere codice non elimina, insieme, la barriera per capire cosa quel codice non sa fare da solo — dove non arriva, cosa non prevede, quale caso limite non ha mai incontrato durante i pochi giorni di test fatti in casa. La differenza tra chi userà questi strumenti per anni senza incidenti e chi si troverà, come Michele, a fissare un estratto conto che non torna, si giocherà su un margine sottile: non la bravura nello scrivere il prompt giusto, ma l’abitudine — poco spettacolare, mai raccontata negli screenshot entusiasti — a chiedersi, ogni tanto, cosa succede quando qualcosa va storto. Una domanda sola.
Punti Chiave per Studenti e Professionisti
- Il vibe coding — descrivere in linguaggio naturale un obiettivo e lasciare che un modello AI generi il codice, senza leggerlo né comprenderlo riga per riga — permette oggi a una piccola impresa turistica senza competenze tecniche di costruire calcolatori di preventivi, moduli di prenotazione personalizzati e cruscotti gestionali che fino a pochi anni fa richiedevano budget e tempi inaccessibili a una struttura di poche camere.
- Il debito tecnico generato da strumenti vibe-coded è invisibile in modo specifico per chi non sa programmare: non è una scorciatoia presa consapevolmente come nel lavoro di uno sviluppatore professionista, ma un rischio strutturale — assenza di test sui casi limite, assenza di limiti minimi e massimi, assenza di gestione esplicita dei dati mancanti — che nessuno, nella stanza, ha gli strumenti concettuali per individuare finché non produce un danno già avvenuto.
- La responsabilità legale ed economica di uno strumento “fatto in casa” con l’intelligenza artificiale resta interamente in capo a chi lo utilizza nella propria attività d’impresa: né il diritto italiano né le condizioni d’uso dei fornitori di AI trasferiscono altrove questa responsabilità, il che rende il controllo umano periodico non un vezzo prudenziale ma una condizione minima di esercizio corretto dell’attività.
Chi, tra chi legge, ha già costruito — o sta pensando di costruire — un piccolo strumento su misura parlando con un’intelligenza artificiale generativa, saprebbe rispondere subito a una domanda semplice: cosa fa, esattamente, quel suo strumento nel momento in cui un dato che si aspetta di ricevere, semplicemente, non arriva?