Un miglioramento di prodotto può passare da circa un mese a 1–2 giorni, ma solo se il team chiude il ciclo tra dati, decisione, sviluppo e misura. È la stima pubblicata da Amplitude per Wave, il suo agente proattivo costruito in gran parte su modelli OpenAI. Il numero attira l’attenzione; il metodo merita di più: l’agente non parte da un prompt generico, ma da comportamento reale, obiettivi, codice, criteri di accettazione e un esperimento controllato.

Per una PMI non significa comprare una piattaforma e lasciare che l’AI modifichi il sito da sola. Significa progettare una pipeline verificabile nella quale ogni passaggio produce un artefatto leggibile: evidenza, ipotesi, piano tecnico, modifica, approvazione e risultato. Questa guida traduce il caso Amplitude in un processo più piccolo, adatto a un portale clienti, un e-commerce, un gestionale o un sito WordPress con funzioni di business.

Il caso Amplitude, letto senza marketing

Wave analizza dati di prodotto, session replay, feedback e codice per individuare opportunità, proporre soluzioni e preparare un piano destinato anche a coding agent come Codex. Secondo il caso studio pubblicato da OpenAI, il sistema è alimentato per circa l’80% da modelli OpenAI e assegna modelli diversi a compiti diversi: ragionamento e indagine profonda, controlli frequenti a costo inferiore e generazione di mockup.

L’esempio più utile riguarda le schede di suggerimento nella homepage di Amplitude. In un campione di 100 session replay, 80 utenti scrivevano una domanda propria e 12 selezionavano un suggerimento. Wave propose di personalizzare le schede usando il contesto recente, mantenendo sia la scrittura libera sia un fallback generico. Dopo una review umana, la modifica passò a un coding agent e poi a un test A/B. Amplitude dichiara un aumento relativo del 160% dei messaggi inviati tramite quelle schede rispetto al controllo, misurato dopo un giorno.

Questi dati provengono dai soggetti che vendono la soluzione, non da un benchmark indipendente. Non dimostrano che qualunque azienda possa ottenere lo stesso risultato. Dimostrano però una cosa replicabile: il lavoro dell’agente era circoscritto a un obiettivo, sostenuto da evidenze osservabili e validato con un confronto. È l’opposto dell’automazione che cambia un’interfaccia perché “sembra migliore”.

Disegna il ciclo prima di scegliere l’agente

Il punto di partenza non è il modello. È la decisione che oggi resta ferma troppo a lungo. Un’azienda può impiegare settimane per capire perché un preventivo non viene completato, perché gli utenti abbandonano un onboarding o perché una funzione viene ignorata. Il primo obiettivo del sistema deve essere comprimere questo tempo senza ridurre la qualità delle prove.

Il ciclo minimo contiene sei passaggi:

  1. Segnale: un evento quantitativo o qualitativo indica un problema circoscritto.
  2. Indagine: l’agente raccoglie dati, replay, errori e feedback pertinenti.
  3. Ipotesi: descrive causa probabile, utenti coinvolti e risultato atteso.
  4. Piano: propone una modifica con criteri di accettazione, rischi e rollback.
  5. Gate umano: una persona autorizza, respinge o restringe l’intervento.
  6. Misura: un esperimento o un rilascio graduale confronta il risultato con la baseline.

Ogni passaggio deve poter fallire senza trascinare automaticamente il successivo. Se mancano dati sufficienti, l’agente non inventa una causa. Se il piano tocca pagamenti, dati personali o permessi, non apre una scorciatoia verso la produzione. Se il test non migliora la metrica primaria o peggiora una metrica di guardia, si ripristina la versione precedente.

È lo stesso principio applicato in una pipeline AI con gate prima della pubblicazione WordPress: l’automazione accelera la preparazione, ma un esito esplicito separa la bozza dalla modifica visibile agli utenti.

Raccogli meno dati, ma collegali bene

Un agente non compensa una tassonomia eventi incoerente. Se “richiesta inviata” significa tre cose diverse, l’analisi sarà precisa nella forma e sbagliata nella sostanza. Prima del pilot scegli un solo flusso e scrivi un dizionario minimo: nome dell’evento, condizione che lo attiva, proprietà ammesse, responsabile e durata di conservazione.

Per un modulo di preventivo, per esempio, possono bastare apertura, avanzamento per fase, errore di validazione, invio riuscito e abbandono. A questi eventi si possono affiancare ticket di assistenza anonimizzati, errori applicativi e session replay configurati per non acquisire campi sensibili. L’obiettivo non è registrare tutto. È collegare un comportamento a una conseguenza di business senza perdere il contesto necessario per interpretarlo.

La documentazione di Amplitude sugli agenti insiste su due input: contesto del prodotto e tipi di insight o azioni ritenuti rilevanti. Specifica inoltre che gli agenti rispettano i permessi del singolo utente. Anche senza adottare Amplitude, questi sono requisiti di progetto: l’agente deve vedere solo le fonti necessarie e deve ricevere una definizione esplicita di ciò che conta.

Io aggiungerei tre controlli che spesso mancano nei prototipi:

  • un identificatore che permetta di risalire dalla raccomandazione alle evidenze usate;
  • una data di scadenza per insight che dipendono da interfacce o campagne temporanee;
  • un registro delle fonti escluse perché incomplete, obsolete o non autorizzate.

Questo rende l’output meno spettacolare ma più difendibile. Quando un responsabile chiede “perché dovremmo cambiare?”, il sistema deve rispondere con eventi, segmenti e limiti, non con una pagina di prosa persuasiva.

