IA no Desenvolvimento Magento 2 e Adobe Commerce: Guia Prático com LLMs, Copilot e Cursor

No que a IA é realmente boa no Magento: boilerplate e tradução de padrões

Magento 2 é um framework com uma quantidade brutal de boilerplate. Para registrar um módulo você precisa, no mínimo, de dois arquivos: app/code/<Vendor>/<Module>/registration.php e app/code/<Vendor>/<Module>/etc/module.xml, e só depois roda bin/magento setup:upgrade para registrar. Esse tipo de estrutura repetitiva é onde o LLM brilha — não porque ele "entende" Magento, mas porque viu milhares de exemplos quase idênticos no treino.

Na minha experiência, esses são os casos em que eu deixo a IA escrever o primeiro rascunho sem pestanajar (e revisar é rápido porque o formato é conhecido):

• Esqueleto de módulo: registration.php, etc/module.xml, composer.json do módulo, estrutura de pastas.
• Wiring de DI: etc/di.xml com preferences, types, virtualTypes e injeção de argumentos.
• Plugins e observers: o esqueleto de um plugin before/after/around e o par etc/events.xml + classe Observer implementando \Magento\Framework\Event\ObserverInterface.
• Resolvers GraphQL: classe implementando \Magento\Framework\GraphQl\Query\ResolverInterface e o schema.graphqls correspondente.
• UI Components de admin: XML de grid (listing) e form com DataProvider — é verboso e a IA acerta a estrutura.
• Data e Schema Patches: classes em Setup/Patch/Data/ e Setup/Patch/Schema/ e o etc/db_schema.xml declarativo.
• Testes PHPUnit: o esqueleto de um teste unitário com mocks dos construtores — chato de escrever à mão, ótimo para gerar.

O melhor caso de uso: traduzir Magento 1 para Magento 2

Onde a IA me poupa horas de verdade é na tradução de padrões. Se você cola um bloco de código Magento 1 (um Mage::getModel(), um observer no formato antigo, um helper) e pede o equivalente idiomático em Magento 2 — com injeção de dependência via construtor, service contracts e repositórios — o resultado costuma ser um excelente ponto de partida. Isso é especialmente útil em projetos de migração de Magento 1 para Magento 2, onde você tem centenas de pequenos trechos legados para reescrever.

Outras tarefas "de tradução" em que a IA é forte e o risco é baixo (porque você valida o resultado rodando):

• Explicar stack traces: cole o erro completo do var/log/exception.log e peça a causa raiz provável. Ela costuma apontar a classe e o método certos.
• Regex e SQL: escrever e, principalmente, explicar uma expressão regular ou uma query complexa contra o schema EAV do Magento.
• Conversão de formatos: de array PHP para XML de config, de cURL para uma query GraphQL, de JSON de payload para uma classe de DTO.

A regra mental que eu uso: a IA é ótima quando o erro é fácil de detectar (compila ou não, o teste passa ou não, o phpcs reclama ou não). Ela é perigosa quando o erro é silencioso — um método que existe mas faz outra coisa, um escaping que falta, um plugin que não dispara.

A armadilha número um: alucinação de APIs, classes e métodos que não existem

A superfície de API do Magento é enorme: milhares de classes, interfaces, métodos mágicos via EAV, extension attributes. O LLM não tem como "saber" todas — ele prediz o próximo token mais plausível. E o nome de método mais plausível para "pegar produto pelo SKU" é getProductBySku(). O problema: \Magento\Catalog\Api\ProductRepositoryInterface expõe get($sku) e getById($id), não getProductBySku(). A IA inventa a assinatura com total confiança.

Isso vai muito além de um nome errado. O estudo de 2025 com 576 mil amostras mostrou que o problema escala para o ecossistema de dependências: cerca de 20% dos pacotes sugeridos por LLMs não existem, e como 43% dos nomes alucinados se repetem, eles viram alvo de slopsquatting — um atacante registra o nome fictício que a IA gera com frequência e espera você rodar composer require num pacote envenenado.

