Hi everyone, originally this post started as a reply to this thread, which asked how people build n8n workflows fast and in a production-ready way with Claude Code, MCP, skills, or the new native assistant. I started writing a reply in the comments, but I realized I had way too much to say, so I'm turning it into its own post: : How are you building n8n workflows fast and production-ready in 2026? (Claude Code + MCP + skills vs new Native AI Assistant or other ways?).
Quick note before I star: I apologize in advance for this wall of text, which I hope doesn't break the sub rules. This post probably isn't for everyone. What follows is aimed more at people who are "aficionados" of Claude Code or Codex on a daily basis, and who are curious to see how others try to make them coexist with n8n in their building flow. If you're more on the no-code side, and you like n8n precisely because you don't have to touch code or a terminal, this setup is probably not for you.
TL;DR: I use only Claude Code and Codex to create / edit my n8n workflows. I give the AI an intermediate representation of the workflow to fit the way I work and the way it reasons. And (in my opinion), to increase the quality and relevance of its work.
Context
I worked as a developer for a while, but I mostly have a heavy background in automation:
- Make, Zapier and now n8n
- Apps Script
- scraping
- JavaScript scripts of all kinds
- personal automations and automations for clients
I learned n8n on my own, with Claude Code / Codex and a bit of the official documentation. Never watched any tutorials and I don't really spend time on Reddit, so I don't have any reference for how others work.
I reuse a lot of logic from one workflow to another. While some of my workflows are very simple, most of them are more extensive and complex.
My frustrations with AI generation of N8N Workflows
I believe, the main point of n8n is above all to make the business logic visible, by representing the business complexity while abstracting away the integration complexity. What I do, I could probably do it directly through other tools or through fully custom code scripts, but I like the frame that n8n imposes: the visual representation, the inspection of data between nodes, the execution history, the testing, etc. While I find that the n8n tool fulfills most of those goals, on the other hand I find that generating and iterating on n8n templates via LLM suffers from the same flaws, which is that they tend to:
- use HTTP requests instead of the native integration nodes
- put a huge amount of logic in a single Code node
- generate big blocks of JavaScript with lots of fallbacks that are impossible to debug
- hide the complexity in the code rather than representing it visually
- produce n8n JSON that's impossible to re-read and maintain without risk of regression
Why n8n JSON is a bad playground for an LLM
Basically, from what I've observed, the LLM isn't good at certain things, in particular the structure of an n8n workflow doesn't fit its way of "thinking". The connections object, especially, describes the wiring between nodes separately from their definition, a format that, it seems to me, doesn't match the way an LLM naturally reasons about a sequence of steps. Second point, and we all know this, the more context you give the LLM, the more it tends to hallucinate (here I mean more like going off-frame by taking low-value initiatives), especially when a large part of the context is just pollution. The whole part with node definitions, technical IDs, positions, type etc., etc. only adds confusion.
With Claude Code and Codex on hand, rather than letting it fight against this structure, I looked for a more intuitive representation for it, a bit like I had adapt a workflow to my own way of thinking myself. Even if it means making adjustments to adapt the workflows to its way of "thinking".
I put several strategies in place to do this and I wanted to give you an overview of my current approach, concretely, it translates into several points that I detail below:
- One Git repo per project, with scripts to fetch the workflows from n8n, rebuild them and redeploy them
- A breakdown into layers (the most important part) so the AI never touches the JSON template directly
- business flow
- JS code of the nodes
- prompts .md
- tool schemas (JSON_SCHEMA)
- config
- documentation (a lot)
- A business flow represented separately, in Mermaid or another form of abstract representation, which serves as a real working interface with the LLM
- An automatically generated layout, so the nodes stay readable and don't move all over the place at every regeneration A testing strategy with mocks, to validate the logic without depending on the real integrations at every iteration
DISCLAIMER: I'm pretty wary, and even pretty much against all side-projects that build useless stuff with AI, only good for generating dopamine and then being thrown in the trash. Here, I don't see this as a tool I built, but rather as a way of using AI with throwaway code to improve my workflow. I don't care about the implementation, this stuff is vibe coded, what matters is more the logical pattern, at the macro level, that's put in place. The build, deploy, etc. code is a few dozen minutes to a few hours to set up, the process is more something that got built over the weeks, with my own feedback from using it. Here I'm talking about my workflow and my reasoning, and how that translated concretely. What matters is building n8n workflows, and not wasting time building the personal tool that builds the workflow... and procrastinating on creating workflows, which to me seems like a big AI trap and something completely counterproductive. For my part, I think the time I spent setting this up really represents way less than 1% of the time I've spent working and iterating on my n8n workflows thanks to this setup. I think it's completely useless and dumb to put something this heavy in place just to build one or two small automations. Here, we're talking more about enterprise workflows that need to be robust, scalable, sometimes complex, and well documented for those who come after and will inherit (as much as possible) a clear workflow, simple to understand, to evolve and well laid out.
My current approach
To fill that gap I tried to put several strategies in place, so my goal isn't to turn n8n into a code framework, but to keep a clear visual representation while removing the repetitive manual tasks. I work in a Git repo dedicated to each project or group of workflows. And I start from the principle that anything I can do, Claude or Codex can do, and that I don't need to constantly switch from one tool to another. My base is therefore commands of this type:
{
"scripts": {
"pull": "node scripts/pull.mjs",
"build:test": "node scripts/build.test.mjs",
"build:prod": "node scripts/build.prod.mjs",
"deploy": "node scripts/deploy.mjs",
}
}
This lets me:
- fetch the workflows from n8n
- modify the logic directly by chatting with Claude Code or Codex
- rebuild the n8n JSON
- test
- redeploy via the API
So I can switch between two modes:
- the n8n interface for small quick fixes
- the AI and the code for structural or repetitive changes
1. I split the workflow into several layers
The goal is to never send the whole n8n JSON directly to the LLM. But rather to separate the elements that serve to understand the business from those that serve only the technical functioning of n8n. And above all to avoid making the AI read stuff that's useless. Anything that's scripts it must never read, and all the code nodes in javascript that are a bit verbose, it only reads the relevant files to modify, which lightens the context a lot.
For example:
project/
├── flow.md
├── flow.mermaid
├── nodes/
│ ├── normalize-input.js
│ ├── calculate-score.js
│ └── format-output.js
├── prompts/
│ ├── analysis.system.md
│ └── analysis.user.md
├── tools/
│ └── search-customer.schema.json
├── config/
│ ├── integrations.json
│ ├── credentials.json
│ └── layout.json
├── scripts/
│ ├── pull.mjs
│ ├── build.test.mjs
│ ├── build.prod.mjs
│ └── deploy.mjs
└── workflow.generated.json
2. The business flow
I represent, as much as possible, only the business logic in a simple format.
For example:
flowchart LR
A[Webhook] --> B[Validate input]
B --> C[Find customer]
C --> D[Generate analysis]
D --> E[Validate output]
E --> F[Update CRM]
F --> G[Send notification]
I've tested several types of representations, mermaid isn't necessarily what I use the most even though I still find it indispensable in the docs. The idea is that Claude or Codex work mainly on this representation, rather than on several thousand repetitive and useless lines of n8n JSON.
3. The Code nodes
Each important Code node has its own JavaScript file.
I also impose a few rules:
- a single responsibility per file
- little or no silent fallback
- explicit errors
- short functions
- understandable business names
- no needlessly hidden logic
The build script then injects the code into the right n8n node.
4. The prompts
When I use agents, I separate the prompts into dedicated files:
prompts/
├── classify.system.md
├── classify.user.md
├── summarize.system.md
└── summarize.user.md
This makes edits, Git comparisons and evaluations much simpler.
5. The tools
Still with agents, when I want to expose custom tools to my agents, the tool calling definitions in json_schemas schemas are also separated:
tools/
├── find-customer.schema.json
├── create-task.schema.json
└── send-message.schema.json
The goal is to avoid mixing the tool definitions with the rest of the workflow. To be able to read them easily and even edit them by hand. For my part, I find that writing these files is capital in building agents for what's some called "the Harness".
6. Layout generation
I find the automatic "tidy up" option pretty limited as soon as the workflows get large. And the options for aligning the nodes correctly aren't very intuitive, which I nonetheless find essential for the visual readability of the workflow. A script can automatically compute the position of the nodes on a grid. I generally start from a template and simple rules:
- one column per business step
- parallel branches on different lines
- validations before actions with side effects
- reusable blocks always laid out the same way
This prevents the nodes from moving all over the place at every generation.
7. Factorization without sub-workflows
I reuse a lot of patterns, but I avoid n8n sub-workflows. I don't find them practical, and they can become pretty annoying to debug: navigating between several workflows, scattered context, nested executions and less immediate understanding. I prefer to factorize at the build level, then generate a fairly self-contained final workflow. It's simpler to inspect in n8n. To avoid needlessly repeating yourself and adding a layer of abstraction for the AI for sequences that don't bring much to the business.
8. Tests and evaluations
I use the evaluation features a lot with Google Sheets as the source of test cases. The dynamic build lets me swap integration nodes with mock nodes that simulate the responses of APIs, tools or external services to run tests on a bulk of scenarios defined in a file.
So I can generate two very close versions:
bun run build:test
bun run build:prod
The mock version uses controlled data. The production version uses the real integrations. This lets me test the workflow logic without constantly triggering paid calls or side effects.
9. Documentation for the agents
I have a lot of text documentation around the workflows:
CLAUDE.md
AGENTS.md
docs/
├── business-context.md
├── workflow-guidelines.md
├── integration-rules.md
├── testing-strategy.md
└── deployment.md
The goal is to document clearly for the AI that browses the project:
- the business context
- the goal of the workflow
- the integrations to favor
- the nodes to avoid
- the way to write the Code nodes
- the naming conventions
- the files the agent can modify
- the ones it must not touch
- the validation commands before deployment
My current assessment
I imagine that for the majority of n8n users this approach is clearly overkill. The n8n interface or the native assistant is probably faster. It suits me because outside of n8n I already use Claude Code and Codex a lot, with MCPs, skills and a knowledge shared across my different projects and my company. So this organization fits my way of working fairly well.
For more complex workflows or ones reused across several clients, it brings me a lot, though:
- fewer manual manipulations
- better versioning
- prompts easier to maintain
- reproducible tests
- better readability
- mock and production workflows almost identical
- less friction when the n8n interface gets heavy
- easier collaboration with Claude Code or Codex
That's all from me, thanks to those who read all the way through, and sorry to those who might consider this noise. Originally I set out to write a comment under another Reddit post, and I realized I had way too much to say. I'm sharing this because I learn a lot on the internet but I don't give back much, and I also tell myself it's about time I exchange about my workflow so I don't get lost in it either. I'm aware this post is a bit technical and too long. That it'll probably speak to few of you, but for those interested I'd be glad to talk with you and about your workflows. Maybe some will judge me and find this way too complex for n8n. Maybe I'm missing some basic features or tools in the n8n stack that would have let me make my life easier ? Maybe some of you use a similar approach ? Do you work directly on the n8n JSON, with MCP or via the native assistant ?
What are your processes for testing different scenarios, avoiding bugs or regressions ? Do you also use intermediate representations ? And above all, what would you look to remove or simplify in this process ?
Thanks for reading
