muench.dev Articles

Adobe Commerce Optimizer: Das Unified Data Model unter der Haube

2026-04-13T07:00:00+00:00

Vor kurzem habe ich bei einem Adobe Event das Produkt Adobe Commerce Optimizer (ACO) vorgestellt. Bei der Vorstellung wollte ich nicht mit den Standard-Demodaten arbeiten und wollte meine eigenen Demo-Daten nutzen. Dazu musste ich folgende Dinge klären: Welche API nimmt Daten entgegen? Wie ist das Datenmodell strukturiert? Und wie kommt das Ergebnis in mein Storefront (oder eigenes Frontend)?

Was ist das Unified Data Model?

Hinter ACO steckt eine SaaS-Schicht namens Merchandising Services, die auf einem zentralisierten, quellenunabhängigen Datenspeicher basiert. Adobe spricht in diesem Zusammenhang von der CCDM-Architektur – Composable Catalog Data Model.

Der Kerngedanke: Produktdaten kommen aus beliebigen Quellen (ERP, PIM, Magento, Shopify, was auch immer), landen in einem einzigen Basiskatalog und werden dort nach einem einheitlichen Modell gespeichert. Die Storefront greift über GraphQL darauf zu – gefiltert durch Catalog Views und Policies (Regelwerk).

Das Standardfrontend ist die neue Adobe Commerce Storefront auf Basis von Edge Delivery Services (EDS). Diese Storefront ist darauf ausgelegt, Produktdaten direkt über die GraphQL-Schicht von ACO zu konsumieren – ohne klassischen Magento-Applikationsstack dazwischen. Wer ein eigenes Headless-Frontend betreiben will, kann ebenfalls direkt auf den GraphQL-Endpoint aufsetzen; die EDS-Storefront bleibt aber der von Adobe vorgesehene und gepflegte Standardweg.

Datenerfassung: REST rein

Daten kommen über eine RESTful Data Ingestion API in den ACO. Die Base-URL folgt diesem Schema:

https://{region}-{environment}.api.commerce.adobe.com/{tenantId}

Alle Requests benötigen einen Authorization-Header mit Bearer-Token (IMS-Credential-basiert) sowie Content-Type: application/json.

Schritt 1: Attribut-Metadaten definieren

Bevor ein einziges Produkt importiert werden kann, müssen die Attribut-Metadaten angelegt werden – und das pro Locale. ACO muss vorab wissen, wie es mit jedem Attribut umgehen soll: Ist es filterbar? Sortierbar? Suchbar? Mit welchem Gewicht?

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/products/metadata' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "code": "name",
      "source": { "locale": "en-US" },
      "label": "Product Name",
      "dataType": "TEXT",
      "visibleIn": ["PRODUCT_DETAIL", "PRODUCT_LISTING", "SEARCH_RESULTS"],
      "filterable": false,
      "sortable": true,
      "searchable": true,
      "searchWeight": 1,
      "searchTypes": ["AUTOCOMPLETE"]
    },
    {
      "code": "brand",
      "source": { "locale": "en-US" },
      "label": "Brand",
      "dataType": "TEXT",
      "visibleIn": ["PRODUCT_LISTING", "SEARCH_RESULTS"],
      "filterable": true,
      "sortable": false,
      "searchable": true,
      "searchWeight": 1,
      "searchTypes": ["AUTOCOMPLETE", "CONTAINS", "STARTS_WITH"]
    }
  ]'

Der dataType kann TEXT, DECIMAL, BOOLEAN oder INT sein. visibleIn steuert, wo das Attribut auf der Storefront erscheint: Produktdetailseite, Listing, Suchergebnisse, Vergleich.

Schritt 2: Produkte anlegen

Danach kommen die eigentlichen Produkte per POST. Das Produkt-Objekt trägt neben den Pflichtfeldern (sku, source, name, slug, status) alle benutzerdefinierten Attribute als flache Key/Value-Liste im attributes-Array. Über routes wird das Produkt Kategorien zugeordnet.

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/products' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "sku": "aurora-battery-pro-100",
      "source": { "locale": "en-US" },
      "name": "Aurora Battery Pro 100",
      "slug": "aurora-battery-pro-100.html",
      "status": "ENABLED",
      "description": "High-performance 100Ah lithium battery for electric vehicles.",
      "shortDescription": "100Ah LiFePO4 traction battery",
      "visibleIn": ["CATALOG", "SEARCH"],
      "metaTags": {
        "title": "Aurora Battery Pro 100",
        "description": "100Ah LiFePO4 battery for EVs",
        "keywords": ["battery", "aurora", "electric vehicle"]
      },
      "attributes": [
        { "code": "brand", "values": ["Aurora"] },
        { "code": "location", "values": ["US"] },
        { "code": "capacity_ah", "values": ["100"] }
      ],
      "images": [
        {
          "url": "https://example.com/images/aurora-battery-pro-100.jpg",
          "label": "Aurora Battery Pro 100",
          "roles": ["BASE", "SMALL"],
          "customRoles": []
        }
      ],
      "routes": [
        { "path": "batteries" },
        { "path": "batteries/lithium", "position": 1 }
      ]
    }
  ]'

Auffällig: Alle Attributwerte – egal ob TEXT, DECIMAL oder INT – werden als Strings in values übergeben. ACO konvertiert sie intern anhand der vorher definierten Metadaten. An manchen Stellen würde ich mir etwas mehr Tiefe im Datenmodell wünschen, um auch kompliziertere Datenstrukturen (z. B. strukturierte Variantenkonfigurationen) sauber abbilden zu können. Das Array-Modell ist funktional, aber manchmal etwas flach.

Schritt 3: Price Books und Preise

Price Books ermöglichen unterschiedliche Preisstrukturen für verschiedene Kundensegmente, Regionen oder Kanäle – ohne den Basiskatalog zu verändern. Price Books können hierarchisch aufgebaut werden: Ein Basis-Price-Book legt die Währung fest, Kind-Price-Books erben davon und können selektiv überschreiben.

Zunächst werden die Price Books selbst angelegt:

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/price-books' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "priceBookId": "us",
      "name": "US Base Price Book",
      "currency": "USD"
    },
    {
      "priceBookId": "us-retail",
      "parentId": "us",
      "name": "US Retail"
    },
    {
      "priceBookId": "us-wholesale",
      "parentId": "us",
      "name": "US Wholesale"
    },
    {
      "priceBookId": "eu",
      "name": "EU Base Price Book",
      "currency": "EUR"
    }
  ]'

Ein Price Book ohne parentId ist ein Root-Price-Book und muss eine currency definieren. Kind-Price-Books erben die Währung vom Parent und brauchen kein eigenes currency-Feld – nur eine parentId.

Danach werden die Preise pro SKU und Price Book über einen separaten Endpoint gepflegt:

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/products/prices' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "sku": "aurora-battery-pro-100",
      "regular": 899.99,
      "priceBookId": "us"
    },
    {
      "sku": "aurora-battery-pro-100",
      "regular": 749.99,
      "priceBookId": "us-wholesale"
    },
    {
      "sku": "aurora-battery-pro-100",
      "regular": 849.00,
      "priceBookId": "eu"
    }
  ]'

Dasselbe Produkt bekommt also je nach Price Book einen anderen Preis. Welchen Preis die GraphQL-API zurückliefert, steuert der AC-Price-Book-ID-Header im Storefront-Request – ohne dass dafür die Produktdaten angepasst werden müssten.

Das Datenmodell: Catalog Views und Policies

Der eigentlich interessante Teil der CCDM-Architektur ist nicht der Import, sondern die Filterschicht:

Catalog Views definieren eine Geschäftseinheit: ein Händler, eine Marke, ein Markt. Jede View ist mit einer Katalogquelle (Locale) und einer Menge von Policies verknüpft.
Policies sind Datenzugriffsfilter auf Basis von Produktattributen. Eine Policy Brand mit Wert Aurora liefert beispielsweise ausschließlich Produkte, die das Attribut brand = Aurora tragen.

Das bedeutet: Derselbe Basiskatalog kann über verschiedene Catalog Views mit verschiedenen Policies völlig unterschiedliche Produktmengen ausliefern – ohne Datenduplizierung. Für Szenarien mit mehreren Marken, Märkten oder Vertriebskanälen ist das ein erheblicher architektonischer Vorteil.

Ein konkretes Beispiel aus der offiziellen Dokumentation: Ein fiktives Unternehmen (Zenith Automotive) pflegt einen einzigen Katalog für zwei Marken und zwei Märkte. Statt vier separate Instanzen zu betreiben, wird ein View mit zwei Policies konfiguriert:

Policy Location filtert nach Zielmarkt (USA, UK)
Policy Brand filtert nach Marke (Aurora, Bolt)

Ein Produkt trägt die entsprechenden Attribute. Welche Produkte ein API-Aufruf zurückliefert, hängt ausschließlich von den übergebenen Policy-Headern ab – nicht von der Datenstruktur selbst.

Datenzugriff: GraphQL raus

Die Storefront – ob EDS-basiert oder eine eigene Headless-Implementierung – greift auf die Daten per GraphQL Merchandising API zu. Authentifizierung ist auf dieser Ebene nicht erforderlich; die Steuerung läuft über HTTP-Header:

Header	Bedeutung
`AC-View-ID`	Pflichtfeld – welche Catalog View soll verwendet werden?
`AC-Policy-{Name}`	Optional – Filterung nach Policy-Wert, z. B. `AC-Policy-Brand: Aurora`
`AC-Price-Book-ID`	Optional – welches Price Book soll für die Preisberechnung genutzt werden?

Eine typische Produktsuche sieht so aus:

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/graphql' \
  -H 'Content-Type: application/json' \
  -H 'AC-View-ID: {catalogViewId}' \
  -H 'AC-Policy-Brand: Aurora' \
  -H 'AC-Price-Book-ID: us-wholesale' \
  -d '{
    "query": "query ProductSearch($search: String!) {
      productSearch(phrase: $search, page_size: 10) {
        items {
          productView {
            sku
            name
            description
            images { url }
            ... on SimpleProductView {
              price {
                regular {
                  amount { value currency }
                }
              }
            }
          }
        }
      }
    }",
    "variables": { "search": "battery" }
  }'

Die Response enthält ausschließlich Produkte, die zur konfigurierten View und Policy passen. Das Frontend muss nur die richtigen Header mitschicken – die gesamte Kataloglogik liegt in der ACO-Konfiguration.

Praktische Use Cases

Wo ist dieser Ansatz in der Praxis relevant?

Multi-Brand-Händler ohne Datensilos: Wer heute für jede Marke eine separate Magento-Instanz betreibt, kennt den Aufwand: Doppelte Pflege, doppelte Synchronisation, doppelter Upgrade-Aufwand. Mit CCDM ist das ein einziger Basiskatalog mit konfigurierten Views – und die organisatorische Trennung bleibt über Policies erhalten.

Internationalisierung ohne Datenduplizierung: Verschiedene Märkte, verschiedene Preise, verschiedene Sortimente – über Price Books und Policies steuerbar, ohne den Katalog zu kopieren.

Headless-Storefronts mit beliebigem Backend: ACO ist explizit darauf ausgelegt, dass das datenliefernde System kein Adobe Commerce sein muss. ERP, PIM, Shopify, ein eigenes System – alles kann über die REST Ingestion API einspeisen. Die EDS-Storefront konsumiert dann via GraphQL. Wer die EDS-Storefront nicht nutzen will, kann mit einem eigenen Frontend direkt an den GraphQL-Endpoint andocken. Ich habe das exemplarisch umgesetzt unter aco.demo.muench.dev.

Warenkorb und Checkout bleiben flexibel: ACO stellt bewusst keinen Warenkorb bereit. Der wird über API Mesh oder App Builder an ein bestehendes System angebunden. Das ist pragmatisch – und verhindert, dass für einen Storefront-Umbau die gesamte Transaktionslogik angefasst werden muss.

Ehrliche Einschätzung

Das Modell ist relativ einfach aufgebaut (mir manchmal zu einfach). Die klare Trennung zwischen Ingestion (REST), Konfiguration (Catalog Views/Policies) und Delivery (GraphQL) ist sauber durchdacht. Gerade für komplexe Multi-Brand- oder Multi-Market-Setups ist das eine Architektur, die in klassischen Magento-Projekten mit erheblich mehr Aufwand gebaut werden muss.

Allerdings bietet ACO keine Transaktionslogik direkt von Haus aus an. Alles was komplizierter ist, muss momentan selbst angebaut werden.

Dazu kommt: ACO ist SaaS-only. Für Händler, die ihre Datenhaltung im eigenen Rechenzentrum behalten müssen oder wollen – ein Thema, das ich im Tech-Trends-Post für 2026 unter dem Stichwort Sovereign Commerce ausgeführt habe – ist ACO in seiner aktuellen Form keine Option.

Für die richtige Zielgruppe dagegen – Enterprise-Händler mit komplexen Katalogstrukturen, die ihren bestehenden Backend-Stack behalten und die Storefront-Experience modernisieren wollen – ist ACO ein überzeugender Ansatz.

Für alle die vielleicht schon eine sehr heterogene Landschaft haben und sowieso vieles auf Services verteilt haben, ist ACO echt spannend. Die Stärken von ACO sind auch immer in Verbindung mit einem hochskalierenden Frontend auf Basis von Adobe Edge Delivery Services zu sehen. Wer nur einach Daten halten und ausspielen will, für den ist ACO vielleicht nicht das richtige. Das heisst aber nicht, dass es nicht auch spannend sein kann ein eigenes Frontend direkt auf die GraphQL Schnittstelle zu setzen.

Fazit

Das Unified Data Model hinter Adobe Commerce Optimizer ist keine Abstraktionsschicht ohne Substanz. Es ist ein einfaches, quellenunabhängiges Katalogmodell: Daten kommen per REST-API rein, werden über Catalog Views und Policies konfiguriert und per GraphQL ausgeliefert – an die EDS-Storefront oder ein eigenes Frontend.

Wer das selbst erkunden will: Die offizielle Dokumentation ist inzwischen gut aufgestellt. Einstiegspunkte sind die Developer-Doku zur Data Ingestion API und der End-to-End Use Case in der Adobe-Dokumentation. Ihr braucht dann zum Ausprobieren eine Sandbox von Adobe oder lasst es euch von mir zeigen. :-)

Agentic Commerce: Wenn KI-Agenten den Einkaufswagen übernehmen

2026-04-10T05:00:00+00:00

In den letzten Monaten beschäftigt mich ein Thema mehr als jedes andere im E-Commerce-Umfeld: Agentic Commerce. KI-Agenten, die autonom einkaufen, verhandeln und bezahlen – ohne dass ein Mensch auch nur einen Button klickt. Das klingt nach Science-Fiction, ist aber bereits Realität. Und wer im Magento/Adobe-Commerce-Ökosystem unterwegs ist, sollte jetzt genauer hinschauen. Aus diesem Grund gibt es in diesem Blog-Beitrag auch einen Blick ins Magento Ökosystem.

McKinsey beziffert das globale Marktpotenzial auf 3–5 Billionen US-Dollar bis 2030, Gartner prognostiziert, dass 90 % aller B2B-Einkäufe bis 2028 von KI-Agenten abgewickelt werden. Gleichzeitig zeigt ein nüchterner Blick auf die aktuellen Daten: Der Hype ist der realen Nutzeradoption weit voraus. OpenAI hat sein Instant Checkout in ChatGPT Anfang 2026 bereits wieder auf Händler-Apps umgestellt. Deutsche Verbraucher würden einem KI-Agenten im Schnitt maximal 50 Euro pro Monat anvertrauen.

Ich versuche in diesem Post, das Thema strukturiert aufzudröseln: Was ist Agentic Commerce überhaupt? Welche Protokolle setzen sich durch? Wer sind die relevanten Player? Und was bedeutet das konkret für das Magento/Adobe-Ökosystem?

