Shopifys Claude-Code-Playbook: Wie 23.000 Engineers KI-First arbeiten - und was du dir davon abschauen kannst

Letzte Woche ist ein Thread von @zodchiii auf X durch die Engineering-Bubble gegangen, der das Bessemer-Playbook von Shopify zusammenfasst: 23.000 Engineers, Ziel 90 % autonomes Coding bis Q3 2026, und ein erstaunlich klares internes Setup rund um Claude Code.

Wir bauen für Plus-Brands selbst seit 2024 mit Claude Code, Cursor und MCP-Servern. Vieles, was Shopify hier öffentlich macht, deckt sich mit dem, was wir intern eingeführt haben. Manches ist eine Hausnummer größer. In diesem Post übersetzen wir die sechs Patterns aus dem Thread auf realistische Setups für deutsche Shopify-Teams - von 5-Personen-Inhouse-Crew bis zu Plus-Brand mit eigener Engineering-Abteilung.

Was Shopify wirklich sagt

Zwei Dinge vorweg, um den Hype einzuordnen:

1. „90 % autonomes Coding” ist keine Vision, sondern ein Deadline-Statement. Farhan Thawar (VP Engineering) hat das auf der Bessemer-Conference als Q3-2026-Ziel angekündigt. Das heißt: in 4 Monaten.
2. Der produktive Hebel ist nicht „mehr Code”, sondern „mehr Optionen”. Shopify schätzt ihren Produktivitätszuwachs auf rund +20 % - entsteht laut Thawar daraus, dass Teams jetzt 10 Ansätze statt 2 testen, schneller prototypen und Fehler früher fangen. Nicht daraus, mehr Zeilen rauszuhauen.

Das ist die wichtigste Linse, durch die wir das Playbook lesen.

Pattern 1: LLM-Proxy als Infrastructure-Layer

“Shopify didn’t standardize on one AI tool. They standardized the layer underneath it.”

Shopify hat nicht Claude Code oder Cursor zum „offiziellen Tool” erklärt. Stattdessen läuft jeder KI-Request durch einen internen LLM-Proxy:

1. 01
   Engineer

   Client-Tools

   Jede:r Entwickler:in arbeitet im gewohnten Tool - kein erzwungener Standard.

   • Claude Code
   • Copilot
   • Cursor
2. 02
   LLM Proxy

   Zentrales Gateway

   Jeder KI-Request läuft durch eine Stelle. Hier sitzt die gesamte Kontrolle.

   • Auth
   • PII-Filter
   • Audit-Log
3. 03
   Model Provider

   Austauschbar

   Modelle hinter dem Proxy - wechselbar ohne Workflow-Bruch beim Team.

   • OpenAI
   • Anthropic
   • Google
4. 04
   Governance

   Out of the box

   Was der zentrale Layer automatisch liefert - pro Team, nicht pro Tool.

   • Usage Analytics
   • Cost Control
   • Model Routing

Das gibt ihnen drei Dinge, die für jede Plus-Brand mit ≥ 3 Devs Sinn ergeben:

• Zentrale Cost-Kontrolle. Token-Budgets pro Team, Alerts, Hard-Caps.
• Datenschutz auf einer Ebene. PII-Filter, Code-Egress-Regeln, Audit-Logs an einer Stelle, nicht in jedem Tool einzeln.
• Modell-Wechsel ohne Workflow-Bruch. Wenn morgen Claude 4.5 oder GPT-5 günstiger/besser ist, switcht das Proxy - keine Engineer muss etwas neu installieren.

Was das für dich heißt: Du brauchst keinen eigenen Proxy in den ersten 12 Monaten. Aber lass das nicht in Theme-JS oder API-Routes verstreut wachsen. Wir empfehlen Plus-Teams meist OpenRouter oder einen schlanken Cloudflare-Workers-Proxy mit Logging in Datadog. Das ist 2 Tage Setup und spart später Wochen.

Pattern 2: Parallele Agenten statt Single-Chat

“They launch multiple agents simultaneously working on different parts of the codebase.”

