Von Templates zu Prompts: Das neue Shopify-Entwicklungsmodell

Key Takeaways

• Das Shopify AI-Entwicklungsmodell verlagert den Startpunkt eines Builds von einem gekauften Template zu einem geschriebenen Prompt. Du beschreibst das Ergebnis, ein Agent entwirft den nativen Code und ein Mensch überprüft ihn.
• Das alte Modell bestand darin, ein Theme auszuwählen, Page-Builder-Apps zu installieren und Blöcke per Drag-and-Drop zu verschieben. Es ist stabil und vertraut, beschränkt aber Design und Verhalten auf das, was Template und App zulassen.
• Was sich geändert hat, ist ein echter Context Layer. Shopify hat ein AI Toolkit veröffentlicht, das Coding-Agenten mit aktuellen Docs und Schemas füttert, sodass der generierte Code meist schon beim ersten Durchlauf valide ist.
• Das neue Modell bedeutet nicht “KI ersetzt Entwickler”. Es ist der Weg vom Prompt zu überprüftem nativen Code, wobei der Mensch das Urteilsvermögen, die Sicherheit und den Publish-Button behält.
• Altes und neues Modell schließen sich nicht gegenseitig aus. Die meisten Stores werden eine Zeit lang eine Mischung nutzen, und die Aufteilung hängt davon ab, wer die Arbeit macht, nicht davon, was objektiv besser ist.

Ein Jahrzehnt lang bedeutete der Start einer Shopify-Storefront immer denselben ersten Schritt: ein Theme kaufen. Das Shopify AI-Entwicklungsmodell ändert genau das. Anstatt ein Template auszuwählen und es dann passend hinzubiegen, beschreibst du, was du willst, und ein Agent schreibt den Code.

Dies ist ein Argument, kein Spec Sheet. Ich glaube, das Zentrum der Shopify-Entwicklung verlagert sich von Templates und Drag-and-Drop hin zu Prompts und überprüftem nativen Code. Aber dieser Wandel verläuft ungleichmäßig, bringt echte Trade-offs mit sich und der Hype darum überschätzt massiv, wie weit sich der Mensch zurücklehnen kann.

Warum du uns vertrauen kannst

Wir sind seit über vier Jahren in der Shopify-Welt unterwegs und haben mit hunderten von Shops zusammengearbeitet.

Jacques, unser CTO, hat mehr als 15 Jahre Entwicklungs-Erfahrung und hat Storefronts für unzählige Shopify-Marken gebaut.

Wir haben Fudge, den KI-Operator für Shopify-Shops, entwickelt – mit einer 4.9-Bewertung im Shopify App Store und einem Built for Shopify-Badge. Wir sind bei unserem eigenen Produkt natürlich befangen, sagen dir aber ganz ehrlich, wo es Sinn macht und wo nicht.

Das alte Modell: Theme kaufen, Apps installieren, Blöcke platzieren

Für den Großteil der Geschichte von Shopify folgte der Bau eines Storefronts meist immer demselben Weg.

Erstens: Du hast ein Theme gekauft. Der Shopify Theme Store listet ein paar hundert kostenlose und kostenpflichtige Themes, wobei für ein kostenpflichtiges Theme eine einmalige Gebühr anfällt.¹ Das Theme bestimmte dein Layout-System, deine Farboptionen und wie weit du ohne Code gehen konntest.

Zweitens: Du hast Apps installiert, um die Lücken zu füllen. Produktseiten brauchen ein Bundle-Widget, das das Theme nicht mitliefert. Eine Kampagne braucht eine Landingpage, die das Theme nicht bauen kann. Also hast du eine Page-Builder-App hinzugefügt – PageFly, GemPages, Shogun, Replo oder eine der vielen anderen.

Drittens: Du hast Blöcke per Drag-and-Drop hin- und hergeschoben. Shopifys eigener Online Store 2.0 Editor erlaubt es dir, auf den meisten Seitentypen Sections ohne Code hinzuzufügen, neu anzuordnen und zu entfernen. Page-Builder-Apps sitzen quasi obendrauf und bringen ihren eigenen visuellen Canvas mit.

Und dieses Modell funktioniert. Es ist der absolute Hauptgrund, warum nicht-technisch versierte Gründer an einem einzigen Wochenende einen Shop launchen können. Es hat drei echte Stärken.