Quase 20% dos pacotes recomendados por LLMs não existem em nenhum registro público; desses pacotes alucinados, 43% aparecem repetidamente em múltiplos prompts, tornando-os alvos previsíveis para ataques de "slopsquatting" — o registro malicioso dos nomes fictícios gerados pela IA. (Resumo do estudo, não citação literal.)

Fonte: ActiveState

O catálogo de alucinações que eu mais vejo no Magento

Como eu blindo contra isso na prática

A defesa não é confiar menos na IA de forma genérica — é ter um processo de verificação determinístico:

• Validar a assinatura contra a classe real: abra a interface (ex.: vendor/magento/module-catalog/Api/ProductRepositoryInterface.php) e confira o método. A IDE com PHP Intelephense ou PhpStorm acusa o método inexistente na hora.
• Rodar composer require só com pacote verificado: antes de instalar qualquer dependência sugerida, confirme no packagist.org que o pacote existe, quem o mantém e quantos downloads tem. Nunca cole um composer require da IA direto no terminal.
• PHPStan como rede: o bitexpert/phpstan-magento pega chamadas a métodos inexistentes em tempo de análise estática — detalho na seção do fluxo de validação.
• Pedir a fonte: eu literalmente peço "confirme em qual classe do core esse método existe e cole a assinatura". Se o modelo titubeia, é sinal vermelho.

Regra de ouro: todo nome de classe, método e pacote que sai de um LLM é uma hipótese até ser confirmado contra o código real.

Padrões obsoletos e deriva de versão: o que o material de treino envenena

O segundo grande risco é mais sutil que a alucinação porque o código funciona — só que está errado segundo as práticas atuais. O LLM foi treinado em anos de blogs, respostas de Stack Overflow e repositórios antigos, muitos da época do Magento 2.0–2.2 ou até de Magento 1. Resultado: ele sugere padrões tecnicamente funcionais, mas obsoletos ou proibidos.

ObjectManager direto: o erro que a documentação proíbe explicitamente

O exemplo canônico. A IA adora resolver "preciso de uma instância dessa classe" com ObjectManager::getInstance()->create(). A documentação oficial é categórica:

The application prohibits the direct use of the ObjectManager in your code because it hides the real dependencies of a class.

Fonte: Adobe Commerce — Object Manager

As únicas exceções aceitas são bem estreitas: magic methods estáticos (__wakeup, __sleep), manutenção de compatibilidade retroativa em construtores, fixtures de testes de integração e as próprias classes de criação de objetos (factories e proxies). Em todo o resto, dependência se injeta via construtor. Aqui o contraste do que a IA tende a gerar versus o que vai para produção:

// O que a IA frequentemente sugere (ERRADO em código de aplicação)
class MyService
{
    public function load($id)
    {
        $om = \Magento\Framework\App\ObjectManager::getInstance();
        $repo = $om->get(\Magento\Catalog\Api\ProductRepositoryInterface::class);
        return $repo->getById($id);
    }
}

// O padrão correto: injeção via construtor
class MyService
{
    public function __construct(
        private readonly \Magento\Catalog\Api\ProductRepositoryInterface $productRepository
    ) {}

    public function load(int $id)
    {
        return $this->productRepository->getById($id);
    }
}

O resto da lista de antipadrões que a IA ressuscita

• Helper classes para lógica de negócio: herdar de \Magento\Framework\App\Helper\AbstractHelper para colocar regra de negócio. Hoje isso é cheiro de código — a lógica vai em service contracts e classes de domínio.
• Models abstratos antigos: estender AbstractModel e fazer $model->load()/->save() direto, em vez de usar o repository e os métodos do service contract.
• InstallSchema / UpgradeSchema: a IA ainda gera Setup/InstallSchema.php e UpgradeSchema.php. Desde o 2.3 o caminho é o esquema declarativo em etc/db_schema.xml mais Data Patches.
• SQL cru com concatenação: montar query com variáveis interpoladas em vez de usar o \Magento\Framework\DB\Adapter\AdapterInterface com bind — risco direto de SQL injection (próxima seção).
• jQuery/RequireJS desatualizado: exemplos de frontend de versões antigas que não batem com o tema atual.

