How I use AI coding agents on Adobe Commerce projects

I have worked on Magento and Adobe Commerce for 17 years. For some time now, Claude Code and Codex have been open in a terminal next to my editor every working day. This post describes how that setup works, where it saves real time on an Adobe Commerce codebase, and where I still do the work by hand.

It is written for two readers: the merchant who pays for engineering hours and wants to know what changes, and the engineering lead who is deciding how far to let agents into the repository.

What I mean by “AI-augmented”

An agent does not decide anything on its own in my projects. It reads code, runs commands, proposes changes and writes drafts. I review every diff before it is committed, and nothing reaches production without the same checks a human change goes through.

The useful shift is not “the AI writes the code”. It is that the slow, mechanical parts of the job shrink: finding where a plugin intercepts a method, reading a week of exception.log, checking a module against the coding standard, writing the fifth near-identical test. That leaves more of the paid hours for the decisions that need 17 years of context.

Project memory: one instruction file per store

Every store I work on gets a CLAUDE.md at the repository root. Claude Code loads it into every session, so the agent starts with the facts a new engineer would need in week one:

• Adobe Commerce edition and PHP version, hosting (Adobe Commerce Cloud, Upsun or self-hosted) and how to reach each environment.
• Which vendor modules are patched, and where the patches live.
• The commands that matter: bin/magento setup:di:compile, the test suites, the static checks, how to flush only the caches that need flushing.
• House rules: plugins over preferences, no direct SQL in controllers, declarative schema only, where custom modules go.

This file is the cheapest improvement in the whole setup. Without it, an agent guesses at conventions and produces code that works but does not fit the codebase. With it, the first draft usually matches what the team would have written.

Skills and slash commands for repeated work

Adobe Commerce work repeats. A new module needs the same skeleton. A new GraphQL resolver needs a schema entry, a resolver class, DI wiring and a test. An upgrade needs the same checklist every time.

Claude Code lets me package each of these as a skill: a folder with a SKILL.md that describes the task, plus any scripts or reference files it needs. Skills can be committed to the repository under .claude/skills/, so the whole team gets them, and each one is also available as a slash command. The ones I use most on Commerce projects:

• Module scaffold. Creates registration.php, module.xml, di.xml and the folder layout to the project’s conventions.
• Upgrade preflight. Lists every plugin, preference and patch that touches core classes changed between two versions, so the upgrade estimate starts from facts.
• Review pass. Runs PHP_CodeSniffer with the Magento coding standard and PHPStan, then summarizes the findings by risk instead of by file.

For larger tasks I use subagents. Each one runs in its own context window with its own tool list, so a read-only “explorer” can map how checkout is customized across dozens of modules without filling the main session with file contents. Only its summary comes back.

Hooks: guardrails that do not depend on the model behaving

Instructions in CLAUDE.md are advice. Hooks are enforcement. A PreToolUse hook runs a script before the agent uses a tool, and if the script exits with code 2 the call is blocked and the reason is shown to the agent.

On Commerce projects I block edits to files nobody should touch in a feature branch:

#!/usr/bin/env bash
# .claude/hooks/protect-paths.sh, registered as a PreToolUse hook for Edit and Write
file=$(jq -r '.tool_input.file_path // empty')
case "$file" in
  */vendor/*|*/app/etc/env.php|*/generated/*|*/pub/static/*)
    echo "Blocked: $file is generated, vendored or environment-specific." >&2
    exit 2 ;;
esac
exit 0

I combine that with ordinary git pre-commit hooks that run the coding standard and a secrets scan. The agent goes through the same gates as any engineer, and a mistake is caught before it becomes a commit.

MCP: the ticket, the code and the review in one session

The Model Context Protocol (MCP) connects the agent to outside systems through small servers. I use MCP integrations for Atlassian (Jira and Confluence) and Bitbucket. In practice that means I can start a session with a ticket key and the agent reads the ticket, the linked Confluence page and the open pull request before it looks at the code.

Two rules I keep. First, permissions stay narrow: the agent acts with my account’s access and no more, and anything that writes to a client system is approved by me each time. Second, project-level MCP configuration lives in .mcp.json in the repository, so the setup is visible and reviewable, not hidden in one person’s machine.

Log analysis

This is where the time savings are largest and least controversial. A production incident on Adobe Commerce usually means var/log/exception.log, system.log, web server logs and, if the client has it, New Relic or Datadog. On Adobe Commerce Cloud Pro, logs are per node, so the same incident is spread over several files.

I give the agent the files and a time window. It groups repeated stack traces, separates noise (a bot hitting a removed URL) from signal (a payment module timing out under load), and points to the lines of code involved. I then verify the two or three hypotheses that matter. What used to take an afternoon of grep and scrolling now takes a fraction of that, and the written summary goes straight into the incident ticket.

Code review and refactoring

I use agents for a first review pass on every pull request I am asked to review: missing ACL checks on admin controllers, plugins on hot methods such as price rendering, observers doing work that belongs in a queue consumer, N+1 loads in collections. The agent flags candidates; I decide which are real.

Refactoring is the other strong area. Splitting an oversized helper class into services, replacing ObjectManager calls with constructor injection, or moving a legacy cron job to a RabbitMQ consumer are mechanical once the target design is decided. I decide the design, the agent does the bulk edit, and the test suite and a review confirm it.

Where I limit it

Task	Agent’s role
Architecture and integration design	None beyond research; the decision is mine
Estimates and roadmap	Gathers facts; I estimate
Payment, tax and checkout logic	Drafts only, reviewed line by line
Production deploys and data changes	None
Client communication	None

Agents are confident when they are wrong. On a platform as large as Adobe Commerce, a plausible answer about how a core class behaves is often outdated or invented. Everything that touches money, personal data or production state is verified by reading the code or running it.

What this means for a merchant

You pay for fewer hours spent searching, reading logs and typing boilerplate, and more hours spent on decisions. Upgrade estimates start from a list of actual conflicts. Incident reports arrive faster and with evidence. Code review covers more of each change.

What does not change: one senior engineer is accountable for every line that ships, and the agent works inside the same branch, test and review process as everyone else.

If you want this kind of workflow on your Adobe Commerce project, or want your own team to adopt it safely, get in touch.