Was Agentic Commerce vom klassischen E-Commerce unterscheidet

Der entscheidende Unterschied liegt in der Rollenverteilung. Im traditionellen E-Commerce sucht, vergleicht und kauft der Mensch aktiv. Bei Conversational Commerce führt ein Chatbot ein Gespräch, aber der Mensch entscheidet. Bei Agentic Commerce delegiert der Mensch – er definiert Ziele, Budget und Präferenzen, und der Agent handelt innerhalb dieser Leitplanken eigenständig.

Deloitte beschreibt vier evolutionäre Stufen:

Assisted Discovery – KI hilft bei der Produktsuche
Agentic Shopping – Agent übernimmt Teilschritte autonom
Autonomous Shopping – vollständig eigenständige Käufe
Agent-to-Agent Commerce – Käufer- und Verkäufer-Agenten verhandeln direkt miteinander, ohne dass je ein Mensch einen Bildschirm sieht

Wir stehen gerade zwischen Stufe 1 und 2. Stufe 4 ist Zukunft – aber die Infrastruktur dafür entsteht jetzt.

Der Protokoll-Stack: Kein Krieg, sondern Schichten

Anfangs gab es viel Lärm um einen angeblichen „Protocol War" zwischen MCP, A2A, UCP und ACP. Das hat sich inzwischen differenziert. Die Protokolle sind keine Konkurrenten, sondern Schichten eines gemeinsamen Stacks.

MCP – die universelle Datenschicht

Das Model Context Protocol (MCP), im November 2024 von Anthropic vorgestellt, ist mittlerweile der De-facto-Standard dafür, wie Sprachmodelle auf externe Daten, APIs und Tools zugreifen. Es funktioniert wie „USB-C für KI" – eine standardisierte Schnittstelle, unabhängig vom Modell-Hersteller.

Im Dezember 2025 übergab Anthropic MCP an die Agentic AI Foundation (AAIF) unter dem Dach der Linux Foundation. Gründungsmitglieder sind AWS, Google, Microsoft und OpenAI – inzwischen sind über 10.000 öffentliche MCP-Server registriert. Das ist ein starkes Signal für langfristige Stabilität.

A2A – Agenten reden miteinander

Googles Agent-to-Agent Protocol (A2A), im April 2025 vorgestellt, ermöglicht Agenten unterschiedlicher Hersteller, einander zu entdecken und Aufgaben zu delegieren. Kernkonzept sind Agent Cards – JSON-Metadaten unter /.well-known/agent.json, die Fähigkeiten und Auth-Anforderungen beschreiben. Quasi eine Visitenkarte für Agenten. Im Juni 2025 ebenfalls an die Linux Foundation übergeben, inzwischen mit 150+ unterstützenden Organisationen.

UCP vs. ACP – die eigentliche Protokollfrage im Commerce

Das ist die Frage, die mich im Moment am meisten beschäftigt. Die Kollegen bei valantic haben dazu einen lesenswerten Deep-Dive zum Agentic Commerce Protocol veröffentlicht, der die technischen Unterschiede beider Ansätze gut herausarbeitet.

Das Universal Commerce Protocol (UCP) wurde im Januar 2026 auf der NRF von Google und Shopify gemeinsam vorgestellt. Es deckt den kompletten Commerce-Lebenszyklus ab – von Discovery über Checkout bis Post-Purchase-Support. Transport-agnostisch, mit REST-, MCP- und A2A-Bindings. Die Koalition dahinter ist beeindruckend: Walmart, Target, Etsy, Wayfair, Zalando, Mastercard, Visa, Stripe und 20+ weitere Partner.

Universal Commerce Protocol: Checkout Sequenz

Layered Architecture: UCP trennt die Verantwortlichkeiten in Schichten. Der Shopping Service definiert die Grundbausteine (Warenkorb, Status), während Capabilities (Checkout, Catalog, Orders) und Extensions (z. B. spezielle Liefermodelle) flexibel hinzugefügt werden können.
Discovery via /.well-known: Ähnlich wie bei A2A nutzt UCP einen standardisierten Pfad (/.well-known/ucp), über den Agenten die "Fähigkeiten" eines Shops entdecken und aushandeln können, welche Protokollversionen beide Seiten beherrschen.
State-Management: Ein Checkout im UCP durchläuft definierte Zustände: incomplete (fehlende Daten), requires_escalation (Eingriff nötig) und ready_for_complete (bereit zum Abschluss). Dies ermöglicht den nahtlosen Übergang zwischen KI-Automatisierung und menschlicher Interaktion über das Embedded Checkout Protocol (ECP).

Das Agentic Commerce Protocol (ACP) wurde von OpenAI und Stripe entwickelt und trieb ChatGPTs „Instant Checkout" an. OpenAI hat diesen Ansatz Anfang März 2026 jedoch bereits angepasst: Der Checkout-Prozess verlagert sich zunehmend in händlerspezifische „ChatGPT Apps", weil die Komplexität des Handels – dynamische Preise, Echtzeit-Bestände, Steuerregeln – besser in kontrollierten Händler-Umgebungen abgebildet werden kann. Walmart meldete eine 3x schlechtere Conversion als auf walmart.com direkt.

Agentic Commerce Protocol: Checkout Sequenz

Minimalistische Architektur: Das Protokoll beschränkt sich auf die vier Endpunkte Create, Update, Complete und Cancel Checkout, um die Komplexität für Händler gering zu halten.
Shared Payment Token (SPT): Dies ist der entscheidende Sicherheitsmechanismus. Der Agent (z. B. ChatGPT) sieht niemals die echten Kreditkartendaten des Nutzers. Er erhält lediglich einen "selbstzerstörenden", einmaligen Token von Stripe, den er an den Händler weiterreicht.
Merchant of Record: Im ACP-Modell bleibt der Händler der rechtliche Verkäufer ("Merchant of Record") und behält die Kontrolle über die Abwicklung, Steuern und den Kundensupport.
Voraussetzung: Händler müssen ihre Produktkataloge maschinenlesbar (Product Feed) bereitstellen und ihre Checkout-Logik über die ACP-Schnittstellen zugänglich machen.

Strategisch klug aufgestellt sind Stripe und Shopify – beide sind in beiden Lagern vertreten. Das macht sie zu Gewinnern unabhängig vom Ausgang.

AP2 und ANP als Ergänzungen

Googles Agent Payments Protocol (AP2) regelt die kryptographisch abgesicherte Payment-Autorisierung durch Agenten, mit drei abgestuften Autonomie-Levels.

Das AP2 nutzt das Konzept der Verifiable Credentials (VC), um Vertrauen in autonomen Systemen zu schaffen:

Intent Mandate (Absicht): Erteilt dem Agenten den Auftrag, innerhalb bestimmter Leitplanken (z. B. „maximal 150 €“) zu suchen und zu verhandeln. Es dient als Beweis, dass der Agent nicht eigenmächtig handelt.
Cart Mandate (Warenkorb): Dieses Dokument wird vom Händler und vom Nutzer signiert. Es fixiert den Preis und die Artikelmenge, sodass der Agent den Preis während des Checkouts nicht mehr (zuungunsten des Nutzers) verändern kann.
Payment Mandate (Zahlung): Ein minimaler Datensatz, der an die Bank übermittelt wird. Er signalisiert dem Zahlungsnetzwerk, ob der Nutzer gerade anwesend ist (Human-Present) oder ob der Agent eine vorab genehmigte Daueraufgabe ausführt (Human-Not-Present).

Das Agent Network Protocol (ANP) verfolgt den ambitioniertesten Ansatz mit dezentraler Agenten-Entdeckung via W3C DIDs – ist aber ohne starkes Unternehmens-Backing noch deutlich weniger reif.

ANP verfolgt im Gegensatz zu den meist Client-Server-basierten Protokollen wie ACP oder UCP einen radikal dezentralen Peer-to-Peer (P2P) Ansatz. Es wird oft als das „HTTP des Agentic Web“ bezeichnet und setzt konsequent auf Web-Standards wie W3C DIDs (Decentralized Identifiers) und Semantic Web Technologien.

Mandat im ANP Protokoll

Computer Use als pragmatischer Fallback

Für die vielen Websites ohne API-Anbindung bleibt Browser-Automatisierung der Fallback. Claudes Computer Use erreicht inzwischen 72,5 % auf dem OSWorld-Benchmark (von 14,9 % bei Launch). Langsamer und fehleranfälliger als saubere APIs – aber sofort einsetzbar. McKinsey sieht Web-Crawling als Zwischenschritt, bevor Merchants standardisierte Protokolle implementieren.

Wer baut die Infrastruktur?

Shopify hat den größten Vorsprung

Shopify ist der aggressivste Akteur. Seit den Summer '25 Editions hat jeder Shopify-Store einen eigenen MCP-Endpoint (your-store.myshopify.com/api/mcp). Der Shopify Catalog kategorisiert Milliarden von Produkten für KI-Agenten. Agentic Storefronts ermöglichen es Händlern, ihre Markenpräsenz auf ChatGPT, Perplexity, Google Gemini und Microsoft Copilot direkt aus dem Admin zu steuern.

Besonders interessant: Der neue Agentic Plan öffnet den Shopify Catalog explizit für Marken auf Magento, Salesforce Commerce Cloud und Custom-Stacks – ohne Migration. Das ist eine aggressive Einladung an unsere Community.

Google baut den vollständigsten Stack

Google hat: eigene Protokolle (A2A, AP2), gemeinsam mit Shopify entwickelten Commerce-Standard (UCP), 50 Milliarden indexierte Produkte im Shopping Graph, KI-Shopping in AI Mode und Gemini sowie eine neue Enterprise-Plattform mit Kroger, Lowe's und Woolworths als Live-Kunden. Über eine Milliarde Shopping-Interaktionen täglich laufen durch Google-Oberflächen.

Adobe Commerce ist drin – aber noch nicht live

Für unser Ökosystem ist die Situation ehrlich gesagt gemischt. Adobe hat am 18. Februar 2026 offiziell die Unterstützung von UCP, ACP und AP2 angekündigt – aber noch kein Live-Shopping über KI-Plattformen. Während Shopify-Händler bereits über ChatGPT und Gemini verkaufen, baut Adobe seine Grundlagen noch auf.

Adobe nennt dabei beeindruckende Zahlen aus dem Adobe Digital Insights Report vom Januar 2026: KI-Referrals erzielen eine 31 % höhere Konversionsrate, 254 % mehr Umsatz pro Besuch und 45 % längere Verweildauer gegenüber herkömmlichem Traffic.

Adobes Strategie hat drei Säulen:

Discovery Layer mit dem LLM Optimizer (GA seit Oktober 2025) – macht Produktkataloge für KI-Agenten auffindbar
Agent-to-Agent Commerce Layer durch UCP/ACP-Unterstützung (angekündigt, noch nicht live)
Brand-Owned Experience mit dem Adobe Brand Concierge als konversationelle KI-Schicht auf AEP-Profildaten

Der Adobe Commerce Optimizer ist das vielversprechendste neue Produkt: ein eigenständiges Commerce-Frontend auf Edge Delivery Services mit Lighthouse-Score 100, einer GraphQL-Merchandising API für Agents und Frontends sowie einer Data Ingestion REST API. Entscheidend: Es arbeitet mit jedem Commerce-Backend, nicht nur Adobe Commerce.

Die AEP Agent Orchestrator Plattform (GA September 2025) ist das technische Fundament: 10 zweckgebundene KI-Agenten, ein Reasoning Engine, Agent SDK und Agent Registry. Über 70 % der berechtigten AEP-Kunden nutzen bereits den AI Assistant.

Bildquelle: Adobe

Das Magento MCP-Ökosystem lebt

Was mich positiv überrascht hat: Das MCP-Ökosystem rund um Magento ist überraschend lebendig. Neben dem offiziellen Adobe Commerce Extensibility MCP Server (mit RAG-Zugriff auf die gesamte Dokumentation und 7 AI-Agent-Skills) gibt es mindestens 10 Community-Server:

Rafael Corrêa Gomes' GraphQL-basierter Dev MCP (Practice Director bei Valtech)
Mirasvits kommerzieller AI Agent Connector – ermöglicht Befehle wie „Reduziere alle Sommerprodukte, die sich 30 Tage nicht verkauft haben, um 15 %"
Freentos Extension auf dem Adobe Marketplace
Magenable Magento MPC für OpenAI Agent Builder
Magendoos REST- und GraphQL-MCP-Server mit 594 Endpoints und weitere
mage-remote-run MCP - Der Vollständigkeit wegen liste ich hier auch den MCP Server meines eigenen neuen Tools über den mal auch beliebige Shops flexibel andocken kann ohne etwas in dem jeweiligen Shop zu installieren.

Die Community reagiert schnell. Ob das reicht, um mit Shopifys nativem MCP-Endpoint pro Store mitzuhalten – das ist die Frage, die mich treibt.

ACP-Module für Magento 2: Die Community liefert bereits

Parallel zum MCP-Ökosystem entstehen erste Open-Source-Implementierungen des Agentic Commerce Protocol direkt für Magento 2. Zwei Projekte, die ich im Blick habe:

run-as-root/ACP-for-Magento-2 ist das technisch ausgefeilteste der beiden. Das Modul der Würzburger Agentur run_as_root setzt zu 95 % die OpenAI-ACP-Spezifikation um: vollständige Checkout Session API mit fünf Endpunkten, ACP-konformer Product Feed (inkl. Varianten, Gallery-Images, Echtzeit-Inventory), HMAC-Signaturvalidierung, Idempotency-Key-Handling via Redis und Replay-Attack-Schutz. Die Stripe-Integration für Delegated Payments ist dabei, ebenso wie 39 Unit- und Integrationstests.

magebitcom/magento2-agentic-commerce-module kommt von der lettischen Agentur Magebit und bezeichnet sich selbst als erstes öffentlich verfügbares Open-Source-ACP-Modul für Magento 2. Der Funktionsumfang ist ähnlich: ChatGPT-kompatibler Product Feed Export, Instant Checkout, Delegated Payment via Stripe, Webhooks. Wichtig: Das Modul ist Hyva- und Adobe Commerce Cloud-kompatibel – das ist für viele Projekte entscheidend.

Salesforce und Amazon der Vollständigkeit halber

Salesforce hat mit Agentforce Commerce (GA November 2025) über 6.000 bezahlte Deals abgeschlossen. Die KI-gestützte Intent-Aware Search basiert auf einem Commerce-optimierten Small Language Model. Salesforce-eigene Daten: KI-Agenten beeinflussten 17 % ($13,5 Mrd.) der Holiday-Weekend-Bestellungen 2025.

Amazon betreibt mit Rufus (300 Millionen aktive Nutzer, geschätzt 12 Mrd. Dollar inkrementeller Jahresumsatz) und der „Buy for Me"-Funktion ein geschlossenes Ökosystem. Alle OpenAI-Crawler blockiert, nicht in ACP oder UCP integriert. 40 % des US-E-Commerce sind damit für externe KI-Agenten unsichtbar – eine strategische Entscheidung, die Amazon teuer werden könnte.

Stripe als Payment-Schicht beider Welten

Stripe hat mit der Agentic Commerce Suite (Dezember 2025) eine vollständige Lösung: Katalog-Syndizierung, Checkout, Payments und Fraud Detection. Shared Payment Tokens (SPT) – einmal verwendbar, widerrufbar, programmierbar – lösen das Problem, wie Agenten sicher bezahlen können, ohne Zahlungsdaten offenzulegen. Parallel dazu treiben Coinbase und Cloudflare den x402-Standard voran – optimiert für Micropayments im Machine-to-Machine-Bereich. Bis März 2026 wurden darüber bereits 50 Millionen Transaktionen abgewickelt, durchschnittlich 0,20 US-Dollar je Transaktion.

