Ferramentas de IA no desenvolvimento Magento: o que funciona e o que falha

Assistentes de código com IA já fazem parte do kit da maioria dos desenvolvedores, e o Magento é um bom teste do que eles conseguem e do que não conseguem fazer. O framework é grande, velho o bastante para ter várias gerações de padrões no código público e cheio de convenções que vivem mais em arquivos XML do que em PHP. Um assistente que conhece bem PHP em geral ainda pode escrever código Magento que parece certo e não funciona.

Este artigo é sobre usar ferramentas de IA em projetos Magento 2 de um jeito que economiza tempo sem adicionar bugs: onde elas ajudam, onde falham, como dar o contexto certo e como verificar o que produzem. Não é uma análise de produtos específicos, já que eles mudam a cada poucos meses. Os hábitos de trabalho continuam os mesmos.

Onde a IA ajuda no trabalho com Magento

Boilerplate

Uma feature no Magento muitas vezes precisa de seis ou mais arquivos antes de qualquer regra de negócio: registration.php, module.xml, di.xml, um db_schema.xml com sua whitelist, uma interface de repository e a implementação, interfaces de dados e o XML de UI component do admin. Os assistentes são bons em gerar essa estrutura, principalmente quando você aponta um módulo existente no mesmo projeto e pede o mesmo layout. A estrutura em si é explicada em um módulo custom do zero.

Ler código desconhecido

Em um codebase herdado com dezenas de módulos custom e de terceiros, um assistente com acesso ao repositório rastreia um fluxo muito mais rápido do que ler arquivo por arquivo. Perguntas como "quais plugins rodam no save do produto", "onde esse observer está registrado" ou "o que grava nessa tabela" viram buscas que a ferramenta executa e resume. Você ainda precisa confirmar a resposta, mas ela reduz onde olhar.

Testes

Testes unitários de classes do Magento são em grande parte montagem de mocks, o que é tedioso e combina bem com um assistente. Dê a classe, peça testes que cubram casos específicos e revise as assertions. Confira se os mocks batem com o constructor real e se as assertions testam comportamento, não só que os métodos foram chamados.

Logs, stack traces e SQL

Colar um stack trace do var/log/exception.log ou uma query lenta do slow log do MySQL e pedir uma explicação é uma primeira passada rápida. A ferramenta muitas vezes acha a causa, como um argumento de DI faltando, um plugin no método errado ou um índice ausente, mais rápido do que uma leitura manual. Remova dados de clientes e segredos antes de colar qualquer coisa.

Onde falham

Nomes inventados

A falha mais comum é código que chama classes, métodos, eventos ou paths de configuração que não existem. Parecem plausíveis porque seguem os padrões de nomes do Magento. Um evento chamado catalog_product_save_after_commit ou um path de config como catalog/seo/enable_hreflang parece real e não é. O código pode até passar numa revisão rápida.

Padrões desatualizados

O código público de Magento cobre muitos anos, e boa parte usa padrões que estão deprecated ou foram removidos na 2.4:

• Scripts InstallSchema e UpgradeSchema em vez de declarative schema e data patches.
• Uso direto de ObjectManager::getInstance() em classes.
• O registry para passar dados entre controller e block, em vez de view models e services.
• Salvar models com $model->save() em vez de repositories.
• Código no estilo Magento 1 misturado, como chamadas Mage::.

Um assistente que não sabe a versão alvo mistura tudo isso sem cerimônia.

Esquecer o lado XML

Muito do comportamento do Magento vive na configuração: di.xml, events.xml, layout XML, webapi.xml, acl.xml, crontab.xml, arquivos de queue. Um assistente pode escrever uma classe de observer correta e esquecer de registrá-la, ou registrá-la na área global quando deveria estar na área frontend. O PHP parece certo e nada acontece em runtime.

Area, scope e cache

O escopo de store view nos valores de config, a diferença entre as áreas adminhtml e frontend e o efeito do full page cache sobre o que pode ser renderizado em um block são coisas que os assistentes costumam perder. Sugerir cacheable="false" para consertar um block desatualizado é um exemplo típico. Funciona, e desabilita o full page cache de toda página que tem aquele block.

Dê à ferramenta o contexto certo

A maioria dessas falhas diminui quando o assistente conhece o projeto. Muitas ferramentas leem um arquivo de instruções do projeto na raiz do repositório. Seja qual for o nome do arquivo na sua ferramenta, coloque nele os fatos que o modelo não consegue adivinhar:

• Versão e edição do Magento, versão do PHP, e se o tema é Luma, Hyvä ou headless.
• Como rodar comandos. Em setups baseados em Docker, o bin/magento precisa rodar dentro do container, então informe o prefixo exato do comando.
• Namespace do vendor, onde ficam os módulos custom e regras de código como strict types e constructor property promotion.
• Padrões a evitar: nada de ObjectManager, nada de setup scripts, nada de SQL direto em tabelas de catálogo se a loja é Adobe Commerce.
• O que a ferramenta nunca deve fazer: rodar comandos de deploy, mudar o app/etc/env.php, dar push no Git.

Dê também acesso ao vendor/magento. A melhor defesa contra nomes inventados é uma ferramenta que consegue pesquisar o código real do core antes de escrever qualquer coisa.

Verifique tudo, de forma barata

A regra que sigo: a saída da IA é um rascunho de um dev júnior rápido que leu muitos posts de blog antigos. Ela é revisada e verificada como qualquer outro código. A maioria das verificações é barata e pode ser executada pelo próprio assistente.

Confira se os nomes existem

grep -rn "'checkout_submit_all_after'" vendor/magento/ | head
grep -rn "interface ProductRepositoryInterface" vendor/magento/module-catalog/Api/
grep -rn "product_canonical_tag" vendor/magento/module-catalog/etc/

Se uma interface ou path de config não aparece no vendor/magento nem no seu código, ela não existe. Eventos pedem mais uma checagem: eventos de model como catalog_product_save_after são montados em runtime a partir do _eventPrefix do model mais um sufixo, então busque pelo prefixo, por exemplo _eventPrefix = 'catalog_product', em vez do nome completo do evento.

Compile e rode o lint

php -l app/code/Vendor/Module/Model/Example.php
bin/magento setup:di:compile
vendor/bin/phpcs --standard=Magento2 app/code/Vendor/Module
vendor/bin/phpstan analyse app/code/Vendor/Module

A compilação de DI pega argumentos de constructor errados, classes faltando e referências ruins no di.xml. O coding standard pega padrões deprecated e problemas de escaping nos templates. A configuração dos dois está em o coding standard do Magento e PHPStan para Magento 2.

Rode de verdade

Nada substitui exercitar a feature em um ambiente local: fazer o pedido, salvar o produto, rodar o cron job. Peça ao assistente os passos exatos para testar o que ele construiu, e execute.

Privacidade e segurança

Projetos Magento têm dados que você não deve enviar a um serviço externo sem pensar:

• O app/etc/env.php guarda as credenciais do banco e a chave de criptografia.
• Dumps do banco guardam nomes, endereços e histórico de pedidos dos clientes.
• Logs podem conter e-mails, IPs e referências de pagamento.

Trabalhe com um banco sanitizado, como descrito em sanitizando um banco de staging, exclua segredos do que a ferramenta pode ler sempre que possível e confira os termos de dados da ferramenta que usa. Se a loja é de um cliente, siga a política dele sobre ferramentas de IA antes de começar.

Uma divisão prática do trabalho

O que funciona bem para mim em tarefas de Magento é ficar com as decisões de design e a revisão final, e passar ao assistente as partes mecânicas ou que exigem muita busca. Decidir entre plugin e observer, o modelo de dados, o comportamento de cache e qualquer coisa que toque checkout ou pagamentos ficam com o desenvolvedor. Gerar os arquivos quando o design está claro, escrever testes, pesquisar no codebase e ler logs vão para a ferramenta, com cada resultado verificado como descrito acima.

Usadas assim, as ferramentas de IA aceleram a metade chata do trabalho com Magento e deixam mais tempo para as partes que pedem experiência. Usadas sem contexto e sem verificação, produzem código que passa em uma olhada e falha em produção.

FAQ

Ferramentas de IA conseguem escrever código Magento pronto para produção?

Conseguem escrever um bom primeiro rascunho, principalmente boilerplate e testes. O código ainda precisa de revisão, compilação de DI, checagem do coding standard e teste de verdade, porque nomes de classe inventados e padrões desatualizados são comuns.

Como evito que um assistente de IA use padrões deprecated do Magento?

Informe as versões exatas do Magento e do PHP e liste os padrões a evitar em um arquivo de instruções do projeto. Deixe que ele pesquise o vendor/magento para checar o código real antes de escrever.

É seguro compartilhar código Magento com ferramentas de IA?

O código geralmente é ok se o dono permite. Não compartilhe o env.php, dumps do banco de produção nem logs com dados de clientes. Use um banco sanitizado no trabalho local.

Qual o jeito mais rápido de pegar erros da IA em código Magento?

Rode setup:di:compile, phpcs com o standard Magento2 e PHPStan, e faça grep no vendor/magento para cada evento, classe e path de config que o código usa.

Atendo como freelancer em Magento e Adobe Commerce e uso essas ferramentas com as verificações descritas aqui. Se precisar de ajuda com um projeto, fale comigo.