AI-Coding bei Nordalux: Unser Werkzeug-Stack für Shopify

AI gehört bei uns inzwischen zum Werkzeugkasten, ungefähr so beiläufig wie der Editor oder das Terminal. Wir setzen sie ein, um Sections vorzubereiten, Liquid umzustellen oder durch große Theme-Strukturen zu suchen. Was am Ende live geht, schaut sich trotzdem ein Mensch an, Zeile für Zeile.

Dieser Beitrag zeigt, wie unser Werkzeugkasten heute wirklich aussieht. Nicht als Hochglanz-Demo, eher als Blick auf das, was bei uns gerade tatsächlich auf dem Tisch liegt.

AI als Werkzeug, nicht als Auto-Pilot

Die Idee kommt von uns. Die AI liefert einen Entwurf. Anschließend liest ein Mensch durch, korrigiert, prüft Edge-Cases, gibt frei. Einen vollautomatischen Flow, in dem ein Agent committet und deployt, gibt es bei uns nicht. Ehrlich gesagt: Wir sehen den auch in absehbarer Zeit nicht kommen. Zu viele Detailentscheidungen hängen am Theme, an der Bedienbarkeit für den Händler und an Eigenheiten des konkreten Shops.

Der Stack: AI plus zwei Helfer

Die größte Säule ist AI-Coding für Shopify, also Liquid, Sections, Schema, Tailwind, Theme-Settings. Daneben laufen zwei Tools, die wir bewusst dazugenommen haben, weil sie an Stellen Reibung wegnehmen, an denen reines Code-Tooling nicht hilft.

Wispr Flow für die Eingabe

Prompts werden lang. Eine ordentliche Section-Spezifikation mit Akzeptanzkriterien, Edge-Cases und Verweisen auf bestehende Patterns tippt sich nicht eben weg. Dafür benutzen wir Wispr Flow* (Werbung) als Diktiersoftware. Statt zu tippen, sprechen wir die Anforderung ein, das Tool transkribiert live und glättet die Sprache. Aus zwei Minuten Tippen werden gefühlt 30 Sekunden Sprechen, und nebenbei denkt es sich freier, weil man nicht über die Tastatur gebeugt ist. Besonders nützlich, wenn ein Prompt direkt richtig sitzen muss und der Agent sonst in die falsche Richtung läuft.

Seobility für den SEO-Blick

Sobald die AI im Frontend Hand anlegt, verschiebt sich oft mehr als nur das Layout. Headings ändern sich, Meta-Daten verändern sich mit, manchmal auch die strukturelle Tiefe. Wir nutzen Seobility* (Werbung), um danach kurz die On-Page-Perspektive nachzuziehen: Heading-Hierarchie, Meta-Beschreibungen, interne Verlinkung, Indexierbarkeit. So fallen Änderungen auf, die im Browser unauffällig wirken, der Suche aber später wehtun.

BFSG-Check ist bei uns Pflicht

AI schreibt Code, der funktioniert. Sie schreibt nicht automatisch Code, der für alle Nutzer bedienbar bleibt. Deshalb prüfen wir nach jeder AI-Änderung dieselbe Liste. Hat der Icon-Button ein aria-label? Liegt der Kontrast bei mindestens 4,5:1? Stimmt die Tab-Reihenfolge? Sind Bilder mit sinnvollem alt-Text versorgt, dekorative mit leerem alt? Bekommt jedes interaktive Element einen sichtbaren Focus-State?

Die Liste klingt überschaubar, ist im echten Theme aber schnell verletzt, gerade wenn ein Agent stark auf Funktion fokussiert. Deshalb gehört der A11y-Review fest zu jedem Pull Request, der AI-Code enthält.

Was BFSG eigentlich heißt

Das Barrierefreiheitsstärkungsgesetz (BFSG) ist die deutsche Umsetzung des European Accessibility Act (EU-Richtlinie 2019/882). Verbindlich gilt es seit dem 28. Juni 2025. Seither müssen Online-Shops, die an Endverbraucher verkaufen, die Anforderungen der WCAG 2.1 AA erfüllen, also wahrnehmbar, bedienbar, verständlich und robust für Menschen mit Behinderungen.