Was der Wandel für PSPs konkret bedeutet, beleuchtet valantic in einem separaten Artikel: Agentic Commerce und Payment Service Provider.

Was Agentic Commerce konkret bedeutet

Im B2C noch in der Frühphase

Amazons „Buy for Me" (Beta seit April 2025), Googles entsprechendes Feature in Gemini, ChatGPT Shopping mit 50 Millionen täglichen Anfragen – die erste Welle läuft. Autonomous Reordering durch IoT-Geräte, Preisvergleichs-Agenten, die dutzende Retailer simultan scannen und beim optimalen Zeitpunkt kaufen – das sind die ersten real nutzbaren Use Cases.

Laut Adobe beeinflussten KI-Agenten in der Weihnachtssaison 2025 bereits 262 Milliarden US-Dollar des globalen Online-Umsatzes. KI-generierte Produktempfehlungen erzielen eine 4,4-fach höhere Konversionsrate als die traditionelle Suche.

Im B2B liegt der eigentliche Hebel

Hier sehe ich das größte Potenzial. Procurement-Agenten überwachen Verbrauchssignale, validieren Vertragspreise und platzieren Orders automatisch unter Budgetlimits. Auf der Verkäuferseite reagiert ein Sales Agent dynamisch, passt Rabatte und Lieferkonditionen an und schließt die Bestellung ab – alles in Sekunden. Gartner prognostiziert bis 2028 ein B2B-Beschaffungsvolumen von 15 Billionen US-Dollar durch KI-vermittelte Einkäufe.

Die unbequemen Fragen: Vertrauen, Haftung, Sichtbarkeit

Was die Adoption bremst, sind nicht die Protokolle – sondern Vertrauen und ungelöste Haftungsfragen.

Eine Riverty/Adyen-Umfrage (1.000 Deutsche, Dezember 2025) zeigt: 50 % würden KI-Agenten maximal 50 Euro pro Monat anvertrauen. 46 % assoziieren KI-Shopping mit Skepsis. 93 % verlangen, KI-Entscheidungen jederzeit einsehen und stoppen zu können.

Die Haftungsfrage ist juristisch ungeklärt. Wer haftet, wenn der Agent falsch kauft? Vermutlich bleibt es am Merchant hängen. Hinzu kommt ein 25 % Anstieg bösartiger Händleraktivitäten im Zusammenhang mit Agentic Commerce (Visa) – Betrüger manipulieren agentische Shopping-Ergebnisse gezielt.

Und dann ist da noch Agent Optimization – der Nachfolger von SEO. Wenn nicht mehr Menschen, sondern KI-Agenten die ersten „Kunden" sind, braucht es maschinenlesbare Produktdaten, strukturierte Kataloge und API-First-Architektur. Creatuity empfiehlt dabei konkret: vollständige Produktattribute (technische Daten, Materialien, Zertifizierungen), GraphQL-Abdeckung (reduziert Payload um 30–50 %) und korrektes Schema.org Markup. Gartner prognostiziert einen 25 % Rückgang des traditionellen Suchvolumens bis 2026. Der KI-getriebene Traffic zu US-Retail-Sites stieg laut Adobe im Juli 2025 um 4.700 % im Jahresvergleich.

Eine zentrale strategische Frage bleibt dabei oft ungestellt: Brauchen wir in Zukunft überhaupt noch eigene Webshops? Die valantic-Kollegen haben das klar eingeordnet: Der Webshop verschwindet nicht, seine Rolle verschiebt sich aber vom zentralen Einstiegspunkt zum Fundament eines vernetzten Vertriebssystems. Wer eine modulare, API-basierte Architektur betreibt, ist klar im Vorteil.

Mein Fazit (bisher)

Agentic Commerce ist weder bloßer Hype noch unmittelbare Revolution – es ist eine fundamentale Infrastruktur-Transformation, deren Nutzung der Technologie um 12–24 Monate hinterherhinkt.

Für das Magento/Adobe-Commerce-Ökosystem sehe ich eine gemischte Lage: Wir haben eine lebendige MCP-Community, reichhaltige APIs und mit dem Commerce Optimizer ein zukunftsfähiges Produkt. Der Rückstand auf Shopifys native Agentic Storefronts ist aber real – und die Community holt aktiv auf, wie die ersten ACP-Module zeigen.

Was ich jedem empfehle, der heute im Commerce-Bereich entwickelt:

MCP-Server für den eigenen Shop evaluieren – ob offiziell, kommerziell oder aus der Community
ACP-Modul testen – Magebit oder run-as-root bieten funktionierende Ausgangspunkte
Strukturierte Produktdaten optimieren – Schema.org, JSON-LD und maschinenlesbare Kataloge sind die Grundlage
Adobe Commerce Optimizer imf Auge behalten – als potenzieller Weg zu Agent-fähigen Storefronts
Shopifys Agentic Plan beobachten – Shopify ist hier vorne und sollte immer im Blick sein. Das gilt auch dann, wenn man selbst nicht auf Shopify setzt.

Die nächsten 12 Monate werden von Low-Consideration-Käufen dominiert sein – Nachbestellungen, Standardprodukte, Commodity-Elektronik. Die wirkliche Disruption im High-Engagement-Commerce kommt später, aber langsamer als die Keynote-Slides vermuten lassen.

API-First ist kein Nice-to-have mehr, sondern existenzkritisch. Wer heute maschinenlesbare, gut dokumentierte APIs betreibt, wird morgen von KI-Agenten gefunden. Wer sich ausschließlich auf menschliche Browser-Interaktion verlässt, wird zunehmend unsichtbar.

Weiterführende Artikel

Das Thema ist breit – hier ein paar Beiträge von direkten Kollegen von mir, die ich empfehle um einen Überblick zu bekommen:

valantic: Agentic Commerce – Interview und Einordnung – Was Agentic Commerce wirklich bedeutet und wo wir heute stehen
valantic: Das Agentic Commerce Protocol im Detail – Technischer Deep-Dive zu ACP und UCP
valantic: Agentic Commerce und Payment Service Provider – Was der Wandel für PSPs und Zahlungsinfrastruktur bedeutet
valantic: Brauchen wir noch eigene Webshops? – Strategische Einordnung der Rolle des eigenen Shops im Zeitalter von KI-Agenten

Stabil vs. Volatil: Wann klassische Automatisierung die bessere Wahl ist – und wann nicht

2026-04-07T07:00:00+00:00

Wer mich kennt, weiß: Ich liebe Automatisierung, die einfach funktioniert. Um ein Prinzip zu verdeutlichen, das mir gerade durch den Kopf geht, habe ich ein kleines Gedankenexperiment in n8n aufgebaut. Es ist ein fiktives Szenario, das aber ein reales Problem moderner Workflows auf den Punkt bringt. Ich habe zwei parallele Wege konstruiert, um nützliche Daten zu generieren.

Auf der einen Seite: Ein simpler Code-Node – mein "Fels in der Brandung". Er tut exakt das, was er soll, jedes Mal gleich, nahezu kostenlos. Auf der anderen Seite: Ein AI-Agent, befeuert durch OpenRouter. Das "kreative Chaos", das Lösungen findet, die man nicht hart codieren kann, aber eben auch eine gewisse Unberechenbarkeit mitbringt.

Mir kamen dann die Begriffe Stabil oben in Grün und Volatil unten in Gelb in den Sinn.

Zwei fiktive Wege in einem n8n Workflow

Das ist keine Wertung. Es ist eine Kategorisierung. Und genau darum geht es mir in diesem Post: Wann greife ich zu welchem Werkzeug – und warum?

Was "stabil" bedeutet

Klassische Automatisierung – also regelbasierte Systeme, Skripte, Code-Nodes, Regex – arbeitet deterministisch. Gleiche Eingabe, gleiches Ergebnis. Immer. Das klingt langweilig, ist aber in vielen Kontexten genau das, was ich brauche.

Nehmen wir ein konkretes Beispiel aus der Forschung: Bei der Extraktion von BI-RADS-Scores aus radiologischen Berichten (Röntgenbilder) wurde Regex direkt mit LLMs verglichen [1]. Die Genauigkeit? Nahezu identisch. Der Unterschied: Regex war 28.120-mal schneller. Nicht ein bisschen schneller. 28.000-mal. Das ist kein akademisches Detail – das ist ein Architektur-Argument.

Stabile Automatisierung ist auch aus Sicht der Betriebskosten attraktiv. Ein Code-Node in n8n kostet mich nichts extra. Ein LLM-Aufruf schon. Und bei jedem Zyklus wieder. Wer Workflows mit hohem Durchsatz betreibt, merkt das am Ende des Monats.

Was klassische Automatisierung braucht: saubere, strukturierte Daten und klar definierte Regeln. Wenn ich weiß, was rein geht und was raus kommen soll, ist ein Code-Node die überlegene Wahl. Keine Überraschungen, keine Halluzinationen, kein Token-Verbrauch.

Was "volatil" bedeutet – und warum das kein Fehler ist

KI ist nicht instabil. KI ist in einer gewissen Weise kreativ (KI im Sinne von Generative KI). Das ist ein wichtiger Unterschied.

Wenn ich einem AI Agent eine Aufgabe gebe, bekomme ich nicht zwingend das identische Ergebnis bei identischer Eingabe. Das klingt nach Nachteil – ist aber oft genau das, was ich brauche. Nämlich dann, wenn:

die Eingabedaten unstrukturiert sind (Freitexte, E-Mails, PDFs ohne Schema)
ich keine vollständigen Regeln definieren kann, weil die Varianz zu groß ist
ich Kontext und Intention verstehen muss, nicht nur Muster matchen

Ein Beispiel: Ich möchte eingehende Support-Anfragen automatisch kategorisieren und priorisieren. Kein Regex der Welt kommt damit klar, wenn Kunden auf zwölf verschiedene Arten schreiben, dass ihr Shop-Login nicht funktioniert. Ein LLM versteht das – auch in holprigem Deutsch, mit Rechtschreibfehlern und ohne klare Struktur.

Das ist die Stärke der volatilen Seite. Kein Regelbuch nötig. Dafür: Laufzeitkosten, potenziell variierende Ergebnisse und – wichtig – höherer Ressourcenverbrauch.

Das Demokratisierungsproblem

Hier wird es interessant – und ehrlich gesagt auch ein bisschen heikel.

KI-Tools haben die Automatisierung demokratisiert. Wer früher einen Entwickler brauchte, um einen Workflow zu bauen, kann heute in n8n einen AI Agent hinwerfen, einen Prompt schreiben und loslegen. Das ist großartig. Im Prinzip.

In der Praxis sehe ich aber immer häufiger, dass Nicht-Techniker – und leider auch manche Dienstleister – AI Agents einsetzen, wo ein einfacher Code-Node die bessere Lösung wäre. Nicht aus Böswilligkeit, sondern weil:

Der AI Agent "einfach funktioniert" – zumindest beim ersten Test
Die Kosten und Konsequenzen erst später sichtbar werden
Das Verständnis fehlt, was unter der Haube passiert

Konkret: Wer eine Bestellbestätigung per E-Mail versendet und dafür einen LLM-Aufruf macht, weil "das KI kann", zahlt sinnlose Token-Kosten für eine Aufgabe, die ein Template mit drei Variablen in Millisekunden löst. Sicher ist das nicht zwingend teuer – aber es skaliert schlecht. Und es ist fehleranfälliger: Was, wenn das Modell mal kreativ wird und den Inhalt der E-Mail leicht variiert?

Noch kritischer wird es bei sicherheitsrelevanten Prozessen. KI-generierter Output ist kein deterministischer Output. Wer das in Berechtigungsprüfungen einbaut, ohne das zu verstehen, baut sich ein Problem auf Vorrat.

Schon im Jahr 2020 haben Kollegen von mir bei einer Studie in Deutschland große Defizite bei Expertise zu KI, Prozessoptimierung und Automatisierung [2] festgestellt. Ob wir jetzt in 2026 viel besser darstehen?

Ressourcen, Kosten, Geschwindigkeit

Ein paar Zahlen, die ich im Hinterkopf behalte:

Ein einfacher Code-Node: nahezu keine Laufzeitkosten, Ausführung in Millisekunden
Ein LLM-Aufruf via API: Token-Kosten, die sich bei hohem Durchsatz summieren – und das nicht linear, sondern kumulativ, weil bei Multi-Turn-Konversationen der gesamte Verlauf mitbezahlt wird
Reasoning-Modelle (die mit explizitem "Thinking"): bis zu 50-facher CO₂-Ausstoß gegenüber kompakten Modellen – für oft marginale Genauigkeitsgewinne [3]

Das bedeutet nicht, KI zu vermeiden. Es bedeutet, bewusst zu wählen. Brauche ich wirklich ein Reasoning-Modell für das Taggen von Blog-Posts? Nein. Reicht ein kleineres, schnelles Modell für die Sentiment-Klassifikation von Kundenbewertungen? Ja, in den meisten Fällen.

In meinem privaten n8n habe ich die Metriken immer im Blick.

Dashboard in Grafana

Die meisten meiner n8n Prozesse sind immer noch klassisch ohne KI oder nur an gewissen Stellen mit KI ergänzt. Es gibt aber auch Workflows die nur auf KI basieren.

Wann ich zur KI muss

Es gibt Aufgaben, bei denen ich mit klassischer Automatisierung schlicht nicht weiterkomme:

Unstrukturierte Eingaben verstehen – Freitexte, OCR-Ergebnisse, gescannte Dokumente
Inhaltliche Bewertung – Ist diese Produktbeschreibung vollständig? Klingt dieser Text professionell?
Kontextabhängige Entscheidungen – Was ist die passende Antwort auf diese Kundenfrage, abhängig von Bestellhistorie und aktuellem Kontext?
Kreative Aufgaben – Texte generieren, variieren, übersetzen, zusammenfassen

Für alles davon gibt es keine Regex. Kein if-else-Baum wächst hoch genug. Hier ist KI nicht die bequeme Option – sie ist die einzig sinnvolle.

Der hybride Weg: Determinismus als Leitplanke

Meine persönliche Architektur-Präferenz sieht so aus: deterministischer Rahmen, KI dort wo nötig [4].

In n8n bedeutet das konkret: Ich prüfe zuerst, ob ich ein Problem regelbasiert lösen kann. Wenn ja, Code-Node. Wenn nein, AI Agent – aber mit klaren Leitplanken: definierten Eingabeformaten, validierten Ausgaben, und einem deterministischen Weiterverarbeitungsschritt danach.

Das Diagramm am Anfang dieses Posts zeigt genau das: Beide Wege laufen in denselben Output. Ich entscheide pro Aufgabe, welcher Pfad sinnvoller ist. Das ist keine Entweder-oder-Frage. Es ist eine Designentscheidung.

Wo steckt bei mir überall KI drin?

Wichtig finde ich auch, dass man seine KI-Prozesse im Blick hat. Auch diese benötigen eine Wartung und müssen immer mal wieder angepasst werden. Gerade, wenn neue Modelle auf den Markt kommen.

In meinen Fall habe ich verschiedene Dashboards in meinen Grafana erstellt. Unter anderem eines, dass mir eine Übersicht der in den n8n Workflows genutzten Modelle und Provider bietet.

Metriken in n8n

Gelöst habe ich das über einen n8n Workflow der mir täglich alle anderen Workflows analyisiert und die Metadaten dann in meiner Postgres Datenbank abgelegt.

Eine weiterer wichtiger Teil ist, dass man seine KI Modelle auch mit Testdaten testet. Dazu gibt es aber bestimmt mal einen eigenen Blog-Post von mir.

Fazit