• Es ist vorhersehbar. Du siehst, was du baust. Es gibt keine Unklarheiten darüber, was ein Drag-and-Drop am Ende bewirkt.
• Es ist zugänglich. Keine Code-Kenntnisse erforderlich. Das Theme und die jeweilige App übernehmen das Templating.
• Es ist ausgereift. Diese Tools haben jahrelangen Feinschliff, Template-Bibliotheken und vollen Support hinter sich.

Aber das alte Modell hat eben auch strukturelle Grenzen, die mit dem Wachstum des Shops immer schmerzhafter werden.

Das Limit eines gekauften Templates

Ein Theme ist eine Sammlung von Entscheidungen, die jemand anderes getroffen hat. Wenn deine Marke etwas braucht, das im Theme schlichtweg nicht vorgesehen ist, hast du die Wahl zwischen zwei schlechten Optionen: Einen Entwickler beauftragen, um das Theme zu forken, oder das Design so weit wie möglich in die engen Grenzen zu pressen, die das Theme zulässt.

Das Gewicht gestapelter Apps

Jede Page-Builder-App fügt Scripts hinzu. Viele injizieren eigenes CSS und JavaScript auf jeder betroffenen Seite – das ist einer der häufigsten Gründe, warum die Page Speed eines Shops mit der Zeit massiv abnimmt. Du erbst auch einen klassischen Lock-in-Effekt: Wenn du die App deinstallierst, gehen die damit gebauten Seiten oft kaputt, weil der Content komplett in der App und nicht in deinem Theme gelebt hat.

Die Lücke zwischen „naht dran“ und „genau richtig“

Drag-and-Drop ist schnell für den Standardfall und sehr langsam für den spezifischen Fall. Die Kontrolle auf Pixelebene, Custom-Interaktionen und stark datenabhängige Logik erfordern am Ende dennoch ein Eingreifen in den Code. Der Builder meistert zwar 80% des Weges, stellt dich aber danach vor eine unüberwindbare Wand.

Nichts davon verurteilt das alte Modell als per se schlecht. Es verkörpert vielmehr schlichtweg eine Reihe von Trade-offs, die lange Zeit die einzig praktikable Option auf dem Markt waren.

Was sich geändert hat: Agents haben einen Kontext-Layer bekommen

Der Grund, warum Prompt-gesteuerte Entwicklung vor zwei Jahren noch nicht praktikabel war, ist ziemlich simpel. Ein generelles Sprachmodell (LLM) kennt Shopify nicht gut genug, als dass man ihm bedenkenlos Shopify-Code anvertrauen könnte.

Bitte ein Modell ohne spezifische Tools um eine Liquid-Section oder eine GraphQL-Mutation, und es erfindet wilde Feldnamen, verwendet veraltete Filter und rät die Version der Admin-API ins Blaue hinein. Ein solches Output sieht vielleicht beim Überfliegen richtig aus, scheitert der Praxis aber beim ersten Kontakt dramatisch.

Was sich 2026 maßgeblich geändert hat, ist die Tatsache, dass Shopify exakt diese Lücke mit eigenem Tooling geschlossen hat.

Shopify brachte das AI Toolkit heraus, eine völlig quelloffene Infrastruktur, die KI-Coding-Agents direkt mit Shopifys Live-Dokumentation und internen API-Schemas verknüpft. Das Toolkit erreichte in der Spring ‘26 Edition den Status „General Availability“ und unterstützt Claude Code, Cursor, Codex, VS Code sowie diverse weitere Tools.²

Es übernimmt im Kern zwei sehr entscheidende Aufgaben.

• Docs-Suche: Der Agent fragt die aktuelle Shopify-Dokumentation selbstständig ab, anstatt sich auf veraltete Trainingsdaten zu verlassen.
• Schema-Validierung: Der Agent gleicht seinen eigenen GraphQL-, Liquid- und Extension-Code rigoros mit den hinterlegten Schemas ab, noch bevor er ihn ausliefert.

Besonders die zweite Aufgabe ist der eigentliche Durchbruch. Eine automatische Validierung macht aus einem vagen „sieht richtig aus“ ein bewiesenes „ist Schema-valide“ – und genau das entscheidet darüber aus, ob dir ein Agent den Nachmittag ruiniert oder ihn letzten Endes rettet.

