Il plateau del Good Enough

Qualche tempo fa ho raccontato come ho costruito un’app per gestire il giardino di casa. Prima un foglio Excel, poi una board su Mirò e poi un’applicazione in vibe coding. Funziona, la uso, e ogni volta che la mostro arriva la stessa domanda: quindi non servono più gli sviluppatori?

Non so programmare, ma mi occupo di prodotti digitali da parecchio e ho un background anche in security ¹: sapevo quale problema volevo risolvere, come scomporlo, cosa lasciare fuori e quando fermarmi. L’AI ha scritto il codice; il prodotto l’ho pensato io. E questa differenza è esattamente il punto di questo post (unita a qualche riflessione sul futuro).

La domanda iniziale è legittima mentre risposte che sento di solito oscillano tra due estremi: quella entusiasta (non serve più niente) e quella difensiva (sì, ma non è sicura, non scala, non è vero software). Sono entrambe sbagliate perché guardano l’oggetto, l’app, e non quello che è cambiato davvero: chi può fare cosa, e con quale qualità.

Per spiegarlo uso una metafora che mi sembra reggere meglio di altre: la cucina. Lo spunto nasce da un un post di Napolux, che faceva notare che chiunque può anche aprire un ristorante, ma non è detto che tu ci vada a cena e provo a portarla un po’ più in là.

Ristorante, cuoco privato o fornelli di casa

Fino a pochissimo tempo fa, quando un’azienda aveva bisogno di uno strumento digitale, le opzioni erano sostanzialmente due:

1. Andare al ristorante: scegli dal menu, mangi quello che c’è, alle condizioni del locale. È il SaaS: ci sono trattorie oneste e ristoranti stellati, menu fissi e carte lunghissime, standard molto diversi tra loro, ma il principio non cambia: il piatto è pensato per molti, e sei tu ad adattarti a lui più di quanto lui si adatti a te. ²
2. Chiamare un cuoco a domicilio: il software su misura. Il piatto è tuo, costruito sui tuoi gusti e sulle tue allergie, ma costa di più, richiede tempo e soprattutto richiede che tu sappia spiegare cosa vuoi mangiare. Cosa che, chi fa questo mestiere lo sa bene, non è affatto scontata.

E qui c’è un caso che conosce chiunque abbia gestito un budget: ti serviva una cosa sola, piccola e su misura: un modo per tenere traccia delle richieste dei clienti, un calendario condiviso con due regole specifiche, un modulo che parlasse con il gestionale.

Il cuoco costava troppo per un piatto solo (e l’IT aveva altre priorità, al massimo “apri un ticket”) e allora andavi al ristorante e ordinavi il menu degustazione intero per mangiarne una portata: una suite con quaranta funzioni, licenze per utente, sei mesi di configurazione, per usarne una e mezza. Il resto lo pagavi comunque, e spesso pagavi anche la fatica di adattare il tuo modo di lavorare a quello che il software si aspettava. Il rapporto tra costi e benefici era discutibile, ma era l’unica opzione sul tavolo. ³

Quella portata singola è esattamente ciò che oggi puoi cucinare a casa ed è il motivo per cui una parte del mercato SaaS dovrebbe preoccuparsi più di quanto dichiari: non perché i clienti costruiranno da soli il gestionale completo, ma perché smetteranno di comprarlo per usarne un pezzo (forse è quello che è successo al mondo della musica quando invece di comprare CD con 17 brani per ascoltarne tre, abbiamo iniziato ad acquistare i singoli o solo i brani “top”).

La GenAI con il vibe coding ha aperto una terza strada: cucinare da soli. Non serve più saper programmare per mettere insieme un’app, non serve più saper usare un software di grafica per avere un’immagine decente, non serve più un copywriter per scrivere un testo che stia in piedi. Accendi i fornelli e qualcosa di commestibile esce.

Ed è qui che serve la prima distinzione: saper fare una buona pasta non ti rende un cuoco. Ti rende una persona che sa fare una buona pasta, il che è già moltissimo e copre una parte sorprendente dei bisogni quotidiani.

