Nel novembre 2025 il Collins Dictionary ha scelto "vibe coding" come parola dell'anno e l'ha definita come l'uso dell'IA, guidata in linguaggio naturale, per aiutare a scrivere codice. L'espressione ha attecchito perché l'esperienza è reale. Si descrive un'app, si accetta ciò che il modello scrive, e la domenica sera c'è una schermata funzionante. Un founder oggi può mostrare una demo ai clienti prima di assumere un ingegnere.
Ciò che non è diventato più economico è la parte che rende il software affidabile. Nello Stack Overflow Developer Survey 2025 il 66% degli sviluppatori ha indicato "soluzioni IA quasi giuste, ma non del tutto" come principale frustrazione con gli strumenti IA, e il 45% ha detto che il debug del codice generato dall'IA richiede più tempo. Un prototipo è il luogo in cui il quasi giusto va bene. La produzione è il luogo in cui non va bene.
Questa nota elenca cosa aggiunge la produzione a un prototipo, propone una ripartizione approssimativa dello sforzo e suggerisce come chi gestisce il budget dovrebbe trattare la demo che gli è appena stata mostrata.
L'accelerazione è reale, e ancora non misurata
La misurazione più accurata della velocità del coding con IA viene da METR, un'organizzazione di ricerca non profit. Il suo studio randomizzato del 2025 ha rilevato che sviluppatori open source esperti impiegavano il 19% di tempo in più sulle attività quando l'IA era consentita, con un intervallo di confidenza da +2% a +39%.
Il 24 febbraio 2026 METR ha pubblicato un seguito: 57 sviluppatori, 143 repository, più di 800 attività, a partire da agosto 2025. Sulla stessa scala di variazione del tempo in cui il risultato del 2025 era +19%, le nuove stime puntuali sono -18% per gli sviluppatori tornati dal primo studio (intervallo da -38% a +9%) e -4% per gli sviluppatori reclutati ex novo (intervallo da -15% a +9%). Entrambe le stime puntuali ora indicano che l'IA fa risparmiare tempo. Entrambi gli intervalli includono lo zero.
METR stessa definisce i nuovi dati un segnale inaffidabile. Tra il 30% e il 50% degli sviluppatori ha detto di aver scelto di non sottoporre alcune attività perché non voleva svolgerle senza IA. Le attività in cui l'IA aiuta di più mancano quindi dal campione, e METR ritiene che l'accelerazione reale sia probabilmente maggiore della sua stima.
Per un acquirente la conclusione è circoscritta. L'IA rende più veloce una parte del coding, in una misura che ricercatori attenti non sono riusciti a fissare. Non cambia ciò di cui un sistema ha bisogno prima che le persone possano farci affidamento.
Cosa dimostra un prototipo, e cosa no
Un prototipo del weekend dimostra tre cose utili: l'idea funziona sugli input che qualcuno ha provato, l'interfaccia ha senso per le persone che l'hanno vista e qualcuno la vuole.
Non dimostra che il sistema funzioni su input che nessuno ha provato, che funzioni per duecento persone contemporaneamente, che mostri a ciascuno solo ciò che ha il permesso di vedere, che costi al mese quanto si pensa, né che qualcuno sappia ripararlo quando si rompe di notte. Sono le domande a cui risponde la produzione.
C'è una seconda differenza facile da trascurare. Un prototipo viene giudicato da chi l'ha costruito, il giorno in cui l'ha costruito, con input scelti da lui. Un sistema di produzione viene giudicato da persone che non hanno mai visto la demo, mesi dopo, su dati che non esistevano quando il codice è stato scritto. La maggior parte del lavoro nella tabella seguente esiste perché il secondo giudizio vada bene.
Cosa aggiunge la produzione
Le quote qui sotto sono una ripartizione illustrativa per uno strumento LLM interno, come un copilot di ricerca documentale, che passa da un prototipo funzionante a qualche centinaio di utenti al giorno. Sono opinioni di pianificazione, non misurazioni. Cambiate i pesi per il vostro caso; ciò che conta è la forma.
| Voce di lavoro | Cosa significa | Senza | Quota illustrativa |
|---|---|---|---|
| Logica centrale | Ciò che il prototipo mostra già | Nessun prodotto | 20% |
| Contratti sui dati e pipeline | Controlli di schema su ogni flusso in ingresso; caricamenti pianificati e idempotenti | Un export a monte cambia e le risposte peggiorano senza alcun errore | 15% |
| Set di valutazione e quality gate | Domande reali con risposte attese, eseguite a ogni modifica di prompt o modello | Nessuno sa dire se una modifica ha migliorato o peggiorato le cose | 12% |
| Autenticazione e permessi | Single sign-on; regole di accesso applicate al momento del retrieval | Il personale vede documenti che non dovrebbe vedere | 8% |
| Validazione degli input e gestione degli errori | Limiti di dimensione e formato; gestione di testo ostile negli upload e nei documenti recuperati | Un file anomalo manda giù il servizio o pilota il modello | 8% |
| Monitoraggio e alerting | Latenza, tasso di errore, costo per richiesta, tasso di retrieval vuoti, feedback degli utenti | I problemi li segnalano gli utenti, giorni dopo | 8% |
| Security review e correzioni | Segreti, dipendenze, dati inviati ad API di terze parti | Una chiave esposta o una violazione nel trattamento dei dati | 8% |
| Reperibilità e runbook | Un responsabile nominato e passi scritti per i guasti più comuni | L'unica persona che sa come fare è in ferie | 7% |
| Rollback e processo di rilascio | Prompt, modelli e indici versionati; un modo per tornare all'ultima versione buona | Un rilascio difettoso resta online mentre qualcuno fa il debug | 5% |
| Documentazione e passaggio di consegne | Come funziona, come modificarlo, come gestirlo | Il sistema non può sopravvivere al suo autore | 5% |
| Limiti di costo | Quote per utente, tetti sui token, un interruttore sulla spesa | Un ciclo o un utente intensivo producono una fattura a sorpresa | 4% |
La prima riga è il prototipo. In questa ripartizione è un quinto del lavoro. Gli altri quattro quinti sono invisibili in una demo, ed è per questo che una demo è una guida così scarsa per un budget.
Per gli ingegneri: dove va il tempo
Alcune righe meritano più dettagli, perché è lì che le stime di solito sbagliano.
I permessi vanno nel retrieval, non nella risposta. In un sistema retrieval-augmented il controllo di accesso deve filtrare i documenti prima che arrivino al modello. Filtrare dopo la generazione non funziona: il modello ha già letto il testo riservato e può parafrasarlo. Questo significa che l'indice porta metadati di accesso, resta sincronizzato con il sistema sorgente e qualcuno lo testa con account che hanno diritti diversi.
Il set di valutazione è la specifica in forma eseguibile. È un file versionato di input reali con output attesi o regole di valutazione, eseguito in CI a ogni modifica di prompt, modelli, chunking o impostazioni di retrieval. Costruirlo significa sedersi con le persone che useranno il sistema e scrivere cos'è una risposta corretta. È lento, e nessun assistente può farlo al posto vostro, perché la conoscenza sta negli utenti.
La validazione degli input ora include testo che attacca il modello. Un documento nell'indice può contenere istruzioni. Gli upload possono essere enormi, vuoti, immagini scansionate o con la codifica sbagliata. Ogni caso richiede un comportamento definito e un test.
Il rollback richiede che tutto sia versionato insieme. Un rilascio è un prompt, una versione del modello, una build dell'indice e codice. Se solo il codice è in git, riportare indietro il codice non riporta indietro il comportamento.
I limiti di costo sono una funzionalità di produzione. Un prototipo ha un utente. Un sistema di produzione ne ha qualche centinaio, più script e retry. Quote per utente, numero massimo di token e un alert sulla spesa giornaliera costano poco da costruire ed evitano la sorpresa spiacevole più comune.
Come trattare un prototipo se il budget è vostro
Trattatelo come una specifica. Un prototipo funzionante è la descrizione più chiara di ciò che si vuole che la maggior parte dei progetti riesca mai ad avere. Consegnatelo agli ingegneri insieme all'elenco degli input su cui è stato provato e dei casi in cui ha fallito.
Non trattatelo come l'80% del prodotto. Se un preventivo è basso perché il prototipo esiste, chiedete quali righe della tabella sopra copre. Se la risposta è solo la prima riga, il preventivo è per un secondo prototipo.
Usatelo per verificare la domanda prima di finanziare la produzione. Mettetelo davanti agli utenti a cui è destinato per due settimane. Se non ci tornano, avete risparmiato il budget di produzione, che è la cosa più utile che un prototipo possa fare.
Quando buttare via il prototipo
Riscrivete invece di estendere quando è vera almeno una di queste condizioni:
- ci sono segreti nel codice o nella storia del repository;
- ai dati si accede tramite l'account personale o la chiave API personale di qualcuno;
- interfaccia, logica e accesso ai dati sono mescolati, quindi i permessi non si possono applicare in un unico punto;
- nessuno sa spiegare come è stata prodotta una certa risposta;
- gira su un builder ospitato che non si può distribuire nel vostro ambiente né adeguare alle vostre regole sui dati;
- la logica è lunga e non ha test.
Tenetelo quando la logica centrale è breve, leggibile e separabile, esistono già alcuni test e il flusso dei dati assomiglia a quello di produzione.
Buttare via il codice costa meno di quanto sembri. Il prototipo ha già fatto il suo lavoro: le decisioni sono prese, gli esempi sono raccolti, l'interfaccia è stata provata. I prompt, gli input di esempio e gli screenshot di solito sopravvivono a una riscrittura anche quando il codice no.
Quanto vale il divario in denaro
Le nostre fasce di prezzo pubblicate mostrano lo stesso rapporto. Un proof of concept costa 14k–38k € in 4–7 settimane. Una build di produzione costa 45k–120k € in 10–20 settimane. A entrambi gli estremi dell'intervallo la produzione vale circa tre volte il proof of concept: 45 / 14 ≈ 3.2 e 120 / 38 ≈ 3.2. Quel multiplo è il costo delle righe sopra che non sono la prima. Consegniamo monitoraggio e rollback prima del passaggio di consegne per lo stesso motivo: sono ciò che permette a un cliente di gestire il sistema senza di noi.
Se avete già un prototipo e volete sapere quali righe copre, il teardown gratuito è una prima verifica in sei domande, e una breve discovery a pagamento risponde in modo completo. Lo stesso elenco vale per i copilot documentali interni, dove permessi e set di valutazione di solito richiedono più tempo.
Fonti
- CNN, 'Vibe coding' named Collins Dictionary's Word of the Year, novembre 2025 — https://www.cnn.com/2025/11/06/tech/vibe-coding-collins-word-year-scli-intl
- Stack Overflow, 2025 Developer Survey: AI, luglio 2025 — https://survey.stackoverflow.co/2025/ai
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, luglio 2025 — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR, We are Changing our Developer Productivity Experiment Design, febbraio 2026 — https://metr.org/blog/2026-02-24-uplift-update/