Deriva de versão: 2.3 não é 2.4.9

O treino do modelo não é versionado. Ele mistura APIs de 2.3 com 2.4.x sem distinguir, e o ecossistema mudou muito. As versões em suporte regular ativo mais recentes são 2.4.6, 2.4.7, 2.4.8 e 2.4.9; a linha 2.3.x chegou ao fim do suporte regular em setembro de 2022, e as versões 2.4.0–2.4.3 em novembro de 2022. As mudanças de plataforma recentes são grandes o suficiente para invalidar muita coisa que o modelo "sabe":

Quando peço código à IA, eu sempre informo a versão exata do projeto ("isto é Adobe Commerce 2.4.7-p3, PHP 8.3"). Sem isso, ela assume uma média do treino e te entrega algo que não roda na sua stack. Para o panorama de versões e fim de vida, vale cruzar com o guia do Magento 1 e fim de vida e o de Adobe Commerce vs Magento Open Source.

Segurança: SQL injection, XSS em .phtml e a fé cega em código gerado

Esta é a seção onde código gerado por IA deixa de ser dívida técnica e vira CVE na sua loja. O LLM não tem modelo de ameaça — ele otimiza por "código que parece resolver o problema", não por "código que não pode ser explorado". Em e-commerce, que processa pagamento e dado pessoal, isso é inaceitável sem revisão.

XSS em templates .phtml: o escaping que a IA esquece

O erro mais comum e mais perigoso. A IA gera um .phtml com <?= $block->getData('algo') ?> ou um echo cru de valor que veio do usuário. Sem escaping, é XSS direto. O Magento fornece o objeto $escaper (instância de \Magento\Framework\Escaper) com os métodos certos:

<?php /** @var \Magento\Framework\View\Element\Template $block */ ?>
<?php $escaper = $block->getEscaper(); ?>

<!-- ERRADO: o que a IA costuma gerar -->
<div><?= $block->getCustomerName() ?></div>

<!-- CERTO: cada contexto tem seu método -->
<div><?= $escaper->escapeHtml($block->getCustomerName()) ?></div>
<a href="<?= $escaper->escapeUrl($block->getLink()) ?>"
   title="<?= $escaper->escapeHtmlAttr($block->getTitle()) ?>">link</a>
<script>var x = '<?= $escaper->escapeJs($block->getValue()) ?>';</script>

O bom é que isso é detectável de forma automatizada: o sniff Magento2.Security.XssTemplate, que vem no magento-coding-standard, identifica echo em .phtml sem escaping adequado. É exatamente por isso que rodar o phpcs em todo código gerado não é opcional.

SQL injection: nunca concatene, sempre faça bind

Quando a tarefa envolve uma query direta, a IA frequentemente concatena variáveis na string SQL. No Magento o caminho seguro usa o adapter de conexão com placeholders:

// ERRADO: concatenação (SQL injection)
$sql = "SELECT * FROM sales_order WHERE customer_email = '" . $email . "'";

// CERTO: bind via adapter / select
$connection = $this->resourceConnection->getConnection();
$select = $connection->select()
    ->from('sales_order')
    ->where('customer_email = ?', $email);
$rows = $connection->fetchAll($select);

Nunca cole segredos no prompt

Parece óbvio, mas é o vazamento que eu mais vejo. Para a IA "entender o contexto", o dev cola o app/etc/env.php inteiro — com a crypt/key, credenciais de banco, chaves de API de gateway de pagamento e do ERP. Esse conteúdo pode ser logado, usado em treino dependendo dos termos do serviço, ou simplesmente ficar no histórico. Regras que eu sigo sem exceção:

• Nunca cole: app/etc/env.php, chaves de API, tokens de integração, senhas, a crypt key, dados reais de cliente ou pedido.
• Anonimize o contexto: se precisa mostrar a estrutura do env.php, substitua valores por REDACTED.
• Prefira ferramentas com escopo controlado: em código sensível, use planos enterprise/equipe que garantem não-treino sobre seus dados e, idealmente, mantenha o contexto no seu ambiente (assistentes em IDE rodando localmente).

Esses cuidados se conectam diretamente com o hardening mais amplo da loja — vale ler em conjunto o guia de segurança e hardening do Magento 2. Código gerado por IA é uma nova superfície de risco que entra no mesmo pipeline de revisão de segurança de qualquer outra alteração.

O fluxo de validação obrigatório: compile, phpcs Magento2, PHPStan e PHPUnit

Aqui está o coração do guia. A IA acelera a escrita; o que torna o uso seguro é o fluxo determinístico que roda depois. Esse pipeline não confia no código — ele tenta quebrá-lo. Se passar nas quatro etapas abaixo, o risco cai a um nível aceitável; se não passar, você descobriu o problema antes do cliente.

1) setup:di:compile — o teste de realidade da injeção de dependência

O bin/magento setup:di:compile gera três tipos de código a partir das suas definições: Factories (instanciamento de tipos), Proxies (carregamento lazy) e Interceptors (as classes que ligam o sistema de plugins). Se a IA escreveu um di.xml malformado, referenciou uma classe inexistente ou criou uma dependência circular, o compile falha aqui. E mais: sem rodar esse comando, os plugins around, before e after simplesmente não são ativados — o código está lá, mas não dispara.

bin/magento setup:di:compile

2) phpcs com o ruleset Magento2 — padrões e sniffs de segurança

O pacote oficial é o magento/magento-coding-standard (a versão 40 foi lançada em 6 de março de 2026). Ele traz os sniffs que pegam exatamente os erros que a IA comete, incluindo o de XSS em templates. Instala como dependência de desenvolvimento e roda contra o seu código:

composer require --dev magento/magento-coding-standard

# analisar
vendor/bin/phpcs --standard=Magento2 app/code/MeuVendor/MeuModulo

# auto-corrigir o que dá
vendor/bin/phpcbf --standard=Magento2 app/code/MeuVendor/MeuModulo

O phpcbf conserta automaticamente boa parte das violações de formatação, e o pacote ainda suporta rector para refatorações automatizadas. Esse é o filtro mais rápido e o que mais pega bobagem de código gerado.

3) PHPStan com a extensão Magento — caça a métodos e tipos inexistentes

Aqui é onde você pega a alucinação de API. PHPStan puro não entende as peculiaridades do Magento (retornos do ObjectManager, magic methods __get()/__set(), autoloader de factory/proxy, type hints de extension attributes). A extensão bitexpert/phpstan-magento resolve isso:

composer require --dev bitexpert/phpstan-magento

# rodar a análise estática (ajuste o nível conforme o projeto)
vendor/bin/phpstan analyse app/code/MeuVendor/MeuModulo --level=6

É o PHPStan que grita quando a IA chamou getProductBySku() num objeto que não tem esse método. Para mim, essa etapa é inegociável em qualquer código que mexa com repositórios e service contracts.

4) PHPUnit — os testes que provam o comportamento

Testes unitários do Magento 2 rodam em PHPUnit (a partir do 2.4.0 a plataforma exige PHPUnit 9):

vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist

Detalhe importante: testes de integração exigem isolamento obrigatório entre os casos — não dá para compartilhar objetos da aplicação entre testes. A IA é ótima para gerar o esqueleto dos testes (mocks de construtor, asserts), mas você precisa garantir que os asserts realmente testam o comportamento e não só repetem o que o código faz.

O pipeline consolidado

Eu coloco esses quatro passos no CI. Código gerado por IA passa pelo mesmo portão que código humano — e o portão não negocia. Isso se encaixa no fluxo geral de desenvolvimento de módulos Magento 2.