Ma cucinare per quattro amici una sera non è gestire un servizio da duecento coperti tutte le sere, con il controllo delle materie prime, l’HACCP, la brigata, i tempi di uscita dei piatti e il cliente con l’intolleranza che si presenta senza avvisare. Tradotto: la mia app del giardino funziona benissimo perché la uso solo io. Sicurezza, manutenzione, integrazione con altri sistemi, continuità quando chi l’ha costruita non c’è più: quella è la cucina professionale, ed è un altro mestiere.

Questo non significa che per chi sta dall’altra parte del bancone non cambi niente: cambia moltissimo!

Una parte delle persone andava al ristorante solo perché non sapeva accendere il gas: quella clientela, per le aziende software e per chi sviluppa su misura, sta già sparendo. I piccoli progetti, le personalizzazioni da poche giornate, il mi servirebbe solo un modulino: è la fascia bassa del mercato, ed è la prima a mettersi ai fornelli da sola. Ristoranti e cuochi non spariranno, ma dovranno spiegare molto meglio perché vale la pena uscire di casa.

E la spiegazione, a ben guardare, è banale. Al ristorante non hai mai comprato un piatto di pasta: hai comprato il fatto di non doverla cucinare tu: qualcuno che si occupa delle materie prime, delle certificazioni, della cucina a norma, della brigata, del servizio in sala, del tavolo pronto quando arrivi e dei piatti da lavare quando te ne vai. A volte hai comprato anche una cosa molto specifica che a casa non sapresti fare, ma è l’eccezione, non la regola.

Il piatto è la parte visibile; il valore sta tutto intorno.

Chi sviluppa software sta scoprendo la stessa cosa, e per molti non è una bella scoperta. ⁴

Se il codice si genera, il codice (ma non solo) smette di essere il prodotto. Quello che resta da vendere è il servizio: la sicurezza, la manutenzione, gli aggiornamenti, la continuità, l’integrazione con il resto dei sistemi, qualcuno da chiamare quando le cose si rompono, la responsabilità quando qualcosa va storto.

In una parola: il fatto che il cliente non debba preoccuparsene. Chi vendeva funzionalità dovrà imparare a vendere tranquillità.

Vale anche al contrario: se saper fare la pasta al pomodoro non ti rende un cuoco, ancora meno ti rende un ristoratore.

Il ristoratore è quello che sceglie dove aprire, decide il menu in base a chi passa davanti alla porta, fa i conti con l’affitto, il personale, i fornitori, le recensioni e i tavoli vuoti del martedì sera. Cucinare è la parte facile.

Con il software sta succedendo esattamente questo: visto che costruire un’app richiede un pomeriggio, sono in molti a pensare che il difficile sia fatto e poi scoprono le due cose che il pomeriggio non risolve.

La prima è che l’app risolve un problema che hanno solo loro, o che nessuno è disposto a pagare per risolvere: la versione digitale del ristorante aperto in una via dove non passa nessuno. La seconda è tutto il resto: trovare i clienti, convincerli, farsi pagare, assisterli, gestire chi chiede una funzione in più e chi minaccia di andarsene. Il mercato si sta riempiendo di prodotti costruiti benissimo che non interessano a nessuno. ⁵ Abbassare il costo di costruzione non ha abbassato di un euro il costo di capire cosa costruire, né quello di venderlo.

La soglia si è spostata

Il secondo punto è quello che ho provato a disegnare nel grafico qui sotto per un webinar con Ninja Marketing, e riguarda una distinzione che nel dibattito sull’AI si perde quasi sempre: quella tra lavori che spariscono e lavori che si trasformano.

Sull’asse orizzontale c’è la competenza, da zero a specialista. Su quello verticale la qualità del risultato, divisa in tre fasce: osceno, good enough e ben fatto.

Prima, la curva era quella di sinistra: lenta, convessa: con poca competenza producevi qualcosa di osceno, e per arrivare al buono abbastanza dovevi essere quasi uno specialista. La soglia minima di competenza per un risultato accettabile stava molto a destra. Per questo chiamavi un esperto anche per cose banali: non avevi alternative.

