muench.dev Articles

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!

Was macht Codex gerade? Mehr Übersicht mit dem Tool CodeXRays

2025-10-29T07:25:00+00:00

Ich arbeite sehr gerne mit Codex über die CLI. Das Codex CLI wird mit jedem Release besser. Wenn man versucht nachzuvollziehen was Codex so macht, kann das teilweise sehr unübersichtlich sein. Gerade, wenn eine Session über längere Zeit läuft, entstehen sehr lange Log-Ausgaben. Codex versucht die Ausgaben zwar so benutzrerfreundlich wie möglich zu gestalten indem u.a. Emojis verwendet werden oder auch die Ausgaben mit Bullet-Points strukturiert werden, aber es ist trotzdem nicht immmer möglich denn Überblick zu behalten.

Da unser Job als Software-Entwickler immer mehr in die Richtung der Überwachung der KI geht, ist es wichtig den Überblick zu behalten.

Ich bin in dem Zug auf das Tool CodeXRays gestoßen. Das Tool ist in Python geschrieben und analysiert die Log-Ausgaben von Codex in Echtzeit. Man startet es einfach parallel zu seiner Codex Session.

Installation und Konfiguration

Die Installation erfolgt im einfachsten Fall über pipx. Das Tool pipx solltet ihr in eurer Entwicklungsumgebung einfach an den Start bringen können, falls es nicht sowieso schon da ist.

Hier ist der Einzeiler der das Tool direkt aus dem GitHub Repo installiert:

pipx install git+https://github.com/gastonmorixe/codex-xrays

Wichtig ist es jetzt, dass wir den Logger des in Rust geschriebenen codex-cli konfigurieren. Das passiert durch das Setzen der Umgebungsvariable RUST_LOG.
Wenn ihr die Variable immer gesetzt haben wollt, dann schreibt folgendes in eure .zshrc oder .bashrc (je nach Shell etwas abweichend):

RUST_LOG=codex_core=trace,codex_exec=debug,codex_mcp_client=debug

Alternativ kann man die Variable auch direkt vor die Ausführung von codex-xrays schreiben.
Das sollte es mit dem Setup gewesen sein.

So wird das Log schön (Ausführen)

Wir schon geschrieben läuft das Tool in Regel paralle zur Codex CLI Ausführung. Ihr startet also eure Codex Session ganz normal.
In einem zweiten Terminal startet man dann codex-xrays.
Empfohlen ist das Starten mit folgendem Befehl um die schönste Ausgabe zu bekommen:

codex-xrays --pretty-preview --pretty-mode hybrid --json-pretty

Beispielausgabe

In meinem Fall habe ich mal meine AGENTS.md in einem Projekt aktualisieren gelassen.
CodexXRays ist interaktiv. Ihr könnt in dem Fenster dann mit den Cursor

Tasten die Log-Meldungen auswählen und über "Return" dann die ausführlichen Meldungen sehen.

Wichtig für mich ist es auch mal zu sehen was für Befehle da genau in der Bash ausgeführt werden wie hier im Beispiel zu sehen ist:

Ich werde das Tool mal weiter auspobieren. Es ist auch möglich im Terminal zu filtern, einzelne Meldungen zu pinnen oder auch mal das Logging während einer aktiven Session zu pausieren.
Das kann alles ganz praktisch sein.
Ich hoffe ihr könnt mit dem Tool auch euren Ablauf optimieren.

Kleines Open Source Projekt Update - Oktober 2025

2025-10-23T12:40:00+00:00

Das wird hier kein großer Blog-Post. Allerdings gehen die kleinen Projekte von mir gerne mal unter. Seit einer Weile habe ich zwei n8n Nodes als Community Nodes veröffentlicht. Das eine stellt Nodes für das PKM Tool Capacities bereit. Das andere Tool erlaubt es in n8n mit der Social Media Platform Bluesky zu kommunizieren.

Beiden Projekten habe ich (nach längerer Zeit) mal wieder ein Update spendiert.

Capacities (n8n-nodes-capacities)

Hier ist die Capacities API leider noch etwas limitiert. Ich versuche die bestehende API komplett abzudecken. Ein kleines Feature in der Suche hatte noch gefehlt. Die Suchanfragen kann nun nach "Strukturen" filtern. Das ist wichtig, dass man z.B. nur Weblinks oder nur Seiten suchen möchte.
Bisher musste man dann die Ergebnismenge selbst in n8n filtern.

Es können auch mehre Strukturen angegeben werden.

n8n Bluesky Node (n8n-nodes-bluesky)

Ein von einigen Benutzern lange gewünschtes Feature (GitHub Issue #9) ist, dass man Bilder direkt posten kann.
Bisher konnte man Bilder nur indirekt über das Laden mittels "Fetch Open Graph Tags" einem Post hinzufügen.

Mit dem neuen Update gibt es jetzt die Möglichkeit, dass man direkt ein Image-Binary in das Bluesky Node packt.

Auch Meta-Daten können übergeben werden wie man im Screenshot sieht.

Auf den ersten Blick sieht das ganz einfach aus. Allerdings darf eine Bilddatei nicht größer als ca. 950 KByte sein. Das bedeutet, dass bei zu großen Bildern ein Fehler auftauchen würde. Ich habe hier den Weg gewählt, dass im Node die Library "sharp" dann das Bild on-the-fly verkleinert. Die Logik hatte ich schon für das "Fetch Open Graph Tags" Feature implementiert und konnte diese wiederverwenden.
Zudem muss man bei Bluesky über die API in zwei Stufen arbeiten. Erst das Bild hochladen. Dann den Post erstellen mit der Medien-ID des hochgeladenen Bild.

n98-magerun2

Bei n98-magerun2 ist ja immer was zu tun. Größere Features und Entwicklungen gibt es hier nicht. Allerdings gibt es immer auch mal Wartungen zu machen. Diesen Monat war z.B. der GPG Key der die Phar Dateien signiert abgelaufen und musste verlängert werden. Dazu habe ich mit jetzt einen Reminder (und eine kleine Anleitung für mich) erstellt, damit in zwei Jahren nicht wieder irgendwelche GitHub Actions mit komischen Meldungen fehlschlagen.

Ein weiteres offenes Thema war das Update des genutzten "GitHub Superlinter" auf die Version 8. Hier musste ich einige Konfiguration anpassen.

Das war es dann auch schon mit meinem kleinen Status Update für den Oktober 2025. Mal sehen was der November alles bereithält.
Als kleiner Spoiler... Es könnte sein, dass ich etwas in Richtung Adobe App Builder veröffentlichen werde.