Dieses Open-Source-Repository macht Claude Code zum n8n-Architekten — n8n war noch nie so nützlich
Letzten Dienstag um 23 Uhr habe ich zugesehen, wie Claude Code 140 Produktvarianten aus einem Live-E-Commerce-Shop gelöscht hat. Nicht böswillig. Nicht einmal technisch falsch.
Der Workflow, den ich reparieren lassen wollte, sendete einen PUT-Request an PrestaShops XML-API mit nur 4 Feldern. PrestaShop interpretierte das als "alles andere auf leer setzen." Referenzen weg. Barcodes weg. 140 Kombinationen lautlos gelöscht, während ich in einem anderen Terminal-Tab Ausführungslogs verglich.
TL;DR: n8n stirbt nicht. Das manuelle Erstellen von Workflows stirbt. Ein Open-Source-Repo (czlonkowski/n8n-mcp) hat Claude Code in einen n8n-Architekten verwandelt. Ich habe es an einer echten 55-Node-Produktions-Pipeline getestet und separat meinen eigenen KI-Agenten abgeschaltet, weil er Token für nichts verbrannt hat. Unten: was tatsächlich funktioniert, was kaputtgeht, und ein Framework für die Entscheidung, welches Tool wann zu verwenden ist.
Fünfzehn Minuten später hatte Claude Code auch die Grundursache diagnostiziert, den Fix gebaut (ein GET-vor-PUT-Pattern über 4 neue Nodes), alle 12 Änderungen in einem einzigen atomaren API-Call deployed und die Reparatur verifiziert, indem es den PrestaShop-API-Status vorher und nachher abgerufen hatte.
Dieselbe Untersuchung im n8n-UI hätte mich über eine Stunde gekostet. Ich weiß das, weil ich es schon mal gemacht habe: durch 55 Nodes klicken, zwischen Browser-Tabs wechseln, manuell JSON exportieren, Ausführungsdaten anstarren.
Zwei Wochen zuvor hatte ich meinen eigenen KI-Agenten abgeschaltet. Den Stecker gezogen bei OpenClaw, dem Multi-Model-System, das ich monatelang gebaut und beschrieben hatte. Das Verhältnis von verbrauchten Token zu produziertem Wert war negativ. Der Agent hat ständig Zyklen damit verschwendet, sich selbst zu aktualisieren, anstatt echte Arbeit zu machen.
Jetzt hatte ich ein Paradox in meinem Terminal: einen selbstgebauten KI-Agenten, der seine eigene Stromrechnung nicht rechtfertigen konnte, und ein KI-unterstütztes Workflow-System, das gerade in 15 Minuten eine Produktionsdatenbank gerettet hatte.
Dieses Paradox ist im Grunde die ganze n8n-Debatte gerade.
Das Repo, das n8ns Jobbeschreibung geändert hat
Vor drei Monaten bat ich Claude Code, mir einen n8n-Workflow zu bauen.
Es erfand einen Node namens scheduleTrigger. Diesen Node gibt es nicht. Der echte heißt schedule. Ich verbrachte 20 Minuten damit, einen Import-Fehler in einer JSON-Datei zu debuggen, die völlig valide aussah, weil jeder Property-Name fast richtig war. Nah genug zum Importieren, falsch genug zum Kaputtgehen. Claude war auch so selbstsicher dabei. Peak-Halluzination-Energy. "Hier ist dein Workflow" und das JSON sieht wunderschön aus, bis du merkst, dass die Hälfte der Node-Typen Fan-Fiction sind.
Ich hörte auf, Claude Code n8n anfassen zu lassen.
Dann veröffentlichte ein Entwickler namens czlonkowski einen Open-Source-MCP-Server. Und das nächste Mal, als ich Claude Code bat, einen Workflow zu bauen, kannte es jeden Node-Namen, jedes Property-Schema, jede IF-Branch-Verbindungssyntax. Keine Halluzination. Kein Raten.
Die Online-Debatte darüber, was als nächstes passierte, läuft so: Claude Code frisst n8n das Mittagessen weg. Google Trends zeigen, dass es n8n beim Suchinteresse überholt. YouTube-Creator, die Audiences mit n8n-Tutorials aufgebaut haben, sehen ihre Views sinken. Forum-Threads mit dem Titel "Ist n8n tot?" tauchen jede zweite Woche auf. Der Konsens ist immer derselbe laue Spruch: "es sind komplementäre Tools für verschiedene Skill-Level."
Dieser Konsens ist zutreffend und völlig nutzlos.
Der tatsächliche Wandel ist spezifischer. czlonkowskis n8n-mcp-Server (auf GitHub) gibt Claude Code strukturierten Zugang zu 1.084 n8n-Nodes, 2.600+ Real-World-Konfigurationen aus Templates extrahiert und Validierungsregeln, die Fehler vor dem Deployment abfangen. Ein Begleitprojekt fügt 7 Claude Code Skills hinzu, die Expression-Syntax, Architektur-Pattern und Debugging abdecken.
n8n hat auch ihren eigenen offiziellen MCP ausgeliefert (Settings > Instance-level MCP), aber ihrer ist bewusst limitierter: bestehende Workflows triggern und abfragen, nicht neue bauen. Sicherheitsbewusste Entscheidung, keine Schwäche.
Was also passiert ist: n8ns visueller Builder ist nicht gestorben. Er hat den Job gewechselt. Früher war er das Konstruktions-Tool. Jetzt ist er das Monitoring-Dashboard. Claude Code baut, n8n führt aus.
Aber Workflows schneller zu bauen ist nur die Hälfte. Ich habe 15 Workflows auf meiner n8n-Instanz laufen. Letzten Monat öffnete ich einen, den ich 3 Monate nicht angefasst hatte, und hatte keine Ahnung, was die mittleren 20 Nodes machten. Ein MCP-Call und Claude Code platzierte Sticky Notes auf jeden Node, die erklärten, was er macht, was er erwartet, was kaputtgeht, wenn man ihn ändert. Das allein hätte das Setup gerechtfertigt. Aber dann merkte ich, dass ich das nach jeder Änderung machen konnte.
Das Ding, das den Workflow bearbeitet, dokumentiert auch die Änderung und committed sie zu git mit einer Message, die tatsächlich beschreibt, was passiert ist. Über meine drei Debugging-Sessions bedeutete das 30 Commits mit vollständiger Rollback-Fähigkeit, null manuelle Export/Import-Klicks. Versuch das mal im n8n-UI.
Faire Warnung: Dieses Setup bedeutet, dass du einem KI einen API-Token gibst, der vollen Read/Write-Zugang zu deiner n8n-Instanz bekommt. Ich habe es auf Staging und Produktion gemacht. Ich werde nicht so tun, als wäre das risikofrei. Bei einem meiner Workflows konnte Claude Code den PrestaShop-API-Key in Klartext in einem Parameters-Node sehen. Nützlich für direkte curl-Verifikation. Schrecklich für Credential-Hygiene. Security-Leute, die das lesen, haben gerade eine Störung in der Macht gespürt. Sorry. Die MCP-Schicht hat heute null Credential-Scoping.
Ich argumentierte letzten Monat, dass CLIs MCP für die meisten AI-Agent-Tools schlagen. Für General-Purpose-Agenten denke ich das immer noch. Aber für eine spezifische, gut dokumentierte Plattform wie n8n? Der strukturierte MCP-Ansatz gewinnt. czlonkowski hat es bewiesen.
Drei Momente aus einem echten Produktions-Debug
Ich betreibe eine E-Commerce-Pipeline für redactedshop.com, eine europäische Outdoor-Retail-Site auf PrestaShop 8.2.1. Ein Lieferant sendet einen CSV-Katalog via FTP. Eine n8n-Pipeline liest das CSV, parst es in Google Sheets (mit KI-unterstützter Varianten-Erkennung via Gemini), dann erstellt und aktualisiert ~265 Produkte in PrestaShop inklusive Preise, Bestände, Bilder, Kategorien und Übersetzungen in 3 Sprachen. Zwei Haupt-Workflows, sechs Sub-Workflows, 55 Nodes insgesamt.
Über drei Debugging-Sessions in zwei Wochen handhabte die Combo aus Claude Code + n8n-MCP Probleme, die von trivial bis "wie hat das jemals funktioniert" reichten. Drei Momente stachen heraus, weil jeder einen anderen Punkt beweist.
Das lautlose Löschen
Der update variants prix Node sendete einen PUT an /api/combinations/{id} mit nur id, id_product, minimal_quantity und price. PrestaShops API behandelt einen partiellen PUT als "ersetze die gesamte Ressource." Ugh. Jedes Feld, das du nicht sendest, wird geleert. Das hatte lautlos Referenzcodes und EAN-Barcodes von 140 Produktvarianten gelöscht. Ein zweiter Node hatte dasselbe Pattern UND war auf executeOnce: true gesetzt, was bedeutete, dass nur das erste Produkt jemals aktualisiert wurde. Der Rest wurde komplett übersprungen.
Claude Code zog die Ausführungsdaten via MCP, extrahierte eine spezifische Kombinations-ID, machte einen GET auf die PrestaShop-API, um den Schaden zu sehen, baute 4 neue Code-Nodes, die das GET-vor-PUT-Pattern implementierten, verdrahtete 4 Verbindungen auf IF-Branches neu, entfernte das executeOnce-Flag und deployete alle 12 Änderungen in einem n8n_update_partial_workflow-Call. Im n8n-UI bedeutet diese Sequenz: Node erstellen, positionieren, 6+ Config-Felder ausfüllen, Verbindungsdrähte ziehen, viermal wiederholen, dann manuell verifizieren. Realistisch 20 Minuten sorgfältiges Klicken. Erledigt in einem API-Call, verifiziert in 3 Minuten.
Das war der teure Bug. Der nächste war billig und frustrierend.
Der Typ, den es nicht gab
Google Sheets gibt product_id: 32210 (eine Zahl) zurück, wenn eine Zelle Inhalt hat, aber product_id: "" (einen leeren String), wenn nicht. Der n8n IF-Node's exists-Operator lässt leere Strings stillschweigend durch, weil ein leerer String existiert. Er ist nur leer.
JavaScript-Type-Coercion schlägt wieder zu. Die Sprache, wo [] == false aber [] ? true : false true zurückgibt. Google Sheets hat es nur schlimmer gemacht.
Brauchte 4 Commits über die Session, um zu einem funktionierenden Filter zu konvergieren: erst scheiterte exists, dann würgte isNotEmpty an Zahlen, schließlich funktionierte gt 0 mit typeValidation: loose.
Der MCP-Execution-Inspector machte das diagnostizierbar. Er zeigte die exakte Datenstruktur, die aus jedem Node kam, was sofort das Mixed-Type-Problem offenbarte. Ohne programmatischen Zugang zu Ausführungsdaten hätte ich durch den n8n-UI-Execution-Inspector Node für Node geklickt und JSON-Output-Panels angestarrt. Trotzdem waren Claude Codes erste drei Versuche an der IF-Node-Config falsch. Das Mixed-Type-Verhalten von Google Sheets ist nirgendwo dokumentiert. Musste empirisch entdeckt werden. Vier Commits für einen Filter. Das ist das echte Tempo.
Beide Bugs hatten saubere Enden. Der dritte nicht.
Der Test, der keiner war
Nach dem Fix des Varianten-Update-Pfads musste ich auch den Simple-Product-Update-Pfad validieren. Problem: kein Simple Product existierte im aktuellen Google Sheet Dataset. Claude Codes Lösung war pragmatisch: das JavaScript des Code-Nodes lokal via node -e ausführen, dann einen manuellen PUT via curl auf ein bekanntes Produkt machen, um zu verifizieren, dass die XML-Transformation alle Felder erhält.
Das validiert die Regex- und XML-Logik. Es validiert NICHT die n8n-Expression-Referenzen, die Node-Verkettung oder das continueOnFail-Verhalten. Der Fix ging teilweise ungetestet in Produktion. Ich weiß es. Claude Code hat es markiert. Ein vollständiger End-to-End-Test würde erfordern, eine Simple-Product-Zeile in das Google Sheet zu injizieren, und das habe ich noch nicht gemacht.
Ich erzähle dir das, weil jeder andere Artikel über Claude Code + n8n dir den Happy Path zeigt. Der echte Pfad beinhaltet einen Fix, der live ging ohne ordentlichen Integrationstest und einen Code-Node, der bei der ersten Ausführung crashte, weil Claude Code seiner eigenen Skill-Dokumentation folgte (die Array-wrapped Returns empfahl), während n8ns Runtime-Validator im runOnceForEachItem-Modus Arrays ablehnt.
Das klügste Tool im Raum braucht immer noch eine fehlgeschlagene Ausführung, um die Regeln des Raums zu lernen.
Warum ich meinen eigenen KI-Agenten abgeschaltet habe
Der letzte Abschnitt könnte so klingen, als wäre ich negativ zur Combo eingestellt. Bin ich nicht. Ich bin negativ zur Version, wo jede Demo am Happy Path endet und niemand den Code-Node zeigt, der bei der ersten Ausführung crashte. Diese Lücke zwischen Demo und Produktion, wenn man sie weiterführt, ist genau das, was meinen Agenten getötet hat.
Ich baute OpenClaw, einen Multi-Model-KI-Agenten auf einem 5€-VPS. Kimi K2.5 als primäres Modell, MiniMax M2.5 als Fallback. Die ursprüngliche Version lief auf Claudes OAuth, das Anthropic killte und alle zu bezahlten API-Keys zwang. Da verschob sich die Ökonomie von "billiges Experiment" zu "echte Budget-Entscheidung."
Peter Steinberger argumentierte, man sollte Frontier-Modelle verwenden oder gar nichts. Er hat wahrscheinlich technisch recht, die meisten Probleme von OpenClaw kamen von Modellen, die nicht smart genug waren, um sich zuverlässig selbst zu aktualisieren und zu reparieren. Ein Frontier-Modell würde das wahrscheinlich lösen. Aber Steinberger ist kurz nach dieser Aussage zu OpenAI gewechselt, und Frontier-API-Preise für einen unüberwachten Agenten können 200€/Tag erreichen. Für den Rest von uns, die echte Workloads mit echten Budgets betreiben, macht es Recht haben nicht erschwinglich.
Ich deployete OpenClaw monatelang auf den billigeren Modellen. Dann schaltete ich ihn ab. Wie einen Roomba ausstöpseln, der immer wieder gegen dieselbe Wand fährt, aber mit API-Kosten.
Das Verhältnis war ehrlich und brutal: verbrauchte Token geteilt durch produzierten Wert war negativ. Der Agent verbrauchte ständig Zyklen damit, sich selbst zu aktualisieren, sein eigenes Tooling zu fixen, fehlgeschlagene Prozesse neu zu starten. Der Fix existiert: smartere Modelle. Das Preisschild nicht. Was der Space tatsächlich braucht, ist ein intelligentes CRON-System und echte Self-Tooling-Fähigkeiten, die funktionieren, ohne Frontier-Tier-Token zu verbrennen. Ich überlege, das selbst zu bauen. Aber das ist ein anderer Artikel.
Währenddessen laufen meine n8n-Workflows seit Monaten. Webhooks feuern. CRONs führen aus. Produkte aktualisieren sich. Bestände synchronisieren. Benachrichtigungen werden gesendet. Null Intervention. Null Token-Kosten jenseits des initialen Builds. Die Ausführungslogs sind auditierbar, das Error-Handling ist deterministisch, das Hosting ist stabil.
80% der Business-Automatisierung ist langweilig und niemand im "KI-Agenten werden alles ersetzen"-Lager will das hören. Es sind CRON-Jobs, die um 6 Uhr morgens feuern, Webhooks, die Stripe-Events abfangen, IF/ELSE-Branches, die Daten zum richtigen Endpoint routen. Du brauchst keinen Agenten, der darüber "nachdenkt". Du brauchst eine Pipeline, die zuverlässig ausführt und nichts kostet.
n8n macht das.
Claude Code + MCP macht das Bauen dramatisch schneller. Eigentlich, lass mich eine Zahl auf "dramatisch" setzen: das PrestaShop-Debug, das mich einen Nachmittag gekostet hätte, war in 15 Minuten erledigt. Mein Stack läuft auf einem Claude Max Abo und einer selbst-gehosteten n8n-Instanz auf einem 5€-VPS. Nicht billig, aber verglichen mit Frontier-API-Kosten für einen unüberwachten Agenten, der 24/7 läuft, ist es ein Rundungsfehler. Und diese Kombination deckt 90% der Use Cases ab, für die Leute denken, sie bräuchten autonome Agenten.
Agenten sind nicht nutzlos. Sie sind nur selten. Wenn du genuines dynamisches Reasoning brauchst, das nicht auf einen Entscheidungsbaum reduziert werden kann, das ist Agenten-Territorium. Alles andere ist ein Workflow mit Extra-Schritten und einer größeren Rechnung.
Ich baute den Agenten. Ich schrieb die Artikel. Ich zog den Stecker.
Das Framework: Wann was verwenden
Nachdem ich beide in Produktion betrieben und einen davon getötet habe, so entscheide ich.
n8n allein handhabt mehr, als du denkst. Stabile, repetitive Prozesse. Webhooks, geplante CRONs, Datensync zwischen zwei APIs, Notification-Pipelines. Wenn eine nicht-technische Person verstehen muss, was läuft. Wenn du Audit-Trails und Ausführungslogs brauchst. Wenn Uptime wichtiger ist als Flexibilität. Meine 5 SaaS-Produkte laufen auf n8n allein für etwa 80% ihrer Automatisierung.
Claude Code allein ist das richtige Tool, wenn Dinge sich nicht wiederholen. Schnelles Script, um einen Datensatz zu transformieren. Prototyp, den du nächste Woche wegwirfst. Custom Logic so spezifisch, dass sie in n8n zu verdrahten Overengineering wäre. Exploration-Modus, nicht Deployment-Modus.
Jetzt der interessante Teil. Wenn du dabei bist, 45 Minuten damit zu verbringen, Nodes im n8n-UI zu ziehen für einen Workflow, den du bereits im Kopf gemappt hast, stopp. Das ist Claude Code + n8n via MCP Territorium. Debugging komplexer Pipelines, wo du Ausführungsdaten mit externem API-State cross-referenzieren musst. Migration oder Refactoring bestehender Workflows. Auto-Dokumentation von einem Dutzend Workflows, die du monatelang nicht angefasst hast. Und zunehmend: echte Anwendungen mit n8n als Backend bauen, anstatt Airtable und Google Sheets zu etwas zusammenzukleben, das vorgibt, ein Interface zu sein. Ich habe noch kein vollständiges Frontend so ausgeliefert, aber die Architektur ist offensichtlich: Claude Code scaffoldet ein echtes UI, das mit n8n-Webhooks spricht. Ordentliche App mit ordentlichem Backend. Das steht als nächstes auf meiner Liste.
Und dann gibt es autonome KI-Agenten. Die richtige Wahl, wenn die Aufgabe Reasoning erfordert, das genuinly nicht auf IF/ELSE reduziert werden kann. Wenn der Input unvorhersagbar genug ist, dass du den Entscheidungsbaum nicht vor-mappen kannst. Wenn die Token-Kosten durch den Wert des Outputs gerechtfertigt sind. In meiner Erfahrung über 5 SaaS-Produkte deckt das vielleicht 10% der Automatisierungsaufgaben ab. Die anderen 90% sind Workflows in Agenten-Kostümen 💀 Ich sage das als jemand, der seinen Agenten im schicksten Kostüm angezogen hat. Er konnte trotzdem nicht tanzen.
Dieselbe Disziplin gilt hier wie überall: definiere den Vertrag, bevor du die KI ausführen lässt. Ob es ein Prompt-Contract für Claude Code oder eine Workflow-Spec für n8n ist, das Pattern ist identisch. Klarheit im Voraus, Ausführung danach.
Letzte Sache. czlonkowski maintained n8n-mcp gegen jedes neue n8n-Release. Open-Source, MIT-Lizenz, keine Paywall. Eine Person baute das Ding, das diesen ganzen Artikel möglich gemacht hat. Geh und starre das Repo. Das ist das Mindeste, was wir ihm schulden.
Das Repo: https://github.com/czlonkowski/n8n-mcp
Wenn das dich davor bewahrt hat, etwas neu zu bauen, das bereits funktioniert, oder einen Agenten zu kaufen, den du nicht brauchst, schreibe ich einen davon pro Woche. Workflow-Automatisierung, Claude Code in Produktion und das Zeug, das kaputtgeht, wenn Tutorials enden. Abonniere, wenn das für dich nützlich ist.
Das Cover-Bild? KI hat es gemacht. Ich erreichte meinen kreativen Höhepunkt bei CSS-Gradienten 2017 und meine künstlerische Laufbahn ist seitdem im verwalteten Niedergang.
Wie n8n und KI-Agenten die Workflow-Automatisierung komplett neu definieren — mit echten Produktionsbeispielen aus der Praxis.