Dies ist jedoch keinesfalls ein isoliertes Feature. Shopify forciert KI-Entwicklungen konsequent auf der gesamten Plattform. So stieg die Zahl der wöchentlich aktiven Shops, die den Sidekick-Assistenten fleißig nutzen, im ersten Quartal 2026 im direkten Jahresvergleich um satte 400 % an.³ Im Storefront überzeugen zudem KI-Suchen basierend auf Shopifys Catalog durch eine schlichtweg doppelt so hohe Conversion Rate im Vergleich zur herkömmlichen Suche per gescrapten Daten.⁴ Eine tiefergreifende Gesamtübersicht hierüber haben wir in unserem Beitrag State of Shopify AI in 2026 zusammengefasst.

Der springende Punkt bleibt: Es war in erster Linie der Kontext-Layer – und nicht primär das einzelne Modell selbst –, der Prompt-gesteuerte Shopify-Entwicklungen real und praktikabel gemacht hat. Sobald ein Agent absolute Fakten nachschlagen und folglich die eigene Arbeit validieren kann, entfällt sofort die Pflicht, die Shop-Erstellung mit „Wähle ein Template“ beginnen zu müssen.

Das neue Modell: Vom Prompt zu geprüftem nativem Code

So sieht die Kontur des neuen Modells in ganz einfachen Worten aus.

Du beschreibst ein bestimmtes Resultat in verständlicher Sprache. Ein Agent entwirft passgenauen nativen Code, der exakt auf die aktuellen Shopify-Schemas abgestimmt ist. Ein Mensch führt im Anschluss ein ehrliches und sauberes Review durch – und erst dann geht die Änderung live.

Das finales Output ist haargenau das Gleiche, was auch ein erfahrener Entwickler von Hand getippt hätte: Liquid, JavaScript und CSS, die in deinem eigenen Theme leben. Kein hermetisch abgeschlossener, geheimer proprietärer Block aus einer Drittanbieter-App. Kein fehleranfälliges Widget, das beim unbedarften Deinstallieren gnadenlos zerbricht. Stattdessen reinstes und ehrliches Theme-Code-Handwerk.

Und genau diese genaue Unterscheidung macht das ganze Argument aus. Im alten klassischen Modell besteht das Endprodukt („Artefakt“) einer Page-Builder-App ganz trivial aus App-owned Content. Im völlig neu gedachten Modell hingegen besteht das Output in einem in Gänze dir gehörenden nativen Theme-Code.

Warum natives Output so maßgeblich ist

Grundsätzlich bringt nativer Code ganz gravierende Vorzüge mit sich, die Content aus stark geschachtelten und sogenannten gestapelten („stacked“) Apps schlichtweg nicht aufweisen kann.

• Null Render Tax als Fremd-Zuschlag. Der Code gehört zu hundert Prozent dir, entsprechend lädt auch kein fremdes und blockierendes Vendor-Script bei jedem simplen Seitenaufruf.
• Absolut kein Lock-in-Effekt. Entferne getrost das Programm, welches dir bei der Erstellung des Codes im Vorfeld behilflich war – und vertrau darauf, dass der Code ganz ungetrübt bleibt. Er liegt auf deinem Theme, sowie gut aufgehoben in deinem Git (sofern du das nutzt).
• Ein Plus an voller Kontrolle. Sämtliche denkbaren Zeilen und Logiken, die sich Entwickler ausdenken können, lassen sich mühelos als passabler Test zur Überprüfung vom virtuellen Co-Piloten anfertigen – er spricht dieselbe Coding-Sprache.

Wo weiterhin der Mensch regieren muss

Aber machen wir uns wirklich gar nicht erst irgendetwas vor: Wir haben hier logischerweise keinen absoluten Autopiloten vor uns vorliegen – und wenn dir einer dies so weismachen möchte, hat dieser einfach keine Ahnung (oder etwas zu verkaufen). Die Stärke des virtuellen Entwickler-Pendants rangiert primär bei großen Arbeitsmengen („Volume“) – leider mangelt es der KI im Angesicht tiefsinniger Urteilsvermögen („Judgement“).

KI-Modelle haben nämlich nicht auch nur den Anflug eines Schimmers davon, wie stark etwa überschriebene Produktbeschreibungen und -kopien teure Rankings einreißen und die Monatsarbeit zum Spott eines Momentes degradieren. Sie können verlangsamte Seiten nicht selbst erleben. Ob Design-Sprache respektiert oder auf Teufel komm raus Conversion generiert wird – all dies obliegt weiterhin exklusiv menschlichen Akteuren und Urteilsvorbehalten.