Pflicht wurde es, weil digitale Barrieren in Shops, Apps und Self-Service-Terminals jahrelang nicht von alleine verschwunden sind. Die EU hat den Zugang dort vereinheitlicht, wo vorher jedes Land eigene Regeln hatte oder gar keine. Für Shop-Betreiber in Deutschland heißt das ganz konkret: Verstöße können abgemahnt werden, und die Marktüberwachungsbehörden können Bußgelder verhängen. „Nice to have" ist BFSG damit nicht mehr.

Was nicht in die Cloud-AI geht

Es gibt eine zweite Linie, die wir nicht überschreiten: sensible Daten landen nicht in einer Cloud-LLM. Geschäftsgeheimnisse, Sonderkonditionen, individuell für einen Shop entwickelte Funktionen, alles mit Wettbewerbswert bleibt lokal. Dasselbe gilt für Customer-Daten oder Tokens, falls die in einem Code-Schnipsel auftauchen.

Wenn so etwas gebraucht wird, arbeiten wir entweder mit einer lokal laufenden LLM oder klassisch von Hand, ganz ohne Cloud-KI. Das ist langsamer, aber an dieser Stelle der einzige Weg, der sich sauber anfühlt. Die Cloud-Modelle bleiben dort, wo sie hingehören: bei generischem Liquid, Standard-Sections, Tailwind-Klassen, überall da, wo der Code keine Rückschlüsse auf Strategie, Konditionen oder Auth zulässt.

Wo der Zeitgewinn wirklich liegt

Im Frontend sparen wir merklich Zeit. Ideen, die früher unter „nett, aber dauert" abgelegt worden wären, lassen wir heute einfach skizzieren. Eine Section umstellen, eine Block-Variante testen, eine kleine Animation einbauen, einen Button-Hover ausprobieren: das sind die Aufgaben, bei denen der Agent in Minuten liefert, was vorher gut eine Stunde gebraucht hätte.

Das verschiebt, wie wir mit Ideen umgehen. Statt zu vertagen, probieren wir aus. Wenn die Variante schlechter ist als das Original, fliegt sie raus. Wenn sie besser ist, geht sie ins Theme. Diese kurze Schleife ist für uns der eigentliche Hebel im Frontend, nicht die große neue Funktion, sondern das schnelle, ehrliche Probieren.

Unser Workflow in vier Schritten

• Idee einsprechen, über Wispr Flow* (Werbung), mit Kontext zum Theme und den relevanten Edge-Cases.

• AI baut einen Entwurf: Liquid, Schema, CSS und bei Bedarf JavaScript. Idealerweise an den Patterns orientiert, die im Theme schon gelten.

• Mensch reviewt: Code lesen, anpassen, Mobile und Desktop prüfen, Fallbacks und leere Zustände, und ob die Section für den Händler später bedienbar bleibt.

• A11y- und SEO-Check zum Schluss: BFSG-Punkte (Kontraste, ARIA, Focus, Tab-Reihenfolge) und ein kurzer Seobility-Lauf, bevor wir mergen.

Warum es noch kein vollautomatischer Flow ist

Es klingt verlockend: Idee rein, fertiges Feature raus, niemand dazwischen. In der Praxis funktioniert das nicht. Jeder Shop hat eigene Regeln, eigene Settings, eigene Händler-Eigenheiten. Welche Optionen sollen konfigurierbar sein? Wo darf das Theme bestimmen, wo der Händler? Welche Defaults sind sinnvoll? Was passiert, wenn jemand die Section ganz anders einsetzt als gedacht?

Diese Entscheidungen sind keine Tipparbeit, sie sind die eigentliche Entwicklungsleistung. Und die geben wir nicht aus der Hand. Solange das so bleibt, ist unser Flow halbautomatisch: schneller AI-Entwurf, manuelles Review, bewusste Freigabe. Erst dann geht Code live.

Wenn du AI-Coding für deinen Shop einsetzen willst

AI-Coding lohnt sich vor allem dort, wo wiederkehrende Frontend-Arbeit anfällt: neue Sections, Block-Varianten, kleinere UX-Verbesserungen. Wenn du das für deinen Shopify-Shop sauber aufsetzen willst, inklusive BFSG-Pflichtcheck und einem ehrlichen Review-Loop, sprich uns an. Wir bauen Shopify Custom Coding mit demselben Werkzeugkasten, den wir hier beschrieben haben.