SAP Commerce Cloud KI-Entwicklung verändert, wie wir bei codeitlabs Enterprise-Projekte umsetzen. Nach mehr als zehn Jahren in der SAP Commerce Cloud-Entwicklung – früher bekannt als SAP Hybris – haben wir bei codeitlabs so gut wie jeden Aspekt dieser Plattform erlebt: von der ersten Implementierung über komplexe B2B/B2C-Rollouts bis hin zur langjährigen Wartung umfangreicher Enterprise-Projekte. Die Plattform ist mächtig. Sie ist aber auch extrem repetitiv – zumindest war sie das, bis KI-Assistenten wie Claude Code unseren Entwickleralltag verändert haben.

In diesem Beitrag zeigen wir konkret, welche Aufgaben uns früher Stunden gekostet haben – und wie wir sie heute in Minuten erledigen. Keine Marketing-Phrasen, sondern echte Beispiele aus der täglichen Arbeit mit SAP Commerce Cloud.

Wer wir sind: SAP Commerce Cloud aus der Praxis

codeitlabs wurde von ehemaligen Hybris-Consultants gegründet, die weltweit an Enterprise-E-Commerce-Projekten gearbeitet haben. Unsere Kunden sind Unternehmen, die SAP Commerce Cloud bereits im Einsatz haben oder gerade implementieren – und die wissen, dass diese Plattform tiefgreifende Fachkenntnis erfordert, um sie effizient zu betreiben.

Was uns auszeichnet: Wir kennen nicht nur die offizielle SAP-Dokumentation, sondern auch die undokumentierten Stolperfallen, die versteckten Konfigurationsoptionen und die Best Practices, die man nur durch Jahre echter Projektarbeit sammelt. Genau dieses Wissen kombinieren wir heute mit modernen KI-Werkzeugen.

SAP Commerce Cloud KI-Entwicklung: 5 konkrete Anwendungsfälle mit Claude Code

Es gibt viele Bereiche, in denen ein KI-Assistent hilfreich sein könnte. Aber was hilft wirklich? Hier sind die Bereiche, in denen Claude Code bei SAP Commerce Cloud den größten messbaren Unterschied macht:

1. Spring Beans & items.xml – Datenmodell-Erweiterungen ohne langes Nachschlagen

Wer SAP Commerce Cloud kennt, kennt das Ritual: Eine neue Anforderung kommt rein, das Datenmodell muss angepasst werden. Das bedeutet: items.xml öffnen, die richtige Extension finden, die exakte Syntax für Relations, Attributes, Enums und CollectionTypes prüfen – und hoffen, dass der Platform-Codegeneration-Prozess keine Fehler auswirft.

Ein typisches Beispiel: Ein bestehendes ProductModel soll um ein benutzerdefiniertes Attribut „sustainabilityScore“ (Double) mit Lokalisierung erweitert werden, plus eine neue Relation zu einem neuen „CertificationModel“.

Früher: Syntax in der SAP-Doku nachschlagen, ein ähnliches Beispiel im Projektcode suchen, manuell zusammenbauen, beim ersten Build feststellen, dass ein closing-Tag fehlt oder der type-qualifier falsch ist.

Heute mit Claude Code: Aufgabe beschreiben – korrektes items.xml-Fragment erhalten, inklusive der richtigen deployment-Tags, generate-Attribute und der vollständigen Relation-Definition:

Was viele vergessen: Zu jedem neuen ItemType und jeder neuen Relation gehört auch eine passende Spring-Bean-Konfiguration – der zugehörige DAO, der Service und die Verknüpfung im ApplicationContext. Claude Code generiert auf Basis desselben Prompts auch direkt die vollständige spring.xml-Konfiguration:

Zeitersparnis pro Aufgabe: von 60–90 Minuten auf unter 10 Minuten. Und das über alle Artefakte hinweg: items.xml, Spring-Bean-Definition, DAO-Interface und Service-Klasse in einem Schritt.

2. Performance-Analyse: Versteckte Engpässe, die kein Developer so schnell findet 

