Steps of AI Adoption: quando salire di livello

Che cos'è Steps of AI Adoption

Steps of AI Adoption è un framework pubblicato il 16 luglio 2026 da Boris Cherny, responsabile di Claude Code. Descrive un percorso in cinque livelli: accesso limitato, uso assistito, lavoro parallelo, autonomia supervisionata e organizzazione AI-native. Nasce dal lavoro software e cita soprattutto prodotti Anthropic, quindi non è uno standard indipendente. La sua logica centrale resta però utile anche con Codex, Cursor, Copilot o altri agenti.

• Il framework è un modello operativo proposto da un vendor, non una scala scientifica di maturità.
• I numeri associati ai livelli sono ordini di grandezza illustrativi, non obiettivi da raggiungere.
• Il passaggio importante non è da uno a dieci agenti: è da supervisione continua a verifica affidabile.
• La maturità può cambiare per workflow: puoi delegare molto sulla manutenzione e restare prudente su pagamenti, dati o pubblicazione.

Il bottleneck cambia a ogni livello

Ogni passaggio risolve un limite e ne rende visibile un altro. All'inizio il problema è ottenere accesso a strumenti abbastanza capaci. Nell'uso assistito diventa l'attenzione: se devi leggere ogni azione in tempo reale, il lavoro resta sincrono. Con più task paralleli il collo di bottiglia si sposta sulla review. Quando gli agenti avviano altro lavoro, contano fiducia nel loop, qualità del contesto, costi e capacità di intervenire sulle eccezioni.

• Se controlli ogni passaggio, il bottleneck è la fiducia nella verifica.
• Se accumuli risultati da leggere, il bottleneck è la capacità di review.
• Se gli agenti sbagliano per informazioni mancanti, il bottleneck è il contesto.
• Se il lavoro cresce ma il valore no, il bottleneck è la selezione dei task o il costo per risultato.

Un primo Step 2 piccolo e verificabile

Il framework originale descrive cinque-dieci agenti in parallelo. Non serve partire da lì. Per un professionista o un piccolo team è più prudente provare con due-cinque task indipendenti, ciascuno in un workspace o worktree separato. L'obiettivo non è massimizzare il numero di sessioni, ma verificare se riesci a ricevere risultati controllati senza seguire ogni agente mentre lavora.

• Scegli task che non modificano gli stessi file e non dipendono dalla stessa decisione ancora aperta.
• Scrivi risultato atteso, non-obiettivi e criteri di accettazione prima di avviare il lavoro.
• Fai eseguire all'agente i controlli disponibili e chiedi un riepilogo delle verifiche fallite o mancanti.
• Rivedi il risultato finale, poi esegui merge, pubblicazione o deploy manualmente.
• Interrompi la prova se coordinare e correggere i task richiede più tempo del flusso assistito.

La self-verification che rende possibile il parallelismo

Un agente può lavorare senza supervisione continua solo se riceve feedback dall'ambiente. Nel software arrivano da build, lint, typecheck, test, scansioni e ambienti di sviluppo reali. In altri flussi servono equivalenti misurabili: schema dei dati, link validi, conteggi riconciliati, fonti citate, metadata completi o checklist di conformità. Nessun controllo singolo basta per tutto: combina prove diverse in base al rischio del task.

• Controlli meccanici: formato, schema, duplicati, link, build e test.
• Controlli semantici: fonti pertinenti, criterio editoriale, coerenza con il brief e casi limite.
• Controlli di rischio: permessi, dati sensibili, sicurezza, disclosure e azioni esterne.
• Handoff finale: file modificati, verifiche eseguite, fallimenti, limiti e decisioni ancora umane.
• Scope: non correggere automaticamente file o contenuti estranei al task solo perché il controllo li segnala.

Un esperimento non-coding: audit di pagine stale

Il principio non vale solo per il codice. Un primo esperimento può essere l'audit di venti schede di un catalogo: controllare se il prodotto è ancora attivo, se URL e prezzi sono plausibili, se mancano metadata, link interni, disclosure o confronti utili. In questa fase l'agente non modifica le pagine. Restituisce una lista breve di interventi con evidenza, impatto atteso, costo stimato e criterio di completamento.

• Limita l'output, per esempio ai dieci interventi con maggiore impatto.
• Separa fix meccanici, decisioni editoriali e opportunità commerciali.
• Non trasformare automaticamente un'opportunità in copy o in un link affiliato.
• Ripeti lo stesso audit su un secondo batch prima di automatizzare il processo.
• Misura quanto tempo risparmia la revisione e quanti suggerimenti vengono davvero accettati.

Come capire se sei pronto a salire

Non devi eliminare ogni errore. Devi sapere quali errori ricorrono, come intercettarli e quando serve fermare il flusso. Se il risultato dipende ancora da molte decisioni implicite, se i task si sovrappongono o se la verifica è soprattutto una lettura completa, resta al livello attuale e migliora il processo.

• Riesci a descrivere il completamento con controlli osservabili?
• Il task può essere isolato senza conflitti con gli altri?
• Gli errori più comuni vengono intercettati prima della review umana?
• Il reviewer può valutare il risultato senza ricostruire tutta la sessione?
• Costo e tempo fino all'approvazione sono migliori del flusso precedente?
• Sai quali azioni restano manuali e quali condizioni devono fermare l'agente?

Prima manuale, poi skill, script o routine

Esegui il nuovo flusso manualmente almeno due volte. Se cambia molto tra un caso e l'altro ma segue criteri riconoscibili, può diventare una skill. Se i passaggi sono deterministici, preferisci uno script. Se il processo è periodico, stabile e produce risultati affidabili, puoi valutare una routine programmata. Una piattaforma di orchestrazione viene dopo, quando isolamento, verifiche e handoff semplici mostrano limiti reali.

• Skill: procedura variabile che richiede giudizio e riferimenti caricati al bisogno.
• Script: trasformazione o controllo deterministico con input e output chiari.
• Routine: workflow già stabile che deve ripetersi nel tempo.
• Orchestrazione: utile solo quando coordinamento, code, retry e osservabilità non sono più gestibili con strumenti semplici.

Quando non aumentare l'autonomia

Resta su un singolo agente supervisionato quando il task è piccolo, ambiguo o ad alto impatto. Il parallelismo moltiplica il valore solo se il lavoro si separa bene. Altrimenti moltiplica assunzioni, conflitti e review. Lo stesso vale per l'autonomia supervisionata: se non puoi attribuire un errore, fermare il processo o ricostruire le fonti usate, il loop non ha ancora guadagnato fiducia.

• Evita task paralleli che modificano la stessa area o aspettano la stessa decisione.
• Non delegare merge, deploy, pagamenti o comunicazioni esterne solo per ridurre i passaggi umani.
• Non usare consumo, velocità o volume di output come prova sufficiente di qualità.
• Riduci il livello quando aumentano rework, incidenti, costi imprevedibili o difetti dopo l'approvazione.

Domande frequenti