App auto‑migliorante: ciclo chiuso di miglioramenti

1. Perché a un App serve un ciclo chiuso di miglioramenti

Qualsiasi LLM‑App vive in un mondo che cambia. Arrivano nuovi utenti e scenari, OpenAI rilascia nuovi modelli e meccanismi di safety, voi stessi aggiornate il server MCP, l’Agents SDK, il widget UI… E anche se tutto il codice fosse scritto in modo impeccabile (sì, sì, lo so che quasi ci riuscite), un semplice cambio di modello o di prompt può rompere di nascosto metà dei casi.

Senza un ciclo di miglioramenti la vita è così. L’utente scrive al supporto: “GiftGenius ha iniziato a proporre regali oltre il budget” oppure “rimane fermo a pensare per 15 secondi”. Aprite i log, sistemate qualcosa nel system‑prompt, cambiate modello, rilasciate. Una settimana dopo tutto si ripete, ma altrove. Alla fine — incendio cronico e un mucchio di cambi “magici” che nessuno sa spiegare.

Con il ciclo è diverso. Avete:

• un set chiaro di segnali su tecnica, costi, prodotto e qualità;
• un rituale regolare: guardarli e scegliere ipotesi;
• modifiche controllate in code/config;
• verifiche automatiche: golden case + LLM‑evals + esperimenti.

Allora l’App si trasforma da “prompt congelato” in un sistema vivo, che:

• mostra dove fa male e perché;
• suggerisce cosa esattamente si può migliorare;
• protegge da una degradazione silenziosa dopo una “innocua” modifica al prompt.

In più, bonus: questo ciclo si integra molto bene con tutto ciò che avete già fatto nei moduli precedenti. Log e SLO da M17 danno segnali tecnici, la strumentazione dei costi e AARRR da M19 — segnali economici e di prodotto, golden case e LLM‑evals da M20.1–2 — segnali di qualità. Resta solo collegare tutto in un ciclo operativo comprensibile.

2. Mappa dei segnali per i miglioramenti

Perché l’App possa suggerire dove migliorarsi, serve capire chiaramente quali segnali avete e da dove arrivano. È comodo ragionare in quattro gruppi.

I segnali tecnici arrivano dal vostro stack di observability: log tool_invocation, metriche di latency e error‑rate, health check MCP/ACP, errori OAuth. Rispondono alla domanda “il servizio è vivo e quanto è stabile”.

I segnali economici nascono nella strumentazione dei costi e nel billing: cost_per_tool_call, cost_per_task, cost_per_user, picchi imprevisti di spesa su strumenti o scenari specifici. Dicono: “stiamo bruciando token e denaro più del previsto” oppure, al contrario, “c’è margine, possiamo migliorare la qualità”.

I segnali di prodotto si formano da eventi come app_opened, workflow_started, workflow_completed, checkout_*. Si tratta del tasso di attivazione, delle conversioni tra gli step del funnel, della retention per coorti. Mostrano cosa succede con il comportamento reale delle persone.

I segnali di qualità e comportamento includono i risultati degli LLM‑evals sui golden case (punteggi su correctness/helpfulness/style/safety), revisioni manuali a campione dei dialoghi, thumbs up/down, reclami e recensioni nello Store. È ciò che più si avvicina alla sensazione “l’App è diventata più intelligente/più stupida”.

È comodo raccogliere tutto in una tabella:

Punto chiave: tutti questi segnali vengono loggati con riferimento a uno scenario concreto e alla versione dell’App. Cioè negli eventi compaiono almeno scenario, appVersion e experimentId. Così, vedendo che la helpfulness sui golden case è scesa da 8.5 a 6.2, potete dire non solo “è peggiorato”, ma “è peggiorato nello scenario "gift_selection" dopo il rilascio "1.3.0", nella variante dell’esperimento "B"”.

Nel codice si può persino introdurre una semplice struttura per descrivere un segnale:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // valore "prima"
};

Tali oggetti sono comodi da dare sia alle dashboard sia al vostro futuro assistente di miglioramento.

3. Feedback‑loop canonico: 4 passi

Ora mettiamo insieme il ciclo di miglioramento canonico, su cui potrete fare affidamento ogni volta. È estremamente concreto: quattro passi.

flowchart TD
  A[Segnale: qualcosa fa male
o c’è un'opportunità di crescita] --> B[Ipotesi:
cosa e come cambiamo]
  B --> C[Modifica controllata
in code/config]
  C --> D[Verifica:
offline + online]
  D --> A

