Vibe Coding: trasformare l’esplorazione in idee di prodotto sorprendenti

Cosa significa “Vibe Coding” (senza lo hype)

“Vibe coding” è un’idea semplice: costruire in fretta quando hai curiosità. Invece di cercare di prevedere la soluzione perfetta a priori, apri un file (o uno strumento di prototipazione), segui un’intuizione e vedi cosa succede. L’obiettivo non è la rifinitura—è l’apprendimento, lo slancio e la sorpresa.

Al meglio, il vibe coding somiglia a fare schizzi con il software. Provi un layout UI, un piccolo flusso, un toggle strano, una diversa vista dei dati—qualsiasi cosa che ti aiuti a rispondere a “e se?” in minuti invece che in riunioni.

In cosa differisce dal lavoro di sprint

Uno sprint tipico è ottimizzato per la consegna: requisiti chiari, stime, attività con ambito definito e una definizione di done. Il vibe coding è ottimizzato per la scoperta: requisiti poco chiari, ambito flessibile e una definizione di learned.

Questo non significa “niente disciplina”. Significa che la disciplina è diversa: protegge la velocità rispetto alla completezza e accetta che alcuni esperimenti saranno scartati.

A cosa serve (e a cosa non serve)

Il vibe coding non sostituisce la strategia, le roadmap o il buon giudizio di prodotto. Non giustifica saltare i bisogni degli utenti, ignorare vincoli o rilasciare idee mezze fatte.

Serve invece ad alimentare la scoperta prodotto creando artefatti tangibili presto—qualcosa su cui puoi cliccare, reagire e testare. Quando puoi vedere e toccare un’idea, noti problemi (e opportunità) che nessun documento può rivelare.

Quali risultati aspettarsi

Una buona sessione di vibe coding produce:

• Esplorazione: più percorsi provati rapidamente, senza impegni pesanti.
• Creatività: combinazioni giocose che non sopravviverebbero a una riunione di “dimostralo”.
• Idee di prodotto sorprendenti: il tipo che emerge solo dopo aver costruito una versione grezza e aver pensato: “Aspetta—questa è la parte interessante.”

Perché molte grandi idee muoiono nella fase di pianificazione

La pianificazione dovrebbe proteggere i team dallo spreco di tempo. Ma agisce anche come un filtro—e le idee in fase iniziale sono fragili.

I “filtri di pianificazione” che uccidono la novità

Prima che qualcosa sia approvato, spesso deve passare una checklist familiare:

• Una storia ROI chiara (spesso con numeri che ancora non esistono)
• Una specifica dettagliata (anche se il problema reale non è ancora compreso)
• Allineamento degli stakeholder (che tende a favorire l’interpretazione più sicura)
• Una timeline e un piano risorse fissi (come se l’incertezza fosse un bug di schedulazione)

Niente di tutto questo è “cattivo”. Sono solo ottimizzati per decisioni su lavoro conosciuto, non per opportunità sconosciute.

Perché la certezza precoce è difficile per idee nuove

Il vero valore di un prodotto nuovo è difficile da prevedere da un documento. Se stai esplorando un comportamento fresco, un nuovo flusso di lavoro o un pubblico poco familiare, le domande più grandi non sono “Quanto genererà?”—sono “Alle persone importa?” e “Cosa provano a fare per primo?”

Quelle risposte non appaiono nei fogli di calcolo. Appaiono nelle reazioni: confusione, curiosità, uso ripetuto, abbandono rapido, soluzioni alternative inaspettate.

La pianificazione premia la familiarità—e punisce il “strano ma promettente”

I processi di pianificazione tendono a premiare idee che assomigliano a cose già costruite con successo. Sono più facili da spiegare, stimare e difendere.

Nel frattempo, le idee strane ma promettenti suonano vaghe, hanno categorie poco chiare o rompono assunzioni (“E se rimuovessimo completamente quel passo?”). Vengono etichettate come rischiose—non perché siano cattive, ma perché sono difficili da giustificare a priori.

La pianificazione è utile—solo non per la scoperta iniziale

La pianificazione brilla quando sai già cosa costruire e perché. La scoperta iniziale è diversa: ha bisogno di piccole scommesse, apprendimento veloce e permesso di sbagliare a basso costo. Il vibe coding si colloca qui—prima della certezza—così le idee sorprendenti possono sopravvivere abbastanza a lungo da dimostrarsi.