Das ist der konzeptionelle Bruch, den die meisten Teams noch nicht vollzogen haben. Shopify behandelt Claude Code nicht als „besseres Autocomplete”, sondern als mehrere parallele Mitarbeiter:

# Terminal 1: Refactor
claude -p "refactor src/auth/ to use the new session handler"

# Terminal 2: Tests
claude -p "write integration tests for the payment flow"

# Terminal 3: Docs
claude -p "update API documentation for all changed endpoints"

Der Engineer wird zum Reviewer und Merge-Master. Thawar nennt das „orchestrating intelligent systems”.

In unserer Erfahrung mit Plus-Theme-Projekten funktioniert das wirklich gut für:

• Liquid-Section-Refactors, parallel zu JSON-Template-Updates
• Bulk-Operationen über Metafield-Schemas
• GraphQL-Schema-Migrationen mit gleichzeitiger Doku-Update
• Storybook-Story-Generierung neben Component-Refactor

Es funktioniert nicht für:

• Tightly-coupled Logic, die in einem mentalen Modell bleiben muss
• Sicherheitskritische Reviews (Checkout, Auth, Payment)
• Neuartige Architektur-Entscheidungen ohne klare Vorlage

Faustregel: Wenn du den Task in 2 Sätzen ohne Schaubild beschreiben kannst, ist er parallelisierbar. Sonst single-track.

Pattern 3: Extended Critique Loops für harte Entscheidungen

Für nicht-parallelisierbare Architektur-Entscheidungen lässt Shopify einen Agenten in einer Critique-Schleife laufen:

“Propose an architecture for [X]. Then critique your own proposal: what breaks at scale? Then revise based on your critique. Then critique the revision. Give me the final version with confidence levels for each decision.”

Das Pattern ist nicht neu (LLM-Self-Critique gibt es seit GPT-4), aber als Standard-Prompt im Team-Playbook ist es selten dokumentiert. Wir bauen ähnliche Loops in unsere Solution-Architecture-Phase ein - etwa bei B2B-Pricing-Engines oder Multi-Shop-Strukturen (siehe Multishop-Shopify-Architektur).

Unser Tipp: Schreib den Critique-Prompt als Snippet in dein CLAUDE.md (siehe Pattern 4). Drei Iterationen reichen meist; mehr produziert Diminishing Returns und teils Halluzinationen.

Pattern 4: CLAUDE.md als Team-Infrastruktur - aber schlank

Hier wird’s für jede Shopify-Team-Größe relevant. Shopify committet ihr CLAUDE.md ins Git-Repo und teilt es über alle 23.000 Engineers. Auszug:

# CLAUDE.md (Shopify internal pattern)

## Stack
Ruby on Rails, React, GraphQL, MySQL

## Commands
- Dev: `dev up && dev server`
- Test: `dev test [path]`
- Lint: `dev style`
- Type check: `bin/srb tc`

## Architecture
- app/models/ → ActiveRecord models, business logic
- app/controllers/ → thin controllers, delegate to services
- app/services/ → service objects for complex operations
- app/graphql/ → GraphQL types, mutations, resolvers

## Rules
- NEVER bypass Sorbet type checking
- All new code must have type signatures
- Database queries only through established patterns
- IMPORTANT: run `dev test` after every change

Der spannendste Satz aus Thawars Talk:

“Stuffing CLAUDE.md with every standard and convention makes performance worse, not better. You pay for all of it on every turn.”

Übersetzt: Jedes Token in CLAUDE.md geht in jeden einzelnen Agent-Call. Wenn du 5.000 Zeilen Style-Guide reinkippst, zahlst du das fünfmal pro Stunde. Und der Agent verliert Focus.

Unser Standard für Plus-Shopify-Projekte (kompakt, < 60 Zeilen):

# CLAUDE.md (Plus-Theme-Setup)

## Stack
Shopify Plus, Liquid (DAWN-fork), Tailwind, Alpine.js, GraphQL Admin API,
Cloudflare Workers (Storefront-Proxy + Custom-App-Logic)

