How I use AI coding agents on Adobe Commerce projects

Claude Code and Codex run in a terminal next to my editor every working day. Most of my client codebases are Adobe Commerce, so below is how that setup works there, where it saves time and where I still do the work by hand.

It is written for two readers. One is the merchant who pays for engineering hours and wants to know what changes. The other is 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 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 and writing the fifth near-identical test all take less time. That leaves more of the paid hours for the decisions that need experience with the platform.

Project memory in one 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. Every new module needs the same skeleton, and every GraphQL resolver needs a schema entry, a resolver class, DI wiring and a test. Every upgrade runs through the same checklist.

Claude Code lets me package each of these as a skill. A skill is 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. 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 that enforce the rules

The agent can ignore an instruction in CLAUDE.md, but it cannot get past a hook. A PreToolUse hook runs a script before the agent uses a tool. If the script exits with code 2, the call is blocked and the agent sees the reason.

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. A mistake the agent makes is caught before it becomes a commit.

Tickets and pull requests through MCP

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 I can start a session with a ticket key. The agent reads the ticket, the linked Confluence page and the open pull request before it looks at the code.

I keep two rules. First, permissions stay narrow. The agent acts with my account’s access and no more, and I approve each action that writes to a client system. Second, project-level MCP configuration lives in .mcp.json in the repository, so anyone on the team can see and review it.

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 and separates noise (a bot hitting a removed URL) from signal (a payment module timing out under load). Then it points to the lines of code involved. I 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. The agent looks for plugins on hot methods such as price rendering and for admin controllers without ACL checks. It also looks for observers doing work that belongs in a queue consumer, and for N+1 loads in collections. It flags candidates; I decide which are real.

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

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

More of the paid hours go to decisions and less to searching code and reading logs. Upgrade estimates start from a list of actual conflicts instead of a guess. Incident reports arrive faster and with evidence, and code review covers more of each change. I answer for every line that ships.

If you want this workflow on your project, or want your own team to adopt it safely, write to me.