L’esplorazione come caratteristica, non come deviazione

L’esplorazione è spesso trattata come un piacere colpevole: bello avere dopo il “lavoro reale”. Il vibe coding rovescia questo paradigma. L’esplorazione è il lavoro—perché è così che emerge ciò che vale la pena costruire prima di investire settimane a difendere un piano.

Gioca senza permesso

Il gioco è produttivo quando l’obiettivo è imparare, non spedire. In una sessione di vibe coding puoi provare l’opzione “sciocca”, collegare un’interazione strana o testare un’idea a metà senza chiedere approvazione.

Quella libertà conta perché molti concetti promettenti sembrano irrealistici su un documento, ma diventano ovvi quando puoi cliccare, digitare e sentirli. Invece di discutere ipotesi, crei qualcosa di piccolo che può rispondere.

Piccoli vincoli rendono le idee più nette

Paradossalmente, un po’ di vincolo stimola la creatività. Un limite di tempo di 30–60 minuti ti costringe a scegliere la versione più semplice di un’idea e vedere se ha uno scintilla. Sei meno propenso a sovradisegnare e più incline a provare due o tre direzioni rapidamente.

I vincoli possono essere semplici come:

• “Una sola schermata.”
• “Nessun nuovo modello di dati.”
• “Se non è visibile in 10 minuti, salta.”

Costruire per imparare = slancio

Quando costruisci per imparare, il progresso si misura in intuizioni, non in funzionalità. Ogni prototipo minuscolo risponde a una domanda: questo flusso sembra naturale? La parola è confusa? Il momento centrale è veramente soddisfacente?

Quelle risposte creano slancio perché sono concrete e immediate.

L’esplorazione migliora il gusto di prodotto

L’esplorazione ripetuta allena il tuo “gusto” di prodotto—la capacità di percepire ciò che è elegante, utile e credibile per i tuoi utenti. Col tempo diventi più veloce a individuare vicoli ciechi e migliore a riconoscere le idee sorprendenti che meritano di diventare esperimenti reali (più avanti vedi il riferimento a /blog/turning-experiments-into-real-product-signals).

Loop di feedback rapidi che sbloccano la creatività

Il vibe coding prospera su un vantaggio semplice: il software ti risponde immediatamente. Non devi “decidere” cosa significa un’idea in una riunione—puoi vederla, cliccarla e sentire dove si rompe.

Quel loop di feedback trasforma l’incertezza in movimento, ed è per questo che l’esplorazione resta divertente invece che frustrante.

Perché i prototipi battono i dibattiti

Le discussioni astratte invitano congetture. Ognuno immagina una versione leggermente diversa della stessa funzionalità, poi si discute sui pro e contro di qualcosa che non esiste ancora.

Un prototipo tangibile elimina quell’ambiguità. Anche una UI grezza con dati finti può rivelare:

• cosa notano gli utenti per primo
• cosa ignorano
• dove esitano
• cosa provano a fare dopo

Quelle reazioni valgono più della logica perfetta, perché si basano sul comportamento.

Iterazione rapida rivela un segnale reale

Quando puoi cambiare qualcosa in minuti, smetti di trattare le idee iniziali come preziose. Provi variazioni: testi diversi, layout, impostazioni predefinite, flussi. Ogni versione diventa un micro-esperimento.

Il “segnale” non è se le persone dicono che piace—è quello che fanno davvero quando lo schermo è davanti a loro.

Invece di passare una settimana ad allinearsi su una specifica, puoi eseguire cinque micro-iterazioni in un pomeriggio e capire quale direzione crea curiosità, fiducia o slancio.

Una piccola modifica che cambia tutto

Immagina di prototipare un semplice habit tracker. La prima versione ha un pulsante “Aggiungi abitudine” ben visibile in alto.

Provi una modifica UI: sostituisci “Aggiungi abitudine” con “Inizia una sfida di 7 giorni” e precompili tre sfide suggerite.

All’improvviso gli utenti smettono di sfogliare opzioni e iniziano a impegnarsi. Il prodotto si sposta da “organizzare abitudini” a “completare brevi streak”. Non è una discussione sulle feature—è una nuova direzione di prodotto scoperta tramite un loop di feedback che ottieni solo costruendo.

