Mage-OS eCommerce Insights

AI and Magento: A Community Discussion Recap

mage-os-team — Thu, 07 May 2026 00:00:00 GMT

Recently we hosted an open community discussion about AI and what it means for Magento developers, agencies, and merchants. The conversation was wide-ranging, candid, and at times uncomfortably honest about how quickly day-to-day work is changing. The full recording is available on YouTube; below is a recap of the themes that came up.

The role shift: from developer to reviewer

Several participants described the same transition: where PhpStorm used to be open all day, Claude Code (or Cursor, Augment, Copilot, Codex) is now the default surface, and the human increasingly acts as a code reviewer rather than the primary author. It is happening fast — for some, the shift has compressed into a matter of weeks rather than months.

Why Magento is well-positioned

A recurring point: Magento benefits disproportionately from AI tooling. Two reasons came up.

First, the platform has an unusually large public surface — DevDocs, Stack Exchange, years of community blog posts — which means modern foundation models already understand Magento well, often better than they understand smaller or younger frameworks.

Second, Magento’s structure (modules, area scoping, DI, plugins, observers) gives agents natural boundaries to work within. Compared to greenfield projects where agents tend to introduce duplication and drift, agents working in a Magento codebase tend to stay closer to idiomatic patterns. As one participant put it: the structure of Magento is agent-friendly.

There was also a broader argument that platforms with more code to write benefit more from AI than SaaS platforms where the heavy lifting is hidden behind a vendor’s API. Magento, with its open codebase and extension ecosystem, is exactly that kind of platform.

What about juniors?

This was probably the most contested topic. Two views surfaced:

Juniors should be kept away from AI because they cannot yet recognize when the model is producing bad code or bad patterns.
AI is the single best tool a junior has ever had for exploring a large, intimidating codebase — and even when the model is fifty percent right, that is fifty percent more exploration than a junior would otherwise attempt.

A concrete anecdote: a first-year CS intern contributing to an e-commerce codebase via Claude Code and Cursor was able to participate at a depth that would have been hard to imagine a few years ago. The reviewer’s job got harder, but the contributor’s reach got significantly larger.

A more subtle observation: juniors who are comfortable with conversation and basic terminology tend to get further with these tools than those who approach them cautiously. The skill of talking to the model well is becoming part of the job.

How people are actually using it

A quick snapshot of the tools mentioned:

Claude Code — the most common default, often via the Max plan
Cursor / Augment / Copilot — IDE-integrated agents
Code Rabbit — automated first-pass code review on PRs
GitHub Codespaces — used by some as a sandboxed environment for --dangerously-skip-permissions workflows
Agent Safe House — a sandboxing setup adopted at Hyvä, took roughly four to six hours to set up and then disappears into the background
DDEV — used by others to contain agent execution per project

There was also discussion of unsupervised agents that pick up small tickets and open PRs. One agency described a pipeline where merchant-filed issues are picked up by an agent, validated by end-to-end tests and code sniffers, and only then handed to a human for review. Several people are running variations of this on their own projects — for example, a daily GitHub Action that asks Claude to find one small thing to improve and open a PR for it.

The consistent rule across every setup: human in the loop at the end. Nothing merges or deploys without human eyes.

Security and trust

Nobody on the call has a complete answer here, and that was openly acknowledged. The shared starting point: don’t trust agent output, and don’t trust anything that enters the model’s context from outside — skills, MCP servers, web pages, copied documentation. Prompt injection is a real attack surface.

Approaches in active use:

Sandboxing via Codespaces, Agent Safe House, DDEV containers, or local VMs
Skills review — Hyvä maintains an internal skills repository where every external skill goes through both an AI-driven and a human security review before it can be used
Default distrust — treat the agent like a chatty new developer whose work needs tasting before it goes out

The point was made that running npx against a random package is not meaningfully safer than running an agent skill from the internet. The discipline is the same, the surface is just larger now.

Billing, costs, and the agency model

This is where opinions diverged most sharply.

Some agencies have notified clients that they are using Claude Code, that every line is human-reviewed, and have raised rates on the back of demonstrably faster turnaround. Clients have generally accepted this, especially when the speed gains are visible.

Other participants are seeing the opposite pressure: clients expecting roughly forty percent less cost because AI makes everyone faster. Independent freelancers in particular flagged the awkwardness of charging more when “you’re not really writing the code anymore” — even though the productivity gain clearly justifies it on output.