Das ist der Bereich, in dem erfahrene SAP-Commerce-Entwickler den größten Mehrwert durch Claude Code sehen – nicht weil die Lösung kompliziert ist, sondern weil man den Zusammenhang kennen muss, um das Problem überhaupt zu erkennen.

Das klassische Szenario: Die Anwendung läuft lokal mit einem Entwickler-Account tadellos. Sobald aber 20, 50 oder 100 User gleichzeitig eine Produktdetailseite aufrufen, bricht die Performance ein. CPU-Last steigt, Response-Times explodieren – und niemand im Team weiß warum.

Der häufigste Grund, den wir in Projekten sehen: übermäßig getriggerte Populatoren.

Das Populator-Problem: X User × Y Populatoren = Datenbankinferno 

• Ein typischer DefaultProductConverter hat 8–12 registrierte Populatoren. Jeder davon lädt Daten aus der Datenbank – oft mit eigenen FlexibleSearch-Aufrufen.
• Wenn eine Seite 10 Produkte anzeigt und jedes Produkt diesen Converter durchläuft, entstehen bei 10 Populatoren pro Produkt bereits 100 Datenbankabfragen für einen einzigen Seitenaufruf.
• Bei 50 gleichzeitigen Usern: 5.000 Datenbankabfragen – für eine einzige Seite. Das ist kein theoretisches Worst-Case-Szenario, das haben wir in realen Projekten gemessen.

Wie erkennt man das? Genau das ist das Problem – ohne gezieltes Logging oder Profiling sieht man im Code nur saubere, gut strukturierte Klassen. Jeder einzelne Populator sieht unproblematisch aus. Den kumulierten Effekt sieht man erst unter Last.

Claude Code analysiert die gesamte Populator-Kette, identifiziert welche Populatoren DB-Calls auslösen und zeigt konkret wo Daten mehrfach geladen werden – obwohl sie bereits im vorherigen Populator verfügbar wären:

Weitere Performance-Muster, die Claude Code in Projekten identifiziert:

• Lazy-Loading-Fallen: Zugriff auf eine Collection-Relation (z. B. product.getVariants()) innerhalb eines Populators, der in einer Schleife über eine Produktliste läuft – klassisches n+1-Problem.
• Unnötige SessionService-Aufrufe: getCurrentUser() oder getCurrentCatalogVersion() werden in mehreren Populatoren einzeln aufgerufen, statt einmalig im Converter zwischengespeichert zu werden.
• CacheUnit-Fehler: Ein Populator invalidiert unbeabsichtigt den Cache eines anderen Bereichs, weil er ein Model modifiziert, ohne es explizit zu speichern – führt zu einem inkonsistenten Zustand unter Last.
• Fehlende @Cacheable-Annotationen auf DAO-Methoden, die bei jedem Aufruf dieselbe FlexibleSearch-Query ausführen.

Das Entscheidende: Claude Code sieht den gesamten Code-Kontext auf einmal – alle Populatoren, ihre Spring-Bean-Definitionen und die Aufruf-Reihenfolge im Converter. Ein einzelner Entwickler, der die Dateien nacheinander öffnet, sieht diesen Gesamtzusammenhang nicht so leicht. Das ist der Kern-Vorteil beim Einsatz eines KI-Assistenten für Performance-Analysen.

3. Unit Tests mit ≥ 90 % Code Coverage – mit IDE-Plugin-Unterstützung

Unit Testing in SAP Commerce Cloud ist notorisch aufwendig: ServiceLayer-Klassen haben viele Abhängigkeiten, Mock-Setups sind komplex, und die Hybris-spezifischen Abstractions (SessionService, ModelService, FlexibleSearchService…) müssen korrekt gemockt werden.

Wichtige Voraussetzung: Ein Code-Coverage von ≥ 90 % ist mit Claude Code nur dann zuverlässig erreichbar, wenn das Claude-Code-IDE-Plugin in IntelliJ IDEA oder VS Code installiert und aktiv ist. Ohne Plugin sieht Claude Code nur den Code-Ausschnitt, den man manuell einfügt. Mit dem Plugin hat Claude Code Zugriff auf den vollständigen Kontext: alle abhängigen Service-Klassen, die Spring-Bean-Hierarchie, Interface-Definitionen und die gesamte Vererbungskette. Erst mit diesem Wissen kann es wirklich alle Edge-Cases und Abhängigkeiten korrekt mocken.