Lo sblocco creativo è questo: ogni build ti dà una reazione, ogni reazione ti dà una mossa successiva.

Come emergono idee inaspettate mentre costruisci

Il vibe coding è terreno fertile per gli “incidenti felici”: piccole sorprese che noti solo quando qualcosa è in esecuzione, cliccabile e leggermente imperfetto.

I piani sono bravi a preservare l’intento. I prototipi sono bravi a rivelare il comportamento—soprattutto quello non intenzionale.

Perché i prototipi producono sorprese

Quando costruisci velocemente prendi centinaia di micro-decisioni (naming, layout, default, scorciatoie, forme di dati). Ogni decisione crea effetti collaterali: una vista strana ma utile, un’interazione più fluida del previsto, un log disordinato che racconta una storia.

In un documento di pianificazione sono “edge case”. In un prototipo sono spesso la prima cosa a cui le persone reagiscono.

Quando un effetto collaterale diventa la funzionalità principale

Un pattern comune nel vibe coding è che la cosa costruita “solo per sbloccarsi” diventa la superficie di maggior valore del prodotto. Tre pattern di esempio:

• Uno strumento di debugging diventa una dashboard. Aggiungi un pannello temporaneo per ispezionare eventi ed errori. Poi capisci che è la vista più chiara di cosa fanno gli utenti. Con un po’ di polish diventa una dashboard interna—o persino un feed attività per i clienti.

• Una scorciatoia diventa un flusso di lavoro. Aggiungi una scorciatoia da tastiera o un’azione one‑click per velocizzare i tuoi test. Un collega la prova e dice: “Così voglio fare tutto il compito.” Improvvisamente la scorciatoia “nascosta” è l’ossatura di un flusso snello.

• Una soluzione alternativa diventa una feature flag. Aggiungi un toggle per bypassare un passo lento durante il prototipaggio. Più tardi quel toggle diventa una preferenza reale (“modalità semplice” vs “avanzata”) che aiuta diversi tipi di utenti.

Come catturare le idee prima che svaniscano

Le idee inaspettate spariscono perché sembrano incidentali. Trattale come segnali di prodotto:

1. Tieni una nota “Sorprese” durante la sessione (una frase ciascuna).
2. Tagga il momento: registra una clip dello schermo di 20–30 secondi o fai uno screenshot quando qualcuno dice “aspett—questo è interessante”.
3. Scrivi il valore ipotizzato (“Potrebbe ridurre il tempo di setup”, “Potrebbe aiutare a spiegare i risultati”).
4. Crea un piccolo test di follow-up per la sessione successiva, non una grande voce di roadmap.

Così il vibe coding resta giocoso—ma trasforma gli incidenti in intuizioni.

Prompt pratici per iniziare una sessione di vibe coding

Una sessione di vibe coding funziona meglio quando parti da una sensazione, non da una specifica. Inizia con una frustrazione utente che quasi puoi sentire: “Voglio solo che sia fatto”, “Perché sto ancora cliccando in giro”, “Non so cosa fare dopo”. Quel segnale emotivo è sufficiente per partire.

Scegli un “vibe” come punto di partenza

Scrivi una frase che catturi la tensione:

• “Dovrebbe sembrare istantaneo.”
• “Dovrebbe essere ovvio.”
• “Dovrebbe essere calmo, non stressante.”

Poi scegli un singolo momento nel flusso dove quel vibe è rotto.

Usa prompt che forzano la semplificazione

Questi prompt sono pensati per comprimere la complessità velocemente—senza richiedere di conoscere già la soluzione giusta:

• E se ci volessero 10 secondi? Cosa rimuoveresti per ottenere il risultato in una breve azione?
• E se togliessimo questo passo? Se elimini una schermata, un campo o una conferma, cosa si rompe—e cosa diventa più fluido?
• Qual è l’input più piccolo che funziona ancora? L’utente può fornire una sola informazione invece di cinque?
• Cosa farebbe di sbagliato un utente alla prima esperienza? Progetta il prototipo per “fallire in modo elegante” apposta.

Costruisci prima la versione interattiva più sottile

Punta alla cosa più piccola che si possa cliccare, digitare o attivare—qualcosa che generi una reazione: un pulsante che aggiorna un’anteprima, un wizard a schermo singolo, uno stato di “successo” finto che ti permette di testare la gratificazione emotiva.

