L’AI non ti rende più produttivo “in media”: o fai il salto, o ti rallenta

C’è un’ipotesi implicita, spesso data per scontata: che distribuendo strumenti di AI la produttività aumenti in modo graduale e relativamente uniforme.

Nella realtà accade l’opposto: stessi strumenti, stessi modelli, stessi abbonamenti. Risultati opposti. Alcuni team accelerano davvero. Altri diventano più lenti. Non è isteria. È un pattern.

Secondo Bisardi, la spiegazione non è “adozione” generica. È soglia. E la definisce nel paper The LLM Productivity Cliff.

La “Productivity Cliff”: la produttività come discontinuità, non come rampa

La tesi chiave è questa: nei compiti complessi, l’impatto degli LLM sulla produttività tende a essere a soglia (productivity cliff), non graduale

– Sotto la soglia (cliff), aumentare l’uso dell’AI porta benefici piccoli, instabili o addirittura negativi. Più review, più correzioni, più contesto perso, più tempo speso a controllare.

– Sopra la soglia (cliff), cambia il modo di lavorare. E i guadagni diventano step-change: grandi e più stabili.

È un’idea quasi banale, finché non la applichi a quello che vedi tutti i giorni: perché una parte del mercato racconta “miracoli” e un’altra racconta “delusioni”.

La risposta è semplice: non tutti gli utenti stanno vivendo la stessa esperienza. Si osservano diversi regimi nell’adozione dell AI.

I tre segnali che la frattura esiste davvero

Il paper sintetizza tre pattern ricorrenti osservati in studi e casi sul campo:

1) Non-monotonicità  

L’adozione iniziale può essere net negative per profili esperti quando il lavoro è complesso e lo scaffolding è debole. In pratica: l’AI aggiunge attrito invece di toglierlo.

2) Bimodalità  

I risultati non si distribuiscono “a campana”. Si concentrano: molti ottengono poco, una minoranza ottiene tantissimo.

3) Inversioni  

In sistemi molto strutturati e “scaffolded”, i junior possono migliorare più dei senior. Non perché diventano geni, ma perché lo scaffolding codifica best practice nel sistema, e chi lo segue beneficia.

Questi tre segnali sono la firma di un effetto a soglia, non di un miglioramento lineare.

La soglia non è “prompt engineering”: è alfabetizzazione architetturale.

Se la frattura esiste, la domanda diventa: qual è la soglia?

Bisardi la chiama architectural literacy (alfabetizzazione architetturale): non “saper scrivere prompt”, ma una disciplina ingegneristica su come si progetta il lavoro con modelli e agenti.

Cinque capacità la caratterizzano:

– Decomposizione: spezzare obiettivi ambigui in sotto-task trattabili dal modello e isolare dove serve giudizio umano.

– Design del workflow: catene iterative, checkpoint, loop di critica per agenti. Non il colpo singolo, non un solo agente, ma un workflow.

– Valutazione dell’output: verifiche sistematiche tarate sui failure mode, non “controllo a occhio”.

– Integrazione di sistema: collegare modelli a dati, strumenti e agenti. L’unità di lavoro diventa il workflow, non la chat.

– Modelli mentali adattivi: sapere cosa il modello può fare in modo affidabile, dove tende a fallire, e progettare il workflow di conseguenza.

Traduzione brutale: sotto soglia l’LLM è un assistente conversazionale. Sopra una soglia diventa un componente in un sistema progettato.

Quando la frattura è più ripida

Il paper indica tre condizioni che rendono la frattura (cliff) visibile:

– Alta complessità del task (design aperto, architettura, ricerca, pianificazione, multi-modulo).

– Basso scaffolding (prompt non strutturati, assenza di tools per i modelli AI, fragile context engineering ).

– Modelli mentali disallineati (soprattutto nei professionisti ancorati a workflow legacy: o fiducia eccessiva o sfiducia totale).

Questo aiuta a spiegare perché l’impatto degli LLM varia molto tra contesti: non dipende solo dal modello, ma anche da task design, disponibilità di contesto e grado di integrazione con strumenti e dati.

Il punto pratico: la frattura è tra “integrazione” e “ridisegno”

Per rendere la soglia concreta, Bisardi descrive una progressione in tre livelli di maturità d’uso degli LLM nei workflow:

– Livello 1: uso superficiale  

Prompt singoli, copy-paste, correzioni ovvie. Effetti piccoli, spesso instabili nei compiti complessi.

– Livello 2: integrazione nel workflow  

Catene multi-step, contesto più ricco, iterazione disciplinata. Benefici più consistenti, ma limitati.

– Livello 3: ridisegno architetturale  

Task riprogettati attorno all’AI, toolchain custom, orchestrazione agentica, controlli automatici, integrazione con dati e API.

La frattura è il passaggio tra Livello 2 e Livello 3. È lì che “si spacca” la distribuzione.

Una conseguenza scomoda: nasce un’ineguaglianza AI-native

Se i guadagni arrivano solo oltre soglia, allora l’AI non distribuisce benefici in modo uniforme. Li concentra.

Chi costruisce capacità architetturali (persone e organizzazioni) accumula vantaggio: workflow riusabili, costi marginali più bassi, velocità e qualità migliori. Chi resta sotto soglia paga l’overhead e vede poco ritorno.

Non è solo una questione di “skill individuale”. È una questione di infrastruttura organizzativa.

Un accenno al secondo paper: come si costruisce scaffolding “vero”

Il secondo lavoro di Bisardi entra nel “come” su un progetto reale di software engineering: invece di trattare il contesto come testo da incollare nella chat, propone di sistematizzarlo come parte dell’architettura software.

In sintesi, propone un’architettura di context engineering a due livelli:

• Permanente strato dichiarativo del progetto: regole, vincoli e invarianti stabili (policy, requisiti, standard, limiti).

• Living strato programmatico del progetto: un livello dinamico (via MCP server) che espone al modello informazioni strutturate e aggiornate dal sistema e dai suoi artefatti (dati, componenti, configurazioni, strumenti).

L’obiettivo è rendere il contesto ripetibile e verificabile, riducendo la dipendenza da prompt ad hoc e aumentando affidabilità e scalabilità operativa. Questo, da solo, non “garantisce” il salto di produttività, ma riduce l’attrito necessario per attraversare la soglia.

Se la tua strategia è “mettiamo l’AI e vediamo”, stai giocando sotto soglia (cliff). E poi ti stupisci che l’AI “non funzioni” o non vedi grandi risultati.

Il punto non è usare di più gli LLM. È ridisegnare il lavoro abbastanza da superare la frattura.