Wie ich KI-Coding-Agenten bei Adobe Commerce einsetze

Claude Code und Codex laufen an jedem Arbeitstag in einem Terminal neben meinem Editor. Die meisten Codebasen meiner Kunden basieren auf Adobe Commerce, deshalb zeige ich hier, wie dieses Setup dort funktioniert, wo es Zeit spart und wo ich die Arbeit weiterhin von Hand erledige.

Der Text richtet sich an zwei Leser. Der eine ist der Händler, der die Entwicklungsstunden bezahlt und wissen will, was sich ändert. Der andere ist der Engineering-Lead, der entscheidet, wie weit Agenten ins Repository dürfen.

Was ich mit „KI-gestützt“ meine

Ein Agent entscheidet in meinen Projekten nichts allein. Er liest Code, führt Befehle aus, schlägt Änderungen vor und schreibt Entwürfe. Ich prüfe jeden Diff vor dem Commit, und nichts geht in Produktion, ohne dieselben Prüfungen zu durchlaufen wie eine von Menschen geschriebene Änderung.

Der eigentliche Gewinn ist, dass die langsamen, mechanischen Teile der Arbeit schrumpfen. Mit dem Agenten finde ich schneller heraus, wo ein Plugin eine Methode abfängt, und arbeite mich schneller durch eine Woche exception.log. Auch die Prüfung eines Moduls gegen den Coding-Standard und der fünfte fast identische Test kosten weniger Zeit. So bleibt mehr bezahlte Zeit für die Entscheidungen, die Erfahrung mit der Plattform brauchen.

Projektgedächtnis in einer Datei pro Shop

Jeder Shop, an dem ich arbeite, bekommt eine CLAUDE.md im Wurzelverzeichnis des Repositorys. Claude Code lädt sie in jede Sitzung, der Agent startet also mit den Fakten, die ein neuer Entwickler in der ersten Woche bräuchte:

• Adobe-Commerce-Edition und PHP-Version, Hosting (Adobe Commerce Cloud, Upsun oder eigene Server) und wie man jede Umgebung erreicht.
• Welche Drittanbieter-Module gepatcht sind und wo die Patches liegen.
• Die wichtigen Befehle: bin/magento setup:di:compile, die Test-Suites, die statischen Prüfungen, wie man nur die Caches leert, die geleert werden müssen.
• Hausregeln: Plugins vor Preferences, kein direktes SQL in Controllern, nur deklaratives Schema, wohin eigene Module gehören.

Keine andere Maßnahme in diesem Setup bringt so viel für so wenig Aufwand. Ohne sie muss der Agent die Konventionen erraten und liefert Code, der funktioniert, aber nicht zur Codebasis passt. Mit ihr entspricht der erste Entwurf meist dem, was das Team selbst geschrieben hätte.

Skills und Slash-Commands für wiederkehrende Arbeit

Adobe-Commerce-Arbeit wiederholt sich. Ein GraphQL-Resolver braucht zum Beispiel immer einen Schema-Eintrag, eine Resolver-Klasse, die DI-Verdrahtung und einen Test. Neue Module beginnen mit demselben Grundgerüst, Upgrades mit derselben Checkliste.

Mit Claude Code kann ich jede dieser Aufgaben als Skill verpacken. Ein Skill ist ein Ordner mit einer SKILL.md, die die Aufgabe beschreibt, plus den nötigen Skripten oder Referenzdateien. Skills lassen sich unter .claude/skills/ im Repository versionieren, damit das ganze Team sie hat, und jeder ist zugleich als Slash-Command verfügbar. Diese drei nutze ich in Commerce-Projekten am häufigsten:

• Modul-Grundgerüst. Legt registration.php, module.xml, di.xml und die Ordnerstruktur nach den Konventionen des Projekts an.
• Upgrade-Preflight. Listet jedes Plugin, jede Preference und jeden Patch, die Core-Klassen berühren, die sich zwischen zwei Versionen geändert haben. Die Upgrade-Schätzung beginnt so mit Fakten.
• Review-Durchlauf. Führt PHP_CodeSniffer mit dem Magento Coding Standard und PHPStan aus und fasst die Befunde nach Risiko statt nach Datei zusammen.

Für größere Aufgaben nutze ich Subagenten. Jeder läuft in einem eigenen Kontextfenster mit eigener Werkzeugliste. Ein „Explorer“ mit reinen Leserechten kann abbilden, wie der Checkout über Dutzende Module angepasst ist, ohne die Hauptsitzung mit Dateiinhalten zu füllen. Nur seine Zusammenfassung kommt zurück.

Hooks, die die Regeln durchsetzen

Eine Anweisung in CLAUDE.md kann der Agent ignorieren, an einem Hook kommt er nicht vorbei. Ein PreToolUse-Hook führt ein Skript aus, bevor der Agent ein Werkzeug nutzt. Endet das Skript mit Exit-Code 2, wird der Aufruf blockiert und der Agent sieht den Grund.

In Commerce-Projekten blockiere ich Änderungen an Dateien, die in einem Feature-Branch niemand anfassen sollte:

#!/usr/bin/env bash
# .claude/hooks/protect-paths.sh, als PreToolUse-Hook für Edit und Write registriert
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

Dazu kommen gewöhnliche Git-Pre-Commit-Hooks, die den Coding-Standard und einen Secrets-Scan ausführen. Ein Fehler des Agenten fällt so auf, bevor er zum Commit wird.

Tickets und Pull Requests über MCP

Das Model Context Protocol (MCP) verbindet den Agenten über kleine Server mit externen Systemen. Ich nutze MCP-Integrationen für Atlassian (Jira und Confluence) und Bitbucket. In der Praxis kann ich eine Sitzung mit einem Ticket-Schlüssel starten. Der Agent liest das Ticket, die verknüpfte Confluence-Seite und den offenen Pull Request, bevor er den Code ansieht.

Dabei gelten zwei Regeln. Erstens bleiben die Berechtigungen knapp. Der Agent handelt nur mit den Rechten meines Kontos, und jede Aktion, die in ein System des Kunden schreibt, gebe ich einzeln frei. Zweitens liegt die MCP-Konfiguration des Projekts in .mcp.json im Repository, damit jeder im Team sie sehen und prüfen kann.

Log-Analyse

Hier ist die Zeitersparnis am größten und am wenigsten umstritten. Bei einem Produktionsvorfall in Adobe Commerce gehe ich meist var/log/exception.log, system.log und die Webserver-Logs durch, dazu New Relic oder Datadog, falls der Kunde sie nutzt. Bei Adobe Commerce Cloud Pro liegen die Logs pro Knoten, derselbe Vorfall ist also über mehrere Dateien verteilt.

Ich gebe dem Agenten die Dateien und ein Zeitfenster. Er gruppiert wiederholte Stack-Traces und trennt Rauschen (ein Bot ruft eine entfernte URL auf) von echten Signalen (ein Zahlungsmodul läuft unter Last in Timeouts). Dann zeigt er auf die betroffenen Codezeilen. Ich prüfe die zwei oder drei Hypothesen, auf die es ankommt. Was früher einen Nachmittag mit grep und Scrollen kostete, dauert jetzt einen Bruchteil davon, und die schriftliche Zusammenfassung geht direkt ins Vorfall-Ticket.

Code-Review und Refactoring

Ich setze Agenten für einen ersten Durchlauf bei jedem Pull Request ein, den ich prüfen soll. Der Agent sucht nach Plugins auf häufig aufgerufenen Methoden wie dem Preis-Rendering und nach Admin-Controllern ohne ACL-Prüfung. Er sucht auch nach Observern, deren Arbeit in einen Queue-Consumer gehört, und nach N+1-Ladevorgängen in Collections. Er markiert Kandidaten; ich entscheide, welche zutreffen.

Die zweite Stärke liegt im Refactoring. Manche Refactorings sind mechanische Arbeit, sobald das Zieldesign feststeht. Beispiele sind das Aufteilen einer überladenen Helper-Klasse in Services, der Ersatz von ObjectManager-Aufrufen durch Konstruktor-Injection und die Umstellung eines alten Cron-Jobs auf einen RabbitMQ-Consumer. Ich lege das Design fest, und der Agent macht die Massenänderung. Test-Suite und Review bestätigen das Ergebnis.

Wo ich den Agenten begrenze

Aufgabe	Rolle des Agenten
Architektur- und Integrationsdesign	Nur Recherche; die Entscheidung treffe ich
Schätzungen und Roadmap	Sammelt Fakten; ich schätze
Zahlungs-, Steuer- und Checkout-Logik	Nur Entwürfe, Zeile für Zeile geprüft
Produktions-Deployments und Datenänderungen	Keine
Kommunikation mit dem Kunden	Keine

Agenten klingen auch dann sicher, wenn sie falschliegen. Auf einer so großen Plattform wie Adobe Commerce ist eine plausible Antwort zum Verhalten einer Core-Klasse oft veraltet oder erfunden. Alles, was Geld, personenbezogene Daten oder den Produktionszustand berührt, prüfe ich durch Lesen oder Ausführen des Codes.

Was das für Händler bedeutet

Ein größerer Teil der bezahlten Stunden geht in Entscheidungen, ein kleinerer in die Suche im Code und das Lesen von Logs. Upgrade-Schätzungen beginnen mit einer Liste tatsächlicher Konflikte statt mit einer Vermutung. Vorfallberichte kommen schneller und mit Belegen, und das Code-Review deckt einen größeren Teil jeder Änderung ab. Ich stehe für jede ausgelieferte Zeile ein.

Wenn Sie diesen Workflow in Ihrem Projekt möchten oder Ihr eigenes Team ihn sicher einführen soll, schreiben Sie mir.