Se non sei sicuro, vincolati: una schermata, un’azione primaria, un risultato.

Se il tuo collo di bottiglia è passare da “idea” ad “app in esecuzione”, una piattaforma di vibe-coding come Koder.ai può aiutarti a generare una UI React cliccabile (e persino un backend Go + PostgreSQL) partendo da un breve prompt di chat, poi iterare rapidamente con snapshot e rollback—utile quando lo scopo è imparare senza impegnarsi in una pipeline completa.

Non saltare l’usabilità di base (anche quando sei di fretta)

I prototipi rapidi hanno comunque bisogno di uno standard minimo:

• testo leggibile e etichette chiare (niente icone misteriose)
• accesso da tastiera per le azioni principali
• stati di focus visibili e contrasto colore sufficiente
• un modo ovvio per annullare o tornare indietro

Queste basi mantengono l’esperimento onesto—così il feedback riflette l’idea, non attriti evitabili.

Una struttura leggera che mantiene la produttività

Il vibe coding funziona meglio quando è giocoso e termina con qualcosa che puoi mostrare. Il trucco è aggiungere giusto quel poco di struttura per evitare tinkering infinito—senza trasformare la sessione in un mini progetto a cascata.

1) Limita la durata della sessione (per mantenere alta l’energia)

Scegli una finestra fissa prima di iniziare. Per la maggior parte dei team, 60–180 minuti è il punto ideale:

• 60 minuti per sondare rapidamente se un’idea è anche solo visibile
• 90–120 minuti per un prototipo che si possa cliccare o provare
• 180 minuti quando vuoi anche prendere note e confrontare due direzioni

Imposta un timer. Alla scadenza, smetti di costruire e passa a rivedere ciò che hai imparato.

2) Parti da un singolo obiettivo di apprendimento

Scrivi una frase che definisca cosa vuoi imparare, non cosa vuoi spedire.

Esempi:

• “Gli utenti capiranno la prima schermata senza spiegazioni?”
• “Quale di questi due onboarding è meno confuso?”
• “Possiamo generare un output utile in meno di 30 secondi?”

Se appare una nuova idea a metà sessione, mettila in pausa in una nota “prossima sessione” a meno che non supporti direttamente l’obiettivo.

3) Usa ruoli leggeri per mantenere il ritmo

Non serve un grande team. Tre ruoli semplici mantengono il flusso:

• Driver: costruisce e prende decisioni rapide per non perdere slancio
• Reviewer: reagisce in tempo reale e chiede “risponde all’obiettivo di apprendimento?”
• Note-taker: registra cosa hai provato, cosa è cambiato e cosa ha sorpreso

Ruota i ruoli tra le sessioni.

4) Decidi in anticipo quando smettere di iterare

Chiudi la sessione quando si verifica una di queste condizioni:

• Hai risposto abbastanza bene alla domanda di apprendimento da scegliere una direzione
• Le modifiche diventano estetiche (“pixel polishing”)
• Hai fatto la stessa correzione due volte (segno che stai indovinando)
• Il passo successivo richiede dati reali, utenti reali o integrazione reale

Quando finisci, registra un breve recap: cosa hai costruito, cosa hai imparato e qual è il prossimo esperimento più piccolo.

Trasformare gli esperimenti in segnali di prodotto reali

Il vibe coding è divertente, ma diventa utile solo quando puoi capire se un esperimento indica qualcosa di concreto. L’obiettivo non è “gli utenti l’hanno gradito?”—è “ha ridotto confusione, velocizzato il progresso o creato un desiderio chiaro di riutilizzarlo?”

Modi rapidi per validare (senza sovrasviluppare)

Scegli un test leggero che corrisponda a ciò che hai costruito:

• Test con 5 utenti (30 minuti ciascuno): chiedi di completare un compito pensando ad alta voce. Non spiegare l’interfaccia; osserva dove si bloccano.
• Demo interna + role-play: un collega finge di essere cliente e prova ad usarlo a freddo. Cattura obiezioni e momenti “aspetta, cosa fa questo?”.
• Smoke test con landing page: descrivi il risultato, non le feature, e aggiungi un pulsante “Iscriviti alla lista d’attesa” o “Richiedi accesso”. Se hai utenti già, fai un piccolo annuncio in-app.

Segnali da osservare