KI ist kein Allheilmittel – und klassische Automatisierung ist kein Relikt. Beides hat seinen Platz. Die Kunst liegt darin zu erkennen, welches Werkzeug für welche Aufgabe geeignet ist [5].

Was mich bei der aktuellen Entwicklung beschäftigt: Immer mehr Menschen automatisieren, ohne die Implikationen zu verstehen. Das ist erst mal gut – Automatisierung ist wichtig. Aber die Wahl des falschen Werkzeugs produziert Systeme, die teurer, langsamer, fehleranfälliger und schwerer wartbar sind als nötig.

Meine Faustregel: Wenn ich das Problem vollständig beschreiben kann, brauche ich keine KI. Wenn nicht – dann schon.

Literatur

[1] Lacoste et al. (2025): A Comparative Performance Analysis of Regular Expressions and an LLM-Based Approach to Extract the BI-RADS Score from Radiological Reports. medRxiv.
https://www.medrxiv.org/content/10.1101/2025.06.01.25328636v1.full-text

[2] valantic (2020): Exklusive valantic-Studie: Große Defizite bei Expertise zu KI, Prozessoptimierung und Automatisierung
https://www.valantic.com/de/presse/exklusive-valantic-studie-mit-luenendonk/

[3] ScienceDaily (2025): Thinking AI models emit 50x more CO2 — and often for nothing.
https://www.sciencedaily.com/releases/2025/06/250619035520.htm

[4] Elementum AI (2025): Deterministic vs. Probabilistic AI: Enterprise Workflow Guide.
https://www.elementum.ai/blog/deterministic-vs-probabilistic-ai

[5] ECI Software Solutions: AI vs. Automation: Why the Difference Matters for SMB Growth.
https://www.ecisolutions.com/blog/ai-vs-automation-smb-difference/

Claude Desktop unter Linux

2026-03-31T16:12:00+00:00

Ich arbeite seit Jahren auf Fedora. Linux ist für mich kein Experiment, sondern Alltag. Umso mehr hat es mich gestört, dass Anthropic Claude Desktop offiziell nur für macOS und Windows anbietet. Für Linux: Fehlanzeige.

Mein Kollege bei valantic, Patrick Schönfeld, hat das nicht einfach hingenommen. Er ist KI-Experte, Open-Source-Enthusiast – und jemand, der lieber Probleme löst als darüber redet.

Das Ergebnis: claude-desktop-bin

Hier ein Screenshot von meinem Fedora Desktop

Installation: Für jede Distribution

Patrick hat wirklich alle großen Distributionen bedacht. Kein halbgarer Single-Distro-Port.

Arch Linux / Manjaro

yay -S claude-desktop-bin

Updates kommen automatisch über den AUR-Helper – nichts weiter zu tun.

Debian / Ubuntu

Der empfohlene Weg über das APT-Repository bringt automatische Updates mit:

curl -fsSL https://patrickjaja.github.io/claude-desktop-bin/install.sh | sudo bash
sudo apt install claude-desktop-bin

Wer kein fremdes Install-Script ausführen möchte – das ist ein vollkommen legitimer Standpunkt – greift zum .deb direkt von den Releases:

wget https://github.com/patrickjaja/claude-desktop-bin/releases/latest/download/claude-desktop-bin_1.1.5749-1_amd64.deb
sudo dpkg -i claude-desktop-bin_*_amd64.deb

Fedora / RHEL

wget https://github.com/patrickjaja/claude-desktop-bin/releases/latest/download/claude-desktop-bin-1.1.4088-1.x86_64.rpm
sudo dnf install ./claude-desktop-bin-*-1.x86_64.rpm

NixOS

# Ausprobieren ohne Installation
nix run github:patrickjaja/claude-desktop-bin

# Dauerhaft ins Profil
nix profile install github:patrickjaja/claude-desktop-bin

Wer es direkt in die Systemkonfiguration übernehmen will:

{
  inputs.claude-desktop.url = "github:patrickjaja/claude-desktop-bin";

  environment.systemPackages = [
    inputs.claude-desktop.packages.x86_64-linux.default
  ];
}

AppImage (alle anderen)

wget https://github.com/patrickjaja/claude-desktop-bin/releases/latest/download/Claude_Desktop-1.1.5749-x86_64.AppImage
chmod +x Claude_Desktop-*-x86_64.AppImage
./Claude_Desktop-*-x86_64.AppImage

Cowork unter Linux

Cowork ist Anthropics agentic Workspace-Feature – Dateioperationen, Desktop-Automatisierung, Task-Management direkt vom Desktop aus. Auch hier: offiziell kein Linux-Support.

Patrick hat den Windows Service reverse-engineered und unter Linux lauffähig gemacht. Das Projekt: claude-cowork-service

Der Service ist optional. Claude Desktop funktioniert auch ohne Cowork. Wer ihn möchte:

# Schnellinstallation, jede Distribution
curl -fsSL https://raw.githubusercontent.com/patrickjaja/claude-cowork-service/main/scripts/install.sh | bash

# Arch Linux per AUR
yay -S claude-cowork-service
systemctl --user enable --now claude-cowork

Voraussetzung ist die Claude Code CLI – sie muss installiert und im Pfad erreichbar sein. Die Pfade /usr/bin/claude, ~/.local/bin/claude und /usr/local/bin/claude werden automatisch erkannt.

Was dahintersteckt

Das ist kein Quick-Port. Das Paket enthält eine ganze Reihe gezielter Patches, die aus Claude Desktop – einer Electron-App, primär für macOS entwickelt – eine funktionale Linux-Anwendung machen. Tray-Icon-Integration, DBus-Handling, MCP-Server-Support, Computer Use via xdotool und scrot – alles dabei.

Ein automatisierter CI-Job prüft täglich auf neue Claude-Desktop-Versionen, validiert alle Patches in Docker und stellt sicher, dass nur funktionierende Builds ins AUR kommen. Das ist solide Arbeit.

Ein Hinweis für Wayland-Nutzer: Der globale Shortcut (Ctrl+Alt+Space) funktioniert nur unter X11. Wer auf einem Wayland-Compositor unterwegs ist, startet Claude Desktop so:

claude-desktop --ozone-platform=x11

Das lässt sich auch dauerhaft in der .desktop-Datei eintragen.

Fazit

Es ist inzwischen ein bekanntes Muster: Hersteller ignoriert Linux, Community oder engagierte Entwickler wie mein Kollege Patrick übernehmen.

Danke, Patrick – für die Arbeit, die da drin steckt. Das Ergebnis ist wirklich brauchbar.

Habt ihr Claude Desktop unter Linux schon ausprobiert? Auf welcher Distribution läuft es bei euch?

Update 7. April 2026

Ich habe den Text nach Feedbacl von Patrick nochmal angepasst. Bei RPMs und AppImage hatte ich geschrieben, dass es keine automatischen Update gibt. Das war nicht korrekt. Patrick hat auch für diese Installationen ein automatisches Update bereitgestellt.

Rückblick: Magento Stammtisch Stuttgart – Remote dabei mit mage-remote-run

2026-03-27T07:00:00+00:00

Am 25. März 2026 fand der Magento Stammtisch Stuttgart statt – und ich war dabei. Nicht vor Ort, wie ich es mir gewünscht hätte, sondern von zuhause aus. Eine Erkältung hat mir einen Strich durch die Reisepläne gemacht. Zum Glück war eine Remote-Teilnahme möglich, und so konnte ich trotzdem meinen Beitrag über mage-remote-run halten ... ganz schön viel "remote" :-)

Persönlich vor Ort zu sein hat natürlich einen anderen Charakter. Die spontanen Gespräche am Rande, das gemeinsame Abendessen, das Netzwerken beim Getränk in der Hand – das lässt sich nicht durch einen Video-Call ersetzen. Aber die Community hat das unkompliziert möglich gemacht, und dafür bin ich dankbar.

Mein Beitrag: mage-remote-run in der Praxis

Ich habe mage-remote-run vorgestellt – mein Tool für die Remote-Verwaltung von Magento-Instanzen ohne SSH-Zugriff. Gerade in Cloud-nativen Umgebungen wie Adobe Commerce as a Cloud Service oder abgesicherten Kubernetes-Clustern stößt man schnell an Grenzen, wenn man gewohnte Shell-Werkzeuge einsetzen will. mage-remote-run setzt deshalb konsequent auf einen API-first-Ansatz und kommuniziert über HTTPS mit dem Shop.

Die Vorstellung beim Stammtisch gibt es als Video – ich verlinke es hier, sobald es verfügbar ist.

Neu war das Plugin-System in mage-remote-run, dass ich erstmals beim Stammtisch vorstellen konnte.

MageForge: Ein Build-Tool für Frontend-Entwickler

Mathias Elle, Magento- und Hyvä-Frontend-Experte, hat zusammen mit Thomas Hauschild an MageForge gearbeitet und beim Stammtisch vorgestellt, was dahintersteckt. MageForge ist ein Tool, das speziell auf die Bedürfnisse von Frontend-Entwicklern im Magento-Ökosystem ausgelegt ist – mit dem Fokus auf Build-Prozesse.

Wer schon mal mit Hyvä gearbeitet hat, weiß, dass der Frontend-Stack dort deutlich moderner ist als im klassischen Magento. Genau da setzt MageForge an: Es soll die Build-Workflows vereinfachen und beschleunigen, ohne dass man tief in die Konfigurationsdetails einsteigen muss. Ich bin gespannt, wie sich das Tool weiterentwickelt – das ist genau die Art von pragmatischer Tooling-Arbeit, die der Community gut tut.

Auch in einer CI/CD Pipeline oder beim Reparieren von kaputten Frontend-Setups kann das Tool gute Dienste leisten.

Beeindrucken ist auch, dass es auf dem höchsten PhpStan-Level getestet wurde.
Weil es so gut ist, wird es in der nächsten n98-magerun2 Version ein neues Kommando mageforge:install geben damit ihr es schnell in euer Magento System installieren könnt.

Claude-AI-Benchmarks: Wie sehr machen Regeln den Unterschied?

Anton Gudkov, Magento-zertifizierter Entwickler, hat sich mit einem Thema beschäftigt, das mich ebenfalls intensiv begleitet: dem Einsatz von Claude-AI-Modellen in der Entwicklung. Kudos auch dafür, dass er beim Stammtisch seinen ersten Vortrag hielt. Sein Fokus lag auf einem konkreten und spannenden Aspekt – dem Benchmark unterschiedlicher Einstellungen und Regelwerke.

Die Kernfrage: Wie stark beeinflussen die Konfiguration und die definierten Regeln das Ergebnis, das ein Modell wie Claude liefert? Das ist etwas, was in der Praxis oft unterschätzt wird. Man gibt dem Modell einen Prompt, bekommt eine Antwort – und denkt wenig darüber nach, was passiert, wenn man die Rahmenbedingungen systematisch variiert. Anton hat genau das gemacht und die Ergebnisse verglichen.

Mein Fazit (aus der Ferne): Das ist wertvolle Arbeit. Gerade wenn man KI-Modelle in bestehende Entwicklungsprozesse integriert, lohnt es sich, diese Stellschrauben zu verstehen – und nicht einfach mit den Standardeinstellungen zu leben.

Ich hoffe, beim nächsten Mal persönlich dabei zu sein. Stuttgart wäre es wert gewesen. Danke an Phoenix Media für die wie immer tolle Orga.

mage-remote-run

2026-02-07T18:52:00+00:00

Wer in den letzten 15 Jahren im Magento-Ökosystem unterwegs war, kenn mich eventuell durch das Tool n98-magerun. Es ist das „Schweizer Taschenmesser“ der Magento Entwickler und Administratoren der direkt auf dem Server oder in seiner lokalen Umgebung arbeitet. Aber die Welt des E-Commerce-Hostings hat sich massiv weiterentwickelt.

Mit dem Aufstieg von Cloud-native Architekturen stehen wir heute oft vor einer ganz neuen Herausforderung: Wir stehen vor einer verschlossenen Tür.

Die Absicht: Wenn die Shell zur Sackgasse wird

Mein Ziel mit n98-magerun2 war es immer, Entwicklern maximale Effizienz auf der Konsole zu ermöglichen. Doch in modernen Umgebungen wie Adobe Commerce as a Cloud Service (SaaS) oder hochgradig abgesicherten Kubernetes-Clustern gibt es oft schlichtweg keinen SSH-Zugriff mehr. Security-Policies und Compliance-Vorgaben verhindern den direkten Weg auf den Server oder die Datenbank.

Hier entstand die Idee für mage-remote-run. Die Absicht war nicht, n98-magerun2 zu ersetzen – für die lokale Arbeit mit Tools wie DDEV bleibt es unersetzlich da es direkt im System arbeiten kann. Die Vision war vielmehr, ein Werkzeug zu schaffen, das auch per Remote funktioniert. Es sollte mit allen meinen Magento-Instanzen arbeiten. Es sollte ohne große Einrichtung funktionieren.

Die Idee: API-first statt Shell-first

Mage Remote Run verfolgt einen radikalen API-first Ansatz. Anstatt zu versuchen, Code innerhalb der Infrastruktur auszuführen, kommuniziert das Tool von außen über standardisierte HTTPS- und REST-Schnittstellen mit dem Shop.

Das Kernkonzept basiert auf drei Säulen:

Remote-First Management: Volle Kontrolle über Produkte, Bestellungen und Systemkonfigurationen, ganz ohne Shell-Zugriff.
Plattform-Agnostisch: Es ist egal, ob die Instanz in der Adobe Commerce Cloud als SaaS oder PaaS, bei einem spezialisierten Hoster mit Magento Open Source oder als Mage-OS Instanz läuft.
Moderne Distribution: Als Node.js-basiertes Tool ist es entkoppelt von der lokalen PHP-Umgebung und lässt sich nahtlos in moderne Workflows integrieren.
Mehrer Instanzen verwalten: Es lassen sich Connections zu mehreren Instanzen konfigurieren.

Hat das nicht einen Haken?

Das Konzept hat nur einen Haken. Es ist auf die Möglichkeiten der API beschränkt. Bietet die API eine Funktion nicht an, dann kann ich diese auch nicht aufrufen.
Mit dem Aufkommen einer reinen SaaS Lösung wie Adobe Commerce as a Cloud Service ist es aber per se nicht mehr möglich am Backend-Code Änderungen direkt vorzunehmen. Daher muss Adobe hier selbst schauen, dass man möglichst viele Funktionen per API abdeckt.

Bei der PaaS Variante oder bei On-Premises Systemen kann die API natürlich auch weiterhin erweitert werden. Spezielle selbst angelegte Endpunkte kennt das Tool nicht unebdingt.
Für diesen Fall habe ich ein generisches "rest" Kommando angelegt über das man sehr einfach beliebige Endpunkte mit der aktuell konfigurierten Verbindung ansteuern kann.

Premiere beim Adobe Commerce APAC User Group Event

Ich freue mich besonders, dass ich die Gelegenheit hatte, Mage Remote Run erstmals offiziell im Rahmen der Adobe Commerce APAC User Group am 5. Februar 2026 vorzustellen. Unter dem Titel „Architecting Remote Operations“ konnte ich der Community zeigen, wie wir die Lücke zwischen lokaler Developer Experience und restriktiven Cloud-Umgebungen schließen.

Das Video der Session mit der kompletten Live-Demo findet ihr hier eingebettet:

Im Video gehe ich auch auf den einen oder anderen Use-Case ein und zeige auch wie man mit dem Tool Produkte importieren kann oder es in einer GitHub Action verwendet.

Ein Blick in die Zukunft: KI und MCP

