Ogni strumento di vibe coding vende la stessa illusione: che il costo di un’app sia il costo della sua generazione. Il primo prompt è economico e spettacolare. Il budget muore più tardi, nel fix loop, e il fix loop non è un caso limite. È la modalità operativa normale di ogni strumento di generazione codice su questo sito, una volta che l’app supera dimensioni triviali.
Perché il ventesimo prompt costa più del primo
Il primo prompt scrive su una tela bianca; il modello è bravo in questo, e un singolo round solitamente produce progressi visibili. Il ventesimo prompt, invece, deve modificare un sistema esistente che il modello ricorda solo parzialmente. Man mano che le codebase crescono, superano il contesto di lavoro dell’IA, e il modello inizia a contraddire le proprie decisioni precedenti. Le correzioni affrontano i sintomi piuttosto che le cause alla radice, quindi una patch in un punto ne rompe un altro: è ciò che gli sviluppatori chiamano “effetto whack-a-mole” dei prompt. L’iterazione gonfia inoltre l’artefatto stesso: a causa del contesto limitato, l’IA riscrive funzioni di utilità che non riesce a vedere, lasciando logiche duplicate e un patchwork di stili che rende ogni correzione successiva più difficile da implementare.
Così l’economia dell’unità si inverte. I primi prompt acquistano funzionalità; gli ultimi acquistano tentativi. E ogni tentativo viene fatturato.
Cosa dicono i contatori
I numeri della ricerca, suddivisi per strumento, tratti tutti da report documentati degli utenti.
Lovable vende crediti, con il piano Pro base a 25 euro per 100 crediti al mese. Gli utenti riferiscono che il consumo per singolo prompt è passato da circa 1,2 crediti a 3-4, un’inflazione dei costi di circa dieci volte nel tempo, con persino semplici domande sul codice che consumano frazioni di credito. Le recensioni descrivono il loop canonico: crediti spesi in chat di debugging dove l’agente introduce nuovi errori mentre risolve il primo, con segnalazioni di casi in cui l’IA dichiara di aver risolto il problema senza averlo fatto. Con 3-4 crediti per prompt, un mese da 100 crediti offre meno di 30 tentativi.
Bolt vende token, 10 milioni per il piano Pro da 25$. La lamentela ricorrente è pagare per la mancanza di progressi: l’edit del diff che viene immediatamente riscritto senza il cambiamento, “bruciando token senza produrre modifiche”, e il limite mensile consumato da un errore generato dall’IA, lasciando lo sviluppatore in attesa del mese successivo per correggere l’errore dello strumento stesso. Le recensioni descrivono inoltre un esaurimento opaco dei token durante loop complessi, senza un dettaglio di quali modifiche abbiano consumato le risorse.
Replit ha la curva più ripida perché il prezzo è basato sullo sforzo: la fattura segue quanto intensamente lavora l’agente, e nulla fa lavorare un agente più intensamente del fare debugging di se stesso. Casi documentati: 25$ di crediti consumati in meno di un giorno, 350$ in un singolo giorno, 700$ in un mese e 1.500$ in costi imprevisti del database dovuti in parte ai backup per ogni checkpoint. L’interpretazione più pessimistica della community è strutturale: più errori significano più correzioni, che significano più esecuzioni fatturabili.
Contatori diversi, stessa logica. L’unità di prezzo è il tentativo, e il debugging è l’attività che massimizza i tentativi.
Dare un nome alla tassa
Chiamiamola la tassa del loop di correzione: il divario tra quanto pagheresti se la generazione funzionasse al primo colpo e quanto paghi effettivamente. Ha tre caratteristiche degne di nota. È invisibile al momento dell’acquisto, poiché il prezzo di listino descrive il “percorso ideale”. È regressiva, colpendo più duramente gli sviluppatori meno capaci di diagnosticare le cause alla radice, poiché sono loro a eseguire più round. Ed è correlata all’importanza: le app che innescano i loop più profondi sono quelle aziendali, ricche di edge case e pesanti sull’autenticazione, proprio quelle che devono funzionare per forza, come quelle esaminate in Lovable vs Bolt.
La tassa non rimane solo nella colonna dei costi. Ogni round fatturato su una funzionalità legata all’autenticazione rilancia i dadi della sicurezza (come spiegato in cosa significa realmente che il ‘45% del codice AI è vulnerabile), e il loop stesso rappresenta la forma quotidiana del problema del Giorno Due: la fase di manutenzione in cui ogni modifica rischia di rompere la precedente. Il contatore è solo la parte che vedi in fattura.
Pagare meno, o non pagare affatto
Sugli strumenti di generazione di codice, le mitigazioni sono frutto di esperienza: limitare accuratamente l’ambito dei prompt, salvare ogni stato funzionante, leggere i diff prima di accettare e riconoscere il drift abbastanza presto da fermarsi. Uno strumento a abbonamento flat come Cursor, almeno, limita il caso peggiore a una cifra mensile nota.
La risposta strutturale è notare quali app non necessitano di un loop. Un portale o uno strumento interno è composto principalmente da autenticazione, permessi e CRUD; su una piattaforma come Softr, queste sono configurazioni: cambi un’impostazione, la modifica viene applicata, senza round di rigenerazione e senza tentativi fatturati. Softr ha crediti AI per il suo Co-Builder, ma poiché tutto ciò che l’IA fa può essere fatto anche manualmente, un bilancio vuoto non blocca mai una correzione. Per le app aziendali, il loop di correzione più economico è quello che non esiste.