I prototipi iniziali raramente producono numeri stabili, quindi cerca segnali comportamentali e di chiarezza:

• Comprensione: Riescono a spiegare in una frase cosa fa—in modo accurato?
• Tempo-per-valore: Quanto ci mettono a raggiungere il primo risultato significativo?
• Intenzione di riuso: Chiedono di poterlo usare di nuovo, richiedono un link o suggeriscono dove inserirlo nel loro flusso?

Evita metriche da vanità (soprattutto all’inizio)

Fai attenzione alle metriche che sembrano scientifiche ma non dimostrano utilità: visualizzazioni, like, tempo sulla pagina o feedback tipo “sembra interessante”. Un complimento cortese può nascondere confusione.

Documenta gli apprendimenti con un template minimo

Tieni un registro in modo che gli esperimenti diventino conoscenza di prodotto:

• Ipotesi: Crediamo ___ per ___ perché ___.
• Cosa abbiamo costruito: (screenshot) + cosa manca intenzionalmente.
• Metodo di test: chi, dove, per quanto.
• Cosa abbiamo osservato: 3–5 momenti concreti (quote + azioni).
• Segnali: comprensione, tempo-per-valore, intenzione di riuso (basso/medio/alto).
• Decisione: raddoppiare / rivedere / mettere in pausa, e il prossimo passo più piccolo.

Rischi e paletti (per non trasformarlo in caos)

Il vibe coding funziona perché è permissivo—ma la permissività può degenerare. L’obiettivo non è eliminare i vincoli; è usare vincoli leggeri che mantengano l’esplorazione sicura, economica e reversibile.

Rischi comuni da monitorare

• Scope creep: l’“esperimento veloce” si trasforma silenziosamente in un prodotto a metà.
• Debito tecnico: scorciatoie da prototipo entrano nel codice principale e rallentano il lavoro futuro.
• Oggetti luccicanti: ogni nuova idea interrompe la precedente prima che ti abbia insegnato qualcosa.

Paletti semplici che mantengono la produttività

Usa confini che rendono gli esperimenti eliminabili per default:

• Repo o branch sandbox: tieni il lavoro vibe separato (es.: un repo vibes/ o branch chiaramente etichettati) così nulla viene unito per sbaglio.
• Feature flag ovunque: se qualcosa tocca la produzione, nascondila dietro un flag con default off.
• Regole di codice usa-e-getta: limita nel tempo l’esperimento e assumi che sarà cancellato. Se mostra merito, riscrivilo prima di integrarlo.
• Fette piccole e testabili: punta a un comportamento osservabile, non a un flusso completo.

Un criterio di “kill switch”

Decidi in anticipo cosa significa “fine”. Esempi:

• Se non riusciamo a far completare l’azione principale a un utente in 60 secondi, fermarsi.
• Se non riusciamo a produrre un segnale misurabile in un giorno (click, completamento, “aha” qualitativo), fermarsi.
• Se richiede più di X ore per stabilizzarsi, fermarsi e documentare i risultati.

Scrivi il kill switch nel documento dell’esperimento o nel titolo del ticket: “Stop se nessun segnale entro venerdì 15:00”.

Mantenere gli stakeholder sereni (senza sovra-reporting)

Gli stakeholder non hanno bisogno di aggiornamenti costanti—hanno bisogno di prevedibilità. Condividi un riepilogo settimanale: cosa avete provato, cosa avete imparato, cosa eliminate e cosa merita follow-up.

Fai della cancellazione un risultato positivo: prova che avete risparmiato tempo.

Quando passare dalle vibes a un piano

Il vibe coding è utile per far emergere direzioni sorprendenti, ma non dovrebbe essere la modalità operativa finale. Il passaggio alla pianificazione dovrebbe avvenire quando il “interessante” diventa “ripetibile”—quando puoi descrivere cosa funziona senza fare affidamento sulla fortuna, sulla novità o sul tuo entusiasmo personale.

Criteri di maturazione: cosa merita un piano

Passa dalle vibes alla pianificazione quando puoi indicare almeno alcuni di questi segnali:

• Trazione utente ripetuta: più persone provano in modo indipendente, la richiedono ancora o la rimpiangono quando scompare.
• Un caso d’uso chiaro: sai per chi è, quale lavoro aiuta a svolgere e cosa significa successo in una o due frasi.
• Consegna fattibile: hai identificato un percorso realistico per il rilascio (tech, tempo, team), anche senza stime perfette.