There is also a longer-term concern: token costs may rise sharply (a 10× increase within six months was floated) once the current wave of VC subsidization ends. That makes token-efficiency, local models, and hybrid orchestration setups worth thinking about now rather than later.

The hourly-billing model in general is starting to creak. When productivity swings 50–1000% on the same hour of work, hours stop being a useful proxy for value delivered.

Twelve months from now

The most concrete forward-looking prediction: within twelve months we may see a one-click path from “I want a store” to a running, dev-container Magento instance, possibly with one-click deploy to production. The implication is a flood of new Magento stores, including a lot of low-quality ones — the same dynamic that played out when game-development tools became accessible to everyone.

A more optimistic framing: even if the ratio of good to questionable stores stays the same, the absolute number of good stores grows substantially. And as cost of ownership comes down, Magento becomes more competitive again against Shopify for merchants who would otherwise have ruled it out.

For extension vendors, the picture is mixed. Building a decent clone of an existing extension is now a weekend project, which puts pressure on monolithic, do-everything modules. Small, purpose-built, well-maintained extensions look like the more durable shape — particularly ones that handle base capabilities so agencies and merchants can vibe-code their own customizations on top.

David Lambauer’s recent talk came up here too: the long-term pitch against Shopify is increasingly about data ownership and control, not features. Features are cheap now. Owning your data, and being able to build whatever you want against it, is not.

A more speculative thread: as AI lowers the barrier to reading code, the historical role of the developer-as-scribe shifts. Whether that ends in some form of licensure or certification is open, but trust in the ecosystem will matter more, not less.

What the community can do next

A few suggestions surfaced:

Centralize the conversation. Useful discussion is currently scattered across LinkedIn, MageChat Slack, and various Discords. Pulling more of it into Mage-OS would make the knowledge accessible to the whole community.
Share working setups openly. Sandboxing approaches, skill repositories, agent workflows — most of this is being figured out independently by every team.
Curate the noise. As an ecosystem, helping merchants and developers understand which problems AI actually solves (and which it doesn’t yet) is high-leverage right now.
Think about local models. As token economics shift, having a hot-swap path to well-trained local models for parts of the workflow may matter sooner than expected.

Closing

There is no neat conclusion to a conversation like this — the ground is moving too fast. The takeaway most people seemed to agree on: AI is here, it is staying, and Magento is unusually well-positioned to benefit from it if the community treats it the way it has treated every other big shift — openly, with shared tooling and shared standards.

Thanks to everyone who joined. We will be running more of these discussions, and we would like to host more of the AI conversation here in Mage-OS itself. If you would like to participate, get involved in the tech meetings every Tuesday, or join the discussion on Discord.

The full recording is on YouTube.

Calling All Merchants - Purchase Your Own Extensions

arron-moss — Sat, 25 Feb 2023 00:00:00 GMT

Simple ways to streamline operations and reduce costs

In almost 15 years of working with Magento we have taken on many projects from other agencies large and small. One distinguishing factor which governs our appreciation for peer agencies, is whether they help merchants manage their own extensions. There are few things worse than taking on a project when their licensing and extensions are masked with confusion over who purchased what. This not only makes it more difficult to work with composer but it also adds legal risk of ownership and adds time and cost to future upgrades.

If as a merchant, you own all the accounts and therefore the contact methods, licenses, accounts and composer keys, then you are in control and can become agnostic and even work with multiple development agencies or teams simultaneously.

Monogency (mono agency)

Yes it’s a made up word! - or Mono Agency. We refer to agencies with a culture aimed not at providing the best service, but protecting their own commercial interests i.e tying the merchant in as much as possible.

Some agencies insist on being the single SI to a Magento merchant, often citing SLA’s as their reasons. This might be the only way they are prepared to work. That’s not to say this is not still normal, however as merchants are now developing more mature dev ops processes, we are seeing merchants choose to work with multiple agencies or development teams at a time. This year alone we have experience of working with 2 very large UK retailers who have both internal development teams and also are working with multiple SI’s at the same time. This requires standardization in operational processes and ultimately ownership of said processes by the merchant.

The future is Polygency (poly agency)

Again not a word!

For us, merchants whom can be agency-agnostic means they can refrain from agency tie-ins, which is ultimately risk-reducing if done properly. In 15 years of Magento development, the costs we have charged to take over projects and help merchants become more independent, has often outweighed the development costs. This should not be part of the modern TCO (total cost of ownership), otherwise the platform and the merchant both suffer.

If you are working with an agency or developer who insists on purchasing your extensions and not helping you manage your own vendor accounts, it’s likely you will become more constrained to their processes, culture, costs, skill-sets. Ultimately this is a risk to your business.

Tips when looking to purchase Magento extensions:

Never leave it to an external supplier, partner or contract developer
Always purchase and manage your extension subscriptions in-house
Keep a record of your extension vendors/accounts/keys
Always try and ensure all contributing parties use Composer when managing vendor extensions

Achieving Zero-Downtime deployments with Magento Open Source

arron-moss — Sat, 25 Feb 2023 00:00:00 GMT

Introducing Zero-Downtime deployments facilitates faster, more frequent deployments

As an agency working with Magento since 2009, we are always excited at the prospect of moving faster with developments for our clients. Achieving CI/CD for customers on a budget is no easy task. In this article we discuss the pain points and share some of our processes in achieving regular zero-downtime deployments for merchants using Magento Open Source or Adobe Commerce.

Why is it so difficult with Magento 2?

A standard deployment on Magento 2 usually involves certain commands/processes being ran in the event of certain changes. Here we explain the key deployment types.

bin/Magento setup:static-content: deploy - If you have frontend changes which involved typically Javascript or CSS, then you will need to run this. This can be achieved in *zero-downtime.
bin/Magento setup: upgrade - If you have upgrades to Magento or modules or are installing a new module, these require setup:upgrade to be ran and during this phase, the site should be in maintenance mode.
Custom code changes or patches - Either of these in most cases can be achieved with *zero-downtime

* Zero-downtime deployments can only be achieved if you have some way of executing the deployment commands away from the production site. If you do not have a non-production server or managed deployment pipeline such as MGT Code Deploy, MDOQ or Magento Commerce Cloud, then usually you have to put your website into maintenance mode whilst this runs. You want to avoid this. Without a solid deployment process, the TCO will be significantly more.

How does this benefit the merchant?

As an agency this is the question we always ask.

In summary, most of the work we carry out typically falls into one of the above 3 types. In 2 of these cases, with the correct deployment pipeline (building all your static content away from production), you can achieve these with zero-downtime, therefore, delivering fast, iterative changes (CI/CD). Due to costs, CI/CD is not typically common practice with smaller merchants however, with automation it is more cost-effective. So the up-shot is, if you have a deployment process where you can deploy your static content away from production, then for all your front-end development work, you could deploy many times a day. This is really where the Magento product outshines other platforms, since very few platforms allow such control over code and development processes.

Dare we comment on Adobe Commerce Cloud?

In a word yes. It’s fair to say this product has yet to yield real success of it’s own making. Since launch it has flown on the coat-tails of the Magento reputation and been hampered with many issues. Key issues remain. There is no facilitation of development instances or the use of RDE technology, which means however quick a non-production instance can be rolled up on Commerce Cloud, the developer is still ultimately responsible for themselves before they can become a productive ‘coder’. Secondly, the short-sightedness and complete lack of consideration for the Open Source product around dev ops standardisation, continues to yield project/platform failures and ultimately remains a weakness in the future of Magento Open Source for SME’s. Good agencies work very hard in developing their operational processes to best manage this risk, but ultimately, different agencies have their own intellectual property and this makes it more difficult for merchants to feel in control and potentially work with multiple agencies. This needs to evolve! Since it is clear that Adobe have no interest in Open Source, then now is the time they should relinquish the platform to an independent organisation.

How to achieve zero-downtime deployments

I’m almost certainly going to miss options here however this content is here to be revised and updated accordingly.

Magento Commerce Cloud: Reading their documentation, it does not actually sound like true zero-downtime is achieved, however if there are no database changes or module upgrades then we assume that deployments could take place with minimal front-end customer impact. Ie the site does always go into maintenance mode however the amount of time could be very small. I’ve noted this here more for perspective, but since this article is focussed on supporting concepts with Magento Open Source, it’s an irrelevant option.
MGT Code Deploy: Looks powerful, but since it’s only for AWS and carries a monthly fee of 99 Euros, it might not suit the smaller merchants. That said I would recommend any small business on Magento consider something like this to improve stability and therefore frequency of your deployment process. If you only deploy once every 6 months you should be asking yourself the question, did I pick the right platform?
MDOQ offers intelligent deployments and is compatible with AWS and any other production hosting, however with integrated production hosting, MDOQ slashes development costs even when deployment multiple times per day.
If you have any recommendations on solid deployment tools for Magento, please feel free to suggest them for inclusion here. We intend for this article to be live and up-to-date