AI Tools for Magento Development: What Works, What Fails

AI coding assistants are now part of most developers' toolkit, and Magento is a good test of what they can and cannot do. The framework is large, old enough to have several generations of patterns in public code, and full of conventions that live in XML files more than in PHP. An assistant that knows general PHP well can still write Magento code that looks right and does not work.

This article is about using AI tools on Magento 2 projects in a way that saves time without adding bugs: where they help, where they fail, how to give them the right context and how to verify what they produce. It is not a review of specific products, since those change every few months. The working habits stay the same.

Where AI tools help on Magento work

Boilerplate

A Magento feature often needs six or more files before any business logic: registration.php, module.xml, di.xml, a db_schema.xml with its whitelist, a repository interface and implementation, data interfaces, and admin UI component XML. Assistants are good at producing this structure, especially when you point them at an existing module in the same project and ask for the same layout. The structure itself is explained in a custom module from scratch.

Reading unfamiliar code

On an inherited codebase with dozens of custom and third party modules, an assistant with access to the repository can trace a flow much faster than reading files by hand. Questions like "which plugins run on the product save", "where is this observer registered" or "what writes to this table" become searches the tool runs and summarizes. You still need to confirm the answer, but it narrows where to look.

Tests

Unit tests for Magento classes are mostly mock setup, which is tedious and well suited to an assistant. Give it the class, ask for tests that cover specific cases, and review the assertions. Check that the mocks match the real constructor and that the assertions test behavior, not only that methods were called.

Logs, stack traces and SQL

Pasting a stack trace from var/log/exception.log or a slow query from the MySQL slow log and asking for an explanation is a fast first pass. The tool often spots the cause, such as a missing DI argument, a plugin on the wrong method or a missing index, quicker than a manual read. Remove customer data and secrets before pasting anything.

Where they fail

Invented names

The most common failure is code that calls classes, methods, events or config paths that do not exist. They sound plausible because they follow Magento naming patterns. An event called catalog_product_save_after_commit or a config path like catalog/seo/enable_hreflang looks real and is not. The code may even pass a quick review.

Outdated patterns

Public Magento code spans many years, and a lot of it uses patterns that are deprecated or removed in 2.4:

• InstallSchema and UpgradeSchema scripts instead of declarative schema and data patches.
• Direct use of ObjectManager::getInstance() in classes.
• The registry for passing data between controller and block, instead of view models and services.
• Saving models through $model->save() instead of repositories.
• Magento 1 style code mixed in, such as Mage:: calls.

An assistant that is not told the target version will happily mix these.

Missing the XML side

A lot of Magento behavior lives in configuration: di.xml, events.xml, layout XML, webapi.xml, acl.xml, crontab.xml, queue files. An assistant may write a correct observer class and forget to register it, or register it in the global area when it should be in the frontend area. The PHP looks fine and nothing happens at runtime.

Area, scope and cache

Store view scope for config values, the difference between adminhtml and frontend areas, and the effect of full page cache on what can be rendered in a block are things assistants often miss. A suggestion to add cacheable="false" to fix a stale block is a typical example. It works, and it disables full page cache for every page with that block.

Give the tool the right context

Most of these failures shrink when the assistant knows the project. Many tools read a project instructions file at the root of the repository. Whatever the file is called in your tool, put the facts the model cannot guess in it:

• Magento version and edition, PHP version, and whether the theme is Luma, Hyvä or headless.
• How to run commands. In Docker based setups, bin/magento must run inside the container, so give the exact command prefix.
• Vendor namespace, where custom modules live, and coding rules such as strict types and constructor property promotion.
• Patterns to avoid: no ObjectManager, no setup scripts, no direct SQL on catalog tables if the store is Adobe Commerce.
• What the tool must never do: run deploy commands, change app/etc/env.php, push to Git.

Also give it access to vendor/magento. The best defense against invented names is a tool that can search the real core code before it writes anything.

Verify everything, cheaply

The rule I follow: AI output is a draft from a fast junior developer who has read a lot of old blog posts. It gets reviewed and checked like any other code. Most checks are cheap and can be run by the assistant itself.

Check that names exist

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/

If an interface or config path does not show up in vendor/magento or your own code, it does not exist. Events need one extra check: model events such as catalog_product_save_after are built at runtime from the model's _eventPrefix plus a suffix, so search for the prefix, for example _eventPrefix = 'catalog_product', instead of the full event name.

Compile and 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

DI compilation catches wrong constructor arguments, missing classes and bad di.xml references. The coding standard catches deprecated patterns and escaping problems in templates. Setup for both is in the Magento coding standard and PHPStan for Magento 2.

Run it

Nothing replaces exercising the feature in a local environment: placing the order, saving the product, running the cron job. Ask the assistant for the exact steps to test what it built, then do them.

Privacy and security

Magento projects contain data you should not send to an external service without thinking:

• app/etc/env.php holds database credentials and the encryption key.
• Database dumps hold customer names, addresses and order history.
• Logs can contain emails, IPs and payment references.

Work on a sanitized database, as described in sanitizing a staging database, exclude secrets from what the tool can read where possible, and check the data terms of the tool you use. If the store belongs to a client, follow their policy on AI tools before you start.

A practical split of work

What works well for me on Magento tasks is to keep design decisions and the final review, and hand the assistant the parts that are mechanical or search heavy. Deciding between a plugin and an observer, the data model, cache behavior and anything touching checkout or payments stays with the developer. Generating the files once the design is clear, writing tests, searching the codebase and reading logs goes to the tool, with every result checked as described above.

Used this way, AI tools speed up the boring half of Magento work and leave more time for the parts that need experience. Used without context and verification, they produce code that passes a glance and fails in production.

FAQ

Can AI tools write production ready Magento code?

They can write a good first draft, especially boilerplate and tests. The code still needs review, DI compilation, coding standard checks and real testing, because invented class names and outdated patterns are common.

How do I stop an AI assistant from using deprecated Magento patterns?

Tell it the exact Magento and PHP versions and list the patterns to avoid in a project instructions file. Let it search vendor/magento so it can check real code before writing.

Is it safe to share Magento code with AI tools?

Code is usually fine if the owner allows it. Do not share env.php, production database dumps or logs with customer data. Use a sanitized database for local work.

What is the quickest way to catch AI mistakes in Magento code?

Run setup:di:compile, phpcs with the Magento2 standard and PHPStan, and grep vendor/magento for every event, class and config path the code uses.

I am available for freelance Magento and Adobe Commerce work and use these tools with the checks described here. If you need help with a project, get in touch.