Separa indagine, esecuzione e approvazione

Nel caso Wave, Amplitude non usa lo stesso modello per tutto. La pagina OpenAI descrive un modello più capace per le indagini e uno più piccolo per scansioni del codice e controlli ripetuti. In una valutazione interna del Data Science Agent, il modello indicato come GPT‑6.1 Sol ottiene 67,5 punti su 100 contro 69,3 di un altro modello, ma con un costo medio dichiarato di 1,28 dollari contro 2,63 per esecuzione. Il dato non stabilisce un vincitore universale: mostra che qualità, latenza e costo vanno misurati sul singolo compito.

Una PMI può applicare lo stesso principio senza costruire una rete complessa di agenti:

  • un processo economico rileva anomalie e prepara il pacchetto di contesto;
  • un modello più capace formula l’ipotesi e cerca prove contrarie;
  • un coding agent lavora soltanto su un branch isolato e con test definiti;
  • una persona diversa da chi ha configurato il flusso approva il rilascio.

L’isolamento conta più del nome del modello. Credenziali di produzione, database clienti e strumenti di pubblicazione non devono essere disponibili durante l’indagine. Il coding agent riceve il repository, la porzione di specifica necessaria e criteri di accettazione verificabili. La review di una modifica prodotta con Codex deve concentrarsi su differenze, rischi e test, non sulla quantità di codice generata.

Per modifiche reversibili e a basso impatto, come un testo di supporto o l’ordine di elementi non critici, il gate può essere rapido. Per autenticazione, prezzi, pagamenti, consenso o esportazione di dati, l’agente dovrebbe fermarsi al piano e lasciare implementazione e rilascio a un flusso più controllato.

Un pilot di 30 giorni per una PMI

Il pilot deve essere abbastanza piccolo da produrre un confronto credibile. Scegli un solo collo di bottiglia con volume sufficiente: completamento di un modulo, attivazione di una funzione, ricerca interna senza risultati o richiesta di assistenza ricorrente. Evita il restyling generale, perché mescola troppe variabili e rende difficile attribuire l’esito.

Settimana 1: baseline e permessi

Definisci metrica primaria, due metriche di guardia e soglia minima di miglioramento. Per un modulo, la primaria può essere il tasso di completamento; le guardie possono essere errori e richieste di assistenza. Verifica eventi, consenso, mascheramento dei dati e accessi. Raccogli abbastanza esempi da distinguere un pattern da un episodio isolato.

Settimana 2: indagine assistita

Fai produrre all’agente una scheda standard: problema, segmento, evidenze a favore, evidenze contrarie, ipotesi, confidenza, dati mancanti e intervento più piccolo possibile. Un responsabile controlla almeno un campione delle fonti citate. Le schede prive di controprove o con conclusioni più forti dei dati vengono respinte.

Settimana 3: modifica in ambiente isolato

Trasforma una sola ipotesi approvata in ticket tecnico. Includi file interessati, test, accessibilità, performance, sicurezza e procedura di rollback. Il coding agent prepara la modifica, ma non dispone delle chiavi per distribuirla. Test automatici e review umana restano obbligatori.

Settimana 4: esperimento e decisione

Rilascia a una quota controllata o usa un test A/B, se il traffico lo consente. Decidi prima durata, soglia e condizioni di stop. A fine test registra risultato, costo del processo e tempo umano impiegato. Il pilot è utile anche se l’ipotesi fallisce: hai verificato che il ciclo sappia produrre un “no” motivato senza trasformarlo in un rilascio permanente.

Misura il ciclo, non soltanto il modello

Il tempo di risposta dell’LLM è una metrica tecnica, non il risultato aziendale. Per capire se il sistema funziona servono almeno quattro misure: tempo dal segnale alla decisione, percentuale di ipotesi approvate, percentuale di modifiche che superano le metriche prefissate e costo totale per esperimento. Aggiungerei il tasso di rollback e il numero di interventi umani necessari per correggere prove o codice.

Amplitude dichiara che, tra esperimenti, feature flag e guide lanciati dai clienti, un quarto è andato online nello stesso giorno in cui Wave ha individuato l’opportunità, metà entro quattro giorni e due terzi entro una settimana. Anche qui si tratta di dati forniti dall’azienda. Per una PMI la domanda non è se eguagliare quei tempi, ma se ridurre attese e passaggi manuali mantenendo traccia delle decisioni.

Il rischio più comune è ottimizzare ciò che l’agente riesce a vedere. Un aumento dei clic può nascondere utenti più confusi; meno ticket possono dipendere da un canale diventato difficile da trovare. Per questo ogni metrica primaria richiede una guardia e una lettura qualitativa. Velocizzare un ciclo sbagliato produce più modifiche, non un prodotto migliore.

La decisione operativa

Non partire da un agente autonomo che cerca liberamente “cose da migliorare”. Parti da un flusso con una metrica, fonti autorizzate e una modifica reversibile. Fai produrre all’AI evidenze e un piano prima del codice. Separa chi propone, chi esegue e chi approva. Solo dopo tre o quattro cicli riusciti puoi ampliare perimetro o frequenza.

Il vantaggio competitivo non è avere il modello più nuovo. È costruire un sistema che trasforma segnali dispersi in esperimenti piccoli, controllati e documentati. Il caso Amplitude è interessante perché rende visibile questo passaggio: l’agente trova un’opportunità, ma il valore arriva quando un essere umano può verificarla, un ambiente isolato può implementarla e una metrica può smentirla.

Fonti