Von PHP-Extensions zu App Builder: Adobe überlässt die Konvertierung KI-Agenten

Jede Diskussion über ein Magento-Replatforming stößt irgendwann an dieselbe Mauer: die Extensions. Ein zehn Jahre alter Shop trägt Dutzende PHP-Module mit sich — selbst entwickelt, gekauft und nachgebessert —, die im Prozess des Kerns selbst leben. Genau diesen Code akzeptiert die SaaS-Ausgabe, Adobe Commerce as a Cloud Service, nicht mehr: Jede Anpassung muss außerhalb neu geschrieben werden, auf App Builder. Bisher wurde diese Konvertierung von Hand kalkuliert, Modul für Modul — und oft war sie es, die das Vorhaben begrub. Adobe hat beschlossen, die Baustelle auszustatten, mit zwei komplementären Bausteinen: einem gehosteten Migrationsagenten und offiziellen Skills für die Coding-Assistenten, die Ihre Teams ohnehin nutzen.

Ein Agent, der nach freigegebenem Plan arbeitet

Der Commerce Developer Agent ist ein von Adobe gehostetes Werkzeug, erreichbar nach Anmeldung mit einem Adobe-Konto, das zwei Szenarien abdeckt: eine App-Builder-Anwendung von der leeren Seite an erstellen oder eine bestehende Commerce-Extension konvertieren. Seine Besonderheit spricht Entscheider direkt an: Er generiert nichts ohne validierten Plan. Der Agent erzeugt zunächst einen Blueprint — einen in Phasen gegliederten Architekturplan —, den der Entwickler liest, korrigiert und freigibt, bevor eine einzige Zeile Code entsteht. Die Generierung stützt sich dann auf die offiziellen App-Builder-Gerüste: Abonnements auf Commerce-Ereignisse, Webhooks, ein Einstellungsbildschirm für den Händler, Datenpersistenz. Das Ergebnis wird als Archiv exportiert, bereit für Ihr Repository und Ihre Lieferkette.

Ebenso klar benennt die Dokumentation die Grenzen — das ehrt sie. Jeder generierte Code muss gelesen werden, bevor er auch nur in die Nähe der Produktion kommt: Adobe präsentiert den Agenten als Generator von Ausgangspunkten, nicht als autonomen Entwickler. Er baut weder Ihre Continuous Integration noch Ihre lokale Umgebung noch die API-Mesh-Verdrahtung; eine Sitzung behandelt jeweils nur ein Projekt, und ein Generierungslauf kann rund fünf Minuten dauern.

Offene Skills für Ihre eigenen Assistenten

Der zweite Baustein ist für bereits ausgerüstete Teams vielleicht der interessantere. Adobe veröffentlicht offizielle Skills: ausführbare Anleitungen, die einem Coding-Assistenten die korrekten App-Builder-Muster beibringen — eine Anwendung initialisieren, Ereignisse abonnieren, Webhooks setzen, Händlerkonfiguration, Persistenz oder eine Admin-Oberfläche anlegen und ein bestehendes Projekt konvertieren. Sie folgen dem offenen Standard agentskills.io und installieren sich mit einem Befehl (npx skills add adobe/skills) in Claude Code, Cursor, VS Code Copilot oder Gemini CLI. Das öffentliche Repository adobe/skills unter Apache-2.0-Lizenz zählt bereits Dutzende davon — Commerce, aber auch AEM, Analytics und Workfront.

Die Nuance ist strategisch. Der gehostete Agent holt Sie in Adobes Werkzeug; die Skills holen Adobes Wissen in Ihr Werkzeug. Ein Team, das seine Review-Disziplin, seine Konventionen und seine Pipeline bereits hat, übernimmt den zweiten Weg, ohne an der Lieferung irgendetwas zu ändern — und ohne von der Roadmap eines Portals abzuhängen.

Was sich in einem Migrationsdossier ändert

• Die Kalkulation ändert ihre Natur. Die richtige Frage lautet nicht mehr, wie viele Tage das komplette Neuschreiben kostet, sondern wie viele Ihrer Module in die abgedeckten Muster passen: Ereignisse, Webhooks, Konfiguration, Speicher, Admin-Bildschirme. Diese konvertieren schnell und zu planbaren Kosten; was den Bestellprozess im Kern verändert, bleibt ein echtes Architekturprojekt.
• Das Review wird zum größten Kostenposten. Der Code kommt schneller, aber jede Zeile muss gelesen werden; Ihre Senior-Entwickler wechseln vom Autor zum Reviewer. Ohne solides Review-Gate — Abnahmetests, Continuous Integration, die harte Regel, nie ungelesenen Code auszuliefern — produziert ein Generator nur schneller Schulden.
• Der Vendor-Lock-in wird Stück für Stück abgewogen. Die Skills folgen einem offenen Standard und laufen im Assistenten Ihrer Wahl; der Zielcode aber bleibt App Builder, also Adobes Infrastruktur. Die Konvertierung ist ein Plattform-Commitment: Entscheiden Sie es für die Plattform, nicht für die Bequemlichkeit des Werkzeugs.

Womit Sie anfangen sollten

• Inventarisieren Sie Ihre Extensions und sortieren Sie sie in zwei Spalten: von den obigen Mustern abgedeckt oder im Kernprozess verankert. Die zweite Spalte misst Ihre tatsächliche Distanz zum SaaS.
• Pilotieren Sie mit einer einzigen Extension mittlerer Komplexität: Blueprint, Generierung, dann eine ehrliche Messung der Review- und Härtungszeit. Das ist Ihr Stückpreis der Konvertierung; ihn zu multiplizieren schlägt jede abstrakte Schätzung.
• Setzen Sie die Leitplanken, bevor Sie beschleunigen: wiederholbare Tests auf den kritischen Pfaden, Pflicht-Review, nichts in Produktion ohne menschliche Lektüre. Die Generierungsgeschwindigkeit ist nur so viel wert wie Ihre Qualitätskontrolle.

Auf dem Summit im Frühjahr vorgestellt, ist der Agent Ende September in die allgemeine Verfügbarkeit übergegangen, und App Management hat inzwischen seinen eigenen Eintrag in der Commerce-Administration. Adobes Botschaft für 2027 ist eindeutig: Das Neuschreiben Ihrer Extensions ist kein Grund mehr, die Entscheidung aufzuschieben — der Hersteller liefert die Arbeiter. Zu liefern bleibt, was sich nicht generieren lässt: der Bauleiter.