Dalle estensioni PHP ad App Builder: Adobe affida la conversione ad agenti IA

Ogni discussione sul replatforming di Magento finisce per sbattere contro lo stesso muro: le estensioni. Un negozio con dieci anni di vita trasporta decine di moduli PHP — sviluppati in casa, comprati e poi ritoccati — che vivono dentro il processo stesso del core. È esattamente il codice che l'edizione SaaS, Adobe Commerce as a Cloud Service, non accetta più: ogni personalizzazione va riscritta all'esterno, su App Builder. Finora quella conversione si stimava a mano, modulo per modulo, ed era spesso ciò che seppelliva il dossier. Adobe ha deciso di attrezzare il cantiere con due mattoni complementari: un agente di migrazione ospitato e skill ufficiali per gli assistenti di codice che i tuoi team usano già.

Un agente che lavora su un piano approvato

Il Commerce Developer Agent è uno strumento ospitato da Adobe, accessibile previo accesso con un account Adobe, che copre due scenari: creare un'applicazione App Builder da una pagina bianca o convertire un'estensione Commerce esistente. La sua particolarità interessa direttamente chi decide: non genera nulla senza un piano validato. L'agente produce prima un blueprint — un piano di architettura diviso in fasi — che lo sviluppatore rilegge, corregge e approva prima che venga scritta una sola riga di codice. La generazione si appoggia poi agli scheletri App Builder ufficiali: sottoscrizioni agli eventi Commerce, webhook, schermata di impostazioni per il merchant, persistenza dei dati. Il risultato si esporta come archivio, pronto a entrare nel tuo repository e nella tua catena di delivery.

La documentazione è altrettanto chiara sui limiti, e va a suo merito. Tutto il codice generato dev'essere riletto prima di avvicinarsi alla produzione: Adobe presenta l'agente come un generatore di punti di partenza, non come uno sviluppatore autonomo. Non costruisce la tua integrazione continua, né il tuo ambiente locale, né i collegamenti API Mesh; una sessione tratta un solo progetto alla volta e una generazione può richiedere circa cinque minuti.

Skill aperte per i tuoi assistenti

Il secondo tassello è forse il più interessante per i team già attrezzati. Adobe pubblica skill ufficiali: manuali eseguibili che insegnano a un assistente di codice i pattern App Builder corretti — inizializzare un'applicazione, sottoscrivere gli eventi, posare webhook, creare la configurazione merchant, la persistenza o un'interfaccia di amministrazione, e convertire un progetto esistente. Seguono lo standard aperto agentskills.io e si installano con un solo comando (npx skills add adobe/skills) in Claude Code, Cursor, VS Code Copilot o Gemini CLI. Il repository pubblico adobe/skills, con licenza Apache 2.0, ne conta già diverse decine — Commerce, ma anche AEM, Analytics e Workfront.

La sfumatura è strategica. L'agente ospitato ti porta dentro lo strumento di Adobe; le skill portano il sapere di Adobe dentro il tuo strumento. Per un team che ha già la sua disciplina di review, le sue convenzioni e la sua pipeline, la seconda via si adotta senza cambiare nulla del delivery — e senza dipendere dalla roadmap di un portale.

Cosa cambia in un dossier di migrazione

• La stima cambia natura. La domanda giusta non è più quanti giorni servono per riscrivere tutto, ma quanti dei tuoi moduli rientrano nei pattern coperti: eventi, webhook, configurazione, storage, schermate di amministrazione. Quelli si convertono in fretta e a costo prevedibile; ciò che modifica il processo d'ordine nel cuore del software resta un vero progetto di architettura.
• La review diventa la prima voce di costo. Il codice arriva più in fretta, ma ogni riga va letta; i tuoi sviluppatori senior passano da autori a revisori. Senza un cancello di review solido — test di accettazione, integrazione continua, regola del mai in produzione senza rilettura — un generatore produce solo debito più in fretta.
• Il lock-in si valuta pezzo per pezzo. Le skill seguono uno standard aperto e girano nell'assistente che preferisci; il codice di destinazione, però, resta App Builder, quindi l'infrastruttura di Adobe. La conversione è un impegno di piattaforma: decidilo per la piattaforma, non per la comodità dello strumento.

Da dove cominciare

• Fai l'inventario delle estensioni e dividile in due colonne: coperte dai pattern qui sopra, oppure ancorate al processo del core. La seconda colonna misura la tua vera distanza dal SaaS.
• Fai un pilota su una sola estensione di complessità media: blueprint, generazione, poi misura onesta del tempo di review e di consolidamento. È il tuo costo unitario di conversione; moltiplicarlo vale più di qualsiasi stima astratta.
• Metti i guardrail prima di accelerare: test ripetibili sui percorsi critici, review obbligatoria, niente produzione senza una lettura umana. La velocità di generazione vale quanto vale il tuo controllo qualità.

Presentato al Summit in primavera, l'agente è arrivato alla disponibilità generale a fine settembre, e App Management ha ormai la sua voce nell'amministrazione di Commerce. Il messaggio di Adobe per il 2027 è nitido: riscrivere le estensioni non è più un motivo per rinviare la decisione — il vendor fornisce gli operai. Resta da fornire ciò che non si genera: il capocantiere.