Se hai solo “fa figo”, continua a esplorare. Se hai “lo vogliono”, inizia a pianificare.

Riscrivere il prototipo in una specifica semplice

I prototipi sono disordinati per definizione. Quando hai imparato abbastanza, converti l’esperimento in una specifica leggera che catturi la verità scoperta:

• Problem statement: quale frustrazione o desiderio è emerso nell’uso reale?
• Soluzione proposta: qual è la versione minima che offre il valore?
• Non-goals: cosa non costruirete per ora.
• Metrica di successo: cosa misurerete nella prossima release.

Non si tratta di rifinire; si tratta di rendere l’idea trasferibile ad altri.

Checklist di transizione per evitare regressioni

Prima di impegnarti, annota:

• Note UX chiave (cosa ha confuso, cosa hanno amato, cosa hanno ignorato)
• Vincoli noti (dati, performance, compliance, limiti di piattaforma)
• Domande aperte (cosa deve essere testato ancora e come)

La pianificazione aiuta quando l’incertezza è scesa: non stai più indovinando cosa costruire—stai scegliendo come consegnarlo bene.

Dove il vibe coding funziona meglio (e dove no)

Il vibe coding brilla quando lo scopo è scoprire cosa vale costruire—non eseguire perfettamente un piano predeterminato. È più utile nella zona degli “sconosciuti”: requisiti poco chiari, bisogni utente sfumati e concetti nelle prime fasi dove la velocità di apprendimento conta più della precisione.

Ottimi casi d’uso: alto valore di apprendimento, basso impatto negativo

Il vibe coding funziona meglio quando puoi prototipare in fretta, mostrare qualcosa a un utente (o collega) e adattare senza causare danni a valle.

Scenari comuni adatti:

• Scoperta di prodotto iniziale: esplorare una nuova idea di feature, un onboarding, una variante della pagina prezzi o uno strumento interno.
• Esplorazione UI/UX: provare layout alternativi, micro-interazioni o pattern di navigazione per capire cosa “suona giusto” prima del design formale.
• Esperimenti su dati e flussi di lavoro: testare se un workflow può essere semplificato, automatizzato o reso più piacevole.
• Generazione di idee per la roadmap: creare demo piccole per scoprire opportunità che non passerebbero una commissione di pianificazione.

Le migliori sessioni di vibe coding creano artefatti su cui reagire—prototipi cliccabili, piccoli script, integrazioni rozze o schermate “finte” che simulano valore.

Cattivi casi d’uso: quando il costo di sbagliare è alto

Alcuni contesti puniscono l’improvvisazione. In questi casi il vibe coding va strettamente vincolato o evitato.

È poco adatto per:

• Cambiamenti soggetti a compliance (industrie regolamentate, flussi di dati sensibili, requisiti di audit)
• Sistemi critici per la sicurezza (medicina, automotive, trasferimenti finanziari, controlli di sicurezza)
• Migrazioni di infrastrutture core dove cambi parziali possono creare outage o instabilità difficili da diagnosticare
• Lanci pubblici ad alto rischio con requisiti legali/brand stringenti e opzioni di rollback limitate

Puoi comunque usare il vibe coding attorno a queste aree—es.: prototipare un concetto UX con dati finti—senza toccare le superfici critiche di produzione.

Prontezza del team: crea spazio e supporto

Il vibe coding è più facile quando il team ha:

• Supporto junior e pairing così i meno esperti possono esplorare senza bloccarsi o introdurre complessità accidentale
• Pratiche di review chiare (PR leggere, check-in rapidi di design, etichettatura esplicita “solo prototipo”)
• Un budget di tempo che protegge l’esplorazione dalle interruzioni continue di lavoro urgente

Una cadenza pratica è uno slot di esplorazione alla settimana (anche 60–90 minuti). Trattalo come una sessione di laboratorio ricorrente: scopo piccolo, demo rapida, note veloci.

Provalo una volta, poi iterare

Scegli una domanda piccola a cui realmente non sai rispondere, fai una singola sessione di vibe coding, cattura cosa hai imparato (e cosa ti ha sorpreso), poi ripeti la settimana successiva con un esperimento leggermente più definito.