Costruire un MVP con i coding agent: tempi, costi reali e come non rovinarsi il progetto
I coding agent scrivono software in una frazione del tempo di un team tradizionale, e chi costruisce un MVP ne trae un vantaggio enorme. Con una condizione: capire dove va a finire il tempo risparmiato, quanto costano davvero in token e licenze, e dove la velocità si trasforma in debito tecnico. Ecco il quadro, con i numeri.
Ogni founder se lo è chiesto almeno una volta nell'ultimo anno: se un agente scrive il codice al posto del team, quanto acceleri davvero la costruzione di un prodotto, e a che prezzo? Le risposte in giro sono o da pubblicità, «il tuo SaaS in un weekend», o da rifiuto pregiudiziale, «il codice AI è sempre da rifare». La verità sta in mezzo, ed è più interessante di entrambe.
Prima una distinzione che confonde molte decisioni. Gli app builder (Lovable, Bolt, Replit Agent e simili) trasformano un'idea in un prototipo con interfaccia e URL pubblico in pochi minuti: ottimi per validare la forma di un prodotto, non fatti per mantenere un codice di produzione che cresce. I coding agent (Claude Code, Cursor, Codex, Aider e parenti) lavorano dentro un repository vero: esplorano l'architettura, modificano più file, eseguono test, preparano pull request. Per un MVP che deve diventare un prodotto servono i secondi; per un mockup da mostrare agli investitori bastano i primi. Confondere le due categorie è il primo errore, e capita prima di scrivere una riga.
Il paradosso della velocità
I dati sulle velocità reali sono più sfumati delle promesse. Da un lato l'adozione è di massa: la grande maggioranza degli sviluppatori usa o ha in programma di usare strumenti AI, e su compiti isolati gli sviluppatori completano il lavoro sensibilmente più in fretta con un copilota. Dall'altro lato c'è un numero che ogni founder dovrebbe scriversi sul monitor: analisi su decine di milioni di workflow di sviluppo mostrano che dove l'AI fa risparmiare, la quantità di codice scritto cresce in modo enorme, mentre i rilasci effettivi in produzione crescono di poco, attorno a un quinto.
Cosa significa? Che l'AI ha spostato il collo di bottiglia. Scrivere codice non è più il limite: lo sono la revisione, i test, le decisioni di integrazione. Il codice si produce più veloce di quanto si riesca a verificarlo, e la verifica è diventata il lavoro vero. Chi pianifica un MVP con gli agenti deve pianificare con questo in mente: il tempo risparmiato sulla scrittura va reinvestito sulla revisione, non incassato.
Il secondo dato che pesa è la frustrazione più citata dagli sviluppatori: il codice «quasi giusto». Sembra corretto, compila, passa a prima vista; ha però un'assunzione sbagliata in fondo, e trovarla costa più tempo di scriverla da capo. Due terzi degli sviluppatori lo indicano come il problema principale del lavoro con l'AI. In un MVP, dove una regola di business sbagliata in fondo a un modulo può contaminare tutto ciò che viene dopo, il «quasi» è il rischio operativo numero uno.
Quanto costa davvero
Il costo visibile è quello delle licenze: da una ventina di euro al mese per postazione a molto di più per i piani con agenti avanzati. Quello che sorprende i team è tutto il resto. Un programmatore che lavora intensamente con gli agenti consuma in media una decina di euro al giorno in token e calcolo, il che si traduce in centinaia di euro al mese per sviluppatore nei periodi di sviluppo intenso. Per un MVP con due o tre persone al lavoro, la voce «AI» è reale quanto la voce «hosting», e va messa a budget, non scoperta in fattura.
Poi ci sono le trappole di costo, tutte documentate da chi se le è trovate addosso:
- La licenza sbagliata: i piani economici spesso non includono gli agenti CLI più capaci, che richiedono piani premium o fatturazione API a parte. Prima di comprare cinque licenze economiche, verifica quali strumenti includono.
- La chat che si allunga: ad ogni turno l'agente reinvia la storia della conversazione. Una sessione lunga costa, per singolo prompt, anche dieci volte più che all'inizio. Sessioni corte e mirate sono più economiche oltre che più accurate.
- I sottoprocessi in parallelo: far lavorare più agenti insieme senza un tetto di spesa ha prodotto, a chi ci ha provato, spese da migliaia di euro in pochi giorni. I limiti di spesa esistono, si impostano.
- I server di strumenti collegati: ogni integrazione aggiunge i propri schemi nel contesto di ogni messaggio, con un sovraccarico che si paga a ogni turno anche quando lo strumento non serve.
- Il ragionamento esteso: i token di «pensiero» dei modelli di ragionamento vengono fatturati come token di output, e costano parecchio più dell'input. Attivo, è giusto che costi; deve essere una scelta, non un default dimenticato.
Dove la velocità si trasforma in debito
Il costo più grosso degli agenti non si vede in fattura: si vede nel codice, sei mesi dopo. I pattern sono ormai riconoscibili e si possono evitare.
Il primo è la suite di test che mente. Se lo stesso agente scrive il codice e i test, i test replicano le assunzioni del codice, incluse quelle sbagliate. La suite è verde, il prodotto viola i requisiti reali. La regola: le specifiche e i criteri di accettazione li scrive una persona; i test li scrive un agente diverso da quello che ha scritto il codice, o quantomeno si controlla che i test verifichino le specifiche e non il comportamento del codice.
Il secondo è il cosiddetto code slop: blocchi duplicati, astrazioni superflue, refactoring mai fatto. L'agente produce codice accettabile pezzo per pezzo; nessuno gli ha chiesto di mantenere la coerenza d'insieme del progetto. Il refactoring che in un team tradizionale avviene per necessità quotidiana, con gli agenti va pianificato esplicitamente, perché non accade da sé.
Il terzo è organizzativo e colpisce i team misti: gli sviluppatori junior con un agente generano tante pull request poco meditate, e le revisioni affossano i senior. La produttività dei junior senza supervisione è spesso negativa una volta contata la revisione. Se il team è giovane, il senior non diventa dispensabile con gli agenti: diventa più importante.
Il regime di lavoro che tiene la velocità
Le squadre che tirano fuori il massimo dagli agenti non hanno trucchi segreti: hanno impostato il lavoro perché la velocità non si distrugga da sola. Cinque pratiche che fanno la differenza, in ordine d'importanza.
Prima di tutto, la specifica prima del codice. Non si chiede all'agente «crea un'app di prenotazioni»: si scrive una specifica breve con contratti API, modello dei dati e criteri di accettazione espliciti, e si fa lavorare l'agente su quella. È l'approccio che oggi si chiama spec-driven development, e nei progetti che funzionano è la regola, non l'eccezione. La specifica è anche ciò che ti permette di controllare i test al punto precedente.
Secondo: un file di regole nella radice del repository (AGENTS.md o equivalenti), con i comandi di build e test, le convenzioni del progetto e le zone vietate: «non toccare le migrazioni del database e la logica di pagamento senza approvazione esplicita». È un formato aperto adottato da decine di migliaia di progetti, e funziona se resta sotto le duecento righe: più lungo, diventa un costo pagato a ogni turno.
Terzo: piano, poi esecuzione. Gli agenti funzionano meglio se prima esplorano il repository in sola lettura e propongono un piano passo passo, che un umano approva o corregge, e solo dopo modificano i file. Gli errori costosi si fermano tutti in fase di piano, dove correggerli costa una frase.
Quarto: chi pianifica non è chi esegue i compiti meccanici. I modelli più capaci e costosi vanno usati per pianificare e per i passaggi delicati; quelli economici e veloci bastano per compiti meccanici e ripetitivi. La differenza in costo è di ordini di grandezza, la differenza in risultato quasi nulla se il piano è buono.
Quinto: revisione incrociata. Il codice generato da un modello va bene se fatto rileggere a un modello di un laboratorio diverso: chi revisiona la propria produzione ripete i propri punti ciechi. È la versione economica di una seconda opinione umana, non il suo sostituto; i passaggi critici restano passaggi umani.
In pratica, per il tuo MVP
Tradotto in decisioni per chi parte: usa gli app builder per il prototipo da mostrare e passa al repository vero con gli agenti appena l'idea ha una forma; metti a budget il costo AI come voce fissa della squadra; scrivi le specifiche prima di accendere gli agenti; tieni sessioni corte, con piano approvato prima delle modifiche; e metti in calendario il refactoring, che non accadrà da solo.
Fatto così, il guadagno è reale: settimane di lavoro in giorni, con un codice che un team umano può riprendere quando il prodotto cresce. Fatto senza regole, la velocità la vivi una volta sola, in demo; poi arriva la fattura dei token e, subito dopo, il momento in cui nessuno capisce più perché il sistema funzioni ancora. La differenza tra i due esiti non è il modello che scegli: è il regime di lavoro che imponi tu.
Fonti
Easter egg
Il vero protagonista nascosto dell'articolo è AGENTS.md: meno di duecento righe possono costare meno di una sessione lasciata correre.