Nel corso degli anni, lavorando su progetti Adobe Commerce e AEM, ho fatto pace con una verità poco romantica: gran parte della delivery non è codice o architettura. È preparazione. Leggere un brief, allineare un documento di analisi, riformattare un export, scrivere l’ennesima mail di stato, ricostruire il contesto di un ticket. Lavoro necessario, ripetitivo, che erode le ore che vorrei dare alle decisioni vere.
Da gennaio uso Cowork, insieme a Claude Code e ai miei MCP, dentro questo flusso. Non come gadget, ma come parte operativa della giornata. Voglio raccontare come lo uso davvero, cosa delego e cosa tengo saldamente sotto controllo umano. Niente demo perfette: il flusso reale, con i suoi gate e con le sue rogne.
Cosa intendo per “flusso di delivery”
Sgombro il campo da un equivoco. Non parlo di far generare codice di produzione a un agente e spingerlo in un progetto Adobe Commerce senza guardare. Parlo del contorno della delivery: la parte che sta prima e intorno allo sviluppo, e che di solito nessuno misura ma pesa.
Nel mio caso il flusso ha tre stadi ricorrenti. Dal brief alla bozza: trasformare una richiesta cliente disordinata in un documento strutturato, con assunzioni, domande aperte, impatto stimato. Preparazione di documenti e analisi: mettere insieme un export di dati, una checklist di configurazione, una prima lettura di un log. Operatività ripetitiva: le stesse azioni che rifaccio ogni settimana su ambienti simili.
Dal brief alla bozza: il primo drafting lo delego
Qui Cowork mi fa risparmiare più tempo. Prendo il materiale grezzo, una mail del cliente, gli appunti di un workshop, un requisito buttato giù male, e chiedo una prima strutturazione: obiettivo, scope, assunzioni esplicite, rischi, domande da chiudere. Non mi aspetto la verità finale. Mi aspetto un punto di partenza che mi tolga la pagina bianca.
La differenza rispetto a un anno fa è che oggi l’agente lavora dentro i miei file e con i miei strumenti collegati, non in una chat isolata. Legge il documento giusto, produce la bozza nel formato che uso, e io intervengo dove serve il giudizio: cosa è davvero in scope, quale assunzione è pericolosa, dove il cliente si sta illudendo. La bozza è sua. La presa di posizione resta mia.
Il guadagno c’è, ed è consistente: un documento di analisi preliminare che prima mi portava via mezza giornata oggi lo chiudo in un paio d’ore. Ma il guadagno esiste se so già che forma deve avere quel documento. Ho provato a farmelo produrre su un dominio che conoscevo poco, e il risultato era plausibile, ordinato e inutile: non avevo gli anticorpi per accorgermi di cosa mancava. È lo stesso principio di sempre: l’AI moltiplica la competenza, non la crea.
Preparazione e analisi: dove gli MCP cambiano le cose
Il salto vero, per me, sono gli MCP. Un agente che scrive bene testi è utile; un agente che può leggere i sistemi dove vivo è un’altra categoria. Con i connettori giusti, Cowork non ragiona a vuoto: parte dai dati reali del contesto in cui sto lavorando.
Un esempio concreto e anonimizzato. Su un merchant fashion attorno ai 15M di GMV mi arriva la classica segnalazione: un prodotto non si vede a catalogo. Prima era una caccia manuale: controllo stato, visibilità, stock, assegnazione categoria, reindex. Oggi imposto il flusso perché l’agente raccolga quelle informazioni via MCP e mi presenti una diagnosi già ordinata: ecco cosa ho trovato, ecco l’ipotesi, ecco l’azione che propongo. Io leggo, decido, approvo. L’operatività la fa lui, il giudizio lo faccio io.
Vale la pena dire dove questo non funziona. Su un ambiente con dati incoerenti e configurazioni stratificate negli anni, la diagnosi ordinata che l’agente mi presenta è ordinata e sbagliata. Non è un problema di modello: è che il disordine a monte viene amplificato, non risolto. Per questo la prima cosa che dico a un merchant che vuole partire con l’AI è la più noiosa: prima metti in ordine i dati.
Cosa NON delego: i gate umani
Qui voglio essere netto, perché è la parte che troppi saltano. Automatizzare non vuol dire togliere le mani dal volante. Nel mio flusso ci sono gate espliciti dove l’essere umano deve dire sì.
- Qualsiasi azione con effetto sul cliente, una mail che parte, una modifica su un ambiente, un preventivo, passa da una mia approvazione. L’agente prepara, io autorizzo.
- Le decisioni di scope e di stima. Un numero in un’offerta è una responsabilità professionale, non un output da rigenerare. La bozza aiuta; la firma è mia.
- Le scritture sugli ambienti Adobe di produzione. Diagnosi e proposta sì, esecuzione solo con conferma esplicita e tracciata.
Il principio che seguo è semplice: delego la preparazione, non la responsabilità. L’agente riduce il costo di arrivare alla decisione. La decisione resta un atto umano, con un gate visibile. E i gate non sono un atto di sfiducia verso la macchina: sono il punto in cui misuro cosa ha fatto. Su questo la mia posizione è che si parla troppo di rischi teorici e troppo poco di log e metriche. Meno paranoia, più misurazione.
Quanto tempo risparmio davvero
Provo a essere onesto e a non vendere numeri che non ho misurato. Il risparmio non è uniforme. Sulle attività di drafting e preparazione documentale il taglio è netto e lo sento ogni settimana. Sull’operatività ripetitiva a basso rischio il guadagno c’è soprattutto perché elimino context switching. Sulle attività di giudizio, architettura, stime, relazione col cliente, il risparmio è vicino a zero, ed è giusto così: non è lì che voglio automatizzare.
Il tempo che recupero non lo uso per fare più cose. Lo riverso sulla parte in cui un consulente vale qualcosa. Questo è il punto che mi interessa: Cowork non mi rende più veloce a scrivere mail, mi restituisce attenzione da spendere sulle decisioni. E il mestiere, di conseguenza, cambia ma non sparisce: meno esecuzione, più architettura e responsabilità.
Cosa cambierei ancora
Non è tutto liscio. Un agente è bravo quanto il contesto che gli dai: se i miei file sono disordinati, la bozza è disordinata. Ho dovuto investire nel mettere ordine, convenzioni, cartelle, MCP configurati bene, prima di vedere il ritorno, e quella fatica nessuno la racconta mai. Resta il rischio dell’eccesso di fiducia: l’output pulito sembra giusto, ed è esattamente quando serve rileggere. Il mio antidoto è tenere i gate stretti dove l’errore costa.
Ma la direzione, per me, è chiara. La delivery Adobe ha una quota enorme di lavoro di preparazione che non richiede un consulente senior. Delegarla a un agente, con gate umani nei punti giusti, è il modo più concreto che ho trovato per fare meno amministrazione e più mestiere.
Mini-FAQ
Cowork sostituisce lo sviluppo su Adobe Commerce?
No. Nel mio flusso automatizza il contorno della delivery: drafting, preparazione documenti, operatività ripetitiva. Il codice di produzione resta lavoro presidiato, con review e pipeline.
Cosa deleghi e cosa tieni umano?
Delego la preparazione: bozze, analisi, azioni ripetitive a basso rischio. Tengo umane le decisioni di scope, le stime, e ogni azione con effetto sul cliente o sugli ambienti di produzione, che passano da un gate di approvazione.
Quanto tempo si risparmia?
Sul drafting e sulla preparazione documentale il risparmio è netto. Sul giudizio, quasi nullo, e va bene così. Non ho una baseline misurata da darvi, e preferisco dirlo piuttosto che inventare una percentuale.
A cosa servono gli MCP in questo flusso?
Permettono all’agente di partire dai dati reali dei sistemi in cui lavoro, non da ipotesi. È la differenza tra un agente che scrive testi e uno che diagnostica un problema di catalogo leggendo il contesto vero. Sempre che quel contesto sia in ordine.
Fabio Canovi è consulente Adobe italiano specializzato nell’AI agentica, presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Unisce la delivery sull’ecosistema Adobe all’AI agentica applicata al lavoro reale: Claude Code, Cowork e MCP.