Die übergeordnete Disziplin in unserer schönen neuen Modellstruktur fokussiert sich also vollends auf „Review“ statt nur simplen „Prompting“. Im Rahmen unserer Abhandlung zur AI-first Shopify-Entwicklung postulierten wir ohnehin vornehmlich den Umgang mit dem sogenannten Governance Layer (wer darf wann und an welche Positionen schreiben? wie und wo werden Drafts platziert? wie wird ein problemloses Rollback generiert und final gewährleistet?).

Altes Modell vs. neues Modell im direkten Vergleich

Das Risiko des alten Modells sind Bloat und starre Limits; das Risiko des neuen Modells ist ein Agent, der ohne Entwurf oder Undo-Funktion in einen Live-Store schreibt.

Ist klassisches Drag-and-Drop als Konzept nun ad acta gelegt?

Nein, und etwas anderes zu behaupten, ist genau die Art von Hype, die dieser Text vermeiden will.

Drag-and-Drop ist hervorragend für den Standardfall, den ein gutes Theme abdeckt: eine Standard-Produktseite, eine einfache Collection, eine Homepage, die zum Template passt. Wenn deine Anforderungen in dem Rahmen bleiben, wofür das Theme gebaut wurde, ist ein visueller Editor der schnellste Weg und ein Prompt bringt dir keinen Mehrwert.

Wir haben einen vollständigen Vergleich unter KI vs. Drag-and-Drop Shopify Page Builder und ein Ranking unter Die besten KI Page Builder für Shopify. Fairerweise muss man sagen, dass sich beide Ansätze stark überschneiden und die richtige Wahl davon abhängt, wie weit dein Design von den Standards des Templates abweicht.

Das Prompt-gesteuerte Modell gewinnt dort, wo Drag-and-Drop an seine Grenzen stößt: Custom Logic, datenabhängiges Verhalten, markenspezifisches Design und alles, was das Theme nicht vorgesehen hat. Für einen Store, der aus seinem Template herausgewachsen ist, macht das einen Großteil der Arbeit aus.

Die praktische Antwort für die meisten Stores ist eine Mischung. Nutze den visuellen Editor für das Alltägliche und Prompts für die Teile, für die du früher einen Entwickler brauchtest.

Was dies alles nun für die Shopbetreiber bedeutet

Für Händler ist das Versprechen des neuen Modells die Geschwindigkeit von KI, ohne Liquid lernen oder ein Terminal bedienen zu müssen.

Dieses Versprechen gilt nur, wenn das Tool für Händler und nicht für Entwickler gebaut ist. Ein reiner Coding-Agent gibt dir ein allgemeines Modell und eine CLI, und sobald du Mutations erlaubst, schreibt die CLI direkt in deinen Live-Store, ohne Entwurf (Draft) und ohne Undo. Das ist keine Benutzeroberfläche für Händler. Es ist nur ein sehr schneller Weg, um aus Versehen den kompletten Produktkatalog zu überschreiben.

Eine händlerorientierte Version des neuen Modells braucht mehr als nur Code-Generierung.

• Integrierte Shopify Best Practices. Ein allgemeines Modell schreibt generische Templates, es sei denn, du steuerst es bei jedem Prompt. Ein zweckmäßig gebautes Tool hat Online Store 2.0 Sections, Schema-Settings und Performance-Patterns direkt einprogrammiert, sodass der Output standardmäßig Best Practices folgt.
• Drafts und Preview. Jede Änderung beginnt als Entwurf, den du gerendert in deinem Store siehst, bevor er live geht – und nicht als Diff-Code, den du lesen und dir vorstellen musst.
• Rollback und Historie. Du kannst eine frühere Änderung finden, noch einmal ansehen und rückgängig machen.
• Nativer Output. Das Ergebnis ist Theme-Code, also gibt es keinen Lock-in-Effekt, falls du das Tool nicht mehr nutzt.

Genau für diesen Job wurde Fudge, der AI-Operator für Shopify-Stores, entwickelt. Er läuft direkt im Shopify-Adminbereich, arbeitet mit Prompts statt mit Code und behält jede Änderung im Draft-Modus, bis du sie veröffentlichst. Gib ihm ein Ziel, und er liest deinen Store, deine Analytics und Suchdaten aus, bewertet, was sich für dieses Ziel lohnt, und vergleicht die Zahlen vor und nach jeder Änderung. Es ist der Einstieg für Händler in das Prompt-gesteuerte Modell – ohne das Live-Store-Risiko, das eine nackte CLI mit sich bringt. Wenn du Optionen vergleichst, setzt unsere Übersicht der besten Shopify Page Builder Fudge in Kontext zu den älteren Tools.