Passo 1. Individuare un problema o un’opportunità

In questo passo rispondete alla domanda “dove guardare”. Esempi:

• LLM‑eval sui golden case con budget mostra un calo della helpfulness.
• p95 latency per lo strumento "suggest_gifts" è cresciuta da 1.2 s a 3.8 s.
• cost_per_task per lo scenario "gift_selection" è aumentato del 40 % dopo il passaggio a un modello di reasoning.
• La conversione workflow_completed → checkout_success è calata di 5 punti percentuali dopo una modifica al wizard di UX.
• Nello Store in una settimana sono apparsi 10 reclami “regali più costosi del limite indicato”.

Un dettaglio importante: a volte il segnale non dice “male”, ma “si può fare meglio”. Per esempio, vedete che cost_per_task è sensibilmente sotto la soglia consentita, mentre il quality‑score è già 9/10. Significa che potete provare un modello più costoso o uno scenario più “smart” — magari la conversione crescerà.

Passo 2. Formulare un’ipotesi

Un’ipotesi non è “riscriviamo il prompt”, ma “pensiamo che la modifica specifica X nel componente Y migliorerà la metrica Z, perché…”. Senza il “perché” non è un’ipotesi, è un desiderio.

Esempi:

• “Se inseriamo nel system‑prompt una regola di rigoroso rispetto del budget e chiediamo di spiegare sempre come è stato usato il budget, la helpfulness nei case con budget aumenterà di almeno 2 punti”.
• “Se sostituiamo il modello costoso con "gpt-mini" nello step di rerank, cost_per_task scenderà del 30 %, e la conversione non calerà di oltre 1 punto percentuale”.
• “Se semplifichiamo il wizard (uniamo due step in uno) e riscriviamo la CTA, il tasso di attivazione crescerà di 5 punti percentuali”.

Nel codice è comodo descrivere esplicitamente un’ipotesi, almeno come oggetto:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Cosa cambiamo e perché"
  targetMetric: string;  // e.g. "quality.helpfulness" o "conversion.checkout"
  successCriteria: string;
};

Sì, è quasi come un ticket in Jira, ma almeno in forma tipizzata.

Passo 3. Eseguire una modifica controllata

Qui sono importanti due parole: controllata e separata.

Controllata significa che la modifica è formalizzata come PR/commit, collegata a un’ipotesi, ha un changelog e, se possibile, un feature flag o una versione. Non “avete sistemato il prompt in produzione”, ma potete dire quale rilascio l’ha portata.

Separata significa che cercate di non mescolare nello stesso rilascio tre ipotesi diverse. Se contemporaneamente:

• cambiate modello,
• riscrivete metà del system‑prompt,
• e aggiungete un nuovo step nell’UX,

allora anche se le metriche migliorano sarà difficile capire cosa ha funzionato. È molto più onesto procedere a piccoli passi.

Dal punto di vista tecnico le modifiche possono essere ovunque:

• system‑prompt dell’agente (lib/prompt/systemPrompt.ts);
• descrizioni dei tool MCP (description, inputSchema, annotations);
• configurazione dell’agente (limiti dei passi di reasoning, scelta del modello per uno specifico tool);
• codice del widget (CTA, ordine dei passi, testi di errore).

Passo 4. Verificare se è migliorato

La verifica si divide in offline e online.

La verifica offline è l’esecuzione dei golden case sulla nuova versione dell’App senza utenti reali. Qui avete già:

• LLM‑evals (modulo 20.1);
• logica di soglia/baseline (modulo 20.2).

Guardate come sono cambiati i quality‑score sugli scenari target: sono saliti, scesi, rimasti gli stessi. Verificate anche i safety case: qualsiasi modifica al prompt deve prima passare il set di safety.

La verifica online è un esperimento sul traffico reale. Nel caso più semplice attivate la nuova versione per N % degli utenti e confrontate:

• la conversione nell’azione target (checkout, riavvio dello scenario);
• cost_per_task;
• reclami/feedback.

Dopo questo, il ciclo si chiude (ipotesi confermata/smentita e documentata) oppure genera una nuova ipotesi.

4. Assistente interno ai miglioramenti come agente separato

Ora la parte più gustosa: diamo al modello LLM un altro ruolo — non solo rispondere agli utenti, ma anche aiutare voi a migliorare l’App. È un agente interno, separato dal GiftGenius lato utente.

Che cos’è

Questo assistente vive nel vostro ambiente interno (nello stesso repo, in Dev Mode, in un ChatGPT App separato). Esso:

• legge log e campioni di dialoghi;
• guarda le metriche;
• analizza system‑prompt e descrizioni dei tool;
• aiuta a formulare problemi e proposte di modifica.

Di fatto, ottenete un “product/analyst virtuale” che:

• non si stanca di leggere dialoghi;
• trova rapidamente pattern ricorrenti;
• sa scrivere bozze di prompt e changelog.

Quali input accetta

Conviene formalizzare l’input, per facilitare il lavoro dell’agente. Per esempio, il tipo:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // dalla sezione precedente
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Potete creare un oggetto così esportando dai log 10–20 dialoghi non riusciti per lo scenario "gift_selection" e allegando l’attuale system‑prompt e le descrizioni degli strumenti.

Quale output deve restituire

È utile anche fissare la risposta attesa:

export type ImprovementSuggestion = {
  patterns: string[];     // problemi ricorrenti
  promptPatches: string[]; // proposte di frammenti per il system-prompt
  toolsPatches: string[];  // idee per le descrizioni dei tools
  uxCopyIdeas: string[];   // varianti di testi UX
  changelog: string[];     // breve elenco di “cosa cambiare”
};

Il meta‑prompt per un agente del genere sarà all’incirca:

• “analizza esempi e segnali”;
• “descrivi 2–3 pattern di problemi”;
• “proponi 1–2 modifiche al prompt, alle descrizioni dei tool e ai testi UX”;
• “restituisci tutto in un JSON rigidamente definito”.

Poi prenderete questi frammenti, li discuterete nel team, li integrerete nel codice e li farete passare attraverso eval ed esperimenti. Principio importante: questo assistente non cambia nulla da solo in produzione. Genera idee e testo, non commit.

5. Tipi di modifiche: cosa si può effettivamente mettere a punto

Quando compare un assistente del genere e un ciclo chiaro, è molto facile ridurre tutto a “buttami una nuova versione del system‑prompt”. In realtà il campo dei miglioramenti è molto più ampio.

Prompt e istruzioni

Il system‑prompt definisce ruolo, tono, priorità e regole rigide (ad esempio, budget, safety, ordine dei passi). Si può:

• semplificare, rimuovendo istruzioni contraddittorie o duplicate;
• rafforzare, aggiungendo regole mancanti (come nell’esempio del budget);
• adattare a scenari diversi (sotto‑prompt separati per "gift_selection", "post_purchase_help" ecc.).

Le descrizioni dei tool aiutano il modello a capire quando chiamare uno strumento e cosa fa. Qui i miglioramenti spesso si riducono a:

• istruzioni più esplicite “Use this when… / Do not use when…”;
• raffinare le formulazioni (ridurre la sovrapposizione con altri tool);
• aggiungere informazioni sulle conseguenze (destructiveHint, isConsequential).

Le regole di safety sono la parte del prompt/descrizioni che governa il comportamento in domini complessi. È meglio toccarle solo dopo buoni safety‑eval.

Architettura del comportamento (behavior)

A volte il problema non si risolve con il prompt: bisogna cambiare l’ordine delle azioni.

Esempi:

• aggiungere un passo obbligatorio di chiarimento dei parametri prima della chiamata a un tool costoso;
• spostare parte dei calcoli in un passo separato, più economico (ad esempio, un filtro preliminare nel backend);
• limitare il numero di chiamate consecutive ai tool in uno scenario.

Queste modifiche di solito si descrivono nella configurazione dell’agente o nello strato MCP, non soltanto nel prompt.

UX e copywriting

Sì, i testi sui pulsanti e negli errori sono anch’essi parte della qualità. GiftGenius, che scrive:

“Errore 500. Contatta l’amministratore”,

crea un’impressione ben diversa da:

“Non siamo riusciti a ottenere risposta dal negozio. Le tue idee selezionate non sono andate perse, prova a completare l’acquisto più tardi”.

Schermate intermedie, suggerimenti, struttura dei wizard — tutto ciò influisce proprio su quel tasso di attivazione e sulle conversioni che misurate.

Economia

Qui giochiamo al noto “qualità ↔ costo”:

• scelta del modello (costoso con reasoning, veloce/economico);
• profondità dei passi di reasoning/agent (quante iterazioni consentiamo);
• limiti del dialogo (ad esempio, non più di N ricalcoli della selezione in una sessione);
• modalità di fallback “economiche” quando il budget di token/limiti è esaurito.

I segnali qui confluiscono in cost_per_task, cost_per_user, nel margine e si combinano con il quality‑score.

6. Guardrail: cosa non si può delegare alla LLM

Quando nel sistema compare un “assistente ai miglioramenti” e un ciclo comodo, viene voglia di premere il pulsante “Auto‑ottimizzazione” e andare a bere un caffè. Mettiamo subito dei paletti su dove quel pulsante è vietato.

Le modifiche ai permessi (OAuth scopes, strumenti MCP, accessi ai dati) sono sempre area da human‑in‑the‑loop. Nessun modello deve decidere da solo che ora l’App può leggere ordini, toccare i pagamenti o inviare email agli utenti. Lo stesso vale per il flusso di commerce: qualsiasi cambiamento intorno ad ACP/Stripe, limiti, tipi di pagamento e rimborsi passa attraverso revisione umana e test.

Il profilo di safety dell’App (in quali domini ha diritto a consigliare, dove è obbligata a rifiutare) non è nemmeno qualcosa da delegare alla LLM. Il modello può aiutare a formulare il testo delle regole, ma la decisione su quali temi affidare all’App resta vostra.

La policy dei dati e del logging (cosa logghiamo, per quanto conserviamo, come rispondiamo alle richieste di cancellazione dei dati) è nello stesso elenco. La LLM può suggerire la struttura della Privacy Policy, ma non deve cambiare la retention nel codice senza il vostro intervento.

Cosa si può semi‑automatizzare? Formulazioni e wording di prompt, descrizioni dei tool e testi UX, priorità degli strumenti (entro limiti ragionevoli), domande aggiuntive di chiarimento. Tutto questo si può affidare all’assistente come fonte di idee, ma l’ultima parola e la verifica spettano a persone ed a script di eval.

7. Esempio end‑to‑end del ciclo di miglioramento (GiftGenius)

Torniamo al nostro eroe.

Problema

L’utente indica un budget, ma GiftGenius spesso propone regali più costosi di quel limite. Nei log si vedono molte continuazioni del dialogo “no, è troppo caro” e “fai più economico”.

Segnali

Per prima cosa vedete la qualità: l’LLM‑eval sui golden case del tipo “scegli un regalo fino a 50 $” dà una helpfulness intorno a 6/10. Il giudice scrive regolarmente in reason che “i regali superano il budget” o “non è spiegato come è stato considerato il budget”.

In parallelo arrivano segnali di prodotto ed economici:

• la conversione in checkout_success sugli scenari con limite impostato è più bassa che senza limite;
• alcuni utenti abbandonano lo scenario dopo aver visto opzioni troppo costose;
• cost_per_task per tali scenari è più alto, perché l’App ricalcola più volte i regali su richiesta “fai più economico”.

Analisi con l’assistente ai miglioramenti

Raccogliete 20 dialoghi in cui gli utenti si lamentavano del prezzo e formate un ImprovementInput:

• scenario = "gift_selection_with_budget";
• signals con il calo di helpfulness e conversione;
• examples con i dialoghi;
• l’attuale system‑prompt e le descrizioni dei tool.

Passate questo all’agente interno di miglioramento. In risposta restituisce, per esempio:

• Pattern:
  • il budget formulato come “circa fino a 50$” viene interpretato troppo liberamente;
  • il system‑prompt non contiene un requisito esplicito “non proporre mai regali oltre il limite”;
  • le risposte non spiegano all’utente come è stato considerato il budget.
• Proposte:
  • aggiungere nel system‑prompt un’istruzione sul rispetto rigido del limite;
  • chiedere al modello di dichiarare sempre che “tutte le opzioni ≤ X”;
  • aggiungere una domanda di chiarimento se il budget suona vago (“circa”, “intorno a”).

Ipotesi e modifica

Formulate l’ipotesi:

“Se fissiamo esplicitamente il rispetto rigido del limite e chiediamo di spiegare l’uso del budget, la helpfulness nei case con budget salirà almeno a 8/10, e la conversione all’acquisto — di 3 punti percentuali”.

Inserite nel system‑prompt questo frammento:

export const budgetRule = `
Se l'utente indica un budget (ad esempio, "fino a 50$" o "circa 30€"),
considera questa cifra come un limite massimo RIGIDO.

Non proporre mai opzioni più costose di questo limite.
In ogni risposta dichiara esplicitamente che tutte le opzioni rientrano nel budget
e in che modo (per esempio: "tutti i regali non più di 45$").
`.trim();

E aggiungete budgetRule al system‑prompt complessivo di GiftGenius.

Validazione offline

Eseguite il set di golden case “regali con budget” sulla nuova versione:

• la helpfulness dell’LLM‑eval sale da 6.0 a 8.5;
• cresce anche la correctness: il budget è rispettato;
• la safety non peggiora (almeno per ora).

Se invece la helpfulness non cresce o la safety cala, la modifica non passa e l’ipotesi va rivista.

Test online

Poi avviate un esperimento:

• 10 % degli utenti ricevono la nuova versione del prompt (variante B);
• i restanti 90 % — la vecchia (variante A).

Dopo una settimana osservate:

• la conversione workflow_completed → checkout_success per B è diventata, poniamo, 13 % invece di 10 % per A;
• cost_per_task è quasi invariato;
• la quota di dialoghi con reclami “troppo caro” è scesa.

L’esperimento è dichiarato riuscito.

Consolidamento

Dopo di ciò:

• distribuite il nuovo prompt al 100 % del traffico;
• aggiungete un nuovo golden case “budget flessibile fino a 50$” al set di regressione;
• registrate il risultato nel changelog e, magari, nelle note tecniche: così tra sei mesi sarà chiaro perché c’è una formulazione così rigida sul budget nel prompt.

Il ciclo è chiuso. La prossima iterazione può riguardare, ad esempio, i consigli per persone con hobby molto rari o l’ottimizzazione del costo della selezione.

8. Mini roadmap dell’App auto‑migliorante

Perché non sembri “ancora 100500 attività in più”, è utile vedere il minimo necessario perché l’App sia già considerata auto‑migliorante, e cosa aggiungere in seguito.

Versione 1.0: improvement‑loop minimo

Al primo passo bastano tre cose.

Primo, log strutturati e SLO di base. Sapete già loggare tool_invocation, workflow_completed, checkout_* con requestId, userId, scenario, appVersion, costEstimateUsd. Su questo si costruiscono gli SLO: latency, error‑rate, successo del checkout.

Secondo, 10–20 golden case e uno script LLM‑eval. Un set piccolo ma ben scelto di esempi per gli scenari chiave + safety case. Uno script CLI che li esegue tramite l’App e il giudice e restituisce valutazioni JSON.

Terzo, un semplice rituale ogni 2 settimane. Sedetevi (da soli o col team), aprite:

• 2–3 dashboard su SLO, costi, metriche di prodotto;
• il report LLM‑eval sui golden case;

e scegliete 1–2 ipotesi per il ciclo successivo. Formulate, documentate, fate un piccolo rilascio, verificate.

Versione 2.0: improvement‑loop “smart”

Al livello successivo compaiono:

Assistente interno ai miglioramenti. È un agente separato (o un ChatGPT App) che accetta un ImprovementInput e restituisce un ImprovementSuggestion. Vi aiuta a non passare ore a scorrere dialoghi a mano.

Report automatizzati. Sulla base di log ed eval si possono generare:

• cluster di case problematici (ad esempio, tutti i casi in cui l’utente riscriveva il budget);
• bozze pronte all’uso di modifiche a prompt e descrizioni dei tool;
• un changelog breve.

Hook CI. Qualsiasi modifica a prompt, config degli agenti, descrizioni degli strumenti avvia automaticamente:

• la suite funzionale dei golden case;
• la suite di safety.

Se i safety case falliscono o la qualità degli scenari chiave non supera le soglie — la build è rossa, niente rilascio.

9. Pratica

Esercizio 1. Mini feedback‑loop per il vostro App

Prendete uno scenario chiave della vostra applicazione. Per GiftGenius abbiamo già scelto “selezione e acquisto del regalo”; potete prendere uno scenario simile o il vostro.

Descrivete in forma libera (o create un piccolo improvement-plan.md):

Quali segnali monitorerete. Uno per categoria:

• tecnico: per esempio, p95 latency per lo strumento che fa il lavoro principale;
• economico: cost_per_task per questo scenario;
• di prodotto: la conversione workflow_started → workflow_completed o fino all’azione target;
• qualitativo: quality_score medio su alcuni golden case per questo scenario.

Poi fissate quali soglie considerate una degradazione. Non “prima o poi daremo un’occhiata”, ma in modo concreto:

• p95 > 5 secondi — male;
• cost_per_task è aumentato di oltre il 30 % senza crescita dei ricavi — allarme;
• quality_score è sceso sotto 7 — bisogna indagare.

E formulate la prima ipotesi. Per esempio:

“Sospetto che poniamo troppe domande di chiarimento. Se accorciamo il wizard di uno step e rendiamo le domande un po’ più generiche, il tasso di attivazione aumenterà e la helpfulness non ne risentirà quasi. Lo verificherò con una piccola modifica di UX e un esperimento A/B”.

Questo non è più solo “miglioriamo l’UX”, ma un passo concreto nel ciclo.

Esercizio 2. Meta‑prompt per l’assistente ai miglioramenti

Provate a buttare giù il testo del prompt per l’agente interno di miglioramento del vostro App. Potete iniziare dal semplice:

• Descrivere chi è: “Sei l’analista qualità dell’App N, che…”;
• Elencare quale input riceve: dialoghi, segnali, system‑prompt, descrizioni;
• Formulare i compiti:
  • trovare 2–3 pattern di problemi;
  • proporre 1–2 modifiche a prompt, tool, testi UX;
  • assemblare un changelog breve.
• Descrivere il formato della risposta: JSON strutturato con i campi patterns, suggestions, changelog.

Anche se per ora non chiamerete questo agente dal codice, un solo prompt del genere vi aiuterà a strutturare meglio i ragionamenti su come migliorate l’App.

10. Errori tipici nella costruzione del ciclo di miglioramento

Errore n. 1: ottimizzare solo per una metrica.
Concentrarsi su una cosa sola è molto allettante. Si può inseguire solo il cost, gioire del calo della fattura di OpenAI — e non accorgersi di come quality‑score, conversioni e retention scendano. Il ciclo di miglioramento deve guardare a un pacchetto di metriche: qualità ↔ denaro ↔ comportamento degli utenti.

Errore n. 2: modifiche “magiche” al prompt senza misurazioni.
La frase “ho riscritto il system‑prompt, ora dovrebbe andare meglio” senza golden case e eval è un modo sicuro per farsi una sorpresa tra qualche settimana. Qualsiasi modifica al prompt — soprattutto in produzione — deve passare un pipeline chiaro: set di case, LLM‑eval prima/dopo, se necessario — esperimento online. Altrimenti non migliorate l’App, ma sparpagliate la qualità in direzioni casuali.

Errore n. 3: auto‑deploy delle modifiche dall’assistente ai miglioramenti.
Anche se l’assistente ai miglioramenti scrive frammenti di prompt bellissimi e descrizioni degli strumenti convincenti, non è un motivo per pusharli in produzione senza review. Il modello può non vedere tutti i vincoli di business, i rischi di safety, il contesto delle vostre metriche. Il suo ruolo è consulente, non un DevOps con diritto di rilascio.

Errore n. 4: assenza di collegamento tra modifiche, ipotesi e segnali.
A volte i team fanno modifiche “a sentimento” e non fissano quale segnale ha portato al cambiamento e quale ipotesi stanno verificando. Di conseguenza, dopo un mese nessuno ricorda perché è apparso un paragrafo strano nel prompt e a cosa servisse. Una buona PR sulla qualità deve rispondere almeno a tre domande: “cosa faceva male?”, “cosa cambiamo?”, “con quale metrica capiremo che è migliorato?”.

Errore n. 5: dimenticare la safety durante i miglioramenti.
Nella corsa all’utilità è facile allentare i vincoli di safety, rimuovere “rifiuti inutili” dal prompt o dimenticare di eseguire i safety case. Qualsiasi modifica del system‑prompt, delle descrizioni dei tool e del behavior dell’agente deve prima passare per il set di safety‑eval. Se anche un solo case, che prima passava, ora fallisce — è un segnale di stop, per quanto belle appaiano le altre metriche.

Errore n. 6: voler “ottimizzare tutto e subito”.
Riscrivere metà del prompt, cambiare modello, aggiungere un altro tool MCP e un nuovo wizard — tutto in un solo rilascio — suona produttivo, ma elimina completamente la possibilità di capire quale modifica ha dato effetto. Il ciclo di miglioramento è efficace solo quando è iterativo e focalizzato: una‑due ipotesi, un set ridotto di modifiche, un piano di rollback chiaro.

Errore n. 7: trasformare il ciclo di miglioramento in una rara “giornata di grandi pulizie”.
Se una volta ogni sei mesi organizzate un “giorno della qualità” grandioso, e gli altri mesi vivete senza eval e analisi delle metriche, l’App per la maggior parte del tempo “andrà a corrente”. Molto più utile è un piccolo ma regolare rituale: una volta a settimana/due guardare i segnali, aggiornare le ipotesi e fare piccoli passi. È così che il vostro ChatGPT App smette di essere statico e inizia davvero a migliorarsi da solo.