O que exige revisão humana sempre: plugins around(), preferences e events.xml

Há um conjunto de construções no Magento onde a IA pode gerar algo sintaticamente perfeito que quebra silenciosamente o comportamento de outros módulos. Essas eu reviso linha a linha, sem exceção, porque o phpcs e o PHPStan não pegam o problema — ele é semântico, de arquitetura.

Plugins around() e o proceed() esquecido

Plugins são declarados em etc/di.xml e interceptam métodos públicos de classes não-finais. O tipo around recebe um callable $proceed, e aqui mora o perigo. A documentação é clara:

If the around method does not call the callable, it will prevent the execution of all the plugins next in the chain and the original method call.

Fonte: Adobe Commerce — Plugins (Interceptors)

Ou seja: se a IA gerar um around que, em algum caminho de código, não chama $proceed(), ela mata toda a cadeia de plugins seguintes e o método original. Já vi isso quebrar cálculo de preço e regras de carrinho de forma intermitente. Duas decisões que eu tomo:

• Prefira before/after: a maioria dos casos que a IA resolve com around deveria ser um before ou after. around só quando você realmente precisa decidir se o método original roda.
• Garanta o $proceed() em todos os caminhos: revise cada return e cada if para confirmar que $proceed($subject, ...$args) é chamado quando deve.

Vale lembrar também os limites: plugins não conseguem interceptar métodos final, métodos estáticos, __construct, __destruct e classes que implementam NoninterceptableInterface. A IA às vezes gera um plugin para um desses e ele simplesmente nunca dispara — sem erro nenhum.

Preferences: a sobrescrita que afeta o sistema inteiro

Uma preference no di.xml substitui uma classe globalmente. A IA gera preferences com facilidade para "resolver" um problema, mas uma preference sobre uma classe muito usada do core é um martelo: você assume a manutenção daquela classe para sempre e cria conflito com qualquer outro módulo (ou com o próprio core num upgrade) que dependa do comportamento original. Minha regra: preference é último recurso. Antes, eu tento plugin, depois injeção de uma implementação diferente via DI de argumento. Toda preference gerada por IA passa por uma pergunta: "existe uma forma menos invasiva?".

events.xml: o observer que escuta um evento que não existe

O etc/events.xml fica em <module-root>/etc/ para listeners globais, ou em etc/frontend/ e etc/adminhtml/ para áreas específicas. O risco com IA: ela inventa o nome do evento. Se o evento não é disparado em lugar nenhum do código (nenhum $eventManager->dispatch('meu_evento')), o observer nunca roda — e, de novo, sem erro. Antes de aceitar um observer, eu grepo o nome do evento no core e nos módulos para confirmar que ele realmente existe e é disparado no momento que eu preciso.

# confirmar que o evento existe e é disparado
grep -rn "sales_order_place_after" vendor/magento/ app/code/

O denominador comum dessas três construções é o mesmo: elas falham em silêncio. Por isso não basta o pipeline automatizado — precisa de olho humano que entende a arquitetura de interceptação e eventos do Magento.

IA na operação: análise de log, queries GraphQL/REST, cron, EXPLAIN e nginx/varnish

IA no Magento não é só escrever módulo. Boa parte do valor está na operação, onde a IA é excelente em explicar e correlacionar coisas que tomariam tempo manual — e onde o risco é baixo porque você valida o resultado contra a realidade do servidor.

Análise de log e troubleshooting

É um dos meus usos diários. Eu colo trechos (já anonimizados) e peço análise:

• Logs de acesso do nginx: "identifique o padrão de crawl do Googlebot neste log e diga se há desperdício de crawl budget". Casa bem com o guia de SEO técnico do Magento 2.
• exception.log / system.log: agrupar erros recorrentes e apontar a causa raiz provável a partir do stack trace.
• Slow query log do MySQL: ranquear as queries mais lentas e sugerir onde falta índice — ótimo gancho para o guia de performance e Core Web Vitals.