Ein zentraler Bestandteil meiner Vision ist die Vorbereitung auf eine Welt, in der wir Systeme nicht nur über manuelle Befehle steuern. Durch die Unterstützung des Model Context Protocol (MCP) ist Mage Remote Run bereits „AI-Ready“. Es erlaubt KI-Agenten, sicher auf Shop-Daten zuzugreifen und administrative Aufgaben durch natürliche Sprache zu lösen. Generell ist die Funktion aber noch mit Vorsicht zu nutzen. Es gibt bisher auch keine Möglichkeit die Funktion auf rein lesende Kommandos einzuschränken.

Beispiel:

mage-remote-run rest V1/products -m GET --page-size 1 --current-page 1 --format json

Du willst auch mal testen?

Für die Ausführung des Tools wird nur eine einigermaßen neue NodeJS Installation benötigt. Ist diese vorhanden, dann kann man es sehr einfach nutzen.

npm install -g mage-remote-run

Oder Sandboxed:

npx mage-remote-run

Eine Dokumentation findet man hier: https://mage-remote-run.muench.dev

Viel Spaß beim ausprobieren!

OpenCode: Kann viel und macht dich unabhängiger

2026-01-20T11:05:00+00:00

In den letzten Monaten habe ich viel über die Entwicklung von KI-Agenten und die Bedeutung von Standards wie dem Model Context Protocol (MCP) geschrieben. Wer mich kennt, weiß, dass ich immer auf der Suche nach Tools bin, die nicht nur mächtig, sondern auch flexibel und offen sind. Nach dem Testen zahlreicher Agenten bin ich bei OpenCode hängen geblieben. Warum? Weil es genau die Unabhängigkeit bietet, die in der aktuellen KI-Landschaft oft fehlt.

Warum OpenCode? Freiheit durch Open Source

Der Hauptgrund für meinen Wechsel zu OpenCode ist die Philosophie hinter dem Projekt. Das Tool steht unter der MIT-Lizenz direkt auf GitHub, was es zu einer echten Open-Source-Alternative in einem Markt voller proprietärer "Black Boxes" macht.

In einer Zeit, in der man sich schnell an einen einzigen Provider bindet, bietet OpenCode eine beeindruckende Breite an unterstützten Providern. Ob OpenAI Codex, GitHub Copilot oder Google – man ist nicht mehr auf das Wohlwollen eines einzelnen Herstellers angewiesen. Besonders spannend: Man kann mehrere Provider gleichzeitig konfigurieren. Wenn das Quota bei einem Dienst aufgebraucht ist, wechselt man einfach zum nächsten. Auch lokale Instanzen über Ollama lassen sich problemlos einbinden, was ich bereits in meinem n8n-Agenten-Setup als großen Vorteil für den Datenschutz und die Kostenkontrolle hervorgehoben habe.

Nicht verschweigen möchte ich aber, dass es zuletzt Probleme bei der Nutzung von Claude-Code gab. Antrophic möchte es nicht mehr sehen, dass man andere CLI Tools als das eigene nutzt.

Siehe dazu auch: YouTube: What's going on with Claude Code and OpenCode?

OpenAI nutzte diesen Umstand dann direkt um ausdrücklich hinzuweisen, dass man OpenCode auf jeden Fall toll findet und natürlich unterstützt. Da ist schon ein wenig Politik im Spiel. Es zeigt aber auch, dass man sich um die Unabhängigkeit des eigenen Tool-Stacks auch Gedanken machen sollte.

Was, wenn auf aus politischen Gründen die Nutzung des einen odere anderen Modells nicht mehr möglich ist? Dann will ich eben nicht meine komplette Umgebung auf ein anderes Tool mit Vendor-Lock umstellen. Genau hier gibt mir OpenCode eine gewisse Sicherheit.

Ein Paradies für Entwickler: TUI, LSP, Skills, ...

OpenCode ist von Entwicklern für Entwickler gebaut. Das merkt man an jeder Ecke – angefangen bei der schicken TUI (Terminal User Interface).

Die Benutzeroberfläche (TUI)

Die TUI bietet alles, was man für einen effizienten Workflow braucht:

Themes & Konfiguration: Alles lässt sich bis ins kleinste Detail anpassen und sogar pro Projekt überschreiben.
Sidebars & Status: Wichtige Informationen und der Status des aktuellen Modells sind immer im Blick.
Shortcuts: Mit schnellen Tastenkombinationen wechselt man das Modell oder prüft den Status.
Slash-Commands: Ähnlich wie in Mattermost lassen sich Aufgaben über Slash-Commands steuern. Dank eines eigenen SDKs kann man sogar eigene Kommandos und Plugins entwickeln.

Technische Integration

Ein KI-Agent ist nur so gut wie sein Verständnis vom Code. OpenCode nutzt Language Server (LSP) und spezifische Formatter der jeweiligen Programmiersprachen, um eine präzise Code-Analyse und -Manipulation zu gewährleisten. Zudem werden Agent Skills unterstützt (via agentskills.io), um lokal leichtgewichtige Tools zu bauen, ohne direkt einen kompletten MCP-Server aufsetzen zu müssen.

Aber keine Sorge: MCP wird natürlich ebenfalls voll unterstützt.

Architektur: Flexibilität in jeder Umgebung

In meinem Beitrag über monolithische vs. verteilte Agenten habe ich die Vor- und Nachteile verschiedener Strukturen diskutiert. OpenCode schlägt hier eine interessante Brücke:

Sub-Agents: Man kann Agenten mit spezialisierten Sub-Agenten erstellen und in der TUI einfach mit der Tab-Taste zwischen ihnen wechseln.
Parallel Sessions: Mehrere Aufgaben gleichzeitig bearbeiten? Kein Problem.
Headless & Web Mode: Besonders praktisch ist der Headless-Modus für Umgebungen, in denen man auf Datenbanken oder Systeme zugreifen muss, die nicht direkt erreichbar sind. Alternativ lässt sich OpenCode als Webserver starten, um direkt im Browser zu arbeiten.
IDE-Support: Wer lieber in seiner gewohnten Umgebung bleibt, findet immer mehr Plugins für gängige IDEs. Auch die Integration in andere Tools wie Maestro oder der Support für ACP sind vorhanden. Ich setze da persönlich mehr auf die CLI.

Installation: In Sekunden startklar

Die Installation ist denkbar einfach und unterstützt so ziemlich jeden gängigen Paketmanager. Mein Favorit ist die Installation via NPM, aber es gibt viele Wege zum Ziel:

# Über NPM (oder bun/pnpm/yarn)
npm i -g opencode-ai@latest

# macOS & Linux (empfohlen via brew)
brew install anomalyco/tap/opencode

# Windows (via Scoop oder Choco)
scoop install extras/opencode
choco install opencode

# Arch Linux
paru -S opencode-bin

Ein kleiner Tipp für den Start: Mit dem Kommando opencode debug lässt sich die aktuelle Konfiguration inklusive MCP-Servern und Skills überprüfen. Das spart enorm viel Zeit bei der Fehlersuche.

Mein Fazit (bisher)

Die Arbeit mit OpenCode macht einfach Spaß. Es ist aktiv, die Community ist engagiert und die Dokumentation lässt kaum Fragen offen. Es ist das "Schweizer Taschenmesser" für KI-gestütztes Coding, das genau die Flexibilität bietet, die ich mir für meine Infrastruktur wünsche.

Was haltet ihr von Open-Source-Agenten?

Tech-Trends 2026: Wenn die KI den Bildschirm verlässt und zum Kollegen wird

2025-12-14T14:00:00+00:00

Wenn wir uns die Entwicklung der letzten zwei Jahre ansehen, fühlen wir uns oft wie in einem Schnellzug, der kaum an Bahnhöfen hält. Doch basierend auf aktuellen Analysen und Beobachtungen zeichnet sich für das Jahr 2026 ein fundamentaler Wandel ab: Wir verlassen die Phase des reinen Experimentierens ("Wow, ChatGPT kann dichten!") und treten in die Phase der operativen Wertschöpfung ein.

Der gemeinsame Nenner für 2026 ist Autonomie – und zwar nicht mehr nur digital auf unseren Bildschirmen, sondern zunehmend auch physisch in unserer echten Welt. Schauen wir uns im Detail an, was das für uns als Entwickler, E-Commerce-Experten und Data Scientists bedeutet.

Physical AI: Die Intelligenz bekommt einen Körper

Ein entscheidender Wendepunkt für 2026 ist der Aufstieg der "Physical AI". Während wir bisher KI vor allem als Chatbot oder Bildgenerator kannten, verlässt die Intelligenz nun den Bildschirm und manifestiert sich in der physischen Welt. Es ist die Konvergenz von fortschrittlicher KI mit Hardware – von Industrierobotern bis hin zu Consumer-Geräten.

Verkörperte Intelligenz statt starrer Programmierung

Roboter entwickeln sich von "dummen" Automaten, die stur programmierten Pfaden folgen, zu intelligenten Akteuren. Dank fortschrittlicher Modelle nehmen sie ihre Umgebung über Sensoren wahr und treffen autonom Entscheidungen. Wir sprechen hier von verkörperter Intelligenz: Roboter agieren nicht mehr nur als Werkzeuge, sondern als autonome Agenten, die reale Probleme lösen.

(Bildquelle: Google AI)

Ein Beispiel hierfür ist Amazons "DeepFleet"-KI, die riesige Roboterflotten koordiniert, oder BMW-Fabriken, in denen Fahrzeuge selbstständig durch die Produktion navigieren. Es geht um "Vision-Guided Assembly", bei dem Systeme in Echtzeit auf Abweichungen reagieren, anstatt bei jedem Fehler stehenzubleiben.

Die Ära der kollaborativen Automatisierung

Die alte Angst vor der Verdrängung durch Maschinen weicht 2026 dem Konzept der Mensch-Maschine-Teams. Wir sehen den Aufstieg der "kollaborativen Automatisierung":

Aufgabenteilung: Roboter (Cobots) übernehmen routinemäßige, gefährliche oder schwere Aufgaben.
Fokus Mensch: Wir Menschen konzentrieren uns auf Strategie, Kreativität und komplexe Kundenbeziehungen.
Sicherheit: Ein enormer Fokus liegt auf "Fail-Safes", damit diese autonomen Systeme sicher Seite an Seite mit uns arbeiten können.

Revolution in Logistik und neuen Branchen

Die Auswirkungen sind branchenübergreifend spürbar:

Logistik & Lagerhaltung: Autonome Mobile Roboter (AMRs) werden zum Standard in Verteilzentren. Sie bringen Artikel direkt zu den Kommissionierern und reduzieren Leerlaufzeiten drastisch. Gesteuert werden diese Flotten direkt durch E-Commerce-Daten, um Millionen von Bestellungen zu sortieren.
Phygital B2B: Im B2B-Handel verschmelzen physische und digitale Welt. Roboter bestücken beispielsweise Smart Locker, damit Handwerker ihre Bestellungen rund um die Uhr abholen können.
Landwirtschaft: Autonome Drohnen überwachen Felder und sprühen Pestizide nur dort, wo es wirklich nötig ist, was Erträge steigert und die Umwelt schont.
Energie: Drohnen inspizieren Windkraftanlagen oder Stromleitungen, um Risiken für Menschen zu minimieren und Fehler früher zu erkennen.

Technischer Enabler: Damit das alles in Echtzeit funktioniert, verlagert sich die Rechenleistung via Edge AI direkt in die Geräte. Hier gewinnt die Programmiersprache Rust enorm an Bedeutung, da sie die nötige Speichersicherheit und Performance für diese kritischen Systeme liefert.

IoT 2026: Vom Sensornetz zum autonomen Nervensystem (AIoT)

Im Jahr 2026 ist das Internet of Things kein loses Netzwerk vernetzter Sensoren mehr. IoT verschmilzt vollständig mit künstlicher Intelligenz zur AIoT oder Physical AI. Geräte sammeln nicht mehr nur Daten, sondern treffen autonome Entscheidungen direkt am Entstehungsort (Edge).

Von Datensammlung zu Handlung: Zero-Click & Autonomous Commerce

IoT-Systeme werden zu aktiven Marktteilnehmern:

Autonome Nachbestellung (B2B): Sensoren in Lagern, Maschinen oder Produktionslinien überwachen Füllstände und Verschleiß und lösen bei Bedarf automatisch Bestellungen über Commerce-APIs aus – ohne menschliches Eingreifen. Das senkt Lagerkosten und verhindert Produktionsstillstände.
Predictive Maintenance 2.0: KI interpretiert kontinuierlich strukturierte und unstrukturierte Sensordaten, um Ausfälle vorherzusagen, bevor sie auftreten. In Branchen wie Energieversorgung oder Industrie werden manuelle Prüfungen dadurch weitgehend überflüssig.

Edge AI, TinyML & Distributed MLOps

Die Cloud verliert ihre Monopolstellung:

Edge AI & TinyML: Modelle werden so optimiert, dass sie auf ressourcenbeschränkten Geräten laufen. Das reduziert Latenz, spart Bandbreite und verbessert Datenschutz, da Daten das Gerät nicht verlassen müssen.
Distributed MLOps: Deployment, Updates und Monitoring von Modellen erfolgen verteilt über Tausende oder Millionen Geräte.
Rust als Schlüsseltechnologie: Für Embedded- und IoT-Systeme etabliert sich Rust als bevorzugte Sprache, da sie Performance mit hoher Speichersicherheit verbindet.

Expansion der Physical AI: Robotik & Drohnen

IoT wird mobil und autonom:

Branchenübergreifende Autonomie: IoT-gesteuerte Roboter und Drohnen übernehmen Inspektionen, Transporte oder Feldanalysen selbstständig – von Logistik über Landwirtschaft bis Gesundheitswesen.
Lagerhaus-Automatisierung: Flotten aus AGVs und AMRs, gesteuert durch IoT- und Echtzeitdaten, werden zum Standard, um Arbeitskräftemangel und steigende Bestellvolumina abzufedern.

Hardware- und Energiegrenzen

Der Ausbau von AIoT trifft auf physische Limits:

Legacy-Chip-Mangel: Besonders ältere Chiptechnologien (>90 nm), essenziell für IoT-Geräte und Industrieanlagen, geraten unter Druck – ein Risiko für Skalierung und Verfügbarkeit.
Energieeffizienz: Energy-Efficient Computing wird zur Pflicht. Neuromorphe Ansätze und spezialisierte Inference-Chips adressieren den steigenden Strombedarf.

Sicherheit & Sovereign AI im IoT

Da IoT zunehmend kritische Prozesse steuert, wird Sicherheit zur Systemfrage:

Sovereign AI: IoT-Daten und Modelle müssen lokal verarbeitet werden (Data Residency), um regulatorische und geopolitische Risiken zu minimieren.
Preemptive Cybersecurity: KI-basierte Sicherheitssysteme erkennen Angriffe prädiktiv, bevor sie Schaden anrichten können.

Kurz gesagt: IoT ist 2026 das Nervensystem autonomer Agenten. Es liefert nicht nur Daten, sondern führt physische Aktionen wie Bestellungen, Wartungen oder Transporte selbstständig direkt am Gerät aus.

Consumer Hardware: Von Training zu Inference im Alltag

Ein oft unterschätzter, aber zentraler Trend für 2026 ist der Wandel in der Consumer-Hardware. Während in den letzten Jahren vor allem Chips für das Training großer KI-Modelle im Fokus standen, verschiebt sich die Nachfrage nun deutlich in Richtung Inference – also die effiziente Anwendung von KI im Alltag.

Von Trainings-Chips zu Inference-Maschinen

Für Endgeräte zählt nicht maximale Rechenleistung um jeden Preis, sondern Energieeffizienz, geringe Latenz und Verfügbarkeit in Echtzeit. KI-Antworten müssen sofort kommen – ohne Roundtrip in die Cloud. Das führt zu einer neuen Generation von Chips, die speziell für Inference optimiert sind und KI-Funktionen permanent im Hintergrund ausführen können.

