Nel corso degli anni, progettando e gestendo soluzioni Adobe Commerce e AEM, mi sono abituato a una divisione netta: da una parte la piattaforma, con le sue regole e i suoi vincoli; dall’altra il lavoro operativo, quello che ti mangia le giornate. Da qualche mese quella divisione ha smesso di avere senso per me. Non perché le competenze Adobe contino di meno, ma perché ho iniziato a intrecciarle con gli agenti di Claude, Claude Code, Cowork, MCP costruiti su misura, e il risultato non assomiglia né al “consulente Adobe di prima” né al “prompt engineer che scopre l’AI”.
Il punto che voglio difendere qui è semplice, e lo scrivo nella forma più netta che riesco: l’AI è un moltiplicatore di competenza, non un sostituto di competenza. Un agente senza contesto di dominio produce output plausibili e sbagliati. Un architetto Adobe senza leva agentica resta bravo ma lento. La leva funziona se chi la impugna sa già cosa vuole e sa riconoscere quando la macchina sbaglia. Il “se” non è una cautela da mettere in fondo per prudenza: è la tesi.
Perché due competenze isolate rendono meno della loro somma
Faccio un esempio concreto e anonimizzato. Un merchant fashion, intorno ai 15M di GMV, mi chiede di capire perché il conversion rate sul checkout mobile è calato dopo un rilascio. La versione “solo Adobe” di questo lavoro la conosco a memoria: apro Adobe Analytics, segmento, incrocio con i dati di Target sugli A/B test attivi, guardo il codice del checkout in Adobe Commerce, formulo un’ipotesi. Sono giorni di lavoro, quasi tutti spesi a raccogliere ed estrarre, non a ragionare.
La versione “solo AI” è peggiore di quanto sembri. Se do lo stesso problema a un modello senza contesto, ricevo una lista di cause generiche, controlla i tempi di caricamento, verifica i campi del form, che vale per qualunque e-commerce e per nessuno in particolare. Il modello non sa che quel merchant ha una logica di prezzo custom, non sa che il test di Target su quella pagina è partito tre giorni prima del calo, non sa distinguere un bug da una scelta di business.
La competenza di dominio serve a porre la domanda giusta e a validare la risposta; l’agente serve a percorrere in ore lo spazio di ricerca che a mano richiederebbe giorni. Tolgo una delle due e il sistema si sgonfia.
Qui aggiungo una cosa scomoda, che dico volentieri agli sviluppatori con cui lavoro. Chi oggi liquida l’AI come uno strumento inaffidabile sta restando indietro. Non perché l’AI sia infallibile, ma perché su una gran parte del lavoro quotidiano scrive codice meglio di uno sviluppatore medio, e fa code review meglio di quasi tutti noi a fine giornata. Uno sviluppatore che ha chiare idea, processi e metodo, con l’AI fa in un decimo del tempo quello che faceva prima. Uno che non li ha, con l’AI fa danni in un decimo del tempo. Vale lo stesso “se” di prima.
Il metodo: dove l’AI accelera e dove resta il giudizio umano
Nel tempo ho smesso di improvvisare e ho fissato un metodo ripetibile. Non è un framework da vendere, è il modo in cui divido il lavoro tra quello che delego e quello che tengo.
Cosa delego agli agenti
- Bozze e prime versioni. Configurazioni, script di migrazione dati, template di email transazionali, documentazione tecnica. Roba che deve esistere in una prima forma per poterci ragionare sopra. Non parto quasi mai dalla pagina bianca.
- Analisi e riconciliazione. Incrociare export di Adobe Analytics con i log di piattaforma, confrontare un catalogo prodotti tra due ambienti, cercare l’anomalia in migliaia di righe. Con un MCP che parla direttamente con Analytics o con le API di Commerce, l’agente fa in autonomia la parte noiosa e mi porta le eccezioni.
- Operatività ripetitiva. Aggiornare centinaia di schede prodotto, sistemare redirect dopo una migrazione, riallineare metadati. Batch che prima davo a una persona per due giorni e che oggi giro a un agente con un gate di controllo in mezzo.
- Esplorazione e code review. “Fammi vedere tre modi di modellare questo attributo in Commerce, con pro e contro.” Non prendo la risposta come oro colato: la uso per accelerare la mia analisi. E sulle review, ormai, l’agente passa prima di me.
Cosa non delego mai
- L’architettura. La decisione se andare headless o restare sul frontend nativo, come disegnare il modello dati, dove mettere il confine tra Commerce e i sistemi a monte: quella resta mia. È il punto dove un errore costa mesi, non ore.
- Le decisioni di business travestite da scelte tecniche. Un agente ti dirà volentieri qual è la soluzione più pulita. Non ti dirà che quel merchant ha un vincolo di budget, un team interno da rispettare, una scadenza commerciale. Quel contesto lo porto io.
- I gate. Prima di ogni azione che tocca produzione o dati sensibili c’è un mio controllo esplicito. L’agente propone, io approvo. Non è burocrazia: è il punto in cui la mia competenza Adobe verifica che l’output plausibile sia anche corretto.
La linea, in sostanza, la tengo qui: l’AI accelera la produzione e l’analisi, il giudizio umano governa l’architettura, il contesto e i gate di rischio. Se la sposto troppo in là verso l’automazione, comincio a fidarmi di cose che non ho verificato. Se la sposto troppo indietro, torno a essere lento senza motivo. Sto ancora tarando quel punto, e cambio idea più spesso di quanto vorrei ammettere.
Gli MCP su misura sono il vero anello di congiunzione
La parte che mi ha cambiato il lavoro più di ogni altra sono gli MCP costruiti su misura. Un Model Context Protocol server è, in pratica, il modo in cui do all’agente accesso strutturato agli strumenti che uso già: le API di Adobe Commerce, un ambiente di staging, un export di Analytics. Senza, l’agente è un consulente bravo ma cieco. Con, diventa un collega che può guardare i dati veri invece di ipotizzarli.
Qui la mia opinione è netta: il collo di bottiglia dell’AI applicata all’e-commerce non è la qualità del modello, è l’accesso al contesto e la pulizia dei dati che trova. Claude Opus 4.8 è più che capace di ragionare sul mio dominio. Quello che gli mancava era il ponte verso i miei sistemi, e quel ponte lo costruisco io perché conosco entrambe le sponde: so cosa esporre dalle API Adobe e so cosa un agente può farne. Chi conosce solo l’AI costruisce ponti verso il nulla; chi conosce solo Adobe non pensa nemmeno a costruirli.
Il caso in cui il metodo non ha funzionato è istruttivo, e lo racconto perché altrimenti questo pezzo sarebbe una brochure. Su un catalogo con attributi stratificati in dieci anni e regole di prezzo contraddittorie, l’agente collegato via MCP ha prodotto diagnosi sicure e sbagliate. Non era il modello. Erano i dati. Da lì la regola che ripeto a ogni merchant che mi chiede da dove iniziare con l’AI: prima metti in ordine i dati. Poi parliamo di agenti.
Un caso, dall’inizio alla fine
Torno al merchant fashion del checkout. Con il metodo, la giornata va così. Un agente collegato via MCP ad Analytics e all’ambiente di staging estrae i dati di conversione segmentati per device, li incrocia con la lista dei test Target attivi e con la data del rilascio, e mi porta una tabella con l’anomalia già isolata: il calo è concentrato su un solo browser mobile, e coincide con l’attivazione di un test. In parallelo, un secondo passaggio confronta il codice del checkout prima e dopo il deploy e segnala la modifica sospetta.
A questo punto entra il mio pezzo. Guardo l’anomalia e capisco, perché conosco quella piattaforma, che non è un bug del codice: è il test di Target che rende una validazione del form incompatibile con quel browser. Non era una domanda che l’agente poteva chiudere da solo, perché richiede di sapere come Target inietta le varianti e come Commerce gestisce quella validazione. Ma senza l’agente ci sarei arrivato due giorni dopo. La macchina ha ristretto il campo, io ho chiuso il cerchio. Questo è l’incrocio.
Cosa cambia, e cosa no
Non credo che gli agenti rendano obsolete le competenze Adobe. Credo l’esatto contrario: più l’AI diventa capace, più conta chi sa esattamente cosa chiederle e come verificarla. Il rischio vero non è l’agente che sbaglia, quello lo intercetto al gate. Il rischio è il professionista che accetta output plausibili perché non ha il dominio per contestarli. È il costo nascosto di tutta questa storia: senza qualcuno che sappia già la risposta giusta, non riconosci l’errore. E chi non ce l’ha, non se ne accorge.
Sul mestiere del consulente la penso così: cambia, non sparisce. Meno esecuzione, più architettura e responsabilità. Il mio lavoro, oggi, è tenere la linea tra i due mondi nel punto giusto, sapendo che quel punto si sposta.
Mini-FAQ
Gli agenti sostituiscono la competenza su Adobe Commerce?
No. La moltiplicano. Un agente produce output plausibili; serve competenza di dominio per distinguere quelli corretti da quelli sbagliati e per decidere l’architettura. Chi non ha quella competenza non riesce nemmeno ad accorgersi degli errori.
Cos’è un MCP su misura in un progetto Adobe?
È un Model Context Protocol server che dà all’agente accesso strutturato ai sistemi reali: API di Adobe Commerce, un ambiente di staging, export di Analytics. Trasforma l’agente da consulente cieco a collaboratore che ragiona sui dati veri anziché ipotizzarli.
Dove passa il confine tra AI e giudizio umano?
Delego agli agenti bozze, analisi, operatività ripetitiva, esplorazione e code review. Tengo per me architettura, decisioni di business e i gate di controllo prima di ogni azione su produzione o dati sensibili. L’agente propone, io approvo.
Sono Fabio Canovi, consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech. Sono certificato su Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target, e unisco queste competenze all’AI agentica (Claude Code, Cowork, MCP) per accelerare i progetti sul campo. Su questo blog racconto come lavoro davvero, non come si dovrebbe lavorare in teoria.