Wenn du sehen willst, wie das neue Modell Ergebnisse liefert, bevor du dich festlegst, kannst du die kostenlosen Shopify-Tools von Fudge ohne Installation ausprobieren. Darunter ein AI Store Builder, der einen Store anhand einer Beschreibung designt, und ein Redesign-Generator, der mit deinen echten Produkten arbeitet.

Was es für Agenturen und Entwickler bedeutet

Für Entwickler ist das neue Modell keine Bedrohung. Es ändert nur, worin die Arbeitsstunden fließen.

Der Schwerpunkt verlagert sich vom Code tippen hin zum Anleiten und Reviewen. Die repetitiven 70 % – Scaffolding von Sections, validierte Queries schreiben, Liquid-Refactoring, sich in ein fremdes Theme einlesen – genau hier sind Agenten am stärksten. Diese Arbeit wird komprimiert.

Was sich nicht komprimieren lässt, ist Urteilsvermögen. Performance, Barrierefreiheit (Accessibility), Cross-Device-Verhalten und die Einschätzung, ob eine Änderung sicher veröffentlicht werden kann, brauchen nach wie vor einen Menschen. Die Validierung bestätigt, dass der Code korrekt ist, nicht, dass die Entscheidung richtig war.

Für Agenturen verändert dieser Wandel die Unit Economics eines Builds. Weniger Zeit für Boilerplate-Code bedeutet mehr Kapazität für die Arbeit, die Kunden wirklich schätzen: Strategie, Custom Logic und die Ermessensentscheidungen, die ein Modell nicht treffen kann. Die Agenturen, die Probleme bekommen werden, sind diejenigen, deren Wertschöpfung hauptsächlich aus dem Tippen von Code bestand.

Eine Agentur, die einem Agenten Schreibzugriff auf den Live-Store eines Kunden gibt, braucht eine Lösung für Freigaben, Previews und Rollbacks, bevor die erste Mutation läuft.

Die Grenzen des Prompt-gesteuerten Modells

Ausgewogenheit bedeutet, auch zu benennen, wo das neue Modell schwächer oder unbewiesen ist.

• Die Ausführung im Live-Store ist standardmäßig gefährlich. Ein CLI-basierter Agent mit erlaubten Mutations kann Inhalte ohne Entwurf und ohne Undo überschreiben. Das ist das mit Abstand größte Risiko, und es ist real.
• Prompt-Qualität ist immer noch wichtig. Vage Prompts führen zu groben, manchmal falschen Änderungen. Der Skill ist nicht verschwunden; er hat sich von der Syntax zur Spezifikation verlagert.
• Urteilsvermögen lässt sich nicht übertragen. Der Agent hat keine “Ground Truth” darüber, was konvertiert oder zu deiner Marke passt. Diese Entscheidungen zu delegieren, ist ein Fehler.
• Das Tooling ist noch jung. Das AI Toolkit hat 2026 General Availability erreicht. Es ist leistungsfähig, aber das Ökosystem rund um Governance, Previews und Audit Trails formiert sich gerade erst.

Eine faire Zusammenfassung: Das Prompt-gesteuerte Modell ist eine Verschiebung darin, wie Storefront-Code geschrieben wird, und kein fertiger Ersatz für alles, was vorher war. Es ist am stärksten, wo das alte Modell am schwächsten war, und bringt neue Risiken mit sich, die das alte Modell nicht hatte.

Wohin die Reise geht

Die Richtung ist klar, auch wenn das Tempo es noch nicht ist.

Der erste Schritt bei einem Shopify-Build verschiebt sich von “Welches Template?” hin zu “Was möchte ich?”. Das Artefakt verlagert sich von App-eigenen Blöcken zu nativem Theme-Code. Die Rolle des Entwicklers wandelt sich vom Autor zum Anleiter und Reviewer. Und Händler bekommen einen Weg zu Änderungen, für die früher Code nötig war – vorausgesetzt, das Tool umgibt das Modell mit Drafts, Previews und Rollback-Optionen.

Nichts davon löscht das alte Modell aus. Themes und visuelle Editoren werden noch jahrelang das Alltägliche bewältigen. Aber für die Arbeit, die früher an eine Wand stieß, ist diese Wand jetzt niedriger geworden.

Templates sind nicht tot; der Startpunkt hat sich nur verschoben, und die Tools, die sich langfristig durchsetzen, werden Prompt-gesteuerte Generierung mit der Sicherheit kombinieren, die ein Live-Store zwingend verlangt.

FAQ