On-Device AI als Standard

Unternehmen wie z.B. Qualcomm treiben diese Entwicklung massiv voran. "On-Device AI" bedeutet, dass KI direkt auf Smartphones, Laptops oder Wearables läuft – auch offline. Das bringt mehrere Vorteile:

Datenschutz: Sensible Daten verlassen das Gerät nicht.
Kostenkontrolle: Weniger Cloud-Inference reduziert laufende Betriebskosten.
Performance: Sprach-, Bild- oder Gestenerkennung reagieren ohne spürbare Verzögerung.

Diese Entwicklung ist der Schlüssel dafür, dass KI tatsächlich zum unsichtbaren Alltagsbegleiter wird – und nicht nur zur Cloud-API.

Energieeffizientes Computing als Innovationsfeld

Gleichzeitig wächst der Druck, den Energiehunger der IT einzudämmen. Neben klassischen Chip-Optimierungen entstehen neue Paradigmen:

Optisches Computing: Rechenoperationen mit Licht versprechen drastisch geringeren Energieverbrauch bei bestimmten Workloads.
Neuromorphe Systeme: Chips, die das menschliche Gehirn nachahmen, arbeiten ereignisbasiert statt taktbasiert – ideal für Sensorik, Mustererkennung und Edge-Anwendungen.

Auch wenn diese Technologien 2026 noch nicht flächendeckend im Consumer-Markt ankommen, markieren sie die Richtung für die nächste Dekade.

Das Smartphone als biometrische Festung

Im Mobile Commerce und bei digitalen Identitäten wird das Smartphone 2026 zur zentralen Sicherheitsinstanz. Hardware übernimmt dabei Aufgaben, die früher durch Passwörter und manuelle Prüfungen gelöst wurden.

Biometrische Standards: Fingerabdruck- und Gesichtserkennung werden zur Grundvoraussetzung für reibungslose Wallet-First-Bezahlvorgänge und Logins. Passwörter und manuelle Karteneingaben verschwinden zunehmend aus dem Alltag.
Real-World Object Detection: Verbesserte Kameras, LiDAR- und Tiefensensoren ermöglichen es Smartphones, reale Objekte präzise zu erkennen und digitale Inhalte exakt in die physische Umgebung einzubetten.

Für den Handel bedeutet das: Authentifizierung, Zahlung und Kontext verschmelzen zu einem einzigen, hardware-gestützten Prozess.

Smart Home & Connected Devices

Auch im häuslichen Umfeld wird Hardware zum natürlichen Interface zwischen Mensch und digitalem Handel.

Voice Commerce: Smarte Lautsprecher, Wearables und vernetzte Haushaltsgeräte entwickeln sich zu aktiven Einkaufsassistenten. Bestellungen erfolgen kontextbasiert per Sprache – ohne App, ohne Bildschirm, mit minimalen Interaktionsschritten.

Zusammengefasst lässt sich sagen: Consumer-Hardware im Jahr 2026 wird definiert durch KI-Spezialisierung (Inference-Chips), Autonomie und natürliche Interaktion über Biometrie, Sprache und räumliches Verständnis.
Gleichzeitig wächst der Druck, den Energiehunger der IT einzudämmen. Neben klassischen Chip-Optimierungen entstehen neue Paradigmen:

Optisches Computing: Rechenoperationen mit Licht versprechen drastisch geringeren Energieverbrauch bei bestimmten Workloads.
Neuromorphe Systeme: Chips, die das menschliche Gehirn nachahmen, arbeiten ereignisbasiert statt taktbasiert – ideal für Sensorik, Mustererkennung und Edge-Anwendungen.

Auch wenn diese Technologien 2026 noch nicht flächendeckend im Consumer-Markt ankommen, markieren sie die Richtung für die nächste Dekade.

AR & VR: Die Schnittstelle zwischen digitaler und physischer Welt

AR und VR erreichen 2026 einen Reifegrad, der sie erstmals breit einsetzbar macht – auch jenseits von Gaming und Marketing-Demos.

Neue Interaktionsformen

Die Interaktion löst sich von klassischen Controllern:

Gesten- und Blicksteuerung
Kopfbewegungen
Natürliche Sprachbefehle

Dadurch wird AR/VR intuitiver und inklusiver – und gleichzeitig enger mit KI-Systemen verzahnt, die Kontext und Absicht verstehen.

Shopping & E-Commerce neu gedacht

Für den (B2B- und B2C-)Handel ergeben sich konkrete Anwendungsfälle:

Virtual Try-Ons: Kleidung, Brillen oder Schutzkleidung werden realistisch am eigenen Körper visualisiert.
In-Home-Visualisierung: Möbel oder Maschinen lassen sich maßstabsgetreu im eigenen Raum platzieren.
Beratung in Echtzeit: KI-gestützte Assistenten begleiten Nutzer durch immersive Einkaufserlebnisse.

AR/VR wird damit nicht zum Gimmick, sondern zur verkaufsrelevanten Schnittstelle zwischen Produktdaten, Raum und Kunde.

Siehe auch E-commerce Trends 2026: 10 Insights for the Future of Online Shopping

Die Hardware-Krise 2026: Engpässe, Energie und Geopolitik

Neben all diesen Innovationen zeichnet sich für 2026 eine strukturelle Hardware-Krise ab – allerdings nicht als eindimensionaler Mangel, sondern als komplexes Zusammenspiel aus falschen Investitionsanreizen, Energieknappheit und geopolitischen Risiken.

Die Zwei-Klassen-Krise bei Chips

Die Krise wird weniger durch fehlende High-End-KI-Chips bestimmt, sondern durch einen Mangel an sogenannten Legacy-Chips.

Alltagstechnik unter Druck: Während massiv in modernste Fertigung für KI und Smartphones investiert wurde, blieb die Produktion reifer Technologien (über 90 nm) zurück – genau jener Chips, die Autos, Haushaltsgeräte und Medizintechnik benötigen.
Konsequenzen: Produktionsstopps in der Automobilindustrie werden wahrscheinlicher. Ein weltweiter Rückgang der Fahrzeugproduktion um bis zu 20 % gilt als realistisches Szenario, mit längeren Lieferzeiten und steigenden Preisen für Endkunden.

Energie als neuer Flaschenhals

Die Hardware-Krise wird zunehmend zu einer Energie-Krise.

AI Factories: Der massive Ausbau von Rechenzentren treibt den Strombedarf auf ein neues Niveau.
Kosten & Knappheit: Verfügbarkeit und Preis von Elektrizität werden zum limitierenden Faktor für Wachstum.
Gegenmaßnahmen: Unternehmen sind gezwungen, KI-Berechnungen zeitlich zu verschieben – etwa durch Carbon Scheduling, bei dem Inference dann läuft, wenn Energie verfügbar oder günstig ist.

Geopolitische Unsicherheit als Preistreiber

Die Abhängigkeit von globalen Lieferketten bleibt kritisch:

Asien-Abhängigkeit: Ein Großteil der Unternehmen sieht geopolitische Spannungen rund um Taiwan als ernsthafte Bedrohung für die Versorgung mit Halbleitern.
Preissteigerungen: Bereits heute sind die meisten Unternehmen mit steigenden Chippreisen konfrontiert – Kosten, die an Endkunden weitergereicht werden.

Lieferverzögerungen als neues Normal

Selbst ohne Eskalation bleibt die Lage angespannt:

Durchschnittliche Verzögerung: Etwa vier Monate Lieferzeit für Halbleiter gelten als normal.
Planungsunsicherheit: Ein signifikanter Teil der Unternehmen stuft die Versorgungslage für 2026 als kritisch ein.

Essenz: Die Krise entsteht nicht, weil es keine Technologie gibt, sondern weil lange Zeit die falsche priorisiert wurde. Das verstärkt den politischen und wirtschaftlichen Fokus auf Energieinfrastruktur, Resilienz und souveräne Lieferketten.

Green AI: Nachhaltigkeit als Architektur-Entscheidung

Das Thema Nachhaltigkeit wird 2026 von einer spannenden Dualität geprägt sein. Wir stehen vor der Herausforderung, den enormen Energiehunger der KI selbst zu bewältigen (Green AI) und gleichzeitig KI als Werkzeug zu nutzen, um nachhaltiger zu werden (AI for Sustainability).

Die Balance: Green MLOps & Carbon Scheduling

Nachhaltigkeit wird fester Bestandteil von Machine Learning Operations (MLOps). Wir Entwickler optimieren nicht mehr nur auf Genauigkeit eines Modells, sondern suchen den Trade-off zwischen Performance, Kosten und dem CO2-Fußabdruck. Grüne Metriken werden zu zentralen KPIs.

Ein großes Thema wird Carbon Scheduling: KI-Workloads werden zeitlich so gesteuert, dass sie dann laufen, wenn viel erneuerbare Energie im Stromnetz verfügbar ist oder der Strom günstig ist. Da Energieverfügbarkeit zum Engpass für Rechenzentren werden kann, werden Unternehmen gezwungen sein, ihre Energiequellen zu diversifizieren.

Daten für die Kreislaufwirtschaft

KI wird zum Treiber für echten Geschäftswert durch Nachhaltigkeit.

Scope 3 Transparenz: Da Nachhaltigkeitsdaten faktisch Geschäftsdaten sind, nutzen Unternehmen KI, um die komplexen indirekten Emissionen entlang der gesamten Lieferkette (Scope 3) nachzuverfolgen. (Siehe hier auch https://www.scope3transparent.de)
Digitaler Produktpass: Regulatorische Anforderungen zwingen CSOs (Sustainability Officers) und CDOs (Data Officers) zur engen Zusammenarbeit, um die Datenflut für Produktpässe zu bewältigen.
Wettbewerbsvorteil: Im B2B-E-Commerce wird Transparenz über den CO2-Fußabdruck oder die Materialherkunft zur echten Wettbewerbswaffe. Wer diese Daten transparent liefert, gewinnt Aufträge.

Um den sogenannten Rebound-Effekt zu vermeiden – bei dem effizientere KI einfach zu noch mehr Nutzung führt – werden Unternehmen strengere Regeln für die Nutzung von KI-Tokens einführen. KI-Rechenleistung wird nur genehmigt, wenn ein signifikanter geschäftlicher Mehrwert nachweisbar ist.

E-Commerce Trends 2026: Autonomie, Plattformen und Datenhoheit

Der E-Commerce tritt 2026 in eine neue Reifephase ein. Weniger manuelles Shopping, mehr Automatisierung, Autonomie und System-Intelligenz prägen den Markt. Gleichzeitig entsteht ein deutlicher Gegentrend: der Wunsch nach Kontrolle über Daten, Kosten und Infrastruktur.

Agentic Commerce: Wenn Bots einkaufen

Der radikalste Wandel ist der Übergang vom klassischen "Click & Buy" hin zu Agentic Commerce. KI-Agenten handeln im Auftrag von Konsumenten und Unternehmen:

Sie suchen Produkte, vergleichen Angebote und schließen Käufe autonom ab.
Im B2B-Bereich treten Einkaufs-Bots zunehmend direkt mit Verkäufer-Systemen in Verhandlungen.

Der Webshop wird damit weniger Verkaufsoberfläche und mehr API-Endpunkt für Maschinen.
Hier werden alle relevanten Hersteller im Markt Lösungen anbieten (müssen).
Wir werden in 2026 mehr funktionierende Agentic Commerce Prozesse sehen.

Hyper-Personalisierung: Der "Store of One"

Personalisierung erreicht 2026 eine neue Stufe. Shops reagieren in Echtzeit auf Kontext und Absicht:

Dynamische Kataloge und Preise pro Nutzer. Ein Beispiel habe ich in meinem Artikel zum Adobe Technical Bootcamp in Barcelona Adobe Commerce Optimizer) im Bereich Adobe Commerce Optimizer beschrieben.
Individuell generierte Inhalte statt statischer Seiten

Der „Store of One“ ersetzt die klassische Segmentierung – mit messbaren Effekten auf Conversion und Kundenbindung.

Predictive & Zero-Click Commerce

E-Commerce wird zunehmend vorausschauend:

Systeme erkennen Bedarf, bevor er entsteht (z. B. durch IoT-Sensoren im B2B). Was vor einigen Jahren scheiterte wie der Amazon Dash Button, kommt durch die Hintertür wieder zu uns.
Nachbestellungen erfolgen automatisch, ohne aktiven Kaufprozess.

Der Kauf wird zum Hintergrundprozess – Effizienz schlägt Interaktion.

Immersive Commerce als Conversion-Treiber

AR und 3D-Shopping werden vom Nice-to-have zum Standard:

Virtuelle Anproben und In-Room-Visualisierung
Höhere Conversion-Rates und deutlich reduzierte Retouren

Immersion wird zur direkten Umsatzkennzahl.

Plattformen, TCO und Architektur-Entscheidungen

Mit diesen Trends verschärft sich die strategische Plattformfrage.

SaaS & Low-Code: Wachstum durch Convenience

Plattformen wie Shopify profitieren von:

AI-Powered Low-Code/No-Code
Schneller Time-to-Market
Geringer Einstiegshürde und kalkulierbarer TCO

Für viele Unternehmen bleibt dies der schnellste Weg zu skalieren – insbesondere im D2C- und Mid-Market.

Composable Commerce: Freiheit mit Preis

Für komplexe Enterprise-Anforderungen (aber auch nur da!) setzt sich Composable Commerce / MACH durch:

Best-of-Breed statt All-in-One
Hohe Flexibilität und Innovationsgeschwindigkeit

Der Preis dafür ist steigende Komplexität. Ohne saubere Governance steigen Betriebskosten und Abhängigkeiten. Auch 2026 werden Händler die diese Komplexität nicht brauchen sich für eine viel zu große Lösung entscheiden und mit ihrem Vorgaben gegen die Wand fahren.
Auf der anderen Seite wird es auch weiterhin den Irrglauben geben, dass super komplizierte Geschäftsmodelle sich einfach über Standards in Platformen zurechtklicken lassen.
Bei einfache Geschäftsmodelle werden Platformen wie Shopify weiter den Markt dominieren.

Der Gegentrend: Datenhoheit & Sovereign Commerce

Parallel zur SaaS-Dominanz wächst ein starker Gegentrend. Einige werden erkennen, dass man doch lieber die volle Kontrolle über seine Prozesse und Daten möchte.

Sovereign AI & Geopatriation

Unternehmen priorisieren 2026 zunehmend:

Data Residency
Kontrolle über Modelle, Daten und Infrastruktur
Unabhängigkeit von geopolitischen Risiken

Dies ist weniger Ideologie als Risikomanagement. Heute kann keiner mehr Abschätzen was morgen von Politikern beschlossen wird. Regeln die früher galten, sind morgen nicht mehr gültig.
Als Unternehmen gilt es eine Risikobewertung vorzunehmen und ggf. auch die Datenhoheit wieder zu erlangen. Prozesse werden immer mehr auch danach bewertet werden, welche Systeme aus welchen Geo-Regionen verwendet werden. Das wird auch seinen Preis haben, den aber Unternehmen in 2026 mehr bereit sein werden zu zahlen. Vielleicht auch, damit der CEO in der Nacht gut schlafen kann.

Daten-Governance als Wettbewerbsvorteil

Datensicherheit wird kaufentscheidend:

Transparenz über Datenverarbeitung
Vertrauen als Differenzierungsmerkmal

Da immer mehr kriminelle Aktivitäten zu beobachten sind, wird "Trusted Retailer" wird zum echten Asset. Als Shop-Betreiber muss ich in 2026 mehr tun, damit Kunden sich sicher fühlen und damit diese auch wirklich sicher sind. Themen wie Käuferschutz, Zertifikate und Siegel aber auch das klare Kennzeichnen von Informationen sind noch wichtiger.