Reales Beispiel: Ein neuer PricingStrategy-Service mit drei Methoden, der auf FlexibleSearchService, UserService und CatalogVersionService zugreift. Das Schreiben des kompletten Test-Setups war früher eine 2–3-Stunden-Aufgabe.

Mit Claude Code + IDE-Plugin: Den Cursor auf die Service-Klasse setzen, Claude Code den vollständigen Kontext lesen lassen – und einen fertigen JUnit 5-Test mit Mockito-Mocks, allen Edge-Cases und ≥90 % Coverage erhalten:

Was früher 2–3 Stunden dauerte, ist mit dem IDE-Plugin jetzt eine 15-Minuten-Aufgabe – inklusive Review und Anpassungen.

4. ImpEx-Skripte: Datenmigration ohne manuelle Zählarbeit

Datenmigration in SAP Commerce ist ImpEx. Und ImpEx hat eine eigene, manchmal eigenwillige Syntax. Große Migrations-Skripte – beispielsweise das Übernehmen von 50+ Produktattributen in ein neues Schema – waren eine fehleranfällige, zeitintensive Aufgabe.

Claude Code generiert ImpEx-Skripte aus einer einfachen Beschreibung der Anforderung, inklusive UPDATE vs. INSERT-Logik, Header-Definitionen und der richtigen Handhabung von Referenzen auf andere Models. Was früher 1–2 Stunden dauerte, geht heute in 10–15 Minuten.

5. Facades, Converters & Populators – Boilerplate eliminiert

Das SAP Commerce Cloud-Pattern für Facade/Converter/Populator ist gut strukturiert, aber extrem repetitiv. Eine neue ProductFacade mit zugehörigem Converter, Populator und spring.xml-Konfiguration? Das sind mindestens 4 Dateien mit vorhersehbarem Inhalt.

Mit einer präzisen Prompt-Beschreibung generiert Claude Code alle vier Artefakte konsistent, mit korrekten Generics, den richtigen Vererbungshierarchien (z. B. von DefaultProductConverter) und fertig einfügbaren Spring-Bean-Definitionen. Die Zeitersparnis liegt hier bei 60–70 % gegenüber manuellem Tippen.

Was sagen die Zahlen? Produktivitätsgewinn durch SAP Commerce Cloud KI-Entwicklung

Zahlen überzeugen mehr als Versprechen. Hier sind unsere eigenen Messwerte aus realen SAP-Commerce-Projekten der letzten 12 Monate – aufgeteilt nach Aufgabentyp:

Zum Einordnen: Branchen-Durchschnitt vs. SAP Commerce

Laut DX Research (2025, über 135.000 Entwickler) spart ein KI-Assistent im Durchschnitt 3,6 Stunden pro Entwickler pro Woche. Bei SAP Commerce Cloud sehen wir in unseren Projekten 5–6 Stunden – also rund 50 % über dem globalen Schnitt.

Der Grund: SAP Commerce ist eine der repetitivsten Enterprise-Plattformen überhaupt. Strenge XML-Konventionen, komplexe Spring-Konfigurationen und ein tiefes Typ-System bedeuten, dass ein großer Teil der täglichen Entwicklungsarbeit vorhersehbar und damit automatisierbar ist. Genau hier entfaltet Claude Code seinen größten Hebel.

SAP Commerce Cloud KI-Entwicklung:  Was Claude Code nicht übernimmt – und warum das gut ist

Wir möchten transparent sein: Claude Code ist kein SAP-Spezialist, der eigenständig Architekturentscheidungen trifft. Was er nicht ersetzt:

• Plattformspezifisches Erfahrungswissen: Die Kenntnis, warum bestimmte Caching-Strategien in Commerce Cloud problematisch sind, oder wie das OCC-Layer korrekt erweitert wird, ohne spätere Upgrade-Probleme zu riskieren – das lernt man durch Projekte, nicht durch KI.
• Geschäftslogik-Verständnis: Was eine Preisstrategie oder ein Promotions-Ruleset leisten soll, muss ein Mensch verstehen und spezifizieren.
• Code Review & Qualitätssicherung: KI-generierter Code wird immer von erfahrenen Entwicklern reviewed. Der generierte Code ist ein schneller erster Entwurf, kein blindes Endergebnis.

Die Kombination aus jahrelanger SAP Commerce-Erfahrung und modernen KI-Werkzeugen ist das, was wir anbieten. Keines von beiden allein ist so mächtig wie beide zusammen.

Das Mindeste, was ein Gespräch mit uns bringt: Klarheit darüber, wo Ihr Projekt steht und was als nächstes sinnvoll wäre.

Häufige Fragen zur SAP Commerce Cloud KI-Entwicklung

Kann Claude Code SAP Commerce Cloud items.xml automatisch generieren?

Ja. Claude Code generiert vollständige items.xml-Erweiterungen inklusive ItemTypes, Relations, Enums, und CollectionTypes auf Basis einer textuellen Beschreibung. Voraussetzung ist das IDE-Plugin (IntelliJ IDEA oder VS Code), damit Claude Code den vollständigen Projektkontext liest. Die Zeitersparnis beträgt 40–60 % gegenüber manuellem Schreiben.

Wie viel Zeit spart KI in SAP Commerce Cloud-Projekten konkret?

Laut unseren Projekterfahrungen sparen SAP Commerce Cloud-Entwickler mit Claude Code durchschnittlich 5–6 Stunden pro Woche. Das entspricht 50 % mehr als dem globalen Branchendurchschnitt von 3,6 Stunden (DX Research 2025, über 135.000 Entwickler). Der Überschuss erklärt sich durch die besonders wiederholende Natur der SAP-Commerce-Plattform.

Funktioniert Claude Code ohne IDE-Plugin für SAP-CC-Projekte?

Eingeschränkt. Ohne das IDE-Plugin (verfügbar für IntelliJ IDEA und VS Code) sieht Claude Code nur den manuell eingefügten Code-Ausschnitt. Für einfache Aufgaben wie ImpEx-Generierung reicht das aus. Für komplexe Aufgaben wie Unit Tests mit ≥90 % Coverage oder Populator-Analyse ist das Plugin zwingend nötig, da Claude Code die gesamte Abhängigkeitskette kennen muss.

Was kann KI in SAP Commerce Cloud nicht automatisieren?

Claude Code ersetzt kein plattformspezifisches Erfahrungswissen: Caching-Strategien, OCC-Layer-Erweiterungen ohne Upgrade-Risiko oder die Beurteilung, welche Promotions-Regellogik geschäftlich sinnvoll ist. KI-generierter Code wird von erfahrenen SAP-Commerce-Entwicklern geprüft. Die Kombination aus Domainwissen und KI ist stärker als beides allein.

Wie erkennt Claude Code Performance-Problem in SAP Commerce Cloud?

Claude Code analysiert die gesamte Populator-Kette auf einmal – alle Populatoren, ihre Spring-Bean-Definitionen und die Aufruf-Reihenfolge im Converter. Dabei identifiziert es redundante Datenbankabfragen, n+1-Probleme und fehlende @Cacheable-Annotationen. In unseren Projekten führte diese Analyse zu 93 % weniger DB-Abfragen unter Last.

Wie integriert man Claude Code in ein bestehendes SAP Commerce-Cloud-Projekt?

Installation des Claude-Code-CLI (über npm) und des IDE-Plugins für IntelliJ IDEA oder VS Code. Das Plugin verbindet sich mit dem laufenden Claude-Code-Prozess und gibt ihm Zugriff auf den gesamten Projekt-Workspace. Keine spezifische SAP-Commerce-Konfiguration nötig – Claude Code erkennt die Projektstruktur automatisch.