Il costo nascosto del vibe coding 💸
TL;DR: Il vibe coding sembra gratis, ma non lo è: token, output, sessioni e rework hanno un costo reale che non appare mai nello scontrino. Imparare a misurarlo significa sapere quando delegare e quando tenere le redini.
Il conto che non arriva mai 🧾
Lo sai com’è, quella sensazione di produttività iperbolica quando l’agente scrive codice mentre tu bevetti il caffè? Il terminale scorre, le righe si accumulano, e tu pensi: “Wow, sto facendo tutto io.” Poi arriva la bolletta. Non quella dell’elettricità — quella del token.
Il vibe coding non è gratis. È solo differito. Ogni sessione, ogni turno, ogni riga di output che l’agente genera ha un costo che non vedono gli occhi, ma che il portafoglio (o il budget aziendale) registra fedelmente. E il problema non è il costo in sé — è il fatto che non lo stai misurando.
La matematica del non-visibile 🔢
Facciamo un rapido calcolo. Un coding agent medio genera tra 2000 e 5000 token di output per sessione. Il costo di output è tipicamente 3-5x quello di input. Significa che ogni volta che l’agente “pensa ad alta voce” su una funzione, ti sta costando molto più di quanto pensi.
E poi c’è il rework. Quella funzione che sembrava perfetta ma che, dopo tre commit, devi riscrivere perché non gestisce un caso limite. O quel refactor che ha introdotto un bug silenzioso che solo il test di integrazione (quello che non hai ancora scritto) può scoprire.
Ogni token sprecato non è solo denaro: è latenza, contesto inutile e un modello che deve leggere roba che non serve.
Come spiegato nella guida Costi e token, output costa più di input — spesso 3-5x. E il rework moltiplica il conto per un fattore che nessuno vuole calcolare.
Dove si nascondono i token 💣
I token non si vedono, ma si accumulano in posti prevedibili. Il contesto della finestra — tutto ciò che l’agente deve leggere per capire il tuo progetto — cresce ad ogni turno. Ogni file che aggiungi al contesto, ogni commit che includi nella history, ogni istruzione che metti nel prompt diventa peso che il modello deve processare.
Poi ci sono i sotto-agenti. Molti framework moderni delegano a modelli secondari per compiti specifici: ricerca, testing, deployment. Ogni sotto-agente ha il suo consumo di token, spesso invisibile all’utente principale. È come avere un team di consulenti di cui vedi solo la fattura finale.
E non dimenticare il model routing: non tutti i prompt meritano lo stesso modello. Usare un modello di fascia alta per un task banale è come prendere un taxi per attraversare la strada. Sapere quando usare il modello economico e quando alzare il livello è una competenza che risparmia budget reale.
Sessioni infinite: il vizio nascosto 🔄
C’è un pattern che tutti conosciamo ma pochi ammettono: la sessione infinita. Inizi con un task semplice, l’agente produce qualcosa, vedi un problema, chiedi di correggere, ne emerge un altro, e via così per venti turni. Alla fine hai un file che funziona, ma hai bruciato una quantità di token che avrebbe coperto un intero sprint di lavoro manuale.
Il vero costo del vibe coding non è il singolo token — è l’assenza di un piano. Quando deleghi senza sapere esattamente cosa vuoi, ogni turno diventa un esperimento. E gli esperimenti costano.
Come ho scritto in Vibe coding ≠ innovazione, l’entusiasmo non basta a fare la differenza. Serve metodo. E il metodo, quando si parla di agenti, significa sapere quando smettere di chiedere.
Quando delegare e quando no ⚖️
La domanda giusta non è “uso l’agente sì o no?” — è “cosa delego e quando?”.
Delega all’agente cose che conosci già e che vuoi velocizzare: boilerplate, test ripetitivi, conversioni di formato, script una-tantum. Queste sono attività dove il rischio di rework è basso e il guadagno di velocità è alto.
Non delegare cose che richiedono contesto architetturale, scelte di design o comprensione del dominio. L’agente può scrivere codice, ma non capisce il perché di una scelta tecnologica. E quando provi a farglielo capire in tre righe di prompt, ottieni una soluzione che sembra corretta ma che nasconde compromessi che solo l’esperienza può riconoscere.
Il trucco è la comprensione della complessità: task semplici e ben definiti vanno delegati, task ambigui e contestuali restano affari tuoi.
Il vero costo: il rework 🔁
C’è un costo che quasi nessuno misura: il tempo perso a capire cosa ha fatto l’agente. Quando accetti ciecamente output senza revisione, stai accumulando debito tecnico silenzioso. E il debito tecnico, come tutti i debiti, prima o poi va ripagato — con interesse.
Il rework non è solo riscrivere codice. È anche:
- Capire cosa ha fatto l’agente (tempo di lettura)
- Verificare che non abbia introdotto bug (tempo di testing)
- Correggere errori sottili (tempo di debug)
- Documentare ciò che hai fatto (tempo di documentazione)
Ogni ora di rework costa molto più di un’ora di sviluppo attento dalla prima riga.
Il codice scritto con metodo costa meno del codice scritto con fretta — anche se il secondo sembra più rapido.
Come riprendere il controllo 🎯
Ecco una checklist pragmatica per non farsi inghiottire dal vortice del vibe coding:
- Definisci il risultato prima di delegare: sai esattamente cosa vuoi ottenere prima di aprire la sessione.
- Budget di token: imposta un limite mentale (o fisico) per sessione. Se superi, fermati e rivaluta.
- Revisiona ogni output: non accettare mai ciecamente. Leggi, capisci, verifica.
- Misura il rework: tieni traccia di quante volte devi correggere ciò che l’agente ha prodotto.
- Delega per incrementi piccoli: meglio dieci sessioni da cento token che una da mille.
Non si tratta di non usare gli agenti — si tratta di usarli con consapevolezza. Il vero vantaggio non è la velocità, è la qualità della delega.
La bilancia vera ⚖️
La bilancia non è tra umano e macchina. È tra delega cieca e delega consapevole. Da un lato i token che bruci senza rendercene conto, dall’altro la qualità che ottieni quando sai esattamente cosa chiedere.
Il costo nascosto del vibe coding non è il token in più — è l’attenzione che non hai dedicato a capire se stavi delegando nel modo giusto.
E forse il costo più alto è credere che produttività e velocità siano la stessa cosa. Non lo sono. Non lo sono mai state.