Magento Open Source & Hyvä als souveräne Alternative

Da ich selbst in dem Bereich tätig bin, muss ich an dieser Stelle auch etwas zum Magento Open Source Ökosystem schreiben.
Trotz der immer größeren "Kluft" zwischen Adobe Commerce und Magento Open Source abgrenzt sage ich folgendes vorraus:

Magento Open Source bleibt strategisch wichtig für Mittelstand und Enterprise
Hyvä senkt Komplexität, modernisiert UX und reduziert Entwicklungskosten

Damit entsteht eine echte Alternative zu globalen SaaS-Plattformen – insbesondere für Unternehmen mit regulatorischen oder sensiblen B2B-Anforderungen.

Durch die Freigabe des Hyvä-Themes unter einer Open Source Lizenz, wird Hyvä auch in 2026 immer mehr Markt-Standard werden. Vielleicht wird dadurch auch 2026 der Hyvä Theme zum Standard-Theme des Forks Mage-OS. Dadurch wird das Entwickeln von Magento-Erweiterungen, die Hyvä-Kompatibel sind, nicht mehr optional sein. Es wird 2026 noch mehr Lösungen geben, die ein "Hyvä-Kompatibel-Badge" tragen.

Adobe treibt seine SaaS Intitative weiter an. Wer den klassischen Monolith braucht da er nicht auf eine Microservice-Landschaft setzt, wird mehr und mehr zu Hyvä Commerce tendieren. Mehr dazu im nächsten Abschnitt.

Das E-Commerce Ökosystem: Die große Gabelung

Ich habe in der Überschrift bewusst "Gabelung" geschrieben und nicht Spaltung. Eine Spaltung gab es aus meiner Sicht bereits. Für mich sind bereits zwei Ökosysteme vorhanden die noch mit dem Magento Open Source Kern eine Schnittmenge habeben. Es werden aber fundamental unterschiedliche Zielgruppen mit den jeweiligen Lösungen bedient.
Als jemand, der tief im Magento-Ökosystem verwurzelt ist, finde ich die Entwicklung für 2026 genau deswegen besonders spannend. Es zeichnet sich eine deutliche Zweiteilung des Marktes ab: Adobe fokussiert sich weiter auf die Enterprise-Cloud, während Hyvä das Erbe von Magento Open Source modernisiert.

Adobe Commerce: Cloud & Agentic AI

Adobe setzt voll auf Enterprise-Automatisierung und eine tiefere Integration in die Cloud.

Neuer Release-Zyklus: Ab Januar 2026 ändert sich alles. Statt riesiger Quartals-Updates gibt es monatliche, isolierte Sicherheits-Fixes. Das große Feature-Release (LTS) kommt nur noch einmal jährlich im Mai. Das soll "Upgrade-Spikes" glätten und die Wartung planbarer machen.
Agentic Commerce: Das neue "Merchant Center" wird eine KI-gestützte Kommandozentrale. KI-Agenten automatisieren Routineaufgaben – von der Konfiguration komplexer Werbeaktionen bis hin zur Fehlerbehebung bei Datensynchronisationen. Die Adobe Produkte wachsen auch optisch in 2026 immer mehr zusammen. Das wird man auch bei Adobe Commerce sehen. Dieses Jahr wurde schon am Admin-UI umgestyled. Über SDKs können App Builder Anwendungen aussehen wie jede andere Adobe-Anwendungen. Diese Vereinheitlichung der Optik wird auch 2026 weitergehen, mit dem Ziel dem Nutzer ein einheitliches System zu zeigen. Im Hintergrund arbeiten aber die anderne Systeme weiterhin über Schnittstellen zusammen. Das Ziel wird es sein, diese den Benutzern zu verstecken.
Edge Delivery für B2B: Für B2B-Kunden werden "Drop-ins" eingeführt, die extrem schnelle Storefronts ermöglichen – mit Funktionen wie Bestelllisten und Unternehmenshierarchien. Bisher waren die EDS Storefronts überwiegend für B2C fokusiert. Im Jahr 2026 wird man erste B2B Cases sehen. Diese B2B-Shops werden international sein und mit schnellen Storefronts punkten.
App Builder: Mit nativer Unterstützung für Dokumenten-Datenbanken können wir Entwickler datenintensive Microservices direkt im Adobe-Ökosystem bauen, ohne externe AWS-Infrastruktur provisionieren zu müssen. Meine Voraussage für 2026 ist nicht sonderlich spannend hier. Es wird einfach mehr App-Builder Apps geben. Adobe arbeitet weiter daran, dass Entwickler es einfacher haben werden, bestehende Magento Module in App Builder Apps zu transformieren. Viele dieser Apps wird man aber nicht im Adobe Marketplace wahrnehmen, da diese in privaten Umgebungen betrieben werden.

Hyvä: Vom Theme zur Plattform ("Hyvä Commerce")

Hyvä entwickelt sich 2026 von einer reinen Frontend-Lösung zu einer umfassenden Plattform-Erweiterung, die Lücken füllt, die Adobe (bewusst) offen lässt.

Admin Dashboard: Hyvä revitalisiert das Backend mit einem neuen Widget-Framework. Händler können Daten wie Verkäufe, Core Web Vitals oder offene Aufgaben direkt im Admin-Panel visualisieren und personalisieren.
Enterprise-Ready: Hyvä arbeitet aggressiv an der Kompatibilität mit Adobe Commerce Features wie "Negotiable Quotes" oder "Gift Registry". Damit wird es zur echten Alternative für Enterprise-Kunden, die Luma oder PWA Studio vermeiden wollen.
Checkout & Performance: Der Checkout erhält neue Layouts und Login-Workflows. Zudem wandern Tools zur Bildoptimierung direkt in den Core, um externe Abhängigkeiten zu reduzieren.

Magento Open Source lebt

Entgegen aller Unkenrufe bleibt Magento Open Source relevant. Getrieben durch das Hyvä-Ökosystem und die Community (Mage-OS), bleibt die Plattform stabil. Der neue Patch-Modell von Adobe (jährliches Feature-Release) gilt auch für die Open Source Variante, was Planungssicherheit bis 2027/2028 gibt. Da sich ein Unternehmen wie Hyvä nicht um die darunterliegendende Plattform kümmern muss, können die eigenen Mitarbeiter sich auf die innovative Weiterentwicklung fokussieren. Adobe selbst fokusiert sich nicht mehr auf die direkte Weiterentwicklung über Magento-Module. Genau hier wird Hyvä-Commerce zur neuen Standard-Lösung werden und mehr und mehr als eigene Marke (Shopsystem) wahrgenommen werden.

Coding & Data: Der Entwickler als Orchestrator

Die Rolle von uns Entwicklern verändert sich grundlegend. Wir bewegen uns weg von der reinen Syntax-Erstellung hin zur Orchestrierung von Systemen. Ich hatte es schon mehrfach in anderen Blog-Posts geschrieben. Der klassische Coder wird immer weniger gebraucht. Das wird 2026 noch krasser sein. Es werden mehr Software-Architekten benötigt. Diese Architekten geben nur noch ihre Wünsche als Anweisungen an die KI weiter. Der Code-Review wird dann noch vom Menschen gemacht. Auch beim Code-Review wird (aufgrund von Wettbewerbsdruck) immer mehr auf die KI-Mitarbeiter gesetzt werden. Das wird auch Probleme bringen. Man wird mehr von "KI-Pannen" hören da Code mehr und mehr ungesehen "durchgewunken" wird.

Hier sind Sicherheitsmechanismen in der Entwicklung gefragt. Alle diese Themen waren schon 2025 und werden uns 2026 noch mehr beschäftigen. Da die meisten Entwickler kein Dinge wie Linux-Kernel-Entwicklung machen und oft Boilerplate-Code nur ergänzen, ist die Frage ob KI zum Einsatz kommt nicht mehr relevant. Entwickler die keine KI einsetzen, werden ersetzt werden. Entweder durch KI selbst oder durch Entwickler die erfahren im Einsatz mit KI-Tools sind.

Low-Code/No-Code vs. Coding Agents

Eine der meist diskutierten Fragen für 2026 lautet: Wird Low-Code/No-Code durch das direkte Erzeugen von Code via KI-Agenten ersetzt? Die kurze Antwort lautet: Nein – aber es verändert sich grundlegend.

Wenn KI das Coden einfacher macht als No-Code

Klassische Drag-and-Drop-No-Code-Ansätze geraten unter Druck:

Komplexität vs. Prompting: In vielen No-Code-Tools müssen Nutzer komplexe Logiken über verschachtelte Menüs abbilden. Mit KI-gestütztem Coding reicht oft ein präziser Prompt („Erstelle ein Verkaufs-Dashboard in Python“), und produktionsnaher Code entsteht in Sekunden.
AI-Assisted Coding: Tools wie Coding Agents, Copiloten oder IDEs mit KI machen das Schreiben von Code zugänglicher als je zuvor. Entscheidend ist nicht mehr Syntax-Wissen, sondern das Verständnis von Geschäftslogik.
Vibe Coding: Es entsteht ein neues Paradigma, bei dem Menschen Software entwickeln, ohne klassische Entwickler zu sein – sie steuern KI-Agenten über Sprache. Dieses Modell konkurriert direkt mit dem ursprünglichen Versprechen von No-Code.

AI-Powered Low-Code

Gleichzeitig verschwinden Low-Code/No-Code-Plattformen nicht, sondern evolvieren:

Co-Creation: Entwickler und Fachbereiche beschreiben Prozesse, Datenmodelle oder Regeln in natürlicher Sprache – die Plattform generiert daraus lauffähige Module.
Intelligenz statt nur Geschwindigkeit: Low-Code wird zur Orchestrierungs- und Skalierungsplattform, in die KI-Agenten fest integriert sind.
Marktrealität: Prognosen gehen davon aus, dass ein Großteil neuer Unternehmensanwendungen auch 2026 auf Low-Code/No-Code-Plattformen entsteht – allerdings mit nativer KI als Kern.

Ich selbst arbeite viel mit n8n. In n8n sieht man das auch jetzt schon sehr gut. Hier gibt es immer mehr Integrationen für Entwickler direkt über MCP-Server die Workflows zu erzeugen. In der Cloud-Version ist zudem auch ein AI-Assistent integriert der auch direkt aus Sprache die Workflows vorbauen kann, die man dann nur noch modifiziert.
Low-Code Plattformen erlauben auch das Ausführen von reinen Code-Lösungen. Das ist charmant, denn man sieht dann den Prozess weiterhin visuelle. Hier verschmelzen bereits jetzt beide Ansätze.
In 2026 werden Low-Code Plattformen auch weiterhin relevant sein. Es wird mehr Lösungen geben die von AI-Coding-Agents generiert werden und in Low-Code Lösungen integriert sein werden.
Mehr dazu im nächsten Abschnitt.

Warum Low-Code/No-Code aus Unternehmenssicht bleibt

Trotz mächtiger Coding Agents behalten LCNC-Plattformen strategische Vorteile:

Governance & Sicherheit: Sie liefern Leitplanken wie Architekturvorgaben, Compliance-Checks und Security-Scans für KI-generierten Code.
Legacy-Modernisierung: Low-Code bleibt der effizienteste Weg, alte Systeme mit APIs, RPA und KI schrittweise zu modernisieren.

Essenz: Low-Code/No-Code wird nicht durch manuelles Coding ersetzt, sondern durch Natural Language Programming erweitert. Das manuelle Zusammenklicken verliert an Bedeutung – die natürliche Sprache wird zur universellen Schnittstelle, egal ob innerhalb einer Plattform oder direkt im Code-Editor.

KI ist 2026 der Standard-Partner beim Coden. Routineaufgaben wie Boilerplate-Code, Tests und Dokumentation werden fast vollständig automatisiert. Wir Entwickler fungieren zunehmend als "Architekten" und Prüfer des generierten Codes. Der "Vibe", den ich beim Coden so schätze, verlagert sich auf das Lösen komplexer Architekturprobleme.

Data Governance & FinOps

Daten sind das Öl, aber ohne Raffinerie und Sicherheitsvorkehrungen nutzlos. Da KI-Modelle nur so gut sind wie ihre Daten, wird Data Governance zur Priorität. "Lakehouses" (Unified Data Platforms) werden zum Standard, um Datensilos aufzubrechen. Gleichzeitig wird FinOps für KI eine kritische Fähigkeit für Data Scientists: Es geht darum, die explodierenden Kosten für KI-Infrastruktur (Inference Costs) strikt zu kontrollieren.

KI im Alltag 2026: Vom Chatten zum Handeln

KI verlässt 2026 endgültig die Rolle eines reinen Bildschirm-Tools. Wir bewegen uns von einer Phase, in der wir mit KI interagieren, hin zu einer, in der KI für uns handelt, Entscheidungen trifft und physisch präsent wird. KI wird damit zur unsichtbaren Infrastruktur des Alltags.

Vom Assistenten zum digitalen „Angestellten"

Der fundamentalste Wandel ist der Aufstieg der Agentic AI.

Einkaufs- & Service-Bots: Verbraucher delegieren Aufgaben an persönliche KI-Agenten, die Produkte finden, Preise verhandeln und Käufe abschließen. Entscheidungen, die früher langes Vergleichen erforderten, werden in Sekunden getroffen.
Autonome Workflows: Diese Agenten planen Reisen, verwalten Abonnements oder führen Finanztransaktionen selbstständig aus – mit klar definierten Leitplanken des Nutzers.

Arbeit: Weniger Monotonie, mehr Wirkung

KI verändert nicht nur was wir tun, sondern wie wir arbeiten:

Fokus auf Strategie: Routinetätigkeiten wie Rechnungsprüfung, Reporting oder Coding-Grundgerüste werden automatisiert. Menschen konzentrieren sich stärker auf Problemlösung, Kreativität und Entscheidungen.
Demokratisierung von Fähigkeiten: KI-gestütztes Coding und „Vibe Coding“ ermöglichen es auch Nicht-Entwicklern, Software zu erstellen, indem sie ihre Absicht beschreiben.
Der AI Generalist: Digitale Grundfähigkeiten werden zum neuen Standard. Gefragt sind Menschen, die verschiedene KI-Systeme orchestrieren können.

Hyper-Personalisierung & Zero-Click-Erlebnisse

Alltägliche digitale Erlebnisse werden 2026 hochgradig individuell:

Store of One: Online-Shops, Inhalte und Preise werden in Echtzeit für jede einzelne Person generiert.
Prädiktive Services: Systeme erkennen Bedürfnisse, bevor sie explizit formuliert werden – bis hin zum Zero-Click Commerce, bei dem automatisch nachbestellt wird.

Physische KI & immersive Realitäten im Alltag

Die Grenze zwischen digitaler und physischer Welt verschwimmt:

AR & VR: Virtuelle Anproben, immersives Lernen oder therapeutische Anwendungen werden alltäglich und senken Reibung sowie Kosten.
Physical AI: Drohnen, Lieferroboter oder Assistenzsysteme in Krankenhäusern und der Logistik werden Teil des normalen Stadt- und Arbeitsbildes.

Unsichtbare, sichere Transaktionen

Technologie tritt in den Hintergrund:

Biometrische Wallets: Bezahlung und Identifikation erfolgen über Gesicht oder Fingerabdruck – schnell, sicher und ohne bewusste Interaktion.
Instant Refunds: Rückerstattungen laufen automatisiert und nahezu in Echtzeit ab.

Kreativität für alle

Kreative KI wird massentauglich:

Nutzer erstellen, bearbeiten und personalisieren Inhalte mit wenigen Anweisungen.
Eigene Modelle und Stile lassen sich ohne tiefes technisches Wissen einsetzen.