Oggi la curva è quella di destra. Sale ripidissima all’inizio: con una competenza minima arrivi subito nella fascia del buono abbastanza. Poi succede una cosa interessante. La curva si appiattisce, e c’è un lungo plateau in cui aggiungere competenza non produce un miglioramento visibile. Solo verso la fine, quando la competenza diventa davvero specialistica, la curva si impenna di nuovo e supera la soglia del ben fatto.

Attenzione però a come si legge quel punto sulla curva: nl caso del giardino, la competenza minima non era zero: era la mia esperienza di product management, non di programmazione. L’AI ha spostato la soglia per scrivere il codice, non quella per pensare il prodotto. Ed è qui che molti si illudono di partire da zero quando in realtà stanno spendendo, senza accorgersene, competenze che hanno costruito altrove.

Da questo grafico escono due conseguenze, entrambe scomode.

La prima: i lavori che vivevano nella fascia del buono abbastanza sono quelli che spariranno prima. Non perché siano lavori stupidi, ma perché il loro valore stava nell’essere l’unico modo per ottenere un risultato accettabile. Il banner da adattare in dodici formati, la traduzione di servizio, la trascrizione della riunione, la prima bozza della scheda prodotto: lì la soglia di autonomia si è spostata così tanto a sinistra che il ricorso all’esperto non si giustifica più.

A questo punto, di solito, qualcuno tira fuori il paradosso di Jevons, e ultimamente lo citano davvero TUTTI. L’economista inglese osservava a metà Ottocento che macchine a vapore più efficienti non riducevano il consumo di carbone: lo aumentavano, perché rendevano conveniente usarlo per molte più cose.

Applicato a noi: se produrre software, contenuti e analisi costa meno, ne produrremo molti di più, e la domanda complessiva di lavoro crescerà. È probabile che sia vero, ma il paradosso parla di quantità totali, non di chi si porta a casa il lavoro. Più software non significa più giornate per chi vendeva il modulino; significa più lavoro oltre il plateau, e più lavoro per chi sa decidere cosa vale la pena costruire.

La seconda è più sottile: il plateau è una trappola. Se per un lungo tratto la qualità percepita non cambia, chi sta nel plateau non vede la differenza tra il proprio risultato e quello dello specialista. E quindi confonde il buono abbastanza con il ben fatto. Non per presunzione, ma perché per riconoscere il ben fatto serve proprio la competenza che il plateau rende invisibile. È lo stesso problema del vino: per capire perché una bottiglia costa dieci volte l’altra devi averne assaggiate parecchie.

Quindi Piero dice che i professionisti servono ancora e possiamo stare tranquilli. No. Sto dicendo che i professionisti servono per una parte molto più piccola del lavoro, quella che sta oltre il plateau, e che dovranno essere capaci di dimostrare dove sta la differenza. Chi viveva di buono abbastanza ha un problema serio. Chi lavora nel ben fatto deve imparare a farlo vedere.

L’estetica della sagra

C’è un effetto collaterale che stiamo già osservando: l’appiattimento del Good Enough.

Avete presente i manifesti delle sagre di qualche anno fa? Impaginati in Word dal volontario della Pro Loco, tre font diversi in sei righe, la clipart della pannocchia sorridente, una foto un po’ storta dei piatti veri: il risotto dell’anno prima, le costine sulla griglia, la torta della signora che la fa da trent’anni. Nessuno li ha mai scambiati per graphic design, ma ognuno era diverso dall’altro, e ognuno ti diceva una cosa precisa: qui si mangia questo.

Oggi fate un giro per le bacheche e i social delle associazioni del vostro territorio: si vede che sono fatti con l’AI, e si assomigliano tutti. Stessa luce dorata, stessi colori saturi, stesse illustrazioni lucide con quell’aria un po’ plasticosa, stessa composizione. La festa del vino, la sagra del pesce, la castagnata d’autunno: stesso stile, cambia solo il titolo. E l’unicità dell’offerta, che era l’unica cosa che contava, sparisce.