EXPLAIN: a IA lê o plano de execução por você

Colar o resultado de um EXPLAIN e pedir interpretação é um dos melhores usos. Ela aponta o type: ALL (full scan), a ausência de índice, o filesort caro — e sugere o índice. Você ainda valida criando o índice em staging e medindo, mas o diagnóstico inicial vem em segundos:

EXPLAIN SELECT main_table.* FROM sales_order AS main_table
WHERE customer_email = '[email protected]'
ORDER BY created_at DESC;

Gerar queries GraphQL/REST e cron

A IA escreve bem queries GraphQL e chamadas REST contra a Web API do Magento, e gera o esqueleto de um cron job (a classe e a entrada em etc/crontab.xml). Para GraphQL, vale lembrar que um resolver implementa uma das interfaces oficiais — ResolverInterface, BatchResolverInterface ou BatchServiceContractResolverInterface — e que batch resolvers são recomendados em queries porque buscam dados de múltiplos requests numa única operação, evitando o problema N+1. No Adobe Commerce há ainda o GraphQL Application Server (baseado na extensão Open Swoole, exclusivo do Adobe Commerce), que mantém o estado da aplicação entre requisições e pode reduzir o tempo de resposta de GraphQL em até 30%, segundo a documentação oficial.

Fixtures, nginx e varnish

Outros usos operacionais de baixo risco e boa economia de tempo:

O denominador aqui é confortável: em operação, o ciclo de feedback é curto e você testa em staging antes de aplicar. A IA acelera o diagnóstico; o servidor dá a palavra final.

Agentes, MCP e assistentes em IDE: conectar a IA ao codebase Magento

A grande evolução recente não é o modelo ficar "mais inteligente" — é dar a ele contexto real do seu projeto. Um LLM no chat genérico não conhece o seu di.xml, suas classes customizadas nem o estado do seu banco. As ferramentas modernas resolvem isso de formas diferentes, e é aqui que a produtividade dá um salto real em projetos Magento grandes.

Assistentes em IDE

Ferramentas como GitHub Copilot, Cursor e Claude Code trabalham com o contexto do repositório aberto. A diferença prática para o Magento é enorme: em vez de a IA inventar uma assinatura de método, ela pode olhar a interface real que está no seu vendor/ e a sua classe que a injeta. Isso reduz (não elimina) a alucinação, porque o contexto correto está à mão. Em refatoração de um módulo grande, um assistente que navega o codebase encontra todos os usos de uma classe antes de você mudar a assinatura — algo que no chat puro seria impossível.

MCP: o protocolo que conecta IA a ferramentas e dados

O Model Context Protocol (MCP) foi tornado público pela Anthropic em novembro de 2024 e, desde então, foi adotado por OpenAI, Google DeepMind e outros provedores — tornando-se um padrão amplamente adotado para dar ferramentas e contexto a um modelo. O Cursor suporta MCP nativamente via .cursor/mcp.json.

No Magento, isso já é concreto: existe um servidor MCP específico para Magento/Adobe Commerce (github.com/thomastx05/magento-mcp) com mais de 30 ferramentas para catálogo, promoções, CMS e diagnósticos. Na prática, isso permite ao assistente consultar o estado da sua loja (não inventá-lo) durante uma conversa — perguntar quantos produtos há numa categoria, checar uma configuração, rodar um diagnóstico — sem você sair da IDE.

O Model Context Protocol foi tornado público pela Anthropic em novembro de 2024 e passou a ser adotado por outros provedores; o Cursor o suporta via .cursor/mcp.json, e há um servidor MCP dedicado ao Magento/Adobe Commerce com mais de 30 ferramentas para catálogo, promoções, CMS e diagnósticos. (Resumo das fontes, não citação literal.)

Fonte: magento-mcp (GitHub)

Code review assistido por IA

