Das extensões PHP ao App Builder: a Adobe entrega a conversão a agentes de IA

Qualquer discussão sobre replatforming de Magento acaba por bater no mesmo muro: as extensões. Uma loja com dez anos transporta dezenas de módulos PHP — desenvolvidos internamente, comprados e depois retocados — que vivem dentro do próprio processo do núcleo. É exatamente esse código que a edição SaaS, Adobe Commerce as a Cloud Service, já não aceita: toda a personalização tem de ser reescrita no exterior, em App Builder. Até agora, essa conversão era orçamentada à mão, módulo a módulo, e era muitas vezes ela que enterrava o dossiê. A Adobe decidiu equipar o estaleiro com duas peças complementares: um agente de migração alojado e skills oficiais para os assistentes de código que as suas equipas já utilizam.

Um agente que trabalha sobre um plano aprovado

O Commerce Developer Agent é uma ferramenta alojada pela Adobe, acessível após iniciar sessão com uma conta Adobe, que cobre dois cenários: criar uma aplicação App Builder a partir de uma página em branco ou converter uma extensão Commerce existente. A sua particularidade interessa diretamente a quem decide: não gera nada sem um plano validado. O agente produz primeiro um blueprint — um plano de arquitetura dividido em fases — que o programador relê, corrige e aprova antes de ser escrita qualquer linha de código. A geração apoia-se depois nos esqueletos oficiais do App Builder: subscrições de eventos Commerce, webhooks, ecrã de definições para o comerciante, persistência de dados. O resultado exporta-se como arquivo, pronto a entrar no seu repositório e na sua cadeia de entrega.

A documentação é igualmente clara quanto aos limites, o que a honra. Todo o código gerado tem de ser revisto antes de se aproximar da produção: a Adobe apresenta o agente como um gerador de pontos de partida, não como um programador autónomo. Não constrói a sua integração contínua, nem o seu ambiente local, nem as ligações API Mesh; uma sessão trata um único projeto de cada vez e uma geração pode demorar cerca de cinco minutos.

Skills abertas para os seus próprios assistentes

A segunda peça é talvez a mais interessante para as equipas já equipadas. A Adobe publica skills oficiais: guias executáveis que ensinam a um assistente de código os padrões App Builder corretos — inicializar uma aplicação, subscrever eventos, instalar webhooks, criar a configuração do comerciante, a persistência ou uma interface de administração, e converter um projeto existente. Seguem a norma aberta agentskills.io e instalam-se com um único comando (npx skills add adobe/skills) no Claude Code, no Cursor, no VS Code Copilot ou no Gemini CLI. O repositório público adobe/skills, sob licença Apache 2.0, conta já com várias dezenas — Commerce, mas também AEM, Analytics e Workfront.

A nuance é estratégica. O agente alojado fá-lo entrar na ferramenta da Adobe; as skills fazem entrar o saber da Adobe na sua ferramenta. Para uma equipa que já tem a sua disciplina de revisão, as suas convenções e o seu pipeline, a segunda via adota-se sem mudar nada na entrega — e sem depender do roadmap de um portal.

O que isto muda num dossiê de migração

• A estimativa muda de natureza. A boa pergunta já não é quantos dias custa reescrever tudo, mas quantos dos seus módulos cabem nos padrões cobertos: eventos, webhooks, configuração, armazenamento, ecrãs de administração. Esses convertem-se depressa e a custo previsível; o que altera o processo de encomenda no coração do software continua a ser um verdadeiro projeto de arquitetura.
• A revisão torna-se a primeira rubrica de custo. O código chega mais depressa, mas cada linha tem de ser lida; os seus programadores seniores passam de autores a revisores. Sem um portão de revisão sólido — testes de aceitação, integração contínua, regra de nunca pôr em produção sem leitura humana — um gerador limita-se a produzir dívida mais depressa.
• O vínculo ao fornecedor pesa-se peça a peça. As skills seguem uma norma aberta e correm no assistente à sua escolha; o código de destino, porém, continua a ser App Builder, logo a infraestrutura da Adobe. A conversão é um compromisso de plataforma: decida-o pela plataforma, não pela comodidade da ferramenta.

Por onde começar

• Inventarie as suas extensões e separe-as em duas colunas: cobertas pelos padrões acima ou ancoradas no processo do núcleo. A segunda coluna mede a sua verdadeira distância ao SaaS.
• Faça um piloto com uma única extensão de complexidade média: blueprint, geração e depois uma medição honesta do tempo de revisão e de consolidação. É o seu custo unitário de conversão; multiplicá-lo vale mais do que qualquer estimativa abstrata.
• Coloque as salvaguardas antes de acelerar: testes repetíveis nos percursos críticos, revisão obrigatória, nada em produção sem leitura humana. A velocidade de geração vale o que valer o seu controlo de qualidade.

Apresentado no Summit na primavera, o agente chegou à disponibilidade geral no final de setembro, e o App Management tem agora a sua entrada na administração do Commerce. A mensagem da Adobe para 2027 é límpida: reescrever as suas extensões já não é razão para adiar a decisão — o fornecedor fornece os operários. Falta fornecer o que não se gera: o chefe de obra.