Teaching AI to speak PrestaShop

You ask your AI assistant to add a new Back Office listing page. It dutifully reaches for HelperList, configures a few fields, drops in a legacy admin controller, and produces something that would have looked perfectly correct in PrestaShop 1.7. The code compiles, the page renders, and you ship it. Six months later, you end up rewriting it on top of the Grid component, a GridDefinitionFactory, and a CQRS-aware controller wiring, because that is the architecture the rest of the codebase has been using for years.

Why this matters now

The AI is not inventing things. It is faithfully reproducing patterns from the largest, most public corpus of PrestaShop code it could find: years of legacy modules, older tutorials, archived forum threads, and Stack Overflow answers that were correct at the time, and are not anymore. If the project does not tell the model otherwise, it has every reason to assume that HelperList is still how we build lists. That assumption costs every developer real time, whether you are an agency shipping a module to a client, a freelancer customizing a shop, an in-house team maintaining a B2B platform, or a contributor opening a pull request to the core.

What we are doing about it

If you write PrestaShop code with AI assistance, you have almost certainly seen this exact pattern. The conventions the project has converged on (CQRS, multistore-aware code, layer separation, BC rules, modern admin architecture) were built up over years and live in the heads of a handful of people, in scattered documentation pages, and in the memory of past PR reviews. None of that knowledge is visible to an AI assistant when you open a file and ask for help.

Any AI tool can read these files. Any contributor can write them. We are deliberately avoiding tool-specific lock-in.