Vale per le sagre, ma guardate i manifesti delle associazioni sportive e i menù di molte realtà dove una cosa che mi ha colpito è che sono sparite le foto (vere) dei piatti e al loro posto ci sono immagini generate. Sembra un passo avanti estetico e invece è un passo indietro comunicativo, perché l’immagine generata non mostra il prodotto, ma lo nasconde rappresentando l’idea media di quel cibo.

Le aziende non sono messe meglio: gli stessi post con la stessa struttura e le stesse frasi a effetto, le stesse landing page con lo stesso gradiente viola, le stesse immagini di stock generate che non mostrano né il prodotto né le persone che lo fanno. Tutto pulito, tutto accettabile, tutto uguale.

Quando TUTTI arrivano al buono abbastanza, il buono abbastanza smette di essere un vantaggio e diventa il pavimento e la differenza, come sempre, si sposta più in alto: proprio nella zona dove serve la competenza che pensavamo di non dover più pagare. Compresa quella, apparentemente banale, di capire che cosa va mostrato. ⁶

Brigate che si formano e si sciolgono

Mettiamo insieme i pezzi.

Se il buono abbastanza si alza e le persone possono ottenere un feedback molto più rapido sul proprio lavoro (provo, guardo, correggo, riprovo), il ricorso ai professionisti si riduce. Non sparisce: si concentra nei momenti in cui serve davvero.