Eu uso IA como primeira passada de code review, nunca como a única. Ela é boa em pegar o óbvio: escaping faltando num .phtml, um around sem $proceed(), um TODO esquecido, um nome de variável enganoso. Mas ela não entende o impacto de negócio da mudança nem o contexto histórico do módulo. O fluxo que funciona para mim: IA faz a varredura mecânica, eu faço a revisão de arquitetura e de risco. Para um panorama mais amplo do estado das ferramentas de IA no ecossistema Adobe, vale o guia de IA no Magento e Adobe Commerce.

Honestidade sobre o estado da arte

Sendo direto: essas ferramentas são aceleradores poderosos, não pilotos automáticos. MCP e assistentes em IDE reduzem alucinação ao dar contexto, mas não removem a necessidade do pipeline de validação da seção anterior. Um agente pode propor uma refatoração de 40 arquivos em minutos — e você ainda precisa do setup:di:compile, do phpcs, do PHPStan e dos testes passando antes de confiar em uma linha sequer.

Como dar contexto: exemplos de prompts bons vs. ruins para Magento

A maior parte da diferença entre código útil e código que te faz perder tempo está no prompt. A IA não adivinha sua versão, sua arquitetura nem suas classes — se você pedir no vácuo, ela responde com a média do treino, que é cheia de padrões obsoletos. A regra é simples: dê contexto real. Cole a interface, o di.xml existente, a classe que injeta a dependência. Não peça "um plugin para preço"; peça um plugin para um método específico de uma classe específica, na sua versão.

Prompt ruim (gera padrão obsoleto, provável alucinação)

Escreva um código Magento que pega um produto pelo SKU
e muda o preço dele.

Sem versão, sem classe, sem dizer onde esse código vive. A IA provavelmente vai te dar um ObjectManager, talvez um load() em model abstrato, e um método de repositório que pode nem existir. Você vai descobrir o problema só na hora de rodar.

Prompt bom (contexto, versão, restrições explícitas)

Contexto: Adobe Commerce 2.4.7-p3, PHP 8.3.
Preciso de um plugin AFTER no método getFinalPrice de
\Magento\Catalog\Pricing\Price\FinalPrice para aplicar um
desconto de 10% quando o produto tiver o atributo custom
'is_promo' = 1.

Regras:
- Injeção de dependência via construtor, SEM ObjectManager.
- Declare o plugin no di.xml (me dê o XML também).
- Confirme que getFinalPrice NÃO é final antes de propor o plugin.
- Não invente métodos: se não tiver certeza da assinatura,
  diga em qual classe do core ela está.

Segue minha estrutura atual de módulo:
[cole aqui registration.php e o di.xml existente]

A diferença é abissal. Esse prompt amarra a versão, proíbe o antipadrão explicitamente, pede a verificação de interceptabilidade (lembre: plugin não pega método final) e força a IA a admitir incerteza em vez de alucinar. O resultado já vem perto de pronto e o que sobra é validação mecânica.

Checklist do prompt que eu uso

Limites, governança e propriedade do código

Por fim, o que a IA não resolve. A revisão humana é obrigatória e intransferível — você assina o commit, você responde pela loja. Pontos de governança que eu trato com seriedade:

• Propriedade e licença: entenda os termos da ferramenta sobre o código gerado e, principalmente, evite colar código proprietário de terceiros no prompt para "adaptar".
• Não terceirize a arquitetura: a IA não substitui entender o ciclo de DI, a cadeia de plugins, o EAV e o fluxo de checkout. Quem não entende a arquitetura não consegue revisar o que a IA gera — e aí o ganho de velocidade vira dívida.
• Rastreabilidade: trate código de IA como qualquer contribuição: passa por PR, por CI, por revisão. Em integrações sensíveis (pagamento, ERP e NF-e), o escrutínio é maior ainda.

A IA me deixa entregar mais rápido porque tira o boilerplate do caminho e acelera diagnóstico. Ela não me deixa entregar com menos cuidado. Esses dois fatos convivem — e quem confunde os dois é quem coloca a loja em risco.