Kurz gesagt: KI ist 2026 kein separates Feature mehr, sondern eine stille, handelnde Infrastruktur, die Aufgaben übernimmt, physisch unterstützt und genau zugeschnittene Erlebnisse – bei gleichzeitig wachsendem Anspruch an Transparenz, Kontrolle und Vertrauen.

Fazit: Der "AI Generalist"

Zusammenfassend lässt sich sagen: Die Arbeitswelt 2026 sucht den AI Generalisten. Die Spezialisierung auf eine einzige Programmiersprache oder ein einziges Tool reicht oft nicht mehr aus. Gefragt sind Fachkräfte, die:

Orchestrieren: KI-Tools und autonome Agenten zu einem funktionierenden Ganzen verknüpfen.
Brücken bauen: Die Verbindung zwischen physischer Hardware (Robotik & Consumer Devices) und digitaler Intelligenz herstellen.
Verantwortung übernehmen: Nachhaltigkeit nicht als Last, sondern als Optimierungsproblem verstehen und Governance-Strukturen etablieren.

Es bleibt also spannend. Die Werkzeuge ändern sich radikal, aber die Notwendigkeit für kreative Problemlösung war noch nie so groß wie heute. Packen wir es an!

n8n 2.0 steht vor der Tür - Jetzt das eigene System vorbereiten!

2025-11-29T17:41:00+00:00

Die Spatzen pfeifen es bereits von den Dächern der Automatisierungs-Community: n8n 2.0 steht vor der Tür! Kürzlich wurde im offiziellen Forum die neue Version angekündigt, und wie bei jedem Major-Release bringt auch dieses Update einige spannende Neuerungen, aber auch Breaking Changes mit sich.

Die Beta soll bereits am 8. Dezember zur Verfügung stehen. Grund genug, sich jetzt schon mit den Änderungen vertraut zu machen und die eigene Infrastruktur vorzubereiten.

Vorbereitung ist alles: Der Migration Report

Ein Major-Update kann furchteinflößend sein, besonders wenn komplexe Workflows davon abhängen. Das Team von n8n hat hier jedoch mitgedacht. Es gibt einen integrierten Migration Report direkt im Backend deiner n8n-Instanz unter Settings -> Migration Report.

Dieser Report ist dein bester Freund für das Update. Er prüft deine vorhandenen Workflows und Einstellungen auf Herz und Nieren:

Welche Nodes sind inkompatibel?
Welche Nodes sind von Änderungen betroffen?
Welche Konfigurationen müssen angepasst werden?

Ich empfehle jedem, diesen Report so früh wie möglich zu konsultieren, um böse Überraschungen beim Update zu vermeiden. Eine detaillierte Übersicht der Änderungen findest du auch in der offiziellen Dokumentation zu den Breaking Changes.

Wichtige Breaking Changes im Überblick

Neben den architektonischen Änderungen gibt es einige harte Schnitte, die vor allem Self-Hoster betreffen. Hier sind die wichtigsten Punkte aus der Dokumentation:

Kein MySQL/MariaDB Support mehr: n8n 2.0 stellt die Unterstützung für MySQL und MariaDB als Backend-Datenbank ein. Wenn du diese noch nutzt, ist jetzt der Zeitpunkt, auf PostgreSQL zu migrieren. Der MySQL Support war aber auch schon beim 1.0 Release als deprecated markiert worden. Ich persönlich mag Postgres auch viel lieber.
Zugriff auf Environment Variables: Aus Sicherheitsgründen können Code Nodes standardmäßig nicht mehr auf Umgebungsvariablen zugreifen. Falls deine Skripte darauf angewiesen sind, musst du dies entweder explizit über die Variable N8N_BLOCK_ENV_ACCESS_IN_NODE=false erlauben oder deine Workflows anpassen.
Wegfall der Tunnel-Option: Die Start-Option --tunnel, die oft für schnelle lokale Tests mit Webhooks genutzt wurde, ist ersatzlos gestrichen.
Bereinigung alter Nodes: Nodes für Dienste, die bereits eingestellt wurden oder veraltet sind, wurden nun endgültig aus dem Core entfernt.

Eine große Änderung für mein Setup: Externe Task Runners

Eine der signifikantesten architektonischen Änderungen in n8n 2.0 betrifft die Ausführung von Code. Der interne Task Runner, der bisher "out-of-the-box" Python oder JavaScript Code ausgeführt hat, wird in Version 2.0 nicht mehr standardmäßig aktiv sein.

Stattdessen setzt n8n nun auf externe Task Runners. Das bedeutet, dass Code in einer Sandbox ausgeführt wird, die strikt von der n8n-Hauptinstanz getrennt ist. Das hat zwei große Vorteile:

Sicherheit: Die Angriffsfläche für Hacks wird drastisch minimiert. Standardmäßig sind Nodes für "Git" oder Code-Execution eingeschränkt, sodass beispielsweise kein unkontrollierter Zugriff auf das Dateisystem mehr möglich ist. Natürlich lässt sich das über Einstellungen wieder lockern, wenn man genau weiß, was man tut.
Flexibilität: Benötigst du spezielle Python-Bibliotheken oder Node-Pakete? Du kannst dir einfach dein eigenes Docker-Image für den Task Runner erstellen und hast genau die Umgebung, die du brauchst, ohne die Hauptinstanz aufzublähen.

Mein Setup: Task Runners im Worker Mode

Da ich mein n8n-Setup im Worker Mode betreibe, um die Last besser zu verteilen, musste ich meine docker-compose.yaml etwas stärker anpassen. Die Herausforderung hierbei ist, dass nicht nur der Haupt-Container (Webhook-Prozessor), sondern auch die Worker Zugriff auf Task Runner benötigen.

In meiner aktuellen Konfiguration, mit der ich mich auf die Umstellung vorbereite, habe ich deshalb dedizierte Task Runner Container für den Hauptprozess (n8n) und für den Worker (n8n_worker) definiert.

Hier ist ein Einblick in meine docker-compose.yaml, wie sie aktuell läuft:

x-n8n-task-runners: &service-task-runners-n8n  
  image: ghcr.io/n8n-io/runners:1.122.1

x-n8n: &service-n8n  
  image: ghcr.io/n8n-io/n8n:1.122.1  
  env_file: .env  
  networks:  
    - default  
  user: node  
  volumes:  
    - n8n-data:/home/node/.n8n  
    - "./data:/data"  
  restart: unless-stopped

services:  
  n8n:  
    <<: *service-n8n  
    container_name: n8n  
    ports:  
      - 0.0.0.0:5678:5678  
    depends_on:  
      redis:  
        condition: service_healthy  
    env_file: .env

  n8n_worker:  
    <<: *service-n8n  
    container_name: n8n_worker  
    command: worker --concurrency=6  
    depends_on:  
      - n8n  
    env_file: .env  
    environment:  
      N8N_WORKER_MODE: "true"  
      OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS: "true"

  n8n_main_task_runners:  
    <<: *service-task-runners-n8n  
    container_name: n8n_task_runners  
    env_file: .env  
    restart: unless-stopped  
    environment:  
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679  
      - N8N_RUNNERS_MAX_CONCURRENCY=5  
      - N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT=15  
      - N8N_NATIVE_PYTHON_RUNNER="true"  
    depends_on:  
      - n8n

  n8n_worker_task_runners:  
    <<: *service-task-runners-n8n  
    container_name: n8n_worker_task_runners  
    env_file: .env  
    restart: unless-stopped  
    environment:  
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n_worker:5679  
      - N8N_RUNNERS_MAX_CONCURRENCY=5  
      - N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT=15  
      - N8N_NATIVE_PYTHON_RUNNER="true"  
    depends_on:  
      - n8n_worker

  redis:  
    container_name: n8n_redis  
    image: redis:8-alpine@sha256:5013e94192ef18a5d8368179c7522e5300f9265cc339cadac76c7b93303a2752  
    restart: unless-stopped  
    networks:  
      - default  
    volumes:  
      - redis-data:/data  
    healthcheck:  
      test: ['CMD', 'redis-cli', 'ping']  
      interval: 5s  
      timeout: 5s  
      retries: 10

volumes:  
  n8n-data:  
  redis-data:

In meiner .env Datei habe ich erstmal folgende Variablen zusätzlich eingetragen:

# Task Runners
N8N_RUNNERS_AUTH_TOKEN=<xxxxxxxxxx>
N8N_RUNNERS_ENABLED=true
N8N_RUNNERS_MODE=external
N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0

# Auth
N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false

# Git
N8N_GIT_NODE_DISABLE_BARE_REPOS=false

N8N_RESTRICT_FILE_ACCESS_TO=/data

# Allow all excluded nodes
NODES_EXCLUDE="[]"

Die Einstellungen sind jetzt erstmal so gewählt, dass meine Workflows weiterlaufen können nach dem Update. Ich habe eine paar wenige Nodes die direkte Bash-Befehle ausführen. Diese arbeiten aber bei mir sowieso nur im Container im Verzeichnis /data.

Wie ihr seht, habe ich n8n_main_task_runners und n8n_worker_task_runners definiert, die jeweils via N8N_RUNNERS_TASK_BROKER_URI mit ihrem entsprechenden n8n-Service verbunden sind. Ob dies die absolut optimale Lösung für jedes Szenario ist, wird sich in der Praxis zeigen, aber es ist ein funktionierender Weg, um die neue Architektur im Worker-Mode abzubilden.

Neue Features: Mehr Komfort für Workflow-Builder

Neben den technischen Änderungen unter der Haube gibt es auch sichtbare Verbesserungen, die das Arbeiten mit n8n angenehmer machen:

Verbesserte Canvas: Der Workflow-Editor (Canvas) erhält einen frischen Look and Feel, der moderner und aufgeräumter wirkt (Leider habe ich bisher keinen Screenshot gesehen).
Neue Sidebar: Die Seitenleiste wurde überarbeitet, um die Navigation und den Zugriff auf wichtige Funktionen zu verbessern. Ich bin gespannt ob die Sidebar auch in der Community-Version eine Funktion bekommt,
Autosave (Bald verfügbar): Endlich! Eines der am meisten gewünschten Features kommt. Das automatische Speichern von Workflows wird kurz nach dem Stable-Release eingeführt. Nie wieder verlorene Arbeit durch vergessene Klicks auf "Speichern". Das Feature klingt einfach, ist es aber im Hintergrund nicht.

Fazit

Der Schritt zu n8n 2.0 ist ein wichtiger Meilenstein, der vor allem in puncto Sicherheit und Stabilität Verbesserungen bringt. Wer komplexe Setups betreibt, sollte die Zeit bis zum Release nutzen, um seine docker-compose Konfiguration anzupassen und die Migrations-Tools zu nutzen.

So ein richtiges Fazit kann es jetzt auch noch nicht geben da die Version ja noch nicht da ist.
Ich bin gespannt auf den 8. Dezember!

Rückblick auf den 53. Magento Stammtisch Rhein-Main

2025-11-21T11:49:00+00:00

Es war mal wieder soweit: Die Magento Community im Rhein-Main-Gebiet traf sich zur 53. Ausgabe des Stammtischs. Diesmal hatte e3n nach Mainz eingeladen, und die Räumlichkeiten wurden freundlicherweise von der Thiele & Klose GmbH zur Verfügung gestellt.

Was mich besonders gefreut hat: Der Stammtisch war richtig gut besucht. Einige Teilnehmer hatten auch ein weite Anreise auf sich genommen. Das zeigt, dass das Format und der persönliche Austausch nach wie vor extrem wertvoll sind.

Ein großes Dankeschön vorab auch für das Catering. Es gab leckeres Essen und Getränke – etwas, das ich in der heutigen Zeit keineswegs als selbstverständlich ansehe. So gestärkt ging es dann an die zwei Hauptthemen des Abends.

Performance-Tuning aus der Sicht des Hosters

Den Anfang machte Jonas Hünig von maxcluster. Sein Thema "Performance-Tuning für Magento" ist ein Dauerbrenner, aber Jonas hat einen sehr interessanten Blickwinkel gewählt: die Perspektive des Hosters.

Langsame Shop-Instanzen sind frustrierend – für Kunden, Händler und Entwickler. Jonas zeigte auf, wie man typische Flaschenhälse systematisch aufspürt und analysiert. Besonders gut gefiel mir, dass der Vortrag nicht als reine Verkaufsveranstaltung für maxcluster angelegt war. Die gezeigten Methoden zur Diagnose und die Stellschrauben bei den Serverdiensten waren so aufbereitet, dass sie auch für Hostings außerhalb von maxcluster funktionieren.

Dabei ging es erfreulich tief in die Technik: Jonas sprach auch Linux Kernel spezifische Optimierungen an und zeigte live den Einsatz von strace zur Analyse. Mir persönlich hat dieser sehr technische Deep-Dive extrem gut gefallen.

Natürlich gab es "on top" noch ein paar Insider-Infos zum speziellen Setup bei maxcluster und wie man dort bestimmte Probleme noch effizienter lösen kann.

Kleines Highlight am Rande: maxcluster hatte für jeden Teilnehmer ein kleines Geschenk dabei. Danke für das nette kleine LED-Lampe! Diese hat bei mir zuhause schon seinen Platz gefunden und ist aufgebaut.

Hype oder echter Wandel? Wie KI das Coding verändert

Der zweite Speaker war Tobias Niebergall von e3n. Sein Vortrag knüpfte nahtlos an Themen an, die mich selbst in den letzten Wochen hier im Blog intensiv beschäftigt haben. Unter dem Titel "Hype oder echter Wandel? Wie KI das Coding wirklich verändert" ging es um den Begriff Vibe Coding.

Tobias zeigte, dass KI-gestützte Entwicklung weit mehr ist als nur Code-Vervollständigung. Es geht um den Aufbau smarter Workflows. Anhand von Tools wie Claude, MCP-Servern (Model Context Protocol) und n8n demonstrierte er, wie man sein Entwickler-Team produktiver machen kann. Auch die Sicherheit in Verbindung mit AI-Tools war ein Thema.

Die Kernpunkte waren praxisnah:

Wie setze ich KI gezielt ein, um im "Flow" zu bleiben?
Automatisierung von repetitiven Aufgaben (etwas, das ich mit meinen Agenten-Experimenten nur bestätigen kann).
Wie man Ideen viel schneller in funktionierende Prototypen und Lösungen umsetzt.

Ziel war es, den Entwicklern im Raum die Berührungsängste zu nehmen und Wege zu zeigen, wie man KI schrittweise in den eigenen Alltag integriert.

Wilde Diskussionen zum Abschluss

Wie es sich für einen guten Stammtisch gehört, war nach den Vorträgen noch lange nicht Schluss. Gerade der Vortrag von Tobias hat den Nerv der Zeit getroffen und eine ordentliche Diskussion entfacht.

Es ging thematisch einmal querbeet:

Ausbildung: Lernen Junioren noch richtig Coden, wenn die KI alles übernimmt?
Software-Qualität: Wird der Code besser oder fluten wir unsere Repositories mit KI-generiertem Spaghetti-Code?
Nachhaltigkeit: Wie sieht eigentlich der CO2-Fußabdruck aus, wenn wir für jede kleine Funktion ein LLM befeuern?
Security & WAFs: Auch der Einsatz von Web Application Firewalls wurde diskutiert. Hier hatte Björn Kraus wertvolle Tipps zum Umgang mit mod_security parat und wies darauf hin, dass viele dieser Best Practices bereits in seinem Magento Helm-Chart implementiert sind (siehe auch: modsecurity-crs-proxy).

Es war – im positivsten Sinne – ganz schön wild. Aber genau das macht für mich einen Stammtisch aus: Unterschiedliche Meinungen, leidenschaftliche Debatten und am Ende geht man mit neuen Impulsen nach Hause.

Danke an e3n, Thiele & Klose, maxcluster, die Speaker und alle, die da waren. Es war ein gelungener Abend!