## Commands
- Dev: `shopify theme dev`
- Push: `shopify theme push --unpublished`
- Test: `npm run test:liquid && npm run test:e2e`
- Lint: `theme-check --no-color`

## Architecture
- sections/ → JSON-Templates + Liquid Sections (no business logic)
- snippets/ → Reusable Liquid partials
- assets/ → CSS modules, Alpine components, no inline JS
- config/ → Settings schema; ALWAYS update settings_data.json alongside

## Rules
- NEVER add inline <style> or <script> tags
- ALL Liquid filters must handle `nil` gracefully
- Performance budget: LCP < 1.5s mobile, INP < 200ms
- ALWAYS run theme-check before commit
- IMPORTANT: Never edit settings_data.json manually - use admin UI

Mehr als das muss nicht rein. Style-Guides, Naming-Conventions etc. gehören in separate Memory-Files, die der Agent on-demand lädt (@docs/styleguide.md im Prompt).

Pattern 5: Shopify-eigener MCP-Server

Im April 2026 hat Shopify den Shopify Dev MCP Server open-source gestellt:

claude mcp add --transport stdio shopify-dev-mcp \
  -- npx -y @shopify/dev-mcp@latest

Das gibt Claude Code (oder jedem MCP-fähigen Client) sieben Tools:

1. Aktuelle Shopify-Docs durchsuchen (nicht stale Training-Daten)
2. GraphQL-Queries gegen Live-Schemas validieren
3. Store-Operationen über Shopify CLI ausführen
4. Produkte, Metafelder, Themes anlegen/anpassen
5. Bulk-Operationen mit natürlicher Sprache triggern
6. Live-Schema-Inspection (Admin + Storefront)
7. App-Bridge-Validierung für Custom Apps

Warum das ein Game-Changer ist: Ohne MCP halluziniert Claude bei Shopify-spezifischen API-Feldern und erfindet Liquid-Filter, die es nicht gibt. Mit MCP arbeitet er gegen echte Schemas und aktuelle Docs. In unseren Custom-App-Projekten ist die „Erstwurf-funktioniert”-Quote bei GraphQL-Code dadurch von ca. 60 % auf ca. 90 % gestiegen.

Bonus: Du kannst MCP-Server für eigene Tools bauen - wir betreiben für interne Projekte u. a. MCP-Server für unser Klaviyo-Account, Vercel-Deployments und n8n-Workflows. Sobald ein Tool eine API hat, lohnt ein MCP-Wrapper.

Pattern 6: Strategy-First-Verschiebung

Die Zahl, die wir uns aufschreiben:

Phase	2024	2026 (Shopify)
Strategy (User-Flows, Architektur, Validierung)	30 %	70 %
Execution (Code schreiben)	70 %	30 %

Klingt wie eine PR-Folie. Ist es aber nicht - das ist die operationale Konsequenz aus Pattern 1–5. Wenn KI 70 % deiner Execution übernimmt, verschiebt sich dein Job zu „entscheiden, welcher Code überhaupt existieren soll”.

Für Shopify-Plus-Brands heißt das praktisch:

• Discovery-Phase wird wertvoller (User-Research, Story-Mapping, Datenanalyse)
• CRO-Hypothesen-Backlog (siehe unser CRO-Hypothesen-Post) wird zur Hauptarbeit
• Architecture Reviews vor jeder Major-Feature
• Senior-Engineers verschieben sich zu Tech-Leads / Product-Engineers
• Junior-Aufgaben verschwinden nicht - sie ändern sich: weg vom Boilerplate, hin zu Reviewing & Validierung

Pattern 7 (Bonus): Guardrails, sonst geht alles kaputt

Im Thread auch enthalten: Shopifys settings.json-Permissions:

{
  "permissions": {
    "allow": [
      "Read", "Glob", "Grep", "LS", "Edit",
      "Bash(dev test *)",
      "Bash(dev style *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Read(**/.env*)",
      "Bash(git push *)",
      "Bash(dev deploy *)",
      "Bash(bin/rails db:drop *)",
      "Bash(rm -rf *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

Agents dürfen lesen, schreiben, testen, committen. Sie dürfen nicht pushen, deployen, Datenbanken droppen oder Secrets lesen. Mensch bleibt in jeder irreversiblen Aktion in der Schleife.

Unser Plus-Theme-Äquivalent enthält zusätzlich:

• Deny: Bash(shopify theme push --live *) - keine Live-Pushes durch Agent
• Deny: Bash(shopify api *) (außer read-only Calls)
• Deny: Read(**/private/**) - interne Kundendoku off-limits
• Deny: Bash(npm publish *) - wir publishen keine Custom Apps unbeaufsichtigt

Wir sehen leider regelmäßig Teams, die Claude Code mit --dangerously-skip-permissions laufen lassen und sich wundern, warum eine Migration plötzlich gelöscht ist. Tu das nicht.

Das realistische Setup für deutsche Plus-Teams

Du musst nicht 23.000 Engineers sein, um 80 % des Wertes mitzunehmen. Was wir Kunden konkret empfehlen, je nach Team-Größe:

1–3 Devs (Inhouse oder Agentur-Setup)

• ✅ Claude Code + Shopify Dev MCP installieren (1 Tag)
• ✅ Schlankes CLAUDE.md (< 60 Zeilen) ins Theme-Repo committen
• ✅ Permission-Whitelist statt --dangerously-skip-permissions
• ✅ 1 paralleler Sub-Agent für Tests/Docs während Refactor läuft
• ❌ Noch kein eigener LLM-Proxy nötig

4–10 Devs (mittelgroßer Plus-Brand)

• ✅ Alles von oben +
• ✅ Cloudflare-Workers-LLM-Proxy oder OpenRouter mit Team-Token-Limits
• ✅ Eigene MCP-Server für Klaviyo, Vercel, n8n, was ihr nutzt
• ✅ Critique-Loop-Prompts als Snippets in CLAUDE.md
• ✅ Wöchentliche „Agent-Pattern-Sharing”-Session (15 Min)

10+ Devs (Plus-Brand mit eigener Engineering-Org)

• ✅ Alles von oben +
• ✅ Echter zentraler LLM-Proxy mit Audit-Log + PII-Filter
• ✅ Eigene CLAUDE.md pro Subsystem (Theme, App, Backend) - nicht ein Mega-File
• ✅ MCP-Server fürs interne ERP/PIM
• ✅ Strategy-First-Reorg: Engineering-Manager wird zu Engineering-Strategist

Was wir nicht empfehlen (so wie Shopify es auch nicht macht)

• ❌ Vollautomatische Deployments durch Agenten. Mensch reviewed immer.
• ❌ „Replace your engineers”-Pitches von KI-Tools. Shopify hat mehr Engineers eingestellt, nicht weniger.
• ❌ Einen monolithischen 5.000-Zeilen-CLAUDE.md. Du zahlst Token-Cost auf jeden Turn.
• ❌ Nur ein Tool standardisieren (z. B. „wir nehmen jetzt nur noch Cursor”). Das Wertvolle ist die Infrastruktur drunter.
• ❌ KI-Code ohne Tests mergen. Shopify’s acceptEdits + Test-Required ist keine Verhandlungsbasis.

---

Der Thread von @zodchiii ist eine der seltenen Quellen, in denen ein Plus-Plattform-Anbieter ihr internes KI-Setup offenlegt. Die Lehre für deutsche Plus-Brands: Du musst Shopify nicht eins-zu-eins kopieren - aber die Patterns sind anschlussfähig, auch in einem 3-Personen-Theme-Team.

Wenn du dein eigenes KI-Setup für dein Shopify-Plus-Team sortieren willst - was schlank, was groß, was zuerst - buch dir ein 30-Minuten-Discovery-Gespräch. Wir gehen das nüchtern mit dir durch, basierend auf dem, was wir bei eigenen Plus-Projekten produktiv betreiben.

Quelle: Thread von @zodchiii (darkzodchi) auf X, basierend auf dem Bessemer-Playbook von Shopify VP Engineering Farhan Thawar.