Questo, secondo me, può spingere verso un modello organizzativo noto (e complesso calcolando che per un tema di efficienza si continua a lavorare per funzione ⁷: l’organizzazione a progetto. Gruppi di lavoro che si aggregano attorno a uno scope preciso, portano dentro le competenze specialistiche per il tratto di curva che le richiede, e poi si sciolgono. Un po’ come le cucine che per un evento richiamano la brigata extra: non tieni dieci cuochi a libro paga tutto l’anno, ma il giorno in cui servono devono esserci, e devono saper lavorare insieme da subito.

Proviamo a renderlo più vicino. Un’azienda manifatturiera decide di rifare il configuratore delle offerte, quello che usano i commerciali per comporre preventivi su prodotti con molte varianti. Fino a ieri il percorso era scontato: analisi, capitolato, gara tra due o tre fornitori, sei mesi di sviluppo. Oggi un responsabile commerciale con un po’ di iniziativa e un collega dell’ufficio tecnico mettono in piedi un prototipo funzionante in un paio di settimane. Le regole di configurazione ci sono, i listini anche, l’interfaccia è decente. Siamo nel buono abbastanza e ci siamo arrivati in fretta.

Poi arrivano i problemi che il prototipo non vede. L’interfaccia funziona per chi l’ha disegnata, ma i commerciali sul campo la usano dal telefono, tra un cliente e l’altro. Il collegamento con l’ERP è un export manuale che qualcuno deve ricordarsi di fare. I dati dei clienti stanno in un posto dove nessuno ha deciso chi può vederli. A questo punto entra la brigata: uno specialista di UX per dieci giorni, uno sviluppatore che conosce l’integrazione con l’ERP per tre settimane, qualcuno che si occupi di sicurezza e permessi. Lavorano, consegnano, escono.

Sembra il modello perfetto (e in parte lo è), ma è proprio qui che emergono dei temi sui cui oggi quasi nessuno ha una risposta pronta.

• L’onboarding. Lo specialista che entra non trova un foglio bianco, trova un prototipo pieno di decisioni implicite: perché quella regola è scritta così, perché quel campo è obbligatorio, perché quella variante non è prevista. Nessuno le ha documentate, perché nessuno pensava di doverle spiegare a qualcun altro. Il rischio è che lo specialista passi metà del suo tempo a fare archeologia, oppure, peggio, che rifaccia tutto da capo perché è più veloce che capire. In entrambi i casi il vantaggio del prototipo si consuma.
• L’accountability. Chi risponde del risultato finale, quando la parte buono abbastanza l’ha fatta il cliente e la parte ben fatto l’hanno fatta tre consulenti diversi? Se il configuratore sbaglia un prezzo e l’offerta parte, di chi è il problema? ⁸ Nelle brigate che si formano e si sciolgono questa domanda va risolta prima di accendere i fornelli, non dopo il primo piatto bruciato.
• La differenza tra progetto e prodotto. La brigata lavora a progetto: ha un inizio, una fine, uno scope. Il configuratore invece è un prodotto: vive, cambia con i listini, con le nuove linee, con i commerciali che chiedono una funzione in più. Quando la brigata si scioglie, chi se ne occupa? Se la risposta è chi l’ha fatto all’inizio, nel tempo libero, abbiamo appena costruito il debito tecnico di domani con gli strumenti di oggi.
• Come si prezza? Su quest’ultimo tema non ho una risposta, ho un riferimento. Se lo specialista interviene sul tratto finale, quello che porta il risultato da accettabile a ben fatto, le ore sono una misura povera del valore che porta. L’alternativa naturale è prezzare l’outcome, cioè il risultato. Sulla carta è perfetto; nel mercato attuale è difficilissimo. Prezzare a outcome vuol dire definire insieme cosa conta come risultato, condividere dati e informazioni, accettare che il rischio venga distribuito tra le parti. Richiede una collaborazione tra cliente e fornitore che oggi è l’eccezione, non la regola: la maggior parte dei rapporti è ancora costruita su preventivo, capitolato e contestazione della fattura. Però è la direzione verso cui guardare. E chi continua a vendere giornate per fare cose che il cliente ormai fa da solo sta proponendo un menu che nessuno ordina più (per lo meno in prospettiva).

Automatizzare, generare, ridisegnare

L’ultima riflessione riguarda il tempo. Liberarsi da una parte dell’operatività è una buona notizia solo se si sa cosa farne. Il tempo liberato non è un risultato: è una risorsa e come tutte le risorse si può sprecare.

Qui serve un’altra distinzione, perché sotto l’etichetta “usare l’AI” finiscono tre cose molto diverse:

• Automatizzare vuol dire far fare a una macchina un passaggio che prima faceva una persona, lasciando il processo com’è.
• Generare vuol dire produrre contenuti, documenti, immagini, codice che prima richiedevano un autore. R
• idisegnare vuol dire chiedersi se quel passaggio debba esistere, e ripensare il processo partendo dall’obiettivo.

Per renderlo concreto uso un esempio che porto spesso (dato che è frequente nel lavoro): una campagna di lead generation .

• Il processo classico. Un manager definisce obiettivi e brief, il designer prepara le creatività, il manager le rivede e le approva (via mail e Slack, ovviamente), il performance configura la campagna su Meta e Google, poi esporta i lead e li pulisce a mano in Excel; alla fine il manager compila il report e manda la lista a chi deve chiamare i contatti. Niente di scandaloso: è il modo in cui lavora la maggior parte delle aziende che conosco.
• AI Enhanced. Ruoli e sequenza restano identici; cambia quello che succede dentro ogni passaggio. Il brief si costruisce con l’aiuto dell’AI su target, personas e KPI. Il designer genera concept, copy e varianti A/B invece di partire dal foglio bianco. Raccolta, pulizia e classificazione dei lead diventano un unico passaggio gestito da Make o n8n con un modello che fa la qualificazione; il report si compone da solo. Qui vediamo all’opera i primi due verbi. Automatizziamo l’export, la pulizia, il trasferimento al CRM, l’invio del report. Generiamo brief, creatività, varianti. Spariscono l’export in CSV e il report compilato a mano, compaiono attività nuove come la gestione delle eccezioni, cioè i lead che la macchina non sa classificare. Il performance smette di pulire dati e comincia a gestire casi dubbi. Il designer passa da autore a revisore delle proprie varianti, e fare il revisore richiede competenze diverse, a volte più alte, perché devi accorgerti di cosa manca in qualcosa che sembra completo. È un miglioramento vero. Ma è lo stesso processo, più veloce e con elementi aggiuntivi.
• AI First. Qui si ridisegna. Creatività e preparazione delle campagne procedono in parallelo invece che in sequenza, perché il brief contiene già i guardrail entro cui muoversi. Le revisioni sparse tra mail e chat spariscono e diventano un’unica approvazione prima della messa online, preceduta da un controllo automatico di coerenza con brand e policy. Acquisizione, qualificazione, inserimento nel CRM e assegnazione a chi deve chiamare diventano un flusso continuo, e una persona interviene solo sulle eccezioni, aggiornando le regole di scoring ogni volta che ne trova una. Un agente monitora i KPI, segnala le anomalie e propone ottimizzazioni; fuori dai guardrail decide una persona. Il manager si siede periodicamente a decidere budget e strategia. E soprattutto cambiano i ruoli: il manager diventa decisore, il performance supervisore di workflow e agenti, il designer direttore creativo.

Messe una accanto all’altra, le due versioni dicono una cosa precisa: la versione Enhanced si può fare probabilmente domani mattina (con qualche licenza e un pomeriggio di configurazione), la versione First no. Richiede di decidere a monte cosa è accettabile, chi ha l’ultima parola e su cosa, e come si gestisce l’errore quando lo commette una macchina. È lavoro di processo e di organizzazione e richiede persone capaci di fare un mestiere diverso da quello per cui le abbiamo assunte: rivedere invece di produrre, supervisionare invece di eseguire, decidere invece di compilare. ⁹

Su Harvard Business Review è uscito da poco un articolo che racconta (in maniera strutturata e con il bollino HBR) che il difficile non è sapere che l’AI sa fare delle cose, è capire dove entra nel processo e cosa deve cambiare intorno perché serva davvero. Bene, le indicazioni che ne escono sono quelle che chi ama la Lean riconosce al primo colpo: mappare il flusso dall’inizio alla fine, guardando soprattutto i punti in cui il lavoro cambia mano, dove si accumulano le approvazioni, dove qualcuno ricopia informazioni da un sistema all’altro, dove le decisioni si fermano: lì, più che nelle singole attività, stanno le opportunità.

Automatizzare uno spreco produce soltanto uno spreco più veloce anche quando gira su un modello linguistico. Generare dieci volte più report che nessuno legge non è produttività; è inquinamento informativo.

Per questo trovo pericolosissima la tentazione di usare l’AI per usare l’AI. È la legge del martello nella sua versione più moderna: hai uno strumento nuovo e potente, e improvvisamente tutto sembra un chiodo. La domanda giusta non è dove possiamo mettere l’AI? ma quali obiettivi vogliamo raggiungere, e in quali punti del processo l’AI ci avvicina davvero? Detto altrimenti: l’AI deve entrare nella strategia, non sostituirla.

Il conto, prego

Chiudo con tre avvertenze, perché anche cucinare in casa ha dei costi che non si vedono subito.

• Il lock-in. Se i tuoi processi, i tuoi prompt, i tuoi piccoli strumenti fatti in casa dipendono da un singolo fornitore, la tua cucina non è davvero tua. È un monolocale in affitto, e il padrone di casa può cambiare le regole quando vuole: aggiornare il modello, cambiarne il comportamento, ritirare una funzione su cui hai costruito un pezzo di operatività.
• I costi. I prezzi di oggi sono, in buona parte, prezzi di lancio in un mercato che deve ancora trovare il suo equilibrio. Abbiamo già visto questo film con il cloud: si entra perché costa poco, si resta perché uscire costa troppo. Fare i conti oggi immaginando che le tariffe rimangano queste è un esercizio di ottimismo.
• Ambientale. Ogni richiesta ha un costo in energia e in acqua per il raffreddamento dei data center, e quel costo non compare in nessuna fattura e non ancora nei bilanci di sostenibilità. Non è un motivo per non usare l’AI, ma è uno spunto in più per non usarla a caso.