De las extensiones PHP a App Builder: Adobe confía la conversión a agentes de IA

Toda discusión sobre replatforming de Magento acaba chocando contra el mismo muro: las extensiones. Una tienda con diez años a cuestas transporta decenas de módulos PHP — desarrollados en casa, comprados y luego retocados — que viven dentro del propio proceso del núcleo. Ese es exactamente el código que la edición SaaS, Adobe Commerce as a Cloud Service, ya no acepta: toda personalización debe reescribirse fuera, en App Builder. Hasta ahora, esa conversión se presupuestaba a mano, módulo a módulo, y a menudo era ella la que enterraba el expediente. Adobe ha decidido equipar la obra con dos piezas complementarias: un agente de migración alojado y skills oficiales para los asistentes de código que tus equipos ya usan.

Un agente que trabaja sobre un plan aprobado

El Commerce Developer Agent es una herramienta alojada por Adobe, accesible tras iniciar sesión con una cuenta de Adobe, que cubre dos escenarios: crear una aplicación App Builder desde una página en blanco o convertir una extensión Commerce existente. Su particularidad interesa directamente a quien decide: no genera nada sin un plan validado. El agente produce primero un blueprint — un plan de arquitectura dividido en fases — que el desarrollador relee, corrige y aprueba antes de que se escriba una sola línea de código. La generación se apoya después en los esqueletos oficiales de App Builder: suscripciones a eventos de Commerce, webhooks, pantalla de ajustes para el comerciante, persistencia de datos. El resultado se exporta como archivo, listo para entrar en tu repositorio y en tu cadena de entrega.

La documentación es igual de clara sobre los límites, y eso la honra. Todo el código generado debe revisarse antes de acercarse a producción: Adobe presenta el agente como un generador de puntos de partida, no como un desarrollador autónomo. No fabrica tu integración continua, ni tu entorno local, ni las conexiones con API Mesh; una sesión trata un solo proyecto a la vez y una generación puede tardar unos cinco minutos.

Skills abiertas para tus propios asistentes

La segunda pieza es quizá la más interesante para los equipos ya equipados. Adobe publica skills oficiales: guías ejecutables que enseñan a un asistente de código los patrones App Builder correctos — inicializar una aplicación, suscribirse a eventos, colocar webhooks, crear la configuración del comerciante, la persistencia o una interfaz de administración, y convertir un proyecto existente. Siguen el estándar abierto agentskills.io y se instalan con un solo comando (npx skills add adobe/skills) en Claude Code, Cursor, VS Code Copilot o Gemini CLI. El repositorio público adobe/skills, bajo licencia Apache 2.0, suma ya varias decenas — Commerce, pero también AEM, Analytics y Workfront.

El matiz es estratégico. El agente alojado te lleva a la herramienta de Adobe; las skills llevan el saber de Adobe a tu herramienta. Para un equipo que ya tiene su disciplina de revisión, sus convenciones y su pipeline, la segunda vía se adopta sin cambiar nada del delivery — y sin depender de la hoja de ruta de un portal.

Qué cambia en un expediente de migración

• La estimación cambia de naturaleza. La buena pregunta ya no es cuántos días cuesta reescribirlo todo, sino cuántos de tus módulos caben en los patrones cubiertos: eventos, webhooks, configuración, almacenamiento, pantallas de administración. Esos se convierten rápido y a coste previsible; lo que modifica el proceso de pedido en el corazón del software sigue siendo un verdadero proyecto de arquitectura.
• La revisión se convierte en la primera partida de coste. El código llega más rápido, pero cada línea debe leerse; tus desarrolladores senior pasan de autores a revisores. Sin una puerta de revisión sólida — pruebas de aceptación, integración continua, regla de nunca a producción sin lectura humana — un generador solo produce deuda más deprisa.
• El bloqueo con el proveedor se sopesa pieza a pieza. Las skills siguen un estándar abierto y funcionan en el asistente que elijas; el código de destino, en cambio, sigue siendo App Builder, es decir, la infraestructura de Adobe. La conversión es un compromiso de plataforma: decídelo por la plataforma, no por la comodidad de la herramienta.

Por dónde empezar

• Inventaría tus extensiones y clasifícalas en dos columnas: cubiertas por los patrones de arriba o ancladas en el proceso del núcleo. La segunda columna mide tu verdadera distancia al SaaS.
• Haz un piloto con una sola extensión de complejidad media: blueprint, generación y después una medición honesta del tiempo de revisión y de consolidación. Ese es tu coste unitario de conversión; multiplicarlo vale más que cualquier estimación abstracta.
• Pon las barandillas antes de acelerar: pruebas repetibles en los recorridos críticos, revisión obligatoria, nada a producción sin lectura humana. La velocidad de generación vale lo que valga tu control de calidad.

Presentado en el Summit en primavera, el agente alcanzó la disponibilidad general a finales de septiembre, y App Management tiene ya su entrada en la administración de Commerce. El mensaje de Adobe para 2027 es nítido: reescribir tus extensiones ya no es motivo para aplazar la decisión — el proveedor pone los obreros. Queda por poner lo que no se genera: el jefe de obra.