Wie ich KI-Coding-Agenten bei Adobe Commerce einsetze

Ich arbeite seit 17 Jahren mit Magento und Adobe Commerce. Seit einiger Zeit sind Claude Code und Codex an jedem Arbeitstag in einem Terminal neben meinem Editor geöffnet. Dieser Beitrag beschreibt, wie dieses Setup funktioniert, wo es in einer Adobe-Commerce-Codebasis echte Zeit spart und wo ich die Arbeit weiterhin selbst mache.

Er richtet sich an zwei Zielgruppen: Händler, die Entwicklungsstunden bezahlen und wissen wollen, was sich ändert, und Engineering-Leads, die entscheiden, 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 Änderung von einem Menschen.

Der nützliche Effekt ist nicht „die KI schreibt den Code“. Es ist, dass die langsamen, mechanischen Teile der Arbeit schrumpfen: herausfinden, welches Plugin eine Methode abfängt, eine Woche exception.log lesen, ein Modul gegen den Coding Standard prüfen, den fünften fast identischen Test schreiben. So bleibt mehr bezahlte Zeit für die Entscheidungen, die 17 Jahre Kontext brauchen.

Projektgedächtnis: eine Anweisungsdatei 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 dem, was 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 nötigen Caches leert.
• Hausregeln: Plugins vor Preferences, kein direktes SQL in Controllern, nur deklaratives Schema, wohin eigene Module gehören.

Diese Datei ist die günstigste Verbesserung im ganzen Setup. Ohne sie rät der Agent die Konventionen 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 neues Modul braucht dasselbe Grundgerüst. Ein neuer GraphQL-Resolver braucht einen Schema-Eintrag, eine Resolver-Klasse, die DI-Verdrahtung und einen Test. Ein Upgrade braucht jedes Mal dieselbe Checkliste.

Claude Code erlaubt mir, jede dieser Aufgaben als Skill zu verpacken: ein Ordner mit einer SKILL.md, die die Aufgabe beschreibt, plus die nötigen Skripte 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. Die, die ich in Commerce-Projekten am häufigsten nutze:

• 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 reiner Lese-„Explorer“ kann so abbilden, wie der Checkout über Dutzende Module angepasst ist, ohne die Hauptsitzung mit Dateiinhalten zu füllen. Nur seine Zusammenfassung kommt zurück.

Hooks: Leitplanken, die nicht vom Wohlverhalten des Modells abhängen

Anweisungen in CLAUDE.md sind Empfehlungen. Hooks werden durchgesetzt. 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. Der Agent durchläuft dieselben Prüfungen wie jeder Entwickler, und ein Fehler fällt auf, bevor er zum Commit wird.

MCP: Ticket, Code und Review in einer Sitzung

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 starte ich eine Sitzung mit einem Ticket-Schlüssel, und der Agent liest das Ticket, die verknüpfte Confluence-Seite und den offenen Pull Request, bevor er den Code ansieht.

Zwei Regeln halte ich ein. Erstens bleiben die Berechtigungen eng: Der Agent handelt mit den Rechten meines Kontos und nicht mehr, und alles, was in ein System des Kunden schreibt, gebe ich jedes Mal selbst frei. Zweitens liegt die MCP-Konfiguration des Projekts in .mcp.json im Repository. Sie ist damit sichtbar und prüfbar und nicht auf dem Rechner einer einzelnen Person versteckt.

Log-Analyse

Hier ist die Zeitersparnis am größten und am wenigsten umstritten. Ein Produktionsvorfall bei Adobe Commerce bedeutet meist var/log/exception.log, system.log, Webserver-Logs und, falls vorhanden, New Relic oder Datadog. 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, trennt Rauschen (ein Bot ruft eine entfernte URL auf) von echten Signalen (ein Zahlungsmodul läuft unter Last in Timeouts) und zeigt auf die betroffenen Codezeilen. Danach prüfe ich die zwei oder drei Hypothesen, die zählen. Was früher ein Nachmittag mit grep und Scrollen war, 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: Admin-Controller ohne ACL-Prüfung, Plugins auf heißen Methoden wie dem Preis-Rendering, Observer, deren Arbeit in einen Queue-Consumer gehört, N+1-Ladevorgänge in Collections. Der Agent markiert Kandidaten; ich entscheide, welche echt sind.

Refactoring ist der zweite starke Bereich. Einen überladenen Helper in Services aufteilen, ObjectManager-Aufrufe durch Konstruktor-Injection ersetzen oder einen alten Cron-Job auf einen RabbitMQ-Consumer umstellen ist mechanische Arbeit, sobald das Zieldesign feststeht. Ich lege das Design fest, der Agent macht die Massenänderung, und Test-Suite und Review bestätigen sie.

Wo ich ihn 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 Plattform von der Größe von 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 Ihren Shop bedeutet

Sie bezahlen weniger Stunden für Suchen, Log-Lesen und Boilerplate und mehr Stunden für Entscheidungen. Upgrade-Schätzungen beginnen mit einer Liste tatsächlicher Konflikte. Vorfallberichte kommen schneller und mit Belegen. Code-Reviews decken mehr von jeder Änderung ab.

Was sich nicht ändert: Ein erfahrener Entwickler steht für jede ausgelieferte Zeile ein, und der Agent arbeitet im selben Branch-, Test- und Review-Prozess wie alle anderen.

Wenn Sie diesen Workflow in Ihrem Adobe-Commerce-Projekt möchten oder Ihr eigenes Team ihn sicher